Valg af en projektmodel

1. Valg af en projektmodel

2. Efter denne lektion skal du: • Kende til forskellige projektmodeller, så som vandfaldsmodellen, V-modellen, evolutionær udvikling og spiral-modellen • Kende til forskellige former for iterativ udvikling og prototyping • Kunne identificere vigtige karakteristika ved et projekt, med henblik på at vælge en god projektmodel for projektet • Kende til agile modeller så som SCRUM

3. Hvor skal du hen? “Would you tell me please, which way I ought to go from here?” “That depends on where you want to get to,” said the cat. “I don’t much care where--,” said Alice. “Then it doesn’t matter which way you go,” said the cat. Lewis Carroll, Alice in Wonderland

4. Arkitektur design Detaljeret design Vandfaldsmodellen Idé Analyse Udvikling To klassiske problemer • Ikke plads til læring • Kvalitet ”falder ud over kanten” I brug

5. V-modellen Kan løse: • Kvalitetsproblemet

6. ”Hvis du ikke ved hvad du har med at gøre, så lad være med at gøre det i stor skala.” Tom Gilb

7. Iterativ • Iteration betyder gentagelse • En måde at håndtere et stort projekt er ”en bid af gangen” • Det vil sige at man organiserer projektet som et antal iterationer • Hvilket også giver plads til at lære og blive klogere Kan løse: • Læringsproblemet

8. En (helt) iterativ model 1. Analyse Design Udvikle Test Analyse Design Udvikle Test 2. iteration Analyse Design Udvikle 3. iteration Analyse Design 4. iteration

9. En (delvist) inkrementel model Denne model benyttes ofte i RAD (Rapid Application Development) Idé Analyse Arkitektur-design For hver iteration: Detaljeret design, udvikling og test, samt levering til kunden Udvikling I brug Vedligeholdelse

10. ”Du skal bruge en del af dit snilde til at trylle din opgave lille. Når du først har lagt seletøj på den lad den gro sig så stor, du kan få den!” Piet Hein

11. Spiralmodel – Risikodrevet udvikling Planlæg Kommunikation med kunden Risikoanalyse Kunde Analyse og design evaluering Programmering og i drift

12. Det sværeste først Kousholt (2008: 47)

13. RUP - Rational Unified Process modellen Kilde: http://www.rational.com/products/rup/whitepapers.jsp

14. Komponent-baseret udviklingf.eks. Service OrienteretArkitektur Identificer mulige komponenter Lav itera- tion N+1 af systemet Eftersøg komponenter i bibliotek Gem nye komponenter I bibliotek Udtræk fundne komponenter Byg ikke-fundne komponenter Genbrug = spare penge og kalendertid

15. PRINCE2 projektmodellen Kousholt (2008: 45)

16. Nye måder at arbejde på i det ny årtusinde Nye tilgange til håndtering af projekter er groet frem. Særligt ansporet af den kraftige vækst I kommercielle Internet applikationer før og efter årtusindskiftet • Agile Software Process (Aoyama 1998) • Scrum (Rising and Janoff 2000) • eXtreme Programming (Beck 2000) • Crystal (Cockburn 2001) • Manifesto for Agile Software Development (2001)

17. Tidlige idéer i agile (adræt) projekter • Resultater udvikles bedst i korte værdiskabende iterationer • Bruger og systemudvikler skal arbejde hånd i hånd • Hver iteration skal designes til at adressere et minimum af krav • Når der opstår behov for en ændring, skal den designes ind i løsningen frem for tilføjes (klistres udenpå) • Dokumentationen skal være minimal bortset fra det som produktet i sig selv indeholder

18. ”Hvis du ikke ved hvad du har med at gøre, så lad være med at gøre det i stor skala.” Tom Gilb ”Du skal bruge en del af dit snilde til at trylle din opgave lille. Når du først har lagt seletøj på den lad den gro sig så stor, du kan få den!” Piet Hein

19. Det agile manifest Top level: ”We are uncovering better ways of developing software by doing it and helping others do it.” 2nd level: Through this work we have come to value: Individuals and interactionsover processes and tools Working softwareover comprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan. That is, while there is value in the items on the right, we value the items on the left more.

20. Boehm’s Planning Spectrum Boehm, Barry. (2002) Get ready for agile methods, with care. IEEE Computer, pp. 64-69

21. Agile Der lægges vægt på menneskelige faktorer som medmenneskelighed, talent, færdigheder og kommunikation. Får sin adræthed fra en antagelse om, at tilstrækkelig viden er indarbejdet i teamet. Plan-dreven Risiko for at træffe beslut-ninger på ufuldstændigt grundlag imødegås ved at investere i livscyklus, arkitektur og planer. Resultaterne kan reviewes af eksterne eksperter Mange forandringer  det er dyrt at opdatere planer Sammenligning af metoderUdvikler-perspektivet ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

22. Agile Kunderepræsentanterne skal være forpligtede (”committed”), vidende, samarbejdsvillige, repræsentative og ”empowered” Kunderepræsentanternes viden skal være dækkende for hele applikationen Plan-dreven Risikoen for at træffe beslutninger på ufuldstændigt grundlag imødegås ved at dokumentere beslutningsgrundlag og beslutninger, således at der kan foretages review Sammenligning af metoderKunde-perspektivet ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

23. Agile Antager at verden er foranderlig og har derfor indbygget en forventning om ændringer af krav. Krav kan ikke specificeres på forhånd, men udvikler sig over tid. Selv om der naturligvis er potentiale for succes ved villighed og evne til forandring, så er der en risiko for, at det kan give katastrofale konsekvenser at foretage mange ændringer. Plan-dreven Traditionelle metoder lægger vægt på: Fuldstændige krav Konsistente krav Testbare krav Sporbare krav Traditionelle metoder virker bedst, når krav forbliver forholdsvis stabile, med en ændrings radio på under 1% pr. måned. Sammenligning af metoderKrav-perspektivet ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

24. Agile Agil udvikling bliver vanskelig med mere end 15-20 udviklere Plan-dreven Plan-drevne metoder kan skaleres til meget store projekter. For meget små projekter er der store ”start- omkostninger” i forhold til nytteværdien. Sammenligning af metoderStørrelses-perspektivet ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

25. Netop tilstrækkelige metoder 1/3 • Tunge metoder kræver megen dokumentation, har mange milepæle, og mange krævede aktiviteter • Tunge metoder kan sinke fremdrift og dræbe motivationen i et projekt • For lette metoder fejler på grund af manglende forankring af viden om hvad der skal laves, hvordan det skal laves, og hvad der er lavet • Lette og adrætte (”Agile”) metoder sikrer netop tilstrækkelig kommunikation og forankring af viden i et systemudviklingsprojekt

26. Netop tilstrækkelige metoder 2/3 Der er en grænse for hvor store problemer lette metoder kan løse. Til gengæld kræves færre personer Kilde: Alistair Cockburn (2001). Agile software Development. Addison-Wesley

27. Netop tilstrækkelige metoder 3/3 Nødvendigt med tunge metoder her Lette metoder her Kilde: Alistair Cockburn (2001). Agile software Development. Addison-Wesley

28. Prototyping

29. Der kan gemme sig mangt og meget under begrebet prototyping • En proces til indfange krav • En proces hvor man får noget til at virke hurtigt • En måde der tillader at man hurtigt kommer igang med at kode • En måde at reducere pres udefra ved at skabe en overbevisende illusion om fremdrift • Et synonym for hacking Gerald Weinberg (1997). Anticipating Change. Dorset House. Page 322.

30. Hvad er en prototype? • En prototype er en tidlig prøveversion af et færdigt edb-system. Idéen til at lave prototyper af edb-systemer er inspireret af f.eks. arkitekter, der ofte laver små modeller af deres forslag til bygninger, så andre lettere kan forstå deres idéer. (IT-LEX: Det store informatik-leksikon 2001) • En prototype er en delvis implementering af et system, bygget for eksplicit at lære mere om et problem eller en løsning til et problem. (Davis 1992: 71) • En kørende model af (dele af) et edb-system fokuserende på specifikke aspekter af systemet. (Vonk 1990: 20)

31. Største fordele ved prototyping • Brugerne inddrages bedre • Man får defineret kravene til det nye edb-system bedre • Man får noget til at fungere hurtigt

32. Erfaringer fra 39 virksomheder (Gordon & Bieman, 1995) Meget sikre effekter af prototyping • Produkter udviklet med prototyping bliver lettere at bruge • Brugernes behov bliver næsten altid bedre opfyldt • Udviklingsindsatsen bliver mindsket • Brugerdeltagelsen bliver øget

33. Erfaringer fra 39 virksomhederfortsat Effekter man kan opnå • Performance bliver tit dårligere • Design-kvaliteten bliver ofte bedre • Prototyping kan kræve mere ekspertise Højst usikre effekter af prototyping • De færdige systemer bliver i enkelte tilfælde lettere at vedligeholde • Mængden af features bliver enkelte gange øget pga. prototyping • I enkelte tilfælde bliver estimering sværere

34. Fire prototype dimensioner Blivende Smid-væk Vertikal Horisontal Problem-afklarende Løsnings-implementerende Lille lighed Stor lighed

35. Eksempel 1: Papir-prototype En papir mock-up med skærmbilleder udskrevet fra et tegneværktøj • Blivende versus Smid væk • Vertikal versus Horisontal • Problem-afklarende versus Løsnings-implementerende • Stor lighed versus Lille lighed

36. Eksempel 2: Navigations-prototype En navigations-prototypemed skærmbilleder lavet i Visual Basic, hvor man kan klikke sig rundt, og hvor Visual Basic er det værktøj det endelige system skal kodes i • Blivendeversus Smid væk • Vertikal versus Horisontal • Problem-afklarende versus Løsnings-implementerende • Stor lighed versus Lille lighed

37. Eksempel 3: Funktionel prototype En funktionel prototype der helt konkret afprøver om det er muligt at leve op til et svartidskrav på maksimalt 2 sekunder for et typisk skærmbillede • Blivende versus Smid væk • Vertikal versus Horisontal • Problem-afklarende versus Løsnings-implementerende • Stor lighed versus Lille lighed

38. Pas på at smid-væk prototypen ikke bliver en del af det færdige system Undgå: • “Kunne jeg ikke få prototypen i Beta-test?” • “Jeg har allerede solgt systemet. Hvorfor gør I det ikke lige færdigt?” • “Planen er ændret. Vi har ikke råd til at lave det hele om!”

39. Lav kun funktionelle prototyper til centrale problemer, og når det er helt nødvendigt Undgå: • “Jeg skal lige have det hele med” • “Se den smarte løsning jeg her har fundet på” • “Slow prototyping”

40. Anvendt litteratur • Beck, K. Extreme Programming Explained: Embrace Change, Addison-Wesley, Boston, 2000. • Carey, J.M. & J.D. Currey (1989). The Prototyping Conundrum. Datamation, June 1, 1989, page 29-33. • Cockburn, Alistair (2001). Agile software Development. Addison-Wesley • Davis, Alan M. (1992). Operational Prototyping: A new development Approach. IEEE Software, September 1992, page 70-78. • DeGrace, Peter & Leslie Hulet Stahl (1990). Wicked problems, righteous solutions: Solutions: a Catalogue of Modern Software Engineering Paradigms. Yourdon Press., ISBN 0-13-590126-X • Gordon, V. Scott & James M. Bieman (1995). Rapid prototyping: Lessons Learned. IEEE Software, January 1995, page 85-95. • Rising, L. and Janoff, N.S. "The Scrum software development process for small teams," IEEE Software (17:4), 2000, pp. 26 -32. • Rudd, Jim, Ken Stern & Scott Isensee (1996). Low vs. High Fidelity Prototyping Debate. Interactions, January 1996, volume III.I, page 76-85. • Sutherland, Jeff (2004). Agile development: Lessons learned from the first Scrum. • Schwaber, Ken (2004). Agile Project Management with Scrum. Microsoft Press, 163pp, ISBN 0-7356-1993-X • Takeuchi, H. and I. Nonaka (1986). The New New Product Development Game. Harvard Business Review, 1986 (January-February). • Vonk, Roland (1990). Prototyping: The effective use of CASE Technology. Prentice-Hall