Fagan inspektion

En Fagan-inspektion är en process där man försöker hitta defekter i dokument (som källkod eller formella specifikationer) under olika faser av mjukvaruutvecklingsprocessen . Den är uppkallad efter Michael Fagan, som krediteras med uppfinningen av formella mjukvaruinspektioner .

Fagan-inspektionen definierar en process som en viss aktivitet med fördefinierade in- och utträdeskriterier . I varje process för vilken ingångs- och utträdeskriterier är specificerade kan Fagan-inspektioner användas för att validera om resultatet av processen överensstämmer med de utträdeskriterier som specificerats för processen. Fagan Inspection använder en gruppgranskningsmetod för att utvärdera resultatet av en given process.

Exempel

Exempel på aktiviteter som Fagan-inspektion kan användas för är:

• Kravspecifikation
• Mjukvaru-/informationssystemarkitektur (till exempel DYA [
• Programmering (till exempel för iterationer i XP eller DSDM )
• Programvarutestning (till exempel när du skapar testskript)

Användande

Mjukvaruutvecklingsprocessen är en typisk tillämpning av Fagan-inspektion . Eftersom kostnaderna för att åtgärda ett fel är upp till 10 till 100 gånger lägre i de tidiga operationerna jämfört med att åtgärda ett fel i underhållsfasen, är det viktigt att hitta defekter så nära insättningspunkten som möjligt. Detta görs genom att inspektera resultatet från varje operation och jämföra det med outputkraven, eller exitkriterierna för den operationen.

Kriterier

Inträdeskriterier är de kriterier eller krav som måste uppfyllas för att gå in i en specifik process. Till exempel, för Fagan-inspektioner måste hög- och lågnivådokumenten uppfylla specifika inträdeskriterier innan de kan användas för en formell inspektionsprocess.

Exitkriterier är de kriterier eller krav som måste uppfyllas för att slutföra en specifik process. Till exempel, för Fagan-inspektioner måste lågnivådokumentet uppfylla specifika exitkriterier (som specificeras i högnivådokumentet) innan utvecklingsprocessen kan tas till nästa fas.

Utträdeskriterierna specificeras i ett högnivådokument som sedan används som standard som operationsresultatet (lågnivådokumentet) jämförs med vid besiktningen. Varje misslyckande hos lågnivådokumentet för att uppfylla de högnivåkrav som anges i högnivådokumentet kallas defekter (och kan vidare kategoriseras som större eller mindre defekter). Mindre defekter hotar inte programvarans korrekta funktion, utan kan vara små fel som stavfel eller oestetisk placering av kontroller i ett grafiskt användargränssnitt .

Typiska operationer

En typisk Fagan-inspektion består av följande operationer:

• Planera
  • Beredning av material
  • Arrangering av deltagare
  • Anordnande av mötesplats
• Översikt
  • Grupputbildning av deltagarna om det material som granskas
  • Tilldelning av roller
• Förberedelse
  • Deltagarna granskar föremålet som ska inspekteras och stödmaterial för att förbereda mötet och noterar eventuella frågor eller eventuella defekter
  • Deltagarna förbereder sina roller
• Besiktningsmöte
  • Faktiskt fynd av defekt
• Omarbetning
  • Omarbetning är steget i mjukvaruinspektionen där de defekter som hittas under inspektionsmötet löses av författaren, designern eller programmeraren. På basis av listan över defekter korrigeras lågnivådokumentet tills kraven i högnivådokumentet uppfylls.
• Uppföljning
  • I uppföljningsfasen av mjukvaruinspektioner bör alla defekter som hittats i inspektionsmötet åtgärdas (eftersom de har åtgärdats i omarbetningsfasen). Moderatorn ansvarar för att verifiera att så verkligen är fallet. De bör verifiera att alla defekter är åtgärdade och att inga nya defekter sätts in när de försöker fixa de initiala defekterna. Det är avgörande att alla defekter åtgärdas, eftersom kostnaderna för att åtgärda dem i ett senare skede av projektet kan vara 10 till 100 gånger högre jämfört med nuvarande kostnader.

Fagan inspektion grundmodell

Uppföljning

I uppföljningsfasen av en Fagan-inspektion bör defekter som fixats under omarbetningsfasen verifieras. Moderatorn är vanligtvis ansvarig för att verifiera omarbetning. Ibland kan fasta arbeten accepteras utan att verifieras, som när defekten var bagatell. I icke-triviala fall utförs en fullständig förnyad inspektion av inspektionsteamet (inte bara moderatorn).

Om verifieringen misslyckas, gå tillbaka till omarbetningsprocessen.

Roller

Inspektionsprocessen utförs normalt av medlemmar i samma team som genomför projektet. Deltagarna fyller olika roller inom inspektionsprocessen:

• Författare/designer/kodare: personen som skrev lågnivådokumentet
• Läsare: omskriver lågnivådokumentet
• Granskare: granskar dokumentet på låg nivå från en testsynpunkt
• Moderator: ansvarig för besiktningstillfället, fungerar som coach

Fördelar och resultat

Genom att använda inspektioner kan antalet fel i slutprodukten minska avsevärt, vilket skapar en produkt av högre kvalitet. I framtiden kommer teamet till och med att kunna undvika fel eftersom inspektionssessionerna ger dem insikt i de vanligaste felen i både design och kodning, vilket ger undvikande av fel i grunden till att de inträffade. Genom att kontinuerligt förbättra inspektionsprocessen kan dessa insikter användas ytterligare.

Tillsammans med de kvalitativa fördelarna som nämns ovan kan stora "kostnadsförbättringar" uppnås eftersom undvikande och tidigare upptäckt av fel kommer att minska mängden resurser som behövs för felsökning i senare faser av projektet.

I praktiken har mycket positiva resultat rapporterats av stora företag som IBM, vilket tyder på att 80 % till 90 % av defekterna kan hittas och besparingar i resurser upp till 25 % kan uppnås.

Förbättringar

Även om Fagan-inspektionsmetoden har visat sig vara mycket effektiv, har förbättringar föreslagits av flera forskare. M. Genuchten har till exempel undersökt användningen av ett elektroniskt mötessystem (EMS) för att förbättra produktiviteten för mötena med positiva resultat

Andra forskare föreslår användning av programvara som håller en databas över upptäckta fel och automatiskt skannar programkod efter dessa vanliga fel. Detta bör återigen resultera i förbättrad produktivitet.

Ron Radice, High Quality, Low Cost Software Inspections, Paradoxicon Publishing (21 september 2001)