Valg af en projektmodel

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

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

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

V-modellen Kan løse: Kvalitetsproblemet

”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

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

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

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

”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

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

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

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

Komponent- baseret udvikling f.eks. Service Orienteret Arkitektur Identificer mulige komponenter Komponent- baseret udvikling f.eks. Service Orienteret Arkitektur 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

PRINCE2 projektmodellen Kousholt (2008: 45)

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)

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

”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

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 interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.

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

Sammenligning af metoder Udvikler-perspektivet 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 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. ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

Sammenligning af metoder Kunde-perspektivet 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 ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

Sammenligning af metoder Krav-perspektivet 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. ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

Sammenligning af metoder Størrelses-perspektivet 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. ”Get Ready for Agile Methods, With Care” Barry Boehm, IEEE 2002

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

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

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

Prototyping

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.

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)

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

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

Erfaringer fra 39 virksomheder fortsat 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

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

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

Eksempel 2: Navigations-prototype En navigations-prototype med 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 Blivende versus Smid væk Vertikal versus Horisontal Problem-afklarende versus Løsnings-implementerende Stor lighed versus Lille lighed

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

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!”

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”

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