Udvikling – del II. 2 Håndtering af krav Uanset hvordan vi organiserer udviklingen af et SW-produkt, er håndtering af krav altid kritisk Dårlig håndtering.

Præsentationer af emnet: "Udvikling – del II. 2 Håndtering af krav Uanset hvordan vi organiserer udviklingen af et SW-produkt, er håndtering af krav altid kritisk Dårlig håndtering."— Præsentationens transcript:

1 Udvikling – del II

2 2 Håndtering af krav Uanset hvordan vi organiserer udviklingen af et SW-produkt, er håndtering af krav altid kritisk Dårlig håndtering af krav er den hyppigste årsag til fejlslagne projekter Alle interessenter i et projekt vil typisk stille krav til det – i forskellige former

3 3 Håndtering af krav Hvordan opstår krav? Fra toppen (ledelse, forretningsmulighed) Fra bunden (ændring af eksisterende system, uhensigtsmæssige procedurer, med videre…) Men som regel vil der være nogle krav, som stammer fra projektets ”sponsor”

4 4 Forretningskrav Dem som sponserer projektet, vil stort set altid have krav til projektet Typisk ”høj-niveau” krav –Programmet skal give forbedret kundeservice –Programmet skal spare 5 millioner om året –Programmet skal kunne planlægge ruter for lastbiler, under hensyntagen til aktuel trafik- situation (for det kan vores konkurrenter ikke)

5 5 Forretningskrav Forretningskrav er som regel ikke-tekniske, men mere orienteret mod det forretningsproblem, der skal løses Forretningskrav er sjældent detaljerede nok til at danne basis for udvikling

6 6 Bruger-krav Ofte vil brugerne af systemet have mere konkrete og detaljerede krav –Man skal kunne indtaste data hørende til denne situation i et enkelt skærmbillede –Hvis programmet går ned, skal man ved opstart kunne starte fra hvor man var før –Der skal være en vejledning til hvert felt, i en pop-up boks som fremkommer når man markerer feltet

7 7 Formulering af krav Ligemeget hvor krav kommer fra, skal de kunne formuleres objektivt! Hvorfor? Man kan ikke teste om et krav er opfyldt, hvis det ikke er formuleret objektivt Ethvert krav bør kunne mod- svares af et test-scenarie

8 8 Formulering af krav Hvad synes I om disse krav? –Programmet skal være hurtigt –Programmet skal være nemt at bruge –Programmet skal give os en konkur- rencemæssig fordel –Programmet skal være bedre end det vi har nu –Programmet skal kunne køre på en PC med denne specifikation… –Programmet skal bruge ny teknologi

9 9 Subjektivitet er vores fjende Ethvert krav som er subjektivt formuleret, kan i tilfælde af kon- flikt blive genstand for fortolkning Objektive krav kan testes entydigt og endegyldigt

10 10 Subjektivitet er vores fjende Er bestemt ikke let at omformulere krav til objektiv form –Programmet skal være let at bruge –-> 90 % af vores brugere skal kunne indtaste oplysninger hørende til en sag indenfor 90 sekunder, efter 4 timers brug af programmet Kan være en svær – men også særdeles oplysende – øvelse for en kunde

11 11 V-modellen Vi antager, at krav falder i visse ”niveauer” –Forretningskrav –Brugerkrav –Tekniske krav Hvert krav modsvares af en tilhørende test, som skal undersøge hvorvidt kravet er opfyldt Test-drevet udvikling

12 V-modellen

13 13 …to the extreme I princippet burde vi kunne definere en test-case for hvert eneste krav Vi burde så kunne lave et program, som automatisk tester om alle test-cases er opfyldt Hvis alle test-cases er opfyldt, er program- met klar til levering til kunden! eXtreme Programming (XP)

14 14 eXtreme Programming En udviklingsmetode, som i ekstrem grad tager udgangspunkt i test Skal opfattes som et ”modsvar” til den traditionelle vandfalds-metode Alle elementer i projektet – krav, design, test, programkode, med videre – er konstant i bevægelse

15 15 eXtreme Programming Hovedtræk i XP: –Vi kan definere et fuldt sæt af test-cases for vores produkt, på alle niveauer –Er test-cases opfyldt, er produktet færdigt –Test-cases defineres før programmet udvikles –Meget tæt samarbejde mellem kunde og leverandør –Projekt køres i korte ”iterationer”, og kan revideres efter hver iteration

16 16 eXtreme Programming Fordele ved XP –Stærkt kunde-engagement –Meget fleksibelt mht. krav –Udviklernes mening respekteres –Tag det vigtigste først –Løbende evaluering – skal vi fortsætte?

17 17 eXtreme Programming Ulemper ved XP –Kan være en meget ”alternativ” måde at arbejde med en leverandør på for kunden –Realistisk? Kan man på forhånd definere test- cases for ”alt”? –Jura – hvem har ansvaret hvis det går galt?

18 18 Styr på krav, og hvad så…? Nej, vi har aldrig bare ”styr på krav”… Men vi har altid et øjebliksbillede af krav, og det er altid vores arbejdsgrundlag Ud fra krav udspringer ”designs” –Brugergrænseflade –Databaser –System-design –Detaljeret design

19 19 Brugergrænseflade (GUI) Krav til GUI er næsten altid bruger-drevet Hvordan laver man en god GUI? Involvér brugeren! Hvem andre end brugeren kan afgøre, om en GUI er god…?

20 20 Brugergrænseflade (GUI) Hvordan kan brugeren blive involveret? –Lav prototyper af GUI, gerne low-tech –Samtaler med kerne-brugere –Usability-studies –Mange systemer er faldet på at være ubrugelige i praksis….

21 21 Prototyper En prototype er i denne sammenhæng en slags skitse til det færdige program Formål er primært at kunne vise brugerne noget konkret i løbet af udviklingsforløbet Brugerne er som regel mest interesserede i GUI, ikke i hvad der sker under over- fladen Sjældent forretningskrav til GUI

22 22 Prototyper Ikke-funktionel prototype: Kun en GUI-skal uden funktionalitet, f.eks lavet i Power- Point eller på papir. Evolutionær prototype: Der bygges mere og mere funktionalitet på prototypen, alt efter respons på tidligere prototyper Pilot-prototype: Hvis systemet skal installeres på mange arbejdspladsser

23 23 Farer ved prototyper Prototyper er gode, men… Brug for klar afstemning af forventninger mellem kunde og leverandør (”det virker jo ikke…?”) Hvordan håndteres kundens ønsker om ændringer? Hvem tager den endelige beslutning? Hvem skal betale?

24 24 Databaser Typisk vil vi starte med ret vage ”fortællinger” om hvilket data der er nødvendigt Vi har værktøjer til at bringe os fra en ”fortælling” om data, frem til en egentlig definition af en database

25 25 Databaser Context-diagrammer – hvilken sammenhæng bruges data i, hvem er interessenter i data ER-diagram – fra fortælling (navneord, udsagns-ord, talord), til mere formel definition af relationer mellem data

26 26 System-design Hvad er ”system-design”? Design på et overordnet niveau –Hvad er den tekniske platform? –Hvilken teknologi baserer vi løsningen på? –Integration til anden IT hos kunden? Sjældent et forretningskrav, men kan være dikteret af forhold hos kunden (tradition, eksisterende platform, med videre)

27 27 Detaljeret design Detaljeret design er mest en problem- stilling for dem som udvikler løsningen Måske kan dele af løsningen baseres på et allerede eksisterende koncept Omhandler også udvikling af test på dette niveau, f.eks enhedstest Ikke et niveau som involverer kunden

28 28 En proces for alle? Nej, man må vælge en proces som passer til den kunde man udvikler til I nogle tilfælde kan man rent faktisk specificere næsten alt på forhånd Den kloge organisation vælger den proces som passer til kunden

29 29 En proces for alle? Meget svært at give generelt gyldige retnings- linier for valg af proces, men alligevel: –Er kunden indstillet på fleksibilitet mht pris og tids- punkt for leverance, er en iterativ proces baseret på f.eks prototyper at foretrække (størst chance for at lave det, kunden har brug for) –Jo mere teknisk orienteret projekt, jo større mulighed for at specificere krav på forhånd –Jo mere bruger-orienteret projekt, jo mindre mulighed for at specificere krav på forhånd

30 30 En proces for alle? Yderligere retningslinier –Er fokus på deadline frem for funktiona- litet, bør en iterativ model med korte iterationer bruges –Er funktionel kvalitet højeste prioritet, skal test-delen af projektet gives tilsvarende høj prioritet –Hvis systemet skal anvendes af mange brugere, er bruger-involvering ofte nødvendigt ifm GUI-udvikling

31 31 Typiske problemer Problemer i SW-udvikling er ikke altid relateret til krav… Problemer kan også være –Organisatoriske –Teknologiske –Finansielle –Juridiske –Menneskelige

32 32 Manglende opmærksomhed Selv kritiske projekter kan mangle opmærksomhed fra kundens ledelse Svært at få ledelsen i tale Involverede personer fra kundens side sidder for lavt i organisationen Svært at få truffet ”endelige” beslutninger Modvillighed mod at frigøre ressourcer til projektet, f.eks kommende brugere

33 33 Kod for satan!! Selv om man er enige om en vandfalds- model, bliver kunden utålmodig efter at se ”resultater” = et program ”Vi har ikke tid til at skrive, vi må videre!!” Behandlingen af krav, designs med videre bliver sjusket og forivret Udviklere ”præmieres” kun for udvikling af programkode

34 34 Sølvkuglen En blind tro på, at et givent problem skal løses ved brug af en bestemt teknologi Pres for at bruge bestemt teknologi kan komme både fra kunde og leverandør Kunde: Vi har altid brugt produkter fra X Leverandør: Teknologi Y er sååååå smart!

35 35 I pose og sæk Kunden forventer fast pris, men vil også kunne ændre projektet undervejs Kan nemt give konflikter internt i leverandørens organisation – hvem sælger, hvem leverer? ”Kunden har altid ret”…

36 36 Estimater og usikkerhed Et estimat på en vagt formuleret opgave er naturligvis meget usikkert I første faser af udvikling er en usikkerhed på en faktor 4 ikke urealistisk Kan være meget svært at acceptere for andre…

37 Estimater og usikkerhed

38 38 Estimater og usikkerhed Et ”estimat” på 400 timer betyder egentlig ”mellem 200 og 800 timer” Hvordan planlægger man med intervaller? Tager worst-case? Middelværdi? Skal den som estimerede ”straffes”, hvis det tager 800 timer?

39 39 Sneplovs-modellen Vi har estimeret den første fase af et projekt til at kræve 300 mande-timer, men den tog i praksis 600 mande-timer… Mulige reaktioner –Gange alle øvrige estimater med 2, og dermed udskyde leverancen –Få flere folk på projektet –Regne med, at vi kan indhente de 300 timer senere (almindelig reaktion…)

40 40 Slips vs. håndbajer Leverandøren mangler ”social kompeten- ce” til at begå sig i kundens organisation Kan vi ikke holde møde 1.maj!?

41 41 Ublu optimisme ” Denne gang laver vi ikke de samme fejl” ”Denne nye teknologi er let at lære” ”Vores udviklere arbejder 100 % på projektet” ”Vi kan altid bare sætte flere folk på projektet” ”Virker det ét sted, virker det alle steder” Hvorfor er ublu optimisme ofte et problem? Måske (igen) pga forskel på, hvem der sælger et projekt, og hvem der skal udføre projektet

42 42 Hvad vælter læsset