ES - RESUM PARCIAL 1 (2017)

Resumen Catalán
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 2º curso
Asignatura Enginyeria del Software
Año del apunte 2017
Páginas 22
Fecha de subida 02/08/2017
Descargas 0
Subido por

Descripción

Resum de tota la teoria d'Enginyeria del Software fins al 1r Parcial.

Vista previa del texto

ES - RESUM PARCIAL 1 TEMA 1 - PRINCIPIS D EL’ENGINYERIA DEL SOFTWARE 1. Definició i objectius de l’ES 1.1.
Definició de software Software: - Instruccions (Programes), al executar-se fan el que es desitja i com es desitja.
Estructures de dades, que permeten manipular la informació als programes.
Documentació, que descriu l’operació i utilització dels programes.
Sistema Informàtic: conjunt d’elements que duen a terme algun mètode, procediment o control a través del processament d’informació. Components: HW, SW, persones, documentació, procediments i dades.
 Productes genèrics -  Sistemes “stand‐alone” que es publiciten i venen a qualsevol client.
Exemples: software de PC com programes d’edició, gràfics, fotografia, gestió de projectes, CAD, mercats específics (gestió matrícules acadèmies ensenyament).
Productes a mida - SW desenvolupat per encàrrec d’un client específic per satisfer les seves necessitats.
Exemples: sistemes de control empotrats (embedded) com ara control en producció industrial, software de control de tràfic, software de gestió d’un banc.
1.2.
Evolució del HW/SW 1.3.
 Costos de SW -  𝐶𝑜𝑠𝑡𝑜𝑠 𝑆𝑊 > 𝐶𝑜𝑠𝑡𝑜𝑠 𝐻𝑊 𝐶𝑜𝑠𝑡𝑜𝑠 𝑀𝑎𝑛𝑡𝑒𝑛𝑖𝑚𝑒𝑛𝑡 > 𝐶𝑜𝑠𝑡𝑜𝑠 𝐷𝑒𝑠𝑛𝑒𝑣𝑜𝑙𝑢𝑝𝑎𝑚𝑒𝑛𝑡 (Per SW de llarga vida).
L’ES es preocupa del desenvolupament de software rendible i eficient en costos.
SW vs. HW - Es desenvolupa, no es fabrica. Costos SW centrats a l’enginyeria, no fabricació.
Manteniment complex, no hi ha peces de recanvi.
No es deteriora, però esdevé obsolet.
Més potència HW implica més complexitat SW.
1.4.
   Característiques de SW Crisi del SW SW - Fora de pressupost.
- Dates de lliurament incomplertes o sense entregar.
- Solució errònia o ineficient.
- Insatisfacció de requeriments.
- Complex de mantenir o gestió del canvi complexa.
Causes - Falta de metodologia, mals hàbits.
- Aplicació tècniques clàssiques fallida.
- Comunicació client-desenvolupador no efectiva.
- Prova de SW insuficient.
- Detecció d’errors tardana.
Solució  ES (1960) 1.5.
Enginyeria del Software ES: Aplicació d’un enfocament sistemàtic, disciplinat i quantificable per al desenvolupament, operació i manteniment del software. Objectiu: Desenvolupar SW de qualitat a menor cost possible.
- Satisfà a l’usuari // Funciona impecablement // Fàcil d’usar i mantenir.
Ciències Computació vs ES = Teoria i fonaments vs Pràctica i desenvolupament.
Eng. Sistemes vs ES = Desenvolupament SW, HW, processos vs. Desenvol. SW.
1.6.
 Objectius de l’ES Cost: senzill de calcular. Qualitat: depèn de factors com la següent mètrica mostra: o Operatius (utilització): – Correctesa: satisfà especificacions inicials.
– Exactitud: grau amb què compleix requeriments.
– Eficiència: temps, memòria, processament en la execució.
– Integritat: control d’accessibilitat per persones no autoritzades.
o Revisió (canvis): – Utilitzabilitat: esforç per aprendre i utilitzar el SW correctament.
– Mantenibilitat: esforç per detectar i corregir errors en SW instal·lat.
– Testabilitat: esforç per provar, assegurar que quelcom funciona bé.
– Flexibilitat: esforç per modificar un SW instal·lat.
o Transició (adaptació a nous entorns): – Portabilitat: esforç per traspassar SW d’un HW a un altre.
– Reutilitzabilitat: fins quin punt parts del SW es poden reutilitzar.
– Interoperabilitat: esforç per acoblar el sistema amb altres sistemes.
1.7.
         SW de sistemes. Programes escrits per servir a altres programes (compiladors, editors, gestors de comunicacions, etc.). Forta interacció amb el HW.
Apps SW. Programes “stand‐alone” per necessitats específiques.
SW de temps real. SW que mesura/analitza/controla esdeveniments del món real a mesura que esdevenen. Components: adquisició de dades, anàlisi, control/sortida, monitorització.
SW de gestió. Processament d’informació comercial.
SW d’enginyeria i científic. SW de càlcul numèric, biologia molecular, ...
SW empotrat. SW de només lectura que controla productes i sistemes dels mercats industrials i de consum (ordinador d’un cotxe, control d’un forn, etc.).
SW d'IA. Algorismes no numèrics per problemes per als quals no és adequat el càlcul o l’anàlisi directa. Visió, robòtica, jocs, reconeixement de parla, etc.
Web Apps. Aplicacions “en xarxa” basades en entorns web.
SW de línia de producte. Mercat particular en què s’adreça un volum massiu de consumidors (processadors de text, gràfics, gestors bases de dades).
1.8.
     Aplicacions del SW: Categories Aplicacions del SW: Noves Categories Computació distribuïda/ubiqua. Computació pervasiva, ubiqua, distribuïda deguda a xarxes wireless. Com permetre als dispositius mòbils, ordinadors personals, sistemes industrials comunicar‐se a través de xarxes.
Cloud Computing. SaS (software as a service). La web com una màquina de càlcul.
Big data. Processament de dades massives i detecció de patrons en elles.
Open Source. Software de codi obert “lliure” per a la comunitat.
Altres: Data mining, Grid computing, Cognitive Machines, Software per nanotecnologies 2. Procés, mètode i eina    Procés: Descriu quines activitats realitzar per obtenir SW de qualitat. Defineix un marc de treball per a un conjunt d’àrees que s’han d’establir per a l’entrega efectiva de la tecnologia de l’ES. És el context en què s’apliquen els mètodes tècnics, es produeixen els resultats del treball (models, documents, dades, etc.), s'estableixen fites, s’assegura la qualitat i el canvi es gestiona adequadament.
Mètode: Indica com s’han de dur a terme les activitat del procés i com construir tècnicament el SW. Ofereixen tècniques de modelatge per a les diferents etapes.
Eina: Proporciona suport automàtic o semiautomàtic a procés i mètodes (CASE: Computer Aided Software Engineering).
3. Paradigmes del desenvolupament del SW 3.1.
    Fases en el procés de desenvolupament de SW Anàlisi de requeriments - Comprensió del problema. Especificació de requeriments.
Disseny - Disseny preliminar (detecció de components o mòduls).
- Disseny detallat (lògica interna de cada mòdul).
Codificació Prova - Proves d’unitat, d’integració, de sistema, d’acceptació.
- Caixa blanca i caixa negra.
3.2.
Paradigmes del procés de desenvolupament del SW  Model lineal seqüencial (cicle de vida clàssic o salt d’aigua) Enginyeria i anàlisi de sistemes (anàlisi de viabilitat), anàlisi de requeriments, disseny, codificació, prova i manteniment.
 Model de construcció de prototipus  Model de desenvolupament ràpid d’aplicacions (DRA) Construcció basada en components. És un model lineal seqüencial però amb un temps extremadament curt. Utilitza eines CASE.
 Model evolutiu Té en compte el caire evolutiu del software (és un model iteratiu que permet desenvolupar versions cada vegada més completes).
- Model incremental.
- Model en espiral.
- Model d’assemblatge de components.
Partint d’una llibreria de classes inicial, es combinen les que són útils i se n’implementen de noves que s’afegeixen a la llibreria.
- Model de desenvolupament concurrent.
Modelitza les etapes del procés d’ES com a conjunt d’estats i transicions entre ells.
- Model de mètodes formals.
Permet una especificació matemàtica del software.
3.2.1. Model Lineal-Seqüencial (Cicle de vida clàssic) Avantatges: - Inici‐Final de cada etapa definit → Progrés del projecte mesurable.
- Promou una documentació detallada.
- Acord signat dels requeriments del sistema.
Inconvenients: - Un projecte real mai no és tan marcadament seqüencial. Cal contemplar la possibilitat de tornar a estadis anteriors de desenvolupament.
- Dificultat d’establir explícitament tots els requisits al principi del projecte. El client pot no tenir‐los clars o poden canviar en el decurs del procés.
- El client s’ha d’esperar a veure el resultat al final. Tota la planificació s’orienta a un únic dia de lliurament.
- No permet un desenvolupament per etapes. A vegades seria millor fer una part del sistema i després, millorar‐lo i completar‐lo, però això no es pot fer si tots els requeriments s’han de conèixer a priori.
3.2.2. Model de construcció de prototipus     Per millorar els tres primers inconvenients del cicle de vida clàssic.
Es desenvolupa a partir d’un conjunt de requeriments coneguts (objectius generals): recollida d’objectius globals, disseny ràpid, construcció del prototipus, test del prototipus.
Formes: o En amplada: totes les funcions per limitades o amb algorismes ineficients.
o En profunditat: un subconjunt del producte final, funcions problemàtiques.
Inconvenients o El client ho veu com SW definitiu.
o Prototipus fet amb recursos inadequats.
El desenvolupador no ha de “deixar-se dur” per la comoditat.
3.2.3. Model evolutiu      Intenta solucionar les quatre limitacions del model del salt d’aigua, intentant combinar els beneficis del prototipatge i del cicle de vida clàssic.
El SW es fa per increments i cada increment afegeix una nova funcionalitat al sistema, a més de fer les extensions del disseny necessàries.
Cada increment es prova  Detecció de problemes/errors més precoç.
Llista de control del projecte (tasques ordenades que ha d’incorporar la implementació final). A cada pas es treu una tasca de la llista, es dissenya i s’implementa la solució i s’analitza el sistema obtingut a fi d’actualitzar la llista.
 Fase de disseny, fase d’implementació i fase d’anàlisi.
Molt feedback amb el client (amb els inconvenients que això pot implicar).
Limitacions: o El manteniment deixa de ser una etapa com a tal i es fa al llarg de tot el procés. Com es quantifiquen les modificacions demanades pel client? o Dificultat en marcar la fi de la inclusió de requeriments a la llista de control per part del client.
3.2.3.1.
Evolutiu: Visió Incremental 3.2.3.2.
Evolutiu: Visió en espiral - Afegeix una etapa d’avaluació del risc (circumstàncies potencialment adverses que poden perjudicar el procés de desenvolupament i la qualitat del producte).
Es desenvolupen cíclicament 6 etapes: comunicació amb el client, planificació, anàlisi del risc, enginyeria (disseny), construcció, i avaluació del client.
A cada cicle s’aconsegueix una versió més sofisticada del producte.
L’espiral pot mantenir‐se operativa sempre.
Processos de desenvolupament incremental de SW: TEMA 2 – SCRUM 1. Introducció: Agile Project Management Els mètodes clàssics lineal-seqüencial tenen bastants inconvenients: - La fase de planificació requereix un gran esforç.
- En entorns ràpidament variables, la conversió de requeriments es fa difícil.
- Tecnologies canviants  Requeriments canvien Els paradigmes actuals recomanen mètodes evolutius  Desenvolupament Àgil de SW  Manifest del Desenvolupament àgil de software: o o o o  Individus i interaccions per sobre de processos i eines.
SW funcional i intuïtiu per sobre d’extensa documentació.
Col·laboració amb el client per sobre de la negociació de contracte.
Resposta al canvi per sobre del seguiment de la planificació.
Qualitats dels mètodes àgils: o Minimització del risc  Iteracions curtes.
o Comunicació en temps real (i cara a cara)  Poca documentació escrita.
o Indicat per requeriments impredictibles i que canvien ràpidament.
2. Scrum         “Scrum”: aglomeració, ve del rugbi.
Entorn àgil de desenvolupament i manteniment de productes complexos o Permet abordar problemes d’adaptació complexos, lliurar productes amb el màxim valor i en el menor període de temps Procés iteratiu, incremental o Permet desenvolupar productes on els requeriments canvien ràpidament Basat en el treball d’equip  Equip auto-organitzat o Millora la comunicació i maximitza la cooperació o Maximitza la productivitat o Protegeix l’equip d’interrupcions per impediments/dificultats Controla el caos pels conflictes d'interès i necessitats Es basa en un control empíric de processos o El coneixement ve de l’experiència Scrum utilitza un enfoc iteratiu i incremental per optimitzar la predictibilitat i control de risc Fonaments: o Transparència: El procés ha de ser visible a tothom, així es comparteix una mateixa comprensió del producte i dels “fets” o Inspecció: S’han d’inspeccionar els artefactes i el progrés cap al objectiu o Adaptació: Si es detecta que un procés es desvia del límits acceptables, s’ha de reajustar el procés immediatament.
    Scrum no és un procés o tècnica, és un entorn on es poden emprar diferents processos i tècniques.
Components: o Rols (persones) o Artefactes (eines de control) o Processos: reunions (Sprints) Les regles de Scrum regeixen les relacions i interaccions entre els components de Scrum Scrum és lleuger i fàcil d’entendre, però molt difícil de dominar.
2.1.
      Product Backlog: Llista de requeriments es guarden com a elements (ítems).
o La llista d’elements es prioritza i s’estima el seu esforç (durada).
o Els elements s’anomenen user stories (històries d’usuari).
Sprint: Es progressa en una sèrie de petits increments de temps fixe (<1 mes).
Sprint Backlog: Es seleccionen les funcionalitats a implementar.
Daily Scrum Meeting: Es fa una reunió curta (15min) diària.
El producte es dissenya, codifica i testeja durant el Sprint.
No es fan canvis durant l’ Sprint.
2.2.
   Característiques de Scrum Història Scrum 1995 o o o o 1996 o S’analitzen els processos comuns de desenvolupament de software.
Nn són adequats per processos empírics, impredictibles i no-repetitius.
Jeff Sutherland i Ken Schwaber dissenyen un nou mètode: Scrum.
Mike Beedle millora Scrum.
Presentació de Scrum en la conferència OOPSLA (Object-Oriented Programming Systems, Languages, and Applications).
2001 o Publicació del llibre “Agile Software Development with Scrum” - Ken Schwaber i Mike Beedle.
o S’aplica Scrum amb èxit a més de 50 empreses.
o Els fundadors es fan membres de l’aliança àgil de desenvolupament.
3. Components de Scrum  Rols o Product Owner o Scrum Master o Scrum Team (Equip de Desenvolupament) o Altres: Stakeholders (parts interessades: Usuaris, Direcció) 3.1.
     Artefactes (Elements) o Product Backlog (llista de requeriments) o Sprint Backlog (requeriments seleccionats per al Sprint) o Burn-up/down (gràfiques de progrés) Processos o Sprint Planning Meeting (Planificació del Sprint) o Sprint (Increment o iteració) o Daily Scrum (Seguiment del Sprint) o Sprint Review Meeting (Revisió del Sprint) Rols Product Owner: Client o Actua com a una única veu.
o Té la visió del producte.
o Responsable dels requeriments: decideix el Product Backlog.
o Canvia i re-prioritza el Product Backlog abans de cada Sprint.
o Accepta el SW.
Scrum Master: Responsable del procés o Facilita les reunions, monitora el progrés.
o Ajuda a l’equip: elimina els obstacles i assegura la productivitat aïllant-los de distraccions.
o Interfície entre Product Owner i Scrum Team.
o Interactua amb la resta de l’organització.
Scrum Team: Equip de desenvolupament o 5-8 membres.
o Desenvolupa el producte.
o Equip autònom.
o Responsables dels compromisos.
o Multifuncional: cada membre té unes experteses.
o Auto-organitzat: no hi ha rols, la feina es reparteix d’acord a la feina a fer en el Sprint i les habilitats de cadascú.
3.2.
   Artefactes Product Backlog: Llista de requeriments per tot el procés (Brainstorming) o Aproximació  no exacte, pot anar canviant.
o Es prioritzen els requeriments.
o Pertany al Product Owner  Encarregat de la gestió o Estimació dels elements del Product-Backlog: s’estima la velocitat de desenvolupament de l’equip i el seu esforç (T-shirt size): hores/dies.
Sprint Backlog: Llista de requeriments d’un Sprint o Si una tasca és molt llarga, s’ha de subdividir.
o No hauria de contenir més de 300 tasques.
o Es crea només per el Scrum Team: només l’equip pot afegir/treure elements.
o Els elements tenen 3 dimensions:  Prioritat: de menor a major.
 Detall: desglossament de tasques.
 Estat: Pendent, en progrés, parades, fetes. S’ha d’actualitzar a diari.
Burn-up/down: Gràfiques de progrés o Burn-up: representen la velocitat.
o Burn-down: representen la feina feta. Mostra hores de treball restants i temps estimat per acabar el Sprint: hauria de ser 0 al finalitzar. No sol ser línia recta. Si hi ha imprevistos  temps restant pot pujar! 3.3.
  Processos Project Kick-off Meeting: o Reunió abans que comenci el projecte.
o Es crea el Product Backlog.
Sprint Planning Meeting: o Participants: Product Owner, Scrum Master, Scrum Team.
o Dura aproximadament 8 hores i consta de dues parts.
o Es defineixen els requeriments, prioritats i el tauler i duració de tasques.
o Es defineixen les tasques a fer a cada Sprint.
o 1a Part: es crea el Product Backlog, es determina el Sprint Goal; hi participen Product Owner, Scrum Master, Scrum Team.
o 2a Part: es crea Sprint Backlog; hi participen: Scrum Master, Scrum Team.
o Planificació de tasques: votació, pedra-paper-tisora, poker:  Planning Poker: - El Product Owner explica la user story.
- Cada membre escull una carta en secret (nº Fibonacci).
- Tots alhora mostren les cartes.
- Si hi ha disparitat, es discuteixen els punts de vista.
- Tornar a escollir carta fins consens.
- Cartes Especials:     Sprint: o Iteració o increment, de menys d’un mes de durada, on s’incrementa la funcionalitat del producte.
o Cap influència externa pot interferir a el Scrum Team durant el Sprint.
o Cada Sprint comença amb el Daily Scrum Meeting.
Daily Scrum: Reunió al principi del dia (màxim 15min).
o Cada membre contesta 3 preguntes:  Què s’ha fet?  Quins obstacles s’ha trobat?  Què es farà avui? o Això permet al Scrum Master monitoritzar el progrés, i en cas de problemes:  Planejar treball no identificat en dies anteriors.
 Re-assignar tasques. Eliminar problemes.
 Tothom està convidat  Evita altres reunions innecessàries.
 Només Product Owner, Scrum Master, Scrum Team parlen.
 NO serveix per resoldre problemes ni saber qui fa la feina a temps.
 És una reunió on els membres de l’equip prenen compromisos.
Sprint Review Meeting: o Revisió del Sprint  Objectius assolits?  L’equip presenta el que s’ha aconseguit fer durant el Sprint.
 Se solen mostrar al Product Owner les noves funcionalitats.
o Es defineix el següent Sprint.
o La feina no feta passa al Product Backlog.
o Es decideix si fer un Product Increment o un delivery.
o Informal, es prepara en menys de 2h.
o Participants: Clients, Managers, Product Owner, Altres enginyers.
Sprint Retrospective Meeting: o Resum del Sprint.
o Només participa el Scrum Team.
o Es comprova la velocitat estimada i la real  Burn-down o Retroalimentació (feedback Meeting): què s’ha fet bé? Què s’hauria de millorar o què s’ha millorat? o 3 preguntes: Start – Stop – Continue.
4. Escalabilitat   Es recomanen equips de treball petits (6-10 persones).
“Scrum of scrums” o Experts en Scrum son capaços de dirigir grups de 800 persones.
o Diferents equips de desenvolupament treballem junts.
o La freqüència de les reunions es basa en el grau d’acoblament entre grups de tasques.
5. Eines SW   Open Source: Kunagi, ScrumDo, SprintoMeter, IceScrum, ...
Comercials: JIRA Agile, Eylean, OnTime, ...
6. Scrum: Resum –Procés àgil que permet centrar-se en el lliurament de productes d’alt valor en el menor temps –Permet inspeccionar els progressos del producte de forma ràpida i repetida (Sprint/increment) –Minimització de riscos –Desenvolupament iteratiu i incremental (Sprint) –Es re-planifica a cada increment i s’estableixen les prioritats –Al acabar cada Sprint, es mostra el resultat (demostració del projecte) i es decideix si donar-lo per bo o continuar millorant-lo en un altre Sprint.
–L’equip s’auto-gestiona per determinar la millor manera de lliurar els requisits amb major prioritat.
–Treball en equip, comunicació diària.
TEMA 3 – ANÀLISI DE REQUERIMENTS DEL SW 1. Introducció    Incrementa complexitat dels problemes  Necessitat d’anàlisi de requeriments Dues tasques: Comprensió del problema i Especificació de requeriments.
Requeriments: Conjunt d’idees que el client té sobre què ha de ser el SW a desenvolupar. Són les prestacions del sistema.
1.1.
Tipus de requeriments 1.1.1. Requeriments Funcionals (RF)    Descripció del comportament desitjat del SW.
Cada requeriment funcional expressa una relació entre les entrades i sortides del sistema, és a dir, especifica les sortides que s’han de produir a partir d’unes determinades entrades si les operacions necessàries per aconseguir això.
També han d’especificar com s’ha de comportar el sistema davant de situacions anormals (entrades invàlides, errors, etc.).
1.1.2. Requeriments No Funcionals (RNF)   Restriccions imposades pel client o pel mateix problema i que afecten al disseny.
Normalment són quantificables.
 RNF: De rendiment. Especifiquen restriccions de rendiment del sistema.
o Requeriments estàtics (de capacitat). Restriccions sobre les característiques d’execució (nombre de terminals, usuaris simultanis, etc.).
o Requeriments dinàmics. Restriccions sobre el comportament d’execució del sistema (temps de resposta, throughput, etc..).
 RNF: Restriccions de disseny. Factors presents en l’entorn del client que restringeixen les opcions del dissenyador.
o Acompliment dels estàndards. Format dels informes, procediments d’assignació de comptes, auditories, etc.
o Limitacions hardware. Disponibilitat de recursos: tipus de màquina, S.O., llenguatge, capacitat d’emmagatzematge.
o Recuperació i fiabilitat davant errors. Pot fer el sistema més complex i car.
o Seguretat. Utilització de certes comandes, control d’accés a les dades, condicions d’accés per a diferents perfils d’usuari, etc.
 RNF: Interfícies Externes/Objectius/Decisions de disseny o Requeriments sobre les interfícies externes (RIE): Característiques de la interacció amb gent, HW i altres mòduls de SW.
o Objectius de disseny (OD) o requeriments de qualitat: Restriccions que incideixen en determinats aspectes de la qualitat final del SW (fàcil d’utilitzar, de mantenir, ampliable).
o Decisions de disseny: Són detalls d’implementació (Ex. Persones s’indexen per NIU; l’algorisme d’ordenació serà Quicksort, etc.).
o RIE són més precisos que OD: - OD: el sistema hauria de ser user friendly.
- RIE: La interacció es farà mitjançant menús desplegables i comandes no més llargues de 6 caràcters.
1.2.
Classificació de requeriments 2. Comprensió del problema. Captura de requeriments 2.1.
      Tècniques de comunicació Entrevistes o Tècnica de recollida de requeriments més utilitzada.
o Pràcticament inevitables.
o Fer entrevistes no és trivial  Tècniques d’entrevista.
Qüestionaris o Útils per recollir informació d’un gran número de persones en poc temps.
o Adequats en situacions en les que es dona una gran dispersió geogràfica.
Estudi de Documentació o Manuals sistemes previs.
o Plans estratègics.
o Normatives.
o Estudies de mercat.
o Etc.
Observació in situ o Estudi en viu del mode d’operació de l’empresa.
o Viure el problema des del punt de vista dels usuaris, no dels seus managers.
o El funcionament real de l’empresa no sempre coincideix les normes oficials.
Prototipatge o Construcció d’un model o maqueta del sistema que permet als usuaris avaluar millor les seves necessitats.
o El prototipus pot prendre la forma d’un: - Esquema en paper, descrivint la interacció home-màquina.
- Executable:  En amplada: totes les funcions però limitades o amb algorismes ineficients.
 En profunditat: un subconjunt del producte final, funcions problemàtiques.
o Inconvenients: - El client ho veu com SW definitiu.
- Prototipus s’ha de fer ràpid, i es fa amb recursos inadequats.
 El desenvolupador no ha de deixar-se dur per la comoditat i reaprofitar-lo.
Brainstorming o Es fomenta en la següent creença: una mala idea és millor que cap.
o Adequat especialment per la definició de nous productes  Creativitat.
o L’objectiu és la generació d’idees en un ambient lliure de crítiques i judicis.
Té diferents fases: 1. Preparació - Selecció dels participants i líder de la sessió (Stakeholders).
2. Generació - El líder proposa una llavor o enunciat general a tractar.
- Els participants aporten lliurement idees noves.
- El procés finalitza quan el líder valora que jo no es proposen noves idees, o bé se n’han recollit ja moltes.
- Regles: prohibit criticar idees, fomentar idees més avançades, buscar el major nombre d’idees possible, animar als participants a combinar o completar idees d’altres.
3. Consolidació - Revisar idees: clarificar-les, unificar-les en un sol enunciat.
- Descartar idees: aquelles que es consideren avançades en excés.
- Prioritzar idees: idees essencials, bones idees però no essencials i idees possiblement apropiades per una propera versió del sistema.
4. Documentació - El líder genera un document indicant les idees prioritzades, i els comentaris generats durant la fase de consolidació.
 Casos d´Ús o Especificació de requeriments que forma part de UML.
o La idea es especificar un sistema a partir de la seva interacció amb l’ambient.
o Promou la descripció dle sistema des del punt de vista de qui l’utilitzarà, en lloc del punt de vista de qui l’ha de desenvolupar.
o Un diagrama de casos d’ús és la descripció d’un seguit d’interaccions entre el sistema i un o més actors, en la que es considera el sistema com una caixa negra.
 Desenvolupament Conjunt d’Apps (JDA: Join Application Development) o Conjunt de reunions en grup durant un període de 2 a 4 dies (Stakeholders).
o Avantatge respecte les entrevistes individuals: - Estalvia temps a l’evitar que les opinions dels clients es contrastin per separat.
- Tot el grup, incloent els clients i futurs usuaris, revisa la documentació generada, no només els enginyers de requeriments.
- Els clients i usuaris estan més implicats en el desenvolupament.
o No s’aplica massa per les necessitats d’organització requerides i el problema d’ajust d’horaris.
2.2.
      Problemes associats Incompletesa. No saber a qui demanar informació per comprendre el problema.
Inconsistència. La informació donada pel client no lliga amb d’altres persones.
La funció i el rendiment poden entrar en conflicte amb altre restriccions imposades per altres elements del sistema.
La percepció dels objectius del sistema canvia en el temps.
A mesura que creix la mida del problema, creix la complexitat d’anàlisi.
El client acostuma a no valorar l’etapa d’anàlisi.
2.3.
Característiques dels mètodes de modelat (Principis d’anàlisi) Cada mètode d’anàlisi té una notació i un punt de vista propi. Tanmateix, hi ha uns principis que totes les eines de modelat associades a aquests mètodes haurien de complir:  Partició Un sistema complex només es pot entendre si s’estructura en parts interrelacionades. Les eines que utilitzem han de ser capaces de descriure un problema a partir de les seves parts.
 Abstracció S’ha de ser capaç de definir una entitat o problema en termes generals. Treureli tots els detalls (referenciant-los apart) simplificant-ne la comprensió. Les eines utilitzades han de permetre trobar els detalls de manera progressiva.
 Projecció Permet definir el sistema des de diferents punts de vista (projeccions). Per exemple, operari, administratiu, directiu, etc. La combinació de punts de vista n’assegura la comprensió completa.
3. Especificació de requeriments    El resultat de l’anàlisi és el document d’especificació de requeriments.
Objectius del document d’especificació de requeriments (SRS: Software Requeriments Specification).
Fa una doble funció: Contracte i Base de treball (referència) del dissenyador.
3.1.
Propietats desitjables d’una especificació  Especifica el comportament extern, no la implementació.
  Correcta: cada requeriment indicat és aquell que el SW realment ha de complir.
No ambigua: cada requeriment indicat té un única interpretació possible.
      Completa: Si i només si inclou: o Tots els requeriments relatius a funcionalitat, rendiment, interfícies externes, atributs i restriccions de disseny.
o Defineix les respostes del SW a tot tipus de dades d’entrada possibles, i en tota classe de situacions conflictives.
o Defineix tots els termes interpretables i les unitats de mesura emprades.
Consistent: Si cap subconjunt dels requeriments indicats tenen inconsistència: o En les característiques d’un mateix element (ex. Format).
o Lògica o temporal entre 2 processos (ex. Seqüència vs. Concurrència).
o En els termes emprats (ex. Ús de varis termes per un mateix element).
Ordenada: Per mostrar la importància i/o estabilitat de cada requeriment.
o Importància: essencials (imprescindibles) vs. Desitjables.
o Estabilitat: en funció de la quantitat de canvis esperats en el requeriment.
Verificable: Si els requeriments indicats són verificables.
o Existeix un procés finit i de cost assumible que permet a una persona o màquina certificar que el SW acompleix els requeriments.
o En general, cap requeriment ambigu és verificable.
o Si no es pot definir cap mètode per verificar un requeriment, s’ha de revisar o eliminar.
Modificable: L’estructura i estil del document ha de permetre realitzar canvis en els requeriments fàcilment, de manera completa i consistent.
o És molt important no ser redundant (un mateix requeriment no ha d’aparèixer en més d’un apartat de la SRS). Dificulta les actualitzacions i porta a inconsistències.
Seguible: en dos sentits: o Cap enrere: l’origen de cada requeriment és clar.
o Cap endavant: a cada requeriment s’associarà un únic nom o nombre de referència, de manera que els documents que es generin a partir de la SRS els puguin referenciar unívocament.
3.2.
Revisió i validació de l’especificació Una reunió d’experts que intenten valorar la qualitat del producte (especificació). Dos nivells:  Macroscòpic: comprovar si l’especificació és completa, consistent i precisa.
 Detallat: precisar termes concrets.
3.3.
Estàndard d’especificació de requeriments ANSI/IEEE TEMA 4 – DISSENY DEL SOFTWARE 1. Introducció   Definició. El procés d’aplicar diferents tècniques i principis amb el propòsit de definir un dispositiu, un procés o un sistema amb suficients nivells de detall com per permetre la seva realització física. Està situat en el nucli tècnic del procés d’ES i s’aplica independentment del paradigma de desenvolupament utilitzat.
Domini del Problema  Domini de la Solució Objectiu. Produir un model o representació del sistema que pugui ser utilitzat, en una fase posterior, a fi d’implementar‐lo.
1.1.
  Disseny preliminar: centrat en la transformació dels requeriments de les dades i en l’arquitectura del software (estructura modular).
Disseny detallat: conceptes més específics, refinament de l’estructura de dades i representació algorísmica dels mòduls.
1.2.
        Disseny de Dades, Arquitectònic, Procedimental i d’Interfície Dades. Transforma el model de dades de l’anàlisi (diccionari, en l’estructurat o els atributs, en l’OO), en les estructures de dades que després s’implementaran.
Arquitectònic. Defineix la relació entre els principals elements estructurals del programa. Es desenvolupa una estructura modular i jeràrquica del software.
Procedimental. Transforma els elements estructurals de l’arquitectura del programa en una descripció procedimental dels elements del software.
Descripció de les funcions a un nivell més proper al LP que el nivell de les EP. de l’anàlisi.
Interfície. Descriu com es comunica el software amb ell mateix, amb els sistemes que operen amb ell i amb els operadors que l’utilitzen.
1.3.
  Procés de disseny Principis (objectius) del disseny Verificabilitat. Poder avaluar la correctesa del disseny.
Completesa. Totes les components (estructures de dades, mòduls, interfícies externes, etc.) han de ser especificades.
Consistència. Que no hi hagi inconsistències inherents.
Eficiència. Utilització adequada dels recursos del sistema. Recursos no infinits.
Seguible. Tots els elements del disseny han de poder‐se mapejar cap a l’anàlisi de requeriments.
Simplicitat/Comprensible. Cal tenir en compte que el document de disseny, igual com era el d’especificació de requeriments serà utilitzat com a base per a les etapes posteriors.
          El procés de disseny no ha de ser únic, s’han d’avaluar alternatives.
Cada element del model de disseny s’ha de poder seguir enrere fins a l’anàlisi per saber els requeriments que satisfà.
El disseny no ha d’inventar res de nou. Reutilitzar al màxim.
Minimitzar la distància entre domini del problema i domini de la solució.
Ha de ser uniforme (un estil constant).
Ha d’estructurar‐se per admetre canvis.
Ha de ser robust. Acceptar circumstàncies inusuals.
El disseny no és escriure codi i escriure codi no és dissenyar.
La qualitat del disseny s’avalua mentre es fa, no després.
Cal revisar‐lo per evitar errors conceptuals (semàntics): omissions, ambigüitats, inconsistències.
2. Conceptes del disseny          Abstracció.
Modularitat.
Refinament.
Arquitectura del software. Estructura global del software i la manera com aquesta estructura proporciona integritat conceptual a un sistema.
Jerarquia de control. Estructura de programa.
Partició estructural. L’estructura de programa es pot partir horitzontalment o verticalment.
Estructura de dades. Relació lògica entre els elements individuals de dades.
Procediment del software. Detalls de processament de cada mòdul individualment.
Ocultació de la informació. Els mòduls s’han de dissenyar de manera que la informació (dades i processos) sigui inaccessible per altres mòduls que no la necessitin.
2.1.
Abstracció Permet definir components de manera abstracta a diferents nivells, sense preocupar nos dels seus detalls d’implementació. Una abstracció descriu el comportament extern de la component, sense haver de parar atenció als detalls interns que produeixen el comportament.
L’abstracció és un a la modularització ja que permet veure el ajut comportament extern dels mòduls a fi de connectar-los.
   Abstracció Funcional. Abstracció d’una component des del punt de vista de la funció que realitza. Una seqüència d’instruccions que té una funció específica i limitada. Exemple: porta => obrir, tancar.
Abstracció de dades. Col·lecció de dades que descriuen un objecte de dades.
Exemple: porta => tipus, pes, dimensions, direcció d’obertura, etc.
Abstracció de control. Implica un mecanisme de control del programa sense especificar detalls interns. Exemple: porta => si es prem el botó d’obrir llavors...
2.2.
     Modularitat Aplicar el principi de divide & conquer al disseny de software.
Mòdul. És la unitat bàsica d’un programa, és finita i identificable respecte a la compilació i la lectura. És lògicament separable. Pot ser una macro, una funció, un conjunt de dades i funcions associades, un tipus abstracte de dades, etc.
Mida recomanable d’un mòdul: o 𝐶(𝑝): grau de complexitat d’un problema p.
o 𝐸(𝑝): esforç per programar un solució a p.
o 𝐶(𝑝1 ) > 𝐶(𝑝2 ) → 𝐸(𝑝1 ) > 𝐸(𝑝2 ) o 𝐶(𝑝1 + 𝑝2 ) > 𝐶(𝑝1 ) + 𝐶(𝑝2 ) → 𝐸(𝑝1 + 𝑝2 ) > 𝐸(𝑝1 ) + 𝐸(𝑝2 ) Un programa no es pot dividir infinitament.
Dividir implica augmentar la interdependència entre mòduls: o Augmenta el cost associat a crear les interfícies.
o Costa més detectar l’origen dels errors i corregir-los.
2.3.
Refinament Dues estratègies per dissenyar una jerarquia de mòduls (arquitectura del software):  Top‐down. Refinaments successius. Es comença per un nivell més abstracte i a cada pas obtenim noves components que ofereixen una visió més concreta.
 Bottom‐up. Es comença des de les components de més baix nivell de la jerarquia i de manera progressiva establim les components de nivell més alt.
 Estratègia mixta. Es comença des dels dos extrems de la jerarquia fins trobar-se.
3. Disseny modular efectiu 3.1.
Independència Funcional Un sistema es considera modular si està format per una sèrie de components de manera que cadascuna proporcioni una bona definició d’abstracció, i que un canvi introduït sobre una component tingui un impacte mínim sobre la resta.
La modularitat efectiva s’aconsegueix amb independència funcional, que vol dir mòduls amb una funció única i poca interacció entre ells.
3.2.
Cohesió Cada mòdul té una funció única. És l’extensió del principi de la ocultació.
       Coincidental. Tasques poc relacionades. (Ex: Partir un programa arbitràriament en mòduls cada x línies).
Lògica. Tasques relacionades lògicament. (Ex: mòdul amb totes les funcions d’entrada/sortida).
Temporal. Taques que s’han d’executar durant el mateix període de temps.
(Ex: alliberar memòria, tancar fitxers, etc).
Procedimental. Partició a partir del diagrama de flux, és a dir, elements relacionats que s’executen en un ordre específic.
Comunicacional. Tasques que operen sobre les mateixes dades.
Seqüencial. Les dades resultat de cada element de processament del mòdul són l’entrada del següent element.
Funcional. Tots els elements del mòdul es relacionen per realitzar una única funció.
3.3.
Acoblament És una mesura de la interdependència entre mòduls.
     Dades. Dos mòduls es comuniquen amb paràmetres on cadascun és una dada simple o bé un conjunt de dades homogènies.
Marca (per registre). Un mòdul passa a un altre un registre o estructura de dades amb no homogènia (amb diferents camps). Cal una comprovació de les estructures de dades. Per alta banda, cal evitar passar registres amb molts camps dels quals només se n’utilitza algun.
Control. Un mòdul passa un paràmetre a un altre amb intenció de controlar el seu comportament. És més acceptable que el mòdul inferior doni un control al superior (per exemple, notificació d’error).
Comú. Diversos mòduls accedeixen a la mateixa àrea global de dades.
o Qualsevol error en un mòdul pot afectar a un altre via dades globals.
o Difícil seguir el programa pel que fa a qui modifica les dades globals.
o Manteniment difícil si es canvia l’estructura de dades global (molts mòduls hi accedeixen).
o Si hi ha moltes dades globals, és difícil establir quines dades utilitza cada mòdul.
Contingut. Un mòdul accedeix directament a una part de l’altre mòdul (sentències tipus go to).
𝑶𝒃𝒋𝒆𝒄𝒕𝒊𝒖: ↑ 𝑪𝒐𝒉𝒆𝒔𝒊ó ; ↓ 𝑨𝒄𝒐𝒃𝒍𝒂𝒎𝒆𝒏𝒕 ...

Tags:
Comprar Previsualizar