RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

2002-05-29 LiTH RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 Richard Andersson 2002 SAMMANFATTNING Fagans inspektionsmetod utvecklades ursprungligen för att finna fel och brister i design- och koddokument. Metoden kan dock användas på alla typer av dokument. Första steget är att planera inspektionen, då bland annat en grupp med inspektionsmedlemmar väljs ut. Checklistor skapas helst unika för varje dokumenttyp, samt tid och plats för inspektion bestämms. Efter detta följer fem aktiviteter i form av genomgång, förberedelse, inspektionsmöte, omarbete och till sist uppföljning. Felfinnandet pågår under det tredje och det fjärde steget. RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 1

Dokumenthistorik 1 Dokumenthistorik Version Datum Kommentar 1.0 940221 Deluppgift 1 i hemtentamen i PUMPRO. 1.1 950501 Förbättring av PUM4, 1995 + exempel på granskningsprotokoll. 1.2 960216 Deluppgift 1 i hemtentamen i PUMPRO. 1.3 960511 Förbättring av Anna Fredén, 1996. Checklista med specifika dokumentfrågor tillagt. 2.0 970214 Förbättring av Zhulia Ayani, 1997. Avsnitt om mått på processen tillagt. 2.1 970604 Förbättring av Zhulia Ayani, 1997. Nya checklistor tillagt. 2.2 990610 Förbättring av Homan Shahraki,1999. Anteckningsunderlag för fel tillagts + en del omformuleringar o små korrigeringar gjorts. 2.3 000531 Förbättring av Grace Cheng, 2000. Språkfel och småändringar har gjorts. 3.0 020517 Stora strukturella förändringar. Flyttat om och omorganiserat kapitlen. Rättningar och omformuleringar. Ändat referenser, lagt till korsreferenser. 2 Syfte Inspektioner är bara en typ av ett flertal olika kvalitetskontroller som finns. Kvalitetskontroller syftar till att garantera slutprodukten en viss standard. Detta dokument är framtagen för att beskriva Fagans metod. Fagans inspektionsmetod har som huvudsyfte att: Finna fel och brister i det granskade dokumentet Identifiera avvikelser från standarder Kontrollera att ändringarna blir åtgärdade Samla in data om uppkomna fel och brister Föra statistik över funna fel och brister för att kunna använda erfarenheter från dem i senare projekt. 2 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Användningsområde 3 Användningsområde Inspektion är en formell, effektiv och ekonomisk metod för att hitta fel i design- och koddokument, vilket beskrivs i Design and code inspections to reduce errors in program development [Fagan, 1976]. I ett försök att begränsa de mycket höga extrakostnader som uppkom i programvaruprojekt då fel upptäcktes i slutskedet, började IBM undersöka en ny sorts testning. Detta test utfördes av olika projektdeltagare organiserade i ett inspektionsmöte och gick ut på att fel och brister i ett dokument skulle blottläggas så tidigt som möjligt. Michael E. Fagan, kvalitets-ingenjör vid IBM, presenterade sin metod i en artikel i IBM systems journal 1976. I artikeln beskriver Fagan en metod att granska olika slags dokument. Speciellt beskrivs inspektion av design- och koddokument. Fagan påvisar också nyttan i att även inspektera kravspecifikationer, testplaner, testfall, interaktionsbeskrivningar och så vidare. Eftersom Fagans artikel i stort sett endast tar upp inspektion av design- och koddokument så kommer detta dokument främst att behandla dessa områden. Figur 1 visar när, under en produkts utveckling, som inspektioner utförs. Ju senare ett fel upptäcks i utvecklingsfasen desto dyrare blir det att rätta till det RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 3

Förutsättningar. Någon skriver Kollegor ger kommentarer Projektledaren ger kommentarer Inspektion Modultester Systemtester På-platsen-test Normal drift och användning Figur 1. Inspektion är endast en av flera kvalitetskontroller. 4 Förutsättningar Nedan beskrivs de viktigaste förutsättningarna innan en inspektion påbörjas. 4.1 Process Först och främst är det viktigt att den process man arbetar efter är klart definierad och att milstolparna är bestämda. En milstolpe står för att vissa krav måste vara uppfyllda vid en viss tidpunkt. För att kontrollera dessa krav så föregås varje milstolpe av en fasinspektion. Denna inspektion talar om huruvida kraven för milstolpen är uppnådda och därmed om man får fortsätta eller inte. 4 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Förutsättningar 4.2 Inspektionstidpunkt Som allmän regel gäller att ingen produkt ska inspekteras innan den är klar för leverans. Med andra ord så gäller att om inspektionen inte hade blivit gjord skulle produkten ha leverats i befintligt skick. 4.3 Inspektionsgrupp En inspektion ska genomföras av en grupp projektdeltagare. Denna grupp benämns inspektionsgruppen. Fagan rekommenderar att följande fyra personer ska ingå i gruppen: Moderator Designansvarig Kodansvarig Testansvarig. De personer som ska delta i inspektionen tilldelas olika roller, beroende på vilken typ av dokument som ska inspekteras. En förklaring till vilka roller de olika personerna intar följer nedan. Moderator Moderatorn fungerar som ordförande under inspektionen och styr inspektionen för att effektivt kunna hitta de fel och brister som finns i granskningsobjektet. Moderatorns roll kan sammanfattas i följande sju punkter: Organisera alla praktiska detaljer kring inspektionen. Det är moderatorns ansvar att se till att alla dokument finns tillgängliga samt att informera de som ska närvara vid inspektionen om när och var den ska ske. Leda inspektionsmötet. Se till att inspektionsmötet följer de regler som finns för inspektioner på företaget. Se till att inspektionsprocessen håller en hastighet som medför att gynsamm produktivitet nås, det vill säga antal funna fel per timme maximeras. Notera funna fel och klassificera dem. Föra statistik över funna fel och feltyper. Överlämna listan med funna fel till den som ska rätta felen. Kontrollera att alla felen verkligen har blivit åtgärdade. Designansvarig Designansvarig är den person som ansvarar för designarbetet. Denna person är mycket viktig och central under inspektionsarbetet av design- och koddokument, eftersom personen har varit med och utformat huvudidéerna. Om samma person skulle vara ansvarig för både design-, kodnings- och testarbetet så får denna person uppträda i rollen som designansvarig medan de andra rollerna besätts av utomstående programmerare och testare. RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 5

Förutsättningar Kodansvarig Kodansvarig är den person som ansvarar för kodningsarbetet. Kodansvarig är till stor hjälp vid inspektion av programkod. I och med att varje programmerare oftast har sina egna små trick och lösningsmetoder kan det underlätta mycket att få vägledning vid inspektionsarbetet. Testansvarig Testansvarig är den person som ansvarar för testarbetet. Testansvarig har ett mycket stort ansvar under denna fas. Här gäller det att han eller hon är insatt i de fel som kan uppkomma och orsaka problem längre fram i projektet. Alltså ska en mycket programmeringskunning och helst en mycket erfaren person utses till testansvarig. Dessa fyra personer är de som Fagan rekommenderar. Fyra personer är en bra grund för en inspektionsgrupp och bör inte överskridas för att effektiva inspektioner ska kunna utföras. Om omständigheter kräver fler personer till en inspektion är det bättre att dela upp inspektionen i två delinspektioner istället för att utöka antalet inspektörer. 4.4 Tidsplanering Liksom alla andra aktiviteter under programvaruprojektet måste inspektionen planeras. Det är viktigt att rimlig tid finns avsatt för alla inspektionsaktiviteter, annars kommer inspektionen inte att uppfylla sitt syfte. För att kunna avsätta rätt tid kan man använda sig av erfarenheter från andra projekt. Tabell 1 ger ett visst mått på hur mycket tid som ska avsättas för inspektion av design- och koddokument. Dessa värden kan vara svåra, om inte omöjliga att översätta till andra typer av dokument. Exempelvis är projektplanen och användarhandledningen mera lingvistiskt utformad. Erfarenhet säger att antal rader per timme där kan ökas betydligt. Delsteg Designinspektion Rader per timme Kodinspektion Översikt 500 - Förberedelse 100 125 Inspektionsmöte 130 150 Omarbete 20 h per 1000 rader 16 h per 1000 rader Tabell 1: Uppskattning av tidsåtgång för designoch koddokument 6 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Genomförande 4.5 Effektiva inspektioner För att få effektiva inspektioner är det bra om inspektionsgruppen har bra riktlinjer att rätta sig efter. Nedan följer fem frågor som är bra att ha tänkt igenom innan inspektionen börjar: 1. Vilka typer av fel ska vi leta efter? 2. Hur ska vi hitta dessa? 3. Hur skriver vi bra riktlinjer för att hitta fel? 4. Hur ska inspektionsmetodiken anpassas till det material som granskas? 5. Hur sker återkopplingen efter inspektionen? Det åligger främst moderatorn att finna svaren på dessa frågor, men även kvalitetsansvarig bör på ett tidigt stadie definiera vilka riktlinjer som ska gälla för inspektionerna. För att finna vissa typer av fel kan checklistor underlätta. Dessa delas ut i god tid innan inspektionen och är till för att hjälpa dem som ska närvara vid inspektionen att koncentrera sig på vissa typer av fel. 5 Genomförande Fagans metod består av följande sju delsteg: 1. Planering Moderatorn planerar alla praktiska detaljer kring inspektionen. 2. Genomgång Inspektionsgruppen samlas för en allmän genomgång. Den person som är ansvarig för det dokument som inspekteras är föredragande. 3. Förberedelse Alla personer som ska delta i inspektionsmötet förbereder sig på egen hand. De går igenom det aktuella dokumentet, i första hand för att förstå dess innebörd, men även för att finna fel. Det är viktigt att alla som deltar i inspektionsmötet är väl förberedda. 4. Inspektionsmötet En person läser igenom dokumentet steg för steg enligt moderatorns instruktioner. Frågor och oklarheter tas upp. Sekreteraren antecknar och markerar alla hittade fel. 5. Omarbete Redaktören åtgärdar de fel och brister som påvisades under inspektionsmötet. 6. Uppföljning När man lagt ned så mycket resurser på att upptäcka fel och brister så måste man även kontrollera att dessa åtgärdas på ett korrekt sätt. Dessutom bör RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 7

Genomförande man kunna dra nytta av felstatistiken för att göra efterföljande inspektioner effektivare. 7. Diskussion Inspektionsmötet kan förlängas med en timme för eventuella diskussioner. Nedan beskrivs de sju delstegen mer ingående. 5.1 Planering Moderatorn organiserar alla praktiska detaljer kring inspektionen. Han eller hon bestämmer tid, plats och vilka som ska delta i inspektionen. Det är moderatorns ansvar att se till att alla dokument finns tillgängliga och att informera deltagarna om när och var inspektionen ska äga rum. Erfarenhet har visat att ju noggrannare planering man har desto mer produktivt kan inspektionsmötet bli. 5.2 Genomgång Alla som är inblandade i inspektionen ska närvara under genomgången. Redaktören går i detalj igenom sitt dokument för att förklara uppläggning och tankegångar. Det dokument som ska inspekteras distribueras till alla deltagare. Genomgången tar ungefär en timme. Genomgången är den enda utav de fem punkterna som Fagan kan tänka sig att stryka. Det är nämligen inte alldeles säkert att denna översiktliga genomgång enbart är av godo. Redaktören påverkar de övriga i gruppen genom att förklara sina egna lösningar, vilket gör att gruppens förmåga att själva finna lösningar kanske påverkas. 5.3 Förberedelse För att alla medlemmar av inspektionsgruppen ska vara insatta i materialet, går varje person igenom det på egen hand och studerar dokumentet utifrån sin egen inspektionsroll. Här är det viktigt att koncentrationen läggs på övergripande fel. Enligt Fagan hittas det oftast inte så många fel under denna del som man kan tro, de allra flesta fel dyker upp först under själva inspektionsmötet. För att hjälpa inspektörerna att finna fel kan en checklista delas ut innan förberedelserna påbörjas. Denna checklista används sedan som bas av inspektören. Annat material i form av exempelvis en rankinglista, en lista med de vanliga typer av fel, kan också användas som hjälpmedel. Checklistorna kan med stor fördel vara specialutformade för varje dokumenttyp. Det krävs lite mera arbete initialt att ta fram dessa. Däremot är sannorlikheten större att man hittar fler fel, eller snarare för dokumentet viktigare fel, med hjälp av specifika checklistor. Checklistorna bör inte vara för långa. Det räcker med ungefär 20-25 frågor, det vill säga ungefär vad som får plats på en A4-sida och är vad som fungerar i praktiken. Fler frågor medför inte bättre granskningar och större antal funna fel, utan snarare det att granskarna har svårare att koncentrera sig på de viktiga felen. 8 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Genomförande 5.4 Inspektionsmöte Innan mötet börjar är det bra om moderatorn kollar upp att samtliga i inspektionsgruppen verkligen har satt sig in i materialet som ska granskas. Om så inte är fallet är det bättre att skjuta upp mötet. Samtliga dokument som det inspekterade dokumentet refererar till ska finnas tillgängliga under mötet till ett senare datum. Mötet leds av moderatorn och ska helst inte vara i mer än två timmar, vilket motsvarar den maximala tid som ett effektivt inspektionsmöte kan bedrivas. Mötet kan efter dessa två timmar ytterliggare sträcka sig en timme om moderatorn och samtliga gruppens medlemmar anser att detta är effektivt. Dokumentet inspekteras med den hastighet som ger effektivast utdelning på att hitta fel. För att öka effektiviteten tilldelas deltagarna olika roller. En läsare kan utses, som går igenom dokumentet bit för bit och tolkar det från sitt perspektiv. De andra inspektörerna kommenterar om det finns luckor, oklarheter eller felaktigheter. Inspektionsregler är strikta och kan uppfattas av en del som onödigt arbete, men erfarenhet har visat att inspektion är en effektiv och ekonomisk metod för att kontrollera kvalitet hos en produkt. Med andra ord är det lönsamt att utföra effektiva inspektioner. Alla typer av defekter i dokumentationen inspekteras, inte bara logikfel eller funktionsfel. Checklistor kan användas för att lättare kunna koncentrera sig på en viss typ av fel. När ett fel eller en brist upptäcks noteras den av moderatorn. Detaljer som felets typ, felets art samt svårighetsgraden för felet ska också noteras. Statistik över alla typer av defekter ska skrivas ned och utvärderas. Lösningen till felet diskuteras inte. Det är effektivare att ägna sig åt en sak i taget och att bara försöka finna fel under mötet. När mötet är avslutat ska moderatorn, inom en arbetsdag, rapportera resultatet av inspektionsmötet till sina överordnade. Alla detaljer som ska omarbetas och följas upp bör ingå i rapporten. 5.5 Omarbete Efter inspektionsmötet tar redaktören för det inspekterade dokumentet över för att utföra omarbetet, det vill säga att korrigera de fel som påträffades under förberedelsen och inspektionsmötet. 5.6 Uppföljning Det åligger moderatorn att följa upp det arbete som redaktören utför efter inspektionsmötet. Eftersom ändringar har skett i dokumentet dyker frågan upp huruvida dokumentet ska inspekteras ytterligare en gång. En tumregel kan vara att om mer än fem procent av dokumentet är omarbetat så ska en helt ny inspektion utföras. Om däremot endast en liten del av dokumentet omarbetats kan man nöja sig med att enbart moderatorn verifierar det omarbetade materialet. Det är mycket vanligt att korrigeringar som utförts anses vara fria från fel. Denna inställning leder ofta till att de ändringar som införts har högre fel- RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 9

Genomförande procent än det ursprungliga dokumentet. Moderatorn har som uppgift att följa upp de ändringar som genomförts och avgör ifall dokumentet ska inspekteras ytterligare en gång. Att utföra en ny inspektion är ett sätt att kontrollera resultatet. Beroende på hur stor del som omarbetats kan inspektionen anpassas till rimlig storlek. 5.7 Diskussion Inspektionsgruppen får inte diskutera lösningar under inspektionsmötet. Eftersom bra förslag eller tips kan vara värdefulla för omarbetet kan inspektionsmötet förlängas med en extra timme där inspektörernas personliga åsikter om arbetet och förslag på förbättringar kan diskuteras. 10 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Resultat 6 Resultat Resultatet av en inspektion är inte uppenbart, men med en del analyserande kan mycket information utvinnas. Dessa resultat påverkar såväl dokumentet, processen samt projektdeltagarna i nuläget och i framtiden. Figur 2 påvisar några av de resultat som inspektionen leder till. Operation 1 beskriver en fas eller aktivitet som slutförts. Triangeln I står för en inspektion innan nästa fas eller aktivitet, Operation 2, påbörjats. De resultat i form av åter- och framkoppling som erhålls beskrivs detaljerat i figur 2.. Operation 1 Operation 2 I Korrigera brister i processen Omarbete Korrigera kortsiktiga problem Återmatning av felaktigheter för att uppmärksamma enskilda eller samtliga programmerare Speciella ändrings- eller omarbetningsrekommendationer Analys Rankinglista över moduler med många fel Rankinglista över olika typer av felaktigheter Antal felaktigheter per mängdenhet jämfört med genomsnittet Återkoppling Utbildning för inspektörer och moderatorer Vilka typer av fel att söka efter Bättre metoder för att finna varje typ av fel Uppföljning av detaljfel Antal funna fel per inspektionstimme Inspekterad mängd per inspektionstimme Framkoppling Figur 2. En översiktbild över resultaten från en inspektion. 6.1 Produkter De produkter som utfaller kan hänföras till tre olika kategorier; dokumentet, processen och projektmedlemmarna. Dokumentet Resultatet av en inspektion vad beträffar det inspekterade dokumentet är ganska påtagligt. Figur 2 påvisar detta genom den återkoppling som sker RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 11

Resultat från Omarbete till Operation 1. Resultatet blir en förändrad och förbättrad version av dokumentet. En annan aspekt är de rankinglistor som produceras enligt figuren ovan. En rankinglista över de moduler som har högst andel fel indikerar att vissa moduler bör göras om eller eventuellt inspekteras ytterligare en gång. Det kan också tyda på att dessa moduler ska integrationstestas mycket noggrant. Processen Figur 2 påvisar många punkter om hur processen förbättras efter en inspektion. Den statistik som nämns ovan, antal funna fel och inspekterad mängd, används för att förfina planeringen av inspektioner. Projektmedlemmarna En av de största fördelarna för redaktören av det inspekterade dokumentet är den omedelbara återkoppling redaktören får på sitt arbete. Denna snabba återkoppling verkar i ett utbildande syfte. Redaktören ser de fel som gjorts och kan förbättra sina arbetesmetoder omgående. Det är dock viktigt att i detta sammanhang tillägga att de fel som framkommer under en inspektion inte på något sätt ska användas mot redaktören. En annan fördel med inspektionsmöten i gruppform är spridandet av kunskap. Varje deltagare ska sätta sig in i det inspekterade dokumentet och får därigenom lära sig en annan del av projektet. Dessa personer kan sedan hjälpa till under flera faser i ett projekt då de har en bredare kunskapsbas att stå på. Dessutom sker detta utan extra kostnad. Kostnaden debiteras inspektionen och drabbar inte den enskilda individens kostnad. 6.2 Produktmallar En rankinglista som talar om vilka typer av fel som är vanligast är bra att ha som underlag vid nästa inspektion. Den kan då fungera som mall för nästa inspektion. 6.3 Statistik För att inspektioner och dess resultat ska vara observerbara för alla är det viktigt att föra noggrann statistik över allting. Ledningen kan lättare motiveras att fortsätta understödja inspektionsarbete om antal fel påvisas och tidsvinster redovisas. Att föra statistik över funna fel efter varje inspektion är en viktig del av kvalitetsarbetet. Man kan bland annat avgöra hur effektiv inspektionen varit och se hur inspektionsarbetet kan förbättras. Statistik ger inte alltid sanningen, men man kan ändå urskilja trender, som hur antalet funna fel beror på inspektionshastigheten. Statistiken är nyttig och hjälpsam för kvalitetsansvarig. Insamlad data om brister underlättar för företagsledningen att planera förbättringar, kostnader och eventuell utbildning av personal vid kommande inspektioner eller projekt. 12 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Fördelar med inspektioner 6.4 Utvärdering av processen För att kunna utvärdera processen, beskrivs nedan kortfattat hur processen fungerar och mätbara resurser anges. Resursmått Efter varje inspektion kan bland annat följande variabler mätas: Tiden i timmar för förbredelser (normalt cirka en timme). Tiden i timmar för att hitta ett fel vid inspektion. Inspektionshastighet i antal rader kod eller antal sidor per timme. Antal funna fel vid inspektion av det totala antalet fel. Antal funna fel per timme i relation till inspektionshastighet. Antal funna fel per mängdenhet jämfört med genomsnittet. Antal deltagare i varje inspektion (Mellan tre och fem deltagare anses vara lagom vid en inspektion). Antal papper som förbrukas. Antal fel per sida. Antal felaktiga sidor per dokument. Den totala tidsförbrukningen (omfattar både mötestid och förbredelsetiden) per granskningsgrupp. Om mätvärderna inte är tillfredsställande, kan vissa åtgärder tas inför nästa inspektion. Exempelvis om inspektionshastigheten är låg, kan oförbredda deltagare vara en orsak till detta. Det kan då vara lämpligt att avsätta mer tid till förberedelse. Produktmått Förändringar i det dokument som inspekterats kan anses vara en produkt. Produkten dokument är en kortsiktig produkt, dess liv slutar när leverans sker. Resultatet av en inspektion påverkar den process som används för att ta fram dokument. Denna produkt är iterativ, för varje inspektion som utförs förbättras processen en aning. Projektmedlemmarna, eller snarare deras fortbildning, kan också ses som en produkt av en inspektion. Blanketter för insamling av mätdata Inför varje inspektion skapas checklistor. Ranklistor och checklistor från tidigare inspektion kan med fördel omformas och användas. 7 Fördelar med inspektioner Utförandet av inspektioner innebär fördelar för ett företag. Nedan beskrivs de viktigaste områdena som en bra inspektioner kan påverka positivt. RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 13

Förklaring genom exempel Leverans Om defekter upptäcks tidigare kan eventuella förseningar i leveransen undvikas. Kostnader Ju fortare ett fel upptäcks, desto billigare är det att åtgärda det. Underhåll Kostnader för underhåll blir mindre om produkten innehåller så få fel som möjligt. Tillförlitlighet Produkten innehåller mindre defekter och brister. Produktivitet Produktiviteten ökas då företaget sparar på resurserna, en direkt effekt från ovanstående punkter. Testning Tid och resurser sparas i och med att testningen blir lättare att utföra. 8 Förklaring genom exempel Det är inte enkelt att visa i ett konkret exempel hur en inspektion går till. Därför redovisas istället en del resultat ur artikeln Experience with Fagan s Inspection Method [Doolan, 1992], där Fagans inspektionsmetod utvärderats. 8.1 Problemdomänen Artikeln Problemdomänen är skriven av E. P. Doolan, anställd vid Shell Research. Inom detta forskningslab finns programvarugruppen Seismic Software Support Group (SSSG). Denna grupp består av 25 medlemmar och de utvecklar ett programvarupaket för geofysiska beräkningar. Paketet består av mer än 2 miljoner rader Fortran-kod och det uppdateras minst två gånger per år, för att korrigera fel och möta nya krav. Varje år inkommer 300 till 400 felrapporter och varje rapport kostar i snitt $3,500 att åtgärda. Efter analys av dessa fel har det visat sig att en stor del av dem hänförde sig från brister i arbetet med att upprätta ordentliga kravspecifikationer innan programpaketet ändrades och utökades. 8.2 Införande För att åtgärda dessa problem beslutade man att först och främst följa en strikt standard vid uppförandet av kravspecifikationen samt även införa formell granskning av detta dokument. Man valde att använda sig av Fagans inspektionsmetod. 8.3 Resultat Nedan redovisas några siffror för att ge en ungefärlig uppskattning av en inspektion. Rapporten från Shell Research baseras på inspektion av elva kravspecifikationer om sammanlagt ca 500 sidor. Under förberedandet till inspektionsmö- 14 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Anpassning till PUM-kursen tet studerade deltagarna i genomsnitt fem till sex sidor per timme och det genomsnittliga antalet funna fel per sida var två till tre. Under själva inspektionsmötet täcktes i genomsnitt sju till åtta sidor per timme och ett fel upptäcktes i genomsnitt var tredje minut (Detta blir cirka 40 funna fel under två timmar). Tillsammans lades i genomsnitt 2,2 timmars arbete ned för varje sida i dokumenten. Normalt kan upp till 20 sidor per timme behandlas. Anledningen till att resultatsiffran var så låg i vårt exempel var det att diskussion om hur fel skulle lösas fördes under inspektionsmötet. Detta är inte vad Fagan rekommenderar, men man gjorde detta i alla fall, eftersom man då tyckte sig finna ännu fler fel. Det är svårt att göra en exakt jämförande studie mellan det gamla arbetssättet och det nya, men uppskattningsvis bedömmer författaren att för varje timme som läggs på inspektionsverksamhet sparas 30 timmar av annan verksamhet. 9 Anpassning till PUM-kursen Erfarenheter från kursen TDDB61, Programvaruprojekt i ett helhetsperspektiv, har visat att det inte spelar så stor roll vilka ansvarsområden de i inspektionsgruppen har. Det viktiga är att de kan lägga ner tillräckligt med tid på uppgiften. 9.1 Inspektioner för IEEE 730 De flesta grupper i PUM-kursen väljer att uppfylla den standard som anges i IEEE 730. Som ett minimum för denna standard krävs att följande inspektioner utförs: Mjukvarugranskning Preliminär designgranskning Kritisk designgranskning Verifikation och valideringsgranskning Inspektion av funktioner Fysisk inspektion Inspektion av del i process Administrativa granskningar Dessa inspektioner beskrivs närmare i RUT 10.5 Kvalitetsarbete enligt IEEE 730 v4.0 [Eklund, 2001], där det också definieras hur granskningarna ska genomföras. 9.2 Lösningar på vanliga problem Nedan beskrivs några tips och lösningar till problem som kan dyka upp. Det är svårt att börja använda sig av inspektion om det inte finns någon tidigare erfarenhet. Det är därför viktigt att välja ett lätt första projekt. RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 15

Förändringar av den ursprungliga processen Välj inspektörer som har bättre kunskaper om innehållet i dokumentet än andra gruppmedlemmar. Låt inspektionsprocessen vara levande. Gör små ändringar om det visar sig behövas. Det är svårt att upprätta korrekta arbetsrutiner från första början. Under delstegen förberedelse och inspektionsmöte, ska det kreativa arbetet att verkligen finna fel utföras. Det är lätt att säga, men mycket svårt att göra. Det är en stor fördel att ha lämpliga, omfattande och klara frågor. Även checklistor kan användas som hjälpmedel under förberedelserna. En möjlig väg för att skapa bättre hjälpmedel för feldetektering kan vara att göra en enkel förinspektion av dokumentet eller delar av det. Under denna inspektion upptäcks förhoppningsvis en del fel. Efter en analys av felens art, varför de uppkommit, deras omfattning och så vidare, kan en instruktion sättas samman. Denna instruktion används sedan för vägledning under den ordinarie inspektionen. Att vara alltför många på en inspektion kan ibland innebära problem, eftersom det lätt uppstår diskussioner. Ett annat problem är att det är lätt att bli passiv då de andra har hittat samma fel som man själv. Dessutom åtgår en hel del extra tid i och med att det hade räckt att ett mindre antal personer varit närvarande. Erfarenheter från PUM-kursen har visat att tre till fyra personer är lagom för att bilda granskningsgruppen. 10 Förändringar av den ursprungliga processen När det gäller inspektioner finns det väldigt många olika varianter på hur dessa ska införas. Fagan introducerade sin ursprungsmetod 1976 och denna metod har sedan dess använts på många olika ställen. De brister som upplevts med metoden har ändrats och varje användare av metoden har sin egen tolkning. Därför är det svårt att redovisa några direkta brister som ännu inte åtgärdats. Det finns många varianter på Fagans ursprungliga metod. Under rubrikerna som följer tas några av dessa skillnader upp. 10.1 Förutsättningar Den största skillnaden mellan de olika metoderna brukar vara vilka som ska delta i inspektionen och hur många personer inspektionsgruppen bör bestå av. I Kursmaterialet till TDDB60 [Krysander, 1994] nämns att mellan tre till fem personer är lagom. Vidare sägs att redaktören inte ska delta. En klar skillnad från Fagans ursprungliga inspektioner står att finna i exempelvis Kvalitetssäkring av programvara [Oskarsson, von Schantz, 1987], som anser att redaktören är självskriven. Fördelen med att redaktören deltar är att denne får en direkt återkoppling på sitt sätt att arbeta och slipper göra om samma fel igen. Redaktören kan även förklara eventuella oklarheter. Flera typer av roller tas upp i Kvalitetssäkring av programvara [Oskarsson, von Schantz, 1987], jämfört med andra källor. Bland annat nämns sekreteraren som en roll. Denna person ska avlasta moderatorn vad det gäller ifyllnad 16 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Interna kommentarer av protokoll. Andra roller kan vara; underhållsfilosof, standardövervakare, användarrepresentant (ofta mycket bra vid inspektion av kravspecifikation), systemsamordnare, systemtestare samt teknik- och metodexperter. 10.2 Genomförande I Kursmaterial för TDDB60 [Krysander, 1994], tas det upp en stor skillnad i genomförandet, nämligen ett andra möte efter uppföljningen. Det är en allmän åsikt att detta möte ska ingå i metoden och flera källor redovisar den som ett delsteg i Fagans ursprungliga metod. Mötet har som avsikt att ventilera åsikter och förslag till lösningar, detta på grund av att dessa typer av saker inte ska diskuteras under inspektionsmötet. Det kan också diskuteras om huruvida diskussion ska vara tillåten på inspektionsmötet eller inte. Lite diskussion blir det alltid, men frågan är om moderatorn ska avbryta den med en gång eller tillåta den. Diskussioner kan nämligen leda till nya uppslag och ideer, dock får det aldrig bli en diskussion om småsaker eller om sådant som lika gärna kan tas upp vid senare tillfälle. En lösning kan vara att ha ett litet möte efter det ursprungliga inspektionsmötet, där de olika granskarna kan diskutera eventuella tveksamheter. 11 Interna kommentarer PUM4 1995: Efter att ha använt oss av inspektionsmetod enligt Fagan och även detta kapitel av RUT måste jag som kvalitetsansvarig tillägga att metoden fungerar bra men ska användas med förnuft. Man bör verkligen försöka få samtliga i granskningsgruppen att förstå vikten av inspektioner, det är nästan den tuffaste uppgiften som finns och som tyvärr inte finns omnämnt i Fagans metod. Det är också viktigt att man återkopplar resultatet till arbetsgruppen på ett sätt som gör att nästa inspektion går ännu smidigare och att produkten av nästa inspektion är bättre. Sedan bör man också studera vilka dokument som verkligen behöver inspekteras enligt Fagan och vilka som kan utgå denna metod och genomgå en lite mindre formell genomgång. Det är framförallt de dokument som ligger till grund för fortsatt utveckling som man behöver full kontroll över. Det som framförallt måste gås igenom i samtliga dokument är innehållets relevans. Stavfel och meningsbyggnader leder oftast inte till några större avvikelser tekniskt sätt förutom då de bäddar för missförstånd. Erfarenheter från kvalitetsansvarig i PUM3 1995: Deras inspektionsmöten hade en benägenhet att dra ut på tiden, som exempel kan nämnas att det första inspektionsmötet tog fem timmar att genomföra. Mötena drog ut så på tiden för att alldeles för många småsaker togs upp till diskussion. Så i grund och botten var det två grundfel, dels att det var svårt att styra gruppen så att inte lösningsförslag togs upp och dels var det alldeles för många småfel i materialet som skulle inspekteras. Problemet med gruppstyrningen kunde ha lösts genom att kvalitetsansvarig på tidigt stadie angett riktlinjerna för mötet och sedan hållit stenhårt på dem. Det an- RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 17

Interna kommentarer dra problemet bottnar i att inte tillräckligt med kommenteringar gjorts innan mötet kom till stånd. I sådant fall hade de kunnat koncentrera sig mer på de stora övergripande felen. De gjorde också misstaget att genomföra möten trots att inte alla i gruppen hade satt sig in i det material som skulle granskas. Istället borde mötet ha skjutits upp till senare tillfälle, eftersom det var rätt meningslöst att genomföra det när vissa aspekter i överhuvudtaget inte hade förhansgranskats. Kommentar vid första förbättring, 1997: Jag är medveten om en del brister som förekommer i checklistorna. Vissa frågor ville jag omformulera eller ta bort. Samtidigt vill jag bearbeta frågorna innan, därför har jag valt att byta eller ändra checklistorna senare. Kommentar vid andra förbättring, 1997: I avsnitt 3.3 om moderatorns roll står det att denna person ska vara mycket kunnig inom programmering, ha ledarförmåga och känsla för rollen som moderator. Just att vara mycket kunnig inom programmering är ingen nödvändighet vid inspektion av dokument som är mera lingvistiskt utformad, men eftersom Fagans metod är först och främst en metod för att granska designoch koddokument och det står i kapitel 2 Användningsområde att detta dokument kommer att behandla dessa områden, har jag valt att inte ändra i texten (avsnitt 3.3, om moderatorn). Erfarenheter från PUMPRO: Det är ofta svårt att klassificera fel som hittas vid formella granskningar och det blir inte bättre av att det kan vara olika personer som gör denna klassificering. En nogrann och genomtänkt klassificering av fel hjälper inspektörerna att lättare kunna bestämma feltypen. Att ha alltför stora grupperingar av fel försämrar resultatet från statistiken. Kvaliteten på dokumenten höjs om flera mindre formella granskningar genomförs innan en inspektion. Checklistor är bra hjälpmedel vid förbredelser inför en granskning. Moderatorns ansvar bland annat är att se till att granskarna har fått allt material som finns eller behövs innan varje granskning. Slutsatser som kan dras av formella de granskningar är: Se till att dokumentet inte innehåller enkla fel genom att utföra flera informella granskningar innan en inspektion görs. Var inte flera inspektörer än nödvändigt. Några kan bli passiva och mycket tid slösas bort. Se till att bra checklistor finns tillgängliga. 18 RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0

Referenser Välj inspektörer som har bättre kunskaper om innehållet i dokumentet än andra gruppmedlemmar. Erfarenheter från PUM6 2000: Håller med tidigare kommentarer om att det är svårt att klassificera felen man hittade. Det gör att felstatistiken får en lite större felmarginal då olika sekreterare klassar felen på olika sätt. En annan sak är att så många småfel blev kvar till inspektionen. Vi hittade nästan bara språk och layoutfel. Jag kände inte att det hindrade oss i inspektionen men kan inte låta bli att undra om vi hade hittat större och mer övergripande fel om inte småfelen fanns. En annan PUM-grupp som jag pratade med sa att deras dokument var väldigt bra kommenterade och att det underlättade deras inspektioner väldigt mycket. Så mitt råd är att göra noggranna kommenteringar innan inspektionen för att få bort småfel. 12 Referenser [Fagan, 1976] Fagan, Michael E. (1976), Design and code inspections to reduce errors in program development, IBM systems journal 15 (3), 182-211. [Oskarsson, von Schantz, 1984] Oskarsson, Östen, von Schantz, Christer (1987), Kvalitetssäkring av programvara, Mekanförbundets Förlag, 2:a upplagan, ISBN 91-524-1109-5. [Krysander, 1994] Krysander, Christian (1994), Kursmaterial TDDB60, Kapitel 2: The inspection process, 206-222. [Eklund, 2001] Eklund, Linda (2001), RUT 10.5 Kvalitetsarbete enligt IEEE 730 v4.0, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Doolan, 1992], Doolan, E. P. (1992), Experience with Fagan s Inspection Method, Software - Practice and Experience vol 22 (2), 173-182, februari 1992. 13 Exempel på protokoll och checklistor I detta kapitel finns det samlat några dokumentmallar för inspektioner. Ett exempel på granskningsprotokoll, en allmän checklista och checklistor med specifika frågor finns tillgängliga att användas. Protokollen kan med fördel användas under framförallt ett inspektionsmöte men även under förberedelser. De är även lämpliga att använda till någon mindre formell granskning. Dessutom bifogas även ett anteckningsunderlag för fel, som kan användas för att anteckna de fel som uppkommer under en inspektion. RUT utvecklingshandbok 10.2 Granskning enligt Fagan v 3.0 19

Exempel på protokoll och checklistor Inspektionsprotokoll Granskningsobjekt (namn, version) Antal sidor Datum Tid Plats Redaktör Moderator Sekreterare Granskare Förberedelsetid 20 Inspektionsprotokoll

Exempel på protokoll och checklistor Felstatistik Felstatistik Feltyp Feltyp Felklass Antal 1 = Stavfel, språk 1 2 3 4 5 6 P L S P L S P L S P L S P L S P L S 2 = Grammatik, översättning, ordval 3 =Innehållsfel (avsaknad, felaktighet, oklarhet) 4 = Konsistensfel (konflikter) 5 =Strukturfel 6 = Layoutfel 7 = Spårbarhet 8 = Övrigt Felklass P = Påpekande L = Litet S = Stort 7 P L S 8 P L S Summa: Inspektionsprotokoll 21

Exempel på protokoll och checklistor Resultat Område Ja Nej Kommentar Granskningen är komplett Dokumentet godkännes Del av dokument omgranskas Hela dokument omgranskas Felåtgärd Felen åtgärdas av Åtgärder kontrolleras av Beräknad tidsåtgång Feltyp Antal Andel (%) 1 = Stavfel, språk 2 = Grammatik, översättning, ordval 3 = Innehållsfel (avsaknad, felaktighet, oklarhet) 4 = Konsistensfel (konflikter) 5 = Strukturfel 6 = Layoutfel 7 = Spårbarhet 8 = Övrigt 22 Inspektionsprotokoll

Exempel på protokoll och checklistor Dokument Antal sidor Insp. mötestid Total tid/ Insp. Antal fel Fel/ sida Funna fel/ timme Felaktiga sidor Kommentarer: Inspektionsprotokoll 23

Exempel på protokoll och checklistor Allmän checklista Område Felnr Behandlar Kommentar Allmänt 001 Uppfyller dokumentet sitt syfte? 002 Är dokumentet välstrukturerat? 003 Är dokumentet skrivet på läsarens nivå? 004 Finns det en enhetlig linje i dokumentet? 005 Är dokumentet spårbart? Rubriker 101 Finns alla huvudämnen med? 102 Står alla rubrikerna i rätt ordning? 103 Är rubrikerna enligt mallen? 104 Är rubrikerna rätt stavade? 105 Är rubrikerna fria från avstavningar och punkter? 106 Har rubrikerna logiska, passande namn? 107 Är rubrikerna lagom långa? Innehåll 201 Är innehållet korrekt? 202 Är innehållet konsistent? 203 Är innehållet komplett? 204 Är innehållet realistiskt? 205 Är innehållet verifierbart? 206 Finns en sammanfattning? 207 Avspeglar sammanfattningen innehållet? 208 Finns en ordlista med förklaringar? 209 Finns en innehållsförteckning? 210 Finns en dokumenthistorik med? 211 Är dokumenthistoriken korrekt ifylld? 212 Finns titel, pum-grupp, redaktör och versionsnummer med på försättssidan? 213 Finns det ett alfabetiskt index? 214 Är alla nyckelord givna med liten bokstav? 215 Finns alla nyckelord med i indexet? 216 Nämns det vilka dokument som påverkas om detta ändras? 24 Inspektionsprotokoll

Exempel på protokoll och checklistor Område Felnr Behandlar Kommentar 217 Är kund och handledare nämnda på ett lämpligt sätt? Layout 301 Är all text enligt mallen? 303 Är styckesindelningen den bästa möjliga? 304 Har alla bilder numrering och förklaring över sig? 305 Ger tabeller och bilder ett positivt intryck? 306 Får tabeller och bilder plats på en sida? 307 Är alla sidor numrerade och rätt numrerade? 308 Är bilder och tabeller lagom stora? 309 Är bilderna väl förklarade? 310 Ger helhetsintrycket en stark känsla av att dokumentet är väl utformat? Språk 401 Är språket utformat så att kund och användare kan förstå? 402 Förklaras okända ord och definitioner (direkt eller i ordlista)? 403 Saknar dokumentet tvetydiga formuleringar? 404 Saknar språket grammatiska fel? 405 Är stavningen okej? 406 Är meningsbyggnaden korrekt? 407 Är förklaringarna tillräckliga? 410 Är alla förkortningar skrivna enligt projektstandarden? 411 Är dokumentet i avsaknad av svengelska? 412 Är alla meningar avslutade(.?)? 413 Är kommateringen godkänd? 414 Används ska och bli istället för skall och bliva? 415 Är meningarna lagom långa? Tidslinje 501 Följer dokumentet tidsplanen? 502 Har avsedd tid varit tillräcklig? Inspektionsprotokoll 25

Exempel på protokoll och checklistor Checklista för kravspecifikation Område Felnr Behandlar Kommentar 601 Är kraven verifierbara? 602 Är kraven tydligt specificerade? 603 Är kraven på installation och service väldefinierade? 604 Är kraven uppdelade i funktionella respektive icke-funktionella krav? 605 Finns det krav på befintlig programvara eller maskinvara som krävs för att använda systemet? 606 Är kraven på tillförlitlighet väldefinierade? 607 Är alla begränsningar på systemet beskrivna? 608 Är alla krav relevanta? 609 Är acceptansvillkoren tillräckliga? 610 Finns det specificerat vad som ska dokumenteras till kunden? 611 Framgår det varför kraven är krav? 612 Är kraven på rätt nivå? (inga designbeslut) 613 Kontrollera att kraven ej motsäger varandra. 614 Framgår det vilken typ av användare systemet riktar sig till? 615 Är gränssnittet mot användare väldefinierat? 616 Är systemets in- och utdata välbeskrivna? 617 Kontrollera att kraven ej är uppenbart orimliga. 618 Finns en lättförstådd översikt över systemet med? 619 Är alla krav indelade i ambitionsnivåer? 620 Är kraven spårbara? 621 Är kraven lämpligt numrerade? 622 Finns krav på kompabilitet definierad? 623 Specificeras vilken programvara, maskinvara och dokumentation som ska levereras till kunden? 624 Finns krav på utbildning till kunden? 625 Finns krav på leveranstid? 26 Inspektionsprotokoll

Exempel på protokoll och checklistor Checklista för projektplan Område Felnr Behandlar Kommentar Projektplan 701 Finns alla delar med enligt projektmodellen i kursmaterialet? 702 Är tidsplaneringen realistisk? 703 Är tidsplaneringen för varje fas realistisk? 704 Ligger alla faser i rätt ordning? 705 Ligger alla aktiviteter i rätt ordning och i rätt fas? 706 Är alla milstolpar tydligt definierade? 707 Har alla milstolpar ett syfte? 708 Har gruppmedlemmarna en rimlig arbetsbelastning? 709 Överensstämmer organisationsplanen med nuvarande organisation? 710 Framgår ansvarsfördelningen i organisationsplanen? 711 Är alla ansvarsområden beskrivna? 712 Beskrivs gruppens arbetssätt i organisationsplanen? 713 Uppfyller kvalitetsplanen IEEE 730? 714 Tas alla kvalitetsåtgärder upp? 715 Anges det hur alla kvalitetsaktiviteter ska utföras? 716 Anges det när alla kvalitetsaktiviteter ska utföras? 717 Är testplanen komplett och rimlig? 718 Beskrivs det hur varje test ska utföras? 719 Anges det när varje test ska utföras? 720 Anges det vilka som ska utföra varje test? 721 Försäkrar förändringsplanen spårbarhet? 722 Är förändringsplanen realistisk, dvs kommer vi att följa den? 723 Framgår det hur ett förändringsförslag hanteras? 724 Definieras det hur versionshantering ska gå till? 725 Är alla dokument beskrivna i dokumentplanen? 726 Har alla dokument en ansvarig redaktör? Inspektionsprotokoll 27

Exempel på protokoll och checklistor Område Felnr Behandlar Kommentar 727 Framgår det vilka språkliga konventioner som ska användas? 728 Framgår det vilka mallar som ska användas och hur layouten ska utformas för varje dokument? 729 Finns det angivet var och under vilket namn varje dokument ska sparas? 730 Täcker utbildningsplanen vårt utbildningsbehov? 731 Är alla rapporteringsvägar tydligt beskrivna i rapporteringsplanen? 732 Definieras konventioner för alla typer av rapportering? 733 Tar riskanalysen upp alla tänkbara riskkällor? 734 Är bedömningen av riskernas sannolikhet och inverkan på projektet riktiga? 735 Presenteras gruppen? 736 Presenteras uppgiften? 28 Inspektionsprotokoll

Exempel på protokoll och checklistor Checklista för design Område ID Behandlar Kommentar Designspec. 801 Är effektivitetskraven väldefinierade? 802 Förklaras designmetoden? 803 Följs designmetoden? 804 Finns det förklaringar till alla begrepp/ord som har använts? 805 Är all design på samma abstraktionsnivå? 806 Är implementation möjlig från denna beskrivning? 807 Beskrivs användargränssnittet? 809 Är alla attribut definierade med sina egenskaper? 810 Vilka hjälpmedel har använts? 811 Finns det förklaringar till olika symboler? 812 Framgår det vilket språk som ska användas i implementationen? 813 Finns stark koppling mellan kravspecifikationen och designspecifikationen? 814 Finns hänvisningar till vilka krav som påverkat designen? 815 Finns det säkerhets aspekter? Disskuteras dem? 816 Är systemet förändringsbart? 816 Är designen tillräckligt detaljerad? 817 Stoppas designarbetet där det ska? 818 Kan designen vidareutvecklas? 819 Vilken standard har följts vid design av användargränsnittet? 820 Har standarden följts? Inspektionsprotokoll 29

Exempel på protokoll och checklistor Anteckningsunderlag för fel Nr Sida Felbeskrivning ID P L S J K ID = Felets identitet, P = Påpekande, L = Litet fel, S = Stort fel, J = Justerad, K = Kontrollerad 30 Inspektionsprotokoll