Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
El procés de desenvolupament
Toni Navarrete
Enginyeria del Software II – UPF 2002
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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)
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 6
El cicle de vida en cascada (també dit tradicional, lineal o seqüencial)
Requirementsdefinition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 9
• 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
El cicle de vida basat en prototipus
Escoltar
el clientConstruir/revisar
el prototipus
El client prova
el prototipus
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 12
El cicle de vida iteratiu i incremental
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
Requerimets Anàlisi Disseny Implementació ProvesLliurament
1
Requerimets Anàlisi Disseny Implementació ProvesLliur.
2
...
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 14
El cicle de vida en espiral
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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,...
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 19
Inici
Iteració Iteració . . .d’Elaboració 1 d’Elaboració 2
Unified Process: fases i fluxos
Model denegoci
Normalement de dues setmanes a dos mesos
Elaboració Construcció Transició
Requeriments Anàlisi i DissenyRequeriments
Implementació Proves Desplegament
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 20
Unified Process: fases i fluxos
Organització al llarg del temps
Org
anit
zaci
ó a
l lla
rg d
el
conti
ngut
“Fluxos d’Enginyeria”
“Fluxos de suport”
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 25
El mètode ICONIX
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 27
El mètode ICONIX. Exemple de descripció de cas d’ús
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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ó)
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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,...
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 31
El mètode ICONIX. Robustness diagrams
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 32
El mètode ICONIX. Exemplde de diagrama de seqüència
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 34
El mètode ICONIX: el “mapa” complet
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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– ...
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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.
En
gin
yeri
a d
el S
W II
: El p
rocé
s de
de
sen
volu
pam
ent
Pàgina 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
