El procés de desenvolupament Toni Navarrete Enginyeria del Software II – UPF 2002

El procés de desenvolupament de software Comença amb un problema o necessitats (sovint difusos) Acaba amb un codi (provat) ? Problema Codi Procés de desenvolupament de software

El procés de desenvolupament de software “Un procés de desenvolupament de software descriu una aproximació a construir, desplegar i posiblement mantenir software” [1] És “un conjunt d’activitats estructurat per desenvolupar un sistema software” [2] [1] Craig Larman: Applying UML and patterns, 2nd edition. Prentice-Hall [2] Xavier Amatriain: Apunts d’Enginyeria del Software I

Tècniques, mètodes i eines Una tècnica és la manera pre-establerta en què es duu a terme un pas en l’elaboració d’un producte Un mètode (també se’n diu metodologia) és una manera determinada d’aplicar diverses tècniques successivament “Inclouen models de sistema, notacions, regles, recomacions de diseny i guia de processos” [1] Una eina és un instrument de qualsevol tipus que es fa servir en l’aplicació d’una tècnica [1] Xavier Amatriain: Apunts d’Enginyeria del Software I. UPF

Models de procés o cicle de vida Aquest procés de desenvolupament genèricament s’ajusta a un model de procés (també anomenat model de cicle de vida) En cascada Iteratiu Basat en prototipus (i evolutiu) Incremental En espiral Altres Especificacions formals (molt difícil d’aplicar, rarament s’utilitzen) Desenvolupament basat en components Components COTS, Commercial Off-The-Shelf (en castellà es tradueix com a CYD, Comerciales Ya Desarrollados)

El cicle de vida en cascada (també dit tradicional, lineal o seqüencial)

El cicle de vida en cascada: Inconvenients Difícil fer (predir) una “imatge” perfecta de l’aplicació sense fer cap prova abans Ajorna el risc i això fa que els projectes s’acabin allargant Difícil adaptar-se a canvis en els requeriments

Diferents aproximacions: Cicle de vida iteratiu El model iteratiu permet, en base a repetir les etapes d’anàlisi de requeriments, disseny, implementació i proves, adaptar-se millor als canvis en els requeriments Diferents aproximacions: Basat en prototipus (i evolutiu) Iteratiu i incremental En espiral

El cicle de vida basat en prototipus El desenvolupador i el client es troben i defineixen els objectius globals i n’identifiquen els requeriments Es fa un disseny ràpid i es desenvolupa una maqueta El client l’avalua El cicle es repeteix fins a aconseguir el detall dessitjat Escoltar el client Construir/revisar el prototipus El client prova el prototipus

El cicle de vida basat en prototipus: Problemes i aplicacions El client pot no entendre perquè s’ha de tornar a construir una altra versió Sovint es vol reutilitzar més del compte entre una versió i la següent i els sistemes acaben essent poc estructurats Habitualment cal aprendre eines (com llenguatges de programació) específiques per a prototipatge ràpid Quan s’aplica? L’ideal és aplicar-lo només com a una eina per identificar els requeriments. Després el més probable és que es llenci En cas contrari, parlem de desenvolupament evolutiu o exploratori. Això s’utilitza en alguns casos: Per a sistemes interactius de mida petita-mitjana Per a parts de grans sistemes, com la interfície d’usuari Per sistemes de vida molt curta

El cicle de vida iteratiu i incremental El sistema no es fa tot de cop sinó que es divideix en parts, basant-se en la funcionalitat A cada iteració es fa tot el procés per desenvolupar una part concreta i es lliura el software corresponent Es comença per les que tenen un major risc i a les quals el client dóna més importància Així, es redueix el risc global i les funcionalitats més importants estan més provades En principi, un cop acabada un lliurament, ja no es tornen a analitzar els requeriments d’aquesta part És, probablement, el model més utilitzat avui en dia

El cicle de vida iteratiu i incremental Lliurament 1 Requerimets Anàlisi Disseny Implementació Proves Lliur. 2 Requerimets Anàlisi Disseny Implementació Proves ...

El cicle de vida en espiral Una aproximació molt semblant és combinar això amb el desenvolupament basat en prototipus: model espiral El software en desenvolupa en una sèrie de versions incrementals Durant les primeres versions, s’obté un model en paper o un prototipus Durant les darreres iteracions, es produeixen versions cada vegada més completes del sistema

El cicle de vida en espiral

Exemples de mètodes de procés (o metodologies) UP: Unified Process (o RUP, Rational Unified Process) ICONIX Mètodes àgils Crystal XP: eXtreme Programming Un exemple en UP i ICONIX MOLT IMPORTANT: Cap metodologia “estàndard” s’ajusta a les necessitats d’una organització concreta

Unified Process És un mètode iteratiu i incremental Utilitza UML Creat pels creadors d’UML: Booch, Jacobson i Rumbaugh (“the 3 amigos”) Utilitzat per Rational per als seus productes

Unified Process Permet definir un procés en termes de: Qui: treballadors (workers) Exemples: system analyst, designer, test designer Com: activitats (activities) Exemples: plan an iteration, find use cases and actors, review the design, execute a performance test Què: artefactes (artifacts) Exemples: use case model, software architecture development, a sequence diagram Quan: fluxos (workflows) Un flux descriu una seqüència d’activitats que produeix un resultat observable i que mostren interaccions entre treballadors Exemples: business modelling, requirements, analysis and design,...

Unified Process: fases i fluxos Basat en quatre fases: Inici (Inception) Elaboració (Elaboration) Construcció (Construction) Transició (Transition) Cada fase acaba amb una fita (milestone) ben definit on s’han de prendre certes decisions Cada fase es pot dividir en diverses iteracions internes, que normalment duren entre dues setmanes i dos mesos A cada iteració es donen diferents fluxos, depenent del moment en què estigui el procés

Unified Process: fases i fluxos Inici Elaboració Construcció Transició Iteració Iteració . . . d’Elaboració 1 d’Elaboració 2 Model de negoci Anàlisi i Disseny Requeriments Implementació Proves Desplegament Requeriments Normalement de dues setmanes a dos mesos

Unified Process: fases i fluxos Organització al llarg del temps “Fluxos d’Enginyeria” Organització al llarg del contingut “Fluxos de suport”

Unified Process: les quatre fases Inici: Es mesura l’oportunitat i “alcance” del projecte S’identifiquen entitats externes (actors) i la interacció a alt nivell (casos d’ús). D’aquests casos d’ús alguns es desenvolupen Elaboració S’analitza el domini del problema, s’estableix una arquitectura, es desenvolupa un pla de projecte i s’analitzen els elements de major risc És l’etapa més crítica ja que aquí es defineixen els requeriments i plans de desenvolupament

Unified Process: les quatre fases Construcció: Totes les components restants es desenvolupen i integren al producte Tot és provat en profunditat Transició: Es dóna el software desenvolupat a la comunitat d’usuaris

Unified Process: conclusions És molt complet És “configurable”. Exemples: Es podria fer un procés purament seqüencial Es pot definir perquè sigui molt “pesada” o perquè sigui molt “lleugera” En realitat s’usa, més que com una metodologia, com un framework per definir metodologies Després veurem definirem un subconjunt i farem un exemple

El mètode ICONIX “You can model 80% of most problems by using about 20% of UML” [1] Es “use-case driven” Es pot fer de forma iterativa i incremental Dos bons llibres [2] i [3] [1] “3 amigos”: The Unified Modelling User Guide. Addisson-Wesley [2] Dough Rosenberg: Use Case Driven Object Modelling With UML [3] Dough Rosenberg: Applying Use Case Driven Object Modelling With UML

El mètode ICONIX

El mètode ICONIX Els requeriments els expresem amb un model de casos d’ús. Això inclou: el diagrama de casos d’ús la descripció de cada un, en llenguatge natural, amb un paràgraf per a l’escenari principal i un altre per als alternatius

El mètode ICONIX. Exemple de descripció de cas d’ús

El mètode ICONIX Per altra banda, el resultat final del disseny (el model de disseny) inclou dues parts, l’estàtica i la dinàmica, que estan respecticvament representades per diagrames de classes i diagrames d’interacció (seqüència o col·laboració) ? ? ?

El mètode ICONIX Abans d’obtenir les classes del model de disseny, és necessari, en l’etapa de requeriments o inclús abans fer un model del domini per determinar amb quins objectes hem de treballar És un diagrama de classes sense entrar en detalls d’atributs, cardinalitats,... ? ?

El mètode ICONIX La part més complexa del procés és com obtenim un diagrama de seqüència a partir dels casos d’ús A ICONIX es fa introduïnt el que ells anomenen “robustness diagram”, també anomenats diagrames de col·laboració simplificats Veurem altra aproximació per passar del “què” al “com” utilitzant UP

El mètode ICONIX. Robustness diagrams

El mètode ICONIX. Exemplde de diagrama de seqüència

El mètode ICONIX Aquest Robustness diagram ens ajuda a determinar les classes del disseny i a trobar operacions i a realitzar els casos d’ús en diagrames de seqüència En concret ICONIX proposa que els requeriments es facin a partir d’un prototipus de la interfície d’usuari El procés sol ser incremental, decidint abans de cada increment quins casos d’ús es desenvoluparan

El mètode ICONIX: el “mapa” complet

Què són els mètodes àgils? L’objectiu és tenir metodologies efectives i utilitzables Metodologies molt pesades generen gran quantitat de documentació innecessària que retrasa el desenvolupament ICONIX és un exemple de mètode àgil Un procés àgil ha de ser a la vegada lleuger i suficient També ha de ser adaptable (cada organització, cada projecte són diferents) Un bon llibre al respecte: [1] [1] Alistari Cockburn: Agile Software Development

Crystal Com fer per a tenir una metodologia realment adaptable? Crystal recull una col·lecció d’exemples de metodologies àgiles usades amb èxit per la comunitat amb l’objectiu de què serveixin a les organitzacions com exemple per a crear la seva metodologia

Crystal: diferents colors En funció del tipus de projecte s’aplica una metodologia (identificada per un color) o una altra: Clear Yellow Orange Red Per exemple: per a projectes fins a un màxim de sis persones implicades i on hi ha un alt risc econòmic si el producte no surt s’utilitzaria Crystal Clear

Exemple Crystal Clear Rols necessaris: Política: Sponsor Dissenyador-programador senior Dissenyador-programador Usuari (almenys a temps parcial) Política: El software es lliurarà incremental i regularment, cada dos a tres mesos El progrés està controlat per milestones consistents en lliurament de software i preses de decissions importants Hi ha una implicació directa de l’usuari Workshops al principi i meïtat de cada increment ...

Exemple Crystal Clear Artefactes: Eines: Casos d’ús anotats Esborranys de dissenys Esborranys de pantalles Model de classes ... Manual d’usuari Eines: Sistema de versions Una pissarra blanca

XP: eXtreme Programming El cas extrem dels mètodes àgils El disseny és insignificant És un mètode iteratiu i incremental, amb increments molt petits de funcionalitat Es basa en la millora constant del codi El client o usuari està completament integrat en l’equip de desenvolupament, sempre present Programació col·lectiva: tot el codi és de tots i el pot modificar, mitjançant refactorització, qui sigui quan sigui Programació en parella, un dels aspectes més polèmics La “biblia” de XP: [1] Article per comentar a la propera classe [1] Kent Beck: Extreme Programming Explained. Addisson-Wesley

Bibliografia utilitzada Enginyeria del Sofware en general: Pressman: Ingeniería del Software, un enfoque práctico. 5ª edición. McGraw Hill, 2002. Campderrich: Enginyeria del programari I. UOC Campderrich: Enginyeria del programari III. UOC Unified Process Jacobson, Ivar; Booch, Grady; Rumbaugh, James: El proceso unificado de desarrollo de software. Addison Wesley Kruchten, Philippe: The Rational unified process an introduction Philippe Kruchten. Addison-Wesley Larman: Patterns and UML, 2nd edition.

Bibliografia utilitzada ICONIX Doug Rosenberg (amb Kendall Scott): Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example. Addison Wesley (Object Technology Series) Doug Rosenberg (amb Kendall Scott): Use Case Driven Object Modeling With Uml: A Practical Approach. Addison Wesley (Object Technology Series) Mètodes Àgils Alistair Cockburn: Agile Software Development. Addison Wesley Kent Beck: Extreme Programming Explained César F. Acebal, Juan M. Cueva: eXtreme Programming (XP): un nuevo método de desarrollo de software. En Novática, nº 156, març-abril 2002