System Udvikling

1. System Udvikling Kilde: Per S Laursen

2. Er det svært…? • Sammenlignet med hvad…? • Måske ikke sværere at lave IT-projekter end så mange andre slags projekter • Imidlertid er der – desværre – rigtig mange eksempler på IT-projekter, som er gået galt RHS - Informationsteknologi

3. Er det svært…? • Amanda – system til sagsbehandling af arbejdsløse • Start-budget 214 mill, endelig pris 650 mill • Tidsramme fire år, kører ikke rigtig godt efter ni år… • Elektroniske patient-journaler (EPJ) • Hvert amt har kørt egne projekter – ingen koordination • Indtil videre brugt milliarder… RHS - Informationsteknologi

4. Hvorfor er det så svært…? • Er det sværere end at bygge en bro…? • Ja, kravene til en bro er som regel ret veldefinerede • Mange IT-projekter er – i sidste ende – fejlet på grund af uklarhed om krav RHS - Informationsteknologi

5. Old school IT-udvikling • Engang troede man, at vi kunne specificere krav til f.eks. software een gang for alle • Vi starter med at definere krav, og så laver vi ”alt det andet” bagefter • Vandfalds-metoden RHS - Informationsteknologi

6. Vandfalds-metode Krav Design Implementation Test Vedligehold RHS - Informationsteknologi

7. Hvorfor virker den ikke? • Vandfalds-metoden bygger på en (naiv) idé om rationel og alvidende opførsel • Kunden ved præcist hvad systemet skal kunne, allerede når projektet starter • Kunden kan formidle sine krav til leverandøren på objektiv og entydig vis • Omfanget af et projekt kan estimeres alene ud fra en specifikation af krav RHS - Informationsteknologi

8. Hvorfor virker den ikke? • Dette har vist sig at være særdeles langt fra virkeligheden… RHS - Informationsteknologi

9. Hvordan IT ikke skal sælges… • I lang tid man man troet, at det at købe software var som at købe skovle… • Alt kan specificeres – og prissættes – på forhånd, for det kan andre varer jo! • Meget svært at sælge budskabet om usikkerhed til kunderne – hvem skal betale for usikkerheden…? RHS - Informationsteknologi

10. Hvordan IT ikke skal sælges… • Mange firmaer har solgt store udviklings-projekter til fast pris, uden egentlig at vide hvad de solgte… • Manglende viden hos sælgere…? • Eller måske belønnes sælgere for salg, ikke for gennemførsel…? RHS - Informationsteknologi

11. Hvordan IT ikke skal sælges… • Ville vi acceptere følgende…? Hej, jeg vil gerne købe et jakke-sæt. Jeg fortæller detaljer senere, men jeg vil have en fast pris! Øhm…ok, lad os sige 600,- Godt, i øvrigt skal det være skræddersyet, og lavet af thailandsk silke, og…(så videre) RHS - Informationsteknologi

12. Hvordan IT ikke skal sælges… • Sådan er mange IT-projekter desværre blevet solgt – og hvem ender så med at sidde med problemet…? • Dem som skal udføre selve projektet! RHS - Informationsteknologi

13. Hvordan IT ikke skal sælges… • Således tænkes der ofte i SW-branchen – på lederniveau… • Projektet er solgt til en fast pris på X kroner • Vores interne pris er Y kroner pr. time • For at det skal løbe rundt, skal projektet derfor udføres på X/Y timer! • Selv om vi ikke rigtig ved, hvad projektet går ud på…men det må programmørerne løse! RHS - Informationsteknologi

14. Hvordan IT ikke skal sælges… Med andre ord - projektet er solgt til en fast pris, så internt forsøges det presset igennem til den aftalte pris, og/eller den aftalte deadline Overarbejde… Pizza og cola… Nørd-image… RHS - Informationsteknologi 14

15. Målepunkter • Et SW-projekt indeholder tre essentielle parametre ud over kravene til projektet: • Omkostninger • Varighed • Kvalitet (PS Figur 5.2) RHS - Informationsteknologi

16. Krav • Som nævnt før definerer krav, hvad det endelige produkt skal kunne • I praksis er krav ”levende” – som projektet skrider frem, afklares krav løbende • Krav fremkommer i mange former og fra mange interessenter • Ofte en meget stor udfordring at få gjort krav objektive og testbare RHS - Informationsteknologi

17. Ressourcer • Som regel et ret firkantet mål for, hvor meget ”manpower” der er til rådighed for at udføre et givent projekt • 15 mand i fuld tid i 2 år = 30 mande-år • Men • Har de andre opgave i virksomheden? • Har de relevante kompetencer? • Ferie, sygdom, møder, uddannelse,… RHS - Informationsteknologi

18. Deadline • Ideelt set vil de fleste SW-projekter gerne arbejde til produktet er ”færdigt” – svært at få lov til i praksis • Ofte er deadline påført udefra • Konkurrenter • Større begivenhed (messe eller lign.) • Lovkrav • …men ofte sættes den ret ”tilfældigt” RHS - Informationsteknologi

19. Kvalitet • Hvad er kvalitet i forhold til software…? • At det virker! (?) • Kan være meget svært at formulere, hvad kvalitet egentlig dækker over RHS - Informationsteknologi

20. Kvalitet Bør i princippet være ”indbygget” i de krav, der stilles til softwaren 90 % af brugerne skal give programmet karakteren 10 eller bedre i en bruger-undersøgelse pr. 1/10-2010 Programmet skal kunne udføre en korrekt planlægning i mindst 99 % af et sæt af 500 praktiske tilfælde RHS - Informationsteknologi 20

21. The planning game • Kernen af mange problemer i SW-udvikling har været, at man har troet man kunne fastlægge alle fire parametre på forhånd… • …UDEN at spørge dem, som rent faktisk skal udføre opgaven! RHS - Informationsteknologi

22. The planning game Typisk eksempel; at finde behov for ressoucer ved at regne baglæns fra projektets salgspris: Projektet solgt for 4 millioner Vi koster 500 kr/time Altså 8000 timer til rådighed! Og samtidig insistere på kontrol over krav, kvalitet og deadline! RHS - Informationsteknologi 22

23. The planning game • I mere moderne organisationer spiller man ”the planning game” • Regler: • Ledelsen må vælge værdierne for tre af de fire parametre • De som skal udføre opgaven må så – på basis af disse tre værdier – vælge værdien for den fjerde parameter RHS - Informationsteknologi

24. The planning game • Eksempel • Ledelsen siger • Vi skal være færdige 1/1-2013 • Kravene til funktionalitet er… • Kravene til kvalitet er… • Dem som skal løse opgaven siger: • OK, så skal vi bruge 16 mand som er 80 % på dette projekt, frem til 1/1-2013 RHS - Informationsteknologi

25. The planning game • Eksempel • Ledelsen siger • Vi kan sætte 12 mand af med 70% allokering • Kravene til funktionalitet er… • Kravene til kvalitet er… • Dem som skal løse opgaven siger: • OK, så kan vi være færdige 1/5 - 2013 RHS - Informationsteknologi

26. The planning game • Eksempel (nok det typiske…) • Ledelsen siger • Vi kan sætte 12 mand af med 70% allokering • Kravene til funktionalitet er… • Deadline er 1/1-2013 • Dem som skal løse opgaven siger: • OK, men så bliver det i en skod-kvalitet  RHS - Informationsteknologi

27. Planning poker • Hvordan finder man ud af, hvor meget det kræver at løse en bestemt opgave? • Man løser opgaven  • Alternativt • Tidligere erfaringer • Estimeringsteknikker • Mavefornemmelse / gæt RHS - Informationsteknologi

28. Planning poker Hvis en gruppe skal estimere en opgaves omfang, er der ofte meget psykologi og gruppedynamik involveret Faglig stolthed Tabe ansigt ”Jeg vil ikke virke dum” Estimater bliver ofte for lave RHS - Informationsteknologi 28

29. Planning poker • Planning Poker er et redskab til at gøre estime-ring mere objektivt • Regler • Der fremlægges en opgave, som skal estimeres • Opgavens detaljer kan diskuteres • Efter endt diskussion vælger hver deltager skjult sit eget estimat for opgavens omfang, f.eks i mande-timer • Alle viser deres estimat • De med højest og lavest estimat detaljerer deres grunde for deres estimat • Man tager en runde til, indtil estimaterne er rimeligt ens. RHS - Informationsteknologi

30. Planning poker • For at planning poker kan virke, er der nogle krav til deltagerne • Respektér hinanden, og hinandens argumenter • Det er ikke en kamp om at det laveste estimat skal vinde; det bedste estimat skal vinde • Lær af hinandens argumenter, prøv ikke bare at skyde dem ned • Respektér, at folk ændrer deres estimater undervejs • Stop, når forskellen på det højeste og laveste estimat er mindre end 50 % RHS - Informationsteknologi