Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Valg af en projektmodel

Lignende præsentationer


Præsentationer af emnet: "Valg af en projektmodel"— Præsentationens transcript:

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

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 2. iteration Analyse Design Udvikle Test 3. iteration Analyse Design Udvikle 4. iteration Analyse Design

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:

14 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

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 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.

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

21 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

22 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

23 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

24 Sammenligning af metoder Størrelses-perspektivet
Agile Agil udvikling bliver vanskelig med mere end 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

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

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

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 Cockburn, Alistair (2001). Agile software Development. Addison-Wesley Davis, Alan M. (1992). Operational Prototyping: A new development Approach. IEEE Software, September 1992, page DeGrace, Peter & Leslie Hulet Stahl (1990). Wicked problems, righteous solutions: Solutions: a Catalogue of Modern Software Engineering Paradigms. Yourdon Press., ISBN X Gordon, V. Scott & James M. Bieman (1995). Rapid prototyping: Lessons Learned. IEEE Software, January 1995, page Rising, L. and Janoff, N.S. "The Scrum software development process for small teams," IEEE Software (17:4), 2000, pp Rudd, Jim, Ken Stern & Scott Isensee (1996). Low vs. High Fidelity Prototyping Debate. Interactions, January 1996, volume III.I, page Sutherland, Jeff (2004). Agile development: Lessons learned from the first Scrum. Schwaber, Ken (2004). Agile Project Management with Scrum. Microsoft Press, 163pp, ISBN 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


Download ppt "Valg af en projektmodel"

Lignende præsentationer


Annoncer fra Google