Udvikling – del II

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

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

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)

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 5

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

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

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

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

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 10

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

V-modellen

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

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

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 15

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?

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

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

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

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

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

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

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?

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)

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