Vurdering af kvalitet en note af Tove Zöga Larsen Kvalitet... 2 Test... 2 Hvordan finder man testdata?... 2 Dokumentation af test... 3 Review... 3 Vurderingskriterier... 3 Gennemførelsen af et review... 4 Kundens eller brugerens vurdering... 4 Vurder kvalitet på flere måder... 6 Side af 6
Kvalitet Der er mange forskellige opfattelser af, hvad der forstås ved kvalitet. I denne note vil jeg fortrinsvis begrænse mig til at forstå kvalitet som noget, der lever op til specifikationen. Dvs. kvalitet er det, der opfylder de krav, der er stillet hverken mere eller mindre. Det er en meget forenklet opfattelse, men den er god at bruge i forbindelse med en første vurdering af kvaliteten af et produkt, fordi kvalitet på denne måde kan beskrives og forstås ret præcist. Test Hvis man vil vurdere kvaliteten af et lille program, man har lavet, kan man undersøge, om programmet gør det, der var meningen, og om det gør det rigtigt. Hvis du f.eks. har lavet et program, der beregner gennemsnittet af tre tal, så kan du teste programmet ved at starte programmet, indtaste 3 tal, bede om gennemsnittet, og så se på resultatet. Hvis du indtastede tallene, 2 og 3, og programmet beregnede gennemsnittet til at være 2, har programmet regnet rigtigt. Det er desværre ikke nogen garanti for, at programmet ikke har fejl! For hvad sker der, hvis du indtaster tallene, -2 og 3? Eller -, 0 og 99999999999999999999999999999? Eller 23.235, A og 2? Eller noget helt andet? Jamen, hvornår kan man så sige, at programmet regner rigtigt? Ja, i princippet vil det være en stor (dvs. det vil tage uendelig lang tid) opgave at påvise det, for så skulle man jo teste programmet med alle tænkelige tal i alle tænkelige kombinationer. Men vi vil også ofte stille os tilfreds med mindre, for hvis vi har set, at programmet virker i en del tilfælde, vil de fleste nok være villige (endda tilbøjelige) til at antage, at det også virker i alle andre tilfælde. Hvis du derfor vil vise (eller rettere sandsynliggøre), at dit program regner rigtigt, så vis mig nogle velvalgte eksempler, hvor det gør det. Men måske er der også eksempler, hvor programmet ikke regner rigtigt? Hvad sagde dit program f.eks. til tallet A? Jamen, jeg synes da foreløbig, at det er helt i orden, hvis programmet ikke kan regne med A, for det er jo slet ikke noget tal! Så et eksempel, hvor programmet ikke regner rigtigt, men opfører sig på en måde (f.eks. går ned), så det viser, at det her input ikke var acceptabelt, er også en god ting, for det viser mig, hvad programmets begrænsninger eller forudsætninger er. Hvordan finder man testdata? Vi behøver altså ikke at teste programmet med alle tænkelige tal, men kan nøjes med at teste programmet med nogle udvalgte testdata 2. Disse testdata kan man finde frem til, ved at se på, hvad det er for input, der er gyldigt henholdsvis ugyldigt for programmet. I en god test prøver man programmet af med både gyldige og ugyldige input. Derudover er det sikkert også interessant, hvordan programmet håndterer ekstreme input f.eks. negative Du kan læse om forskellige definitioner på kvalitet i Stig Bang m.fl: Kvalitetsstyring i Systemudvikling. 2 I Softwaretest kom godt i gang med testen fra Dansk IT står der om, hvordan man finder testdata Side 2 af 6
tal eller meget store tal. Og endelig kan der være såkaldte grænseværdier, som måske skal behandles på en særlig måde i programmet f.eks. 0. Dokumentation af test Det er vigtigt, at dokumentere testen 3. Dels fordi man så har bedre mulighed for at gentage testen, hvis man ændrer i programmet, og dels fordi man så kan vise andre, hvad det er programmet kan (og ikke kan). En test som den, jeg har forklaret om ovenfor, kan f.eks. dokumenteres således: Test nr Input: Tal Tal 2 Tal 3 Forventet output: Faktisk output: 2 3 2 2 2-2 3 0,667 0,66667 3-0 99999999999999999999999999999 Fejl Fejl 4 23.234 A 2 Fejl 27 I kolonnen med Faktisk output er her noteret, hvordan programmet rent faktisk reagerede på de nævnte input. Ved at sammenligne det forventede og det faktiske output kan man så vurdere, hvor rigtigt man mener, programmet regner. Review Undervejs i et systemudviklingsforløb laver man jo mange andre ting end at skrive programmer. F.eks. domænemodeller, use cases eller design af brugergrænsefladen. Disse produkter danner ofte grundlag for det videre arbejde, så derfor vil det være en fordel, hvis man kan sikre sig, at de har en rimelig kvalitet. Men man kan jo ikke teste en domænemodel, så hvordan gør man så? Jo, hvis man kan beskrive hvilke krav, der er til domænemodellen, så kan man sammenligne domænemodellen med disse krav, og se hvor godt de stemmer overens. Lidt på samme måde som når man tester, hvor man sammenligner det forventede output med det faktiske output. Det er det, man gør i et review 4. Vurderingskriterier De krav, der er til en domænemodel, kunne man også kalde vurderingskriterier det er jo de kriterier, domænemodellen skal vurderes i forhold til. Larman sammenligner det at udarbejde en domænemodel med at tegne landkort, og opstiller derudfra nogle retningslinier for domænemodellen: Domænemodellen/landkortet må ikke indeholde noget, der ikke findes i det område/domæne, der modelleres De ting, der vises på domænemodellen/landkortet, skal hedde det samme, som de gør i området/domænet, der modelleres Kun de ting i området/domænet, der er relevante i forhold til domænemodellens/landkortets formål, skal tages med. Disse retningslinier kan bruges som vurderingskriterier i et review af en domænemodel, men der kunne sagtens opstilles flere. 3 Poul Staal Vinje skriver i Softwaretest teknik, struktur, metode bl.a. om dokumentation af test 4 Du kan bl.a. læse om reviews i Håndbog i Struktureret programudvikling af Stephen Biering-Sørensen Side 3 af 6
Gennemførelsen af et review Når man vil have et produkt reviewet skal man således ikke kun fremstille selve produktet men også vurderingskriterierne. Reviewet foregår så ved, at forfatteren, som har lavet produktet og opstillet/fundet vurderingskriterierne, beder en reviewer om at sammenligne de to ting. Revieweren kan f.eks. være en kollega. Revieweren får så produktet og tid til at gennemgå det i forhold til vurderingskriterierne. Efterfølgende kan der holdes et møde mellem de to, hvor revieweren fortæller forfatteren, hvor produktet ikke svarer til vurderingskriterierne. Det er ikke meningen, at revieweren skal rette i produktet han skal blot fortælle, hvor det ikke passer med vurderingskriterierne. Så er det op til forfatteren at vurdere, om det er så alvorligt, at der skal rettes, og finde ud af, hvordan der evt. skal rettes. I stedet for at holde et møde kan revieweren også aflevere en skriftlig vurdering af produktet i forhold til vurderingskriterierne, men det vil ofte kræve mere arbejde af revieweren, og forfatteren får heller ikke mulighed for at stille uddybende spørgsmål til reviewerens vurdering. Nedenfor er et eksempel på et resultat af at reviewe en domænemodel for Danske Besøgsvenner i forhold til ovennævnte vurderingskriterier. UDFØRER 0.. 0..3 VÆRT -adresse -hårfarve -sats LØN BESØG -dato -kommentar Følgende forhold stemmer ikke med vurderingskriterierne: Klassen LØN findes ikke i domænet besøgsvennerne er ulønnede. Navnet på klassen UDFØRER er ikke eet, der bliver brugt i domænet. Attributten hårfarve på klassen VÆRT er ikke relevant der tages f.eks. ikke hensyn til hårfarve, når der skal findes en besøgsven til en vært. Denne tilbagemelding kan forfatteren så bruge til at vurdere, om der skal ændres i domænemodellen. Hvis der er tale om store ændringer, kan det også være, at det er en god ide at få domænemodellen reviewet igen, når ændringerne er lavet. Kundens eller brugerens vurdering Ved at bruge tests og reviews gennem systemudviklingsforløbet kan man som systemudvikler gøre meget for at sikre, at man udvikler systemer, som lever op til kravene. Men derfor er det alligevel ikke sikkert, at kunden oplever systemernes kvalitet som høj. Det kan f.eks. være tilfældet, hvis de krav, der er stillet til systemet, ikke svarer til de forventninger, kunden eller brugeren har til systemet. Side 4 af 6
Derfor er det nødvendigt at supplere den interne kvalitetsvurdering, der kan foretages ved hjælp af tests og reviews, med kundernes og brugernes vurderinger. Det kan også gøres på mange måder, men det vigtigste er nok, at kunden og/eller brugeren får reel mulighed for at tage stilling til det produkt, man ønsker en vurdering af. Hvis man f.eks. ønsker brugerens vurdering af, om domænemodellen giver et godt grundlag for det videre arbejde, kan det være svært for brugeren at tage stilling til klassediagrammet, som er en abstrakt beskrivelse af domænet. Hvis man derimod præsenterer brugeren for en objektmodel, som er et konkret eksempel på objekter og deres sammenhænge i domænet, vil brugeren bedre kunne tage stilling til modellen. Et eksempel på en domænemodel (og nu har jeg rettet de fejl, der blev påpeget i reviewet;- ) med tilhørende objektmodel for Danske Besøgsvenner ses her: BESØGSVEN 0.. 0..3 VÆRT -adresse BESØG -dato -kommentar Og objektmodellen kunne se sådan ud: Side 5 af 6
Besøgsven- Objekter: Besøg-objekter: Vært-objekter: Torben Søvej 2, Ringe m 87 Ib m 47 4/9-09 Ulla havde svært ved at huske 0/9-09 Ulla var træt Ulla lodsvej 4, Århus k 7 Daniel m 53 Tove Skovvej 4, Nyborg k 78 Peter m 60 Inge Søvej 3, Ringe k 23 Ved at gennemgå en sådan objektmodel med en medarbejder fra Danske Besøgsvenner, vil det være nemmere at drøfte forskellige spørgsmål til domænemodellen. F.eks. om det kan være rigtigt, at en vært ikke altid er knyttet til en besøgsven: Inge er ikke knyttet til en besøgsven, for hun vil ikke have en mand, og vi har ikke nogen kvindelige besøgsvenner i øjeblikket - men hov, hvordan kan modellen for resten vise, at Inge ikke vil have en mandlig besøgsven?. Eller hvordan man kan vise, at Torben faktisk var med på Ibs sidste besøg hos Ulla? Modellen kan ikke håndtere, at et besøg involverer mere end en vært, så hvis systemet skal kunne holde styr på det, skal domænemodellen ændres. Vurder kvalitet på flere måder Tests, reviews og brugervurderinger giver således hver på sin måde en vurdering af et systems kvalitet, men for at få en bredere vurdering af kvaliteten i udviklingen af systemer er det nødvendigt at kombinere de forskellige former for vurderinger. Der er også forskel på, hvornår de forskellige vurderinger bedst kan foretages. Det vil typisk være sådan, at der er flere reviews end tests i starten af forløbet, senere er der flere tests, og de fleste brugervurderinger vil ligge henholdsvis i starten og i slutningen af systemudviklingsforløbet. Side 6 af 6