1 / 15

Iterativ udvikling og UP

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. Ikke ukendt fænomen…. Problemer ved SW. Symptomer Brugerne behov bliver ikke opfyldt Kraven ændrer sig

nishi
Download Presentation

Iterativ udvikling og UP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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 Larman kap. 2

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

  3. 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 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. Larman kap. 2

  5. Kravspes. Analyse og design Koding Integratjon System Test Sekventiel livscyklus (“vandfalsmodellen”) • En systemudviklingsmodel • Fase opdelt • Hver fase starter når forrige fase er afsluttet 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  Larman kap. 2

  7. Kravspes. R I S I K O R I S I K O Analyse og design Koding Integrasjon System Test T I D Risiki I vandfaldsmodellen 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. Larman kap. 2

  9. Iterativ livscyklus • Billeder fra Larman Larman kap. 2

  10. Iteration 1 Iteration2 Iteration3 Iterativ udvikling 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 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. 2-4 uger • Hvis opgaven ikke kan gennemføres reduceres opgaven/kravene i iterationen. Larman kap. 2

  12. Iteration 3 Iteration 1 Iteration 2 Risiko i iterativ Risiko i vandfaldsmodellen R I S I K O T I D Risiko Larman kap. 2

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

  14. Discipliner og faser • Inception • 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 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. Larman kap. 2

More Related