Iterativ udvikling og UP

Præsentationer af emnet: "Iterativ udvikling og UP"— Præsentationens transcript:

1 Iterativ udvikling og UP
People are more important than any process. Good people with a good process will outperform good people with no process every time Grady Booch Poul Henriksen Larman kap. 2

2 Ikke ukendt fænomen…. Poul Henriksen Larman kap. 2

3 UP forsøger at løse disse problemer
Problemer ved SW Symptomer Brugerne behov bliver ikke opfyldt Kraven ændrer sig Moduler passer ikke sammen Problemer problemerne opdages sent Dårlig kvalitet Vanskeligt at udvide og vedligeholde Tids- og resurce estimater holder ikke Årsager Ufuldstændige krav Mangelfuld kommunikation Ændrede betingelser Stor kompleksitet Uopdaget inkonsistens Mangelfulde test Ukontrollerede ændringer Dårligt arkitektur Subjektive vurderinger Dårlig håndtering af risiko UP forsøger at løse disse problemer Poul Henriksen Larman kap. 2

4 UML <>Udviklingsproces
UML er kun rå diagrammering Diagrammerne skal placeres i en process. Systemudviklingsproces Beskriver en måde til at bygge, indføre og vedligeholde software systemer. UP er ikke den eneste proces men kan være svær at komme uden om. Poul Henriksen Larman kap. 2

5 Sekventiel livscyklus (“vandfalsmodellen”)
En systemudviklingsmodel Fase opdelt Hver fase starter når forrige fase er afsluttet Integratjon System Test Koding Analyse og design Kravspes. Poul Henriksen Larman kap. 2

6 Sekventiel livscyklus (“vandfalsmodellen”)
Analyse Forsøg på at definere krav til systemet Det antages at kravene ikke ændres Design Pba. Analyse designes en løsning I detaljer Et fuldstændigt design Implementering Programmering af alle komponeter beskrevet I design specifikationen. Integrering og test Enheds test Integreres I applikationen Systemtest Gennemføres på ex. 6 måneder Metode der skulle reducere risiko !!!!! Virker modsat  Poul Henriksen Larman kap. 2

7 Risiki I vandfaldsmodellen
T I D Integrasjon System Test Koding Analyse og design Kravspes. Poul Henriksen Larman kap. 2

8 Problemer ved “vandfaldsmodellen”
Ufuldstændige krav Kravene ændrer sig Problemer opdages sent Vanskeligt at udvide og vedligeholde Tids- og resurce estimater holder ikke Virker modsat hvad man troede I 70’erne Dette er en meget risikofyld proces. Er skyld i mange fejlslagne projekter. Poul Henriksen Larman kap. 2

9 Iterativ livscyklus Billeder fra Larman Poul Henriksen Larman kap. 2

10 Iterativ udvikling Iteration 1 Tidsperiode: typisk 2-4 uger
Komponenter med høj risiko udvikles i tidlige iterationer. Hver iteration generere et kørende udgave af programmet- systemet vokser efter hver iteration. Hver udgave af programmet er fuldstændigt integreret og testet Poul Henriksen Larman kap. 2

11 Iterativ udvikling En iteration kan omhandle enkelte usecases. Men store usecase kan opdeles over flere iterationer TimeBoxing Længden af hver iteration er fast typisk på ca uger Hvis opgaven ikke kan gennemføres reduceres opgaven/kravene i iterationen. Poul Henriksen Larman kap. 2

12 Risiko Risiko i iterativ Risiko i vandfaldsmodellen Iteration 1
T I D Iteration 1 Iteration 3 Iteration 2 Poul Henriksen Larman kap. 2

13 Discipliner på tværs af iterationer
Alle discipliner udføres I hver iteration Tyngden af arbejde indenfor hver iteration veksler Poul Henriksen Larman kap. 2

14 Discipliner og faser Inception er ikke en krav-fase
Hvad er motivation for projektet ? Er der en business case ? Etablering af en fælles vision. Det er ikke målet et identificere alle krav. Undersøgelse – hvorefter vi vurdere om vi kan forsætte med projektet ? Elaboration Bygger den centrale del af projektet Systemets kernearkitektur Identificering af hovedparten af kravene Identificere risici I projektet Skal fjerne de elementer der har højst risiko Construction De simple dele af systemet udvikles Transition Frigivelse af udgaver af systemet Feedback på systemet Flytte systemet til produktion Inception er ikke en krav-fase Elaboration er ikke en design-fase Construction er ikke implementeringsfase Poul Henriksen Larman kap. 2

15 Centrale ideer i UP Iterativ udvikling
Håndtering af højrisiko elementer tidligt (teknisk, krav, politiske, brugervenlighed…..) Test tidligt og test ofte Unit-test Integrationstest Load-test Usability-test (fokus grupper) Evaluering på processen Brug tid på at evaluere processen I hver iteration Understøt forandringer Accepter at der kommer forandringer i krav istedet for at bekæmpe ændringer i krav. Poul Henriksen Larman kap. 2