El procés de desenvolupament

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

2. 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

3. 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

4. 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

5. 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)

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

7. 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

8. 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

9. 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

10. El cicle de vida basat en prototipus: Problemes i aplicacions • Problemes • 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

11. 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

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

13. 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

14. El cicle de vida en espiral

15. 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

16. 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

17. 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,...

18. 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

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

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

21. 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

22. 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

23. 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

24. 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

25. El mètode ICONIX

26. 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

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

28. 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ó) ? ? ?

29. 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,... ? ?

30. 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

31. El mètode ICONIX. Robustness diagrams

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

33. 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

34. El mètode ICONIX: el “mapa” complet

35. 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

36. 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

37. 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

38. Exemple Crystal Clear • Rols necessaris: • 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 • ...

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

40. 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

41. 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.

42. 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