Vaak komen fouten in het systeemontwerp pas tijdens de testfase aan het licht. Herstel kost dan veel tijd en geld. De praktijk heeft geleerd dat het Fagan-inspectieproces resulteert in een product met minder fouten, een productiviteitstijging bij het coderen en een besparing op herstelkosten.
Fouten in systeemeisen en systeemontwerpen worden nu veelal pas gevonden tijdens het testen van het totale systeem. Volgens Boehm [1] wordt zo’n 44 procent van de ontwikkelingsinspanning bij softwareprojecten besteed aan het vinden en herstellen van fouten. Dit is een zeer inefficiënte werkwijze. De fouten zijn dan al in de implementatie en de documentatie geslopen. Daarmee zijn het erg dure fouten, omdat dit opnieuw ontwerpen, implementeren en documenteren betekent. Verder geldt dat men in de testfase gevonden fouten probeert te herleiden tot fouten in de implementatie en niet geneigd is ze terug te voeren tot fouten in het systeemontwerp of zelfs systeemspecificaties. Deze feiten zijn reeds lange tijd bekend, en hebben in het verleden geleid tot het invoeren van bijvoorbeeld Fagan-inspecties. Dit is een techniek waarmee producten zo vroeg mogelijk worden geïnspecteerd op de aanwezigheid van fouten. Het zo vroeg mogelijk verwijderen van deze fouten leidt tot aanzienlijke kostenbesparingen.
Ontstaan
Toen Michael Fagan begin jaren zeventig bij IBM aantrad als projectmanager van een groot software-ontwikkelingsproject, zag hij dat de aanpak van het eeuwig repareren werd gevolgd. Tijdens het ontwikkelen van nieuwe producten begon men zo vroeg mogelijk met testen. Gevonden fouten werden opgelost en nieuwe testen volgden. Het herstellen van fouten ging zelfs door nadat het product al aan de klant geleverd is. Deze werkwijze kent drie nadelen, namelijk:
- Er is geen inzicht in het aantal op te lossen fouten. Dit heeft tot gevolg dat het hele vervolgtraject onvoorspelbaar is qua doorlooptijd, inspanning en kwaliteit van het eindproduct.
- Het is niet mogelijk fouten tegen elkaar af te wegen. Hierdoor is het onmogelijk in een kosten/baten-analyse te bepalen welke fouten wel en welke niet opgelost hoeven te worden.
- De samenhang tussen fouten kan niet uitgebuit worden. De samenhang tussen fouten zou aanleiding kunnen zijn een bepaalde module opnieuw te ontwerpen in plaats van alle geconstateerde fouten op te lossen.
In 1976 heeft hij het toen uitgekristalliseerde Fagan-inspectieproces gepubliceerd (zie kader). Sindsdien is het door vele bedrijven met veel succes toegepast.
Fagan-inspecties zijn nu geïntegreerd in meer recentere en bredere pogingen om het vakmanschap op een hoger niveau te brengen. Organisaties en projectteams hanteren het Capability Maturity Model (CMM) als referentiemodel om richting te geven aan verbeteringsinspanningen. In het vijf niveaus tellende CMM zijn Fagan-inspecties expliciet terug te vinden op het derde volwassenheidsniveau (Defined of Gedefinieerd). De implementatie van het proces Peer Reviews op dat niveau is in feite het Fagan-inspectieproces, zoals in het kader is beschreven. De aandacht voor het Personal Software Process (PSP) is snel groeiende. Individuele automatiseerders leren basistechnieken om de schattingsvaardigheid, productiviteit en betrouwbaarheid van het product te verbeteren. Zij volgen daartoe een standaard ontwikkelingsproces, bestaande uit zeven fasen. Twee van deze fasen (Design Review en Code Review) betreffen individuele Fagan-inspecties van het eigen ontwerp en de eigen code.
Praktijkresultaten
Toepassing van Fagan-inspecties door bedrijven laat uitstekende resultaten zien. Met name de productiviteit verbetert aanzienlijk (met 23 procent) en het aantal fouten wordt spectaculair teruggebracht (met 38 procent). Hiernaast worden de totale herstelkosten van gemaakte fouten enorm gereduceerd (factor 4). Van een aantal bekende bedrijven zijn resultaten met Fagan-inspecties gepubliceerd [2], zie kader.
Buiten de genoemde resultaten laten de cijfers – in de vorm van ‘return on investment’ (verhouding tussen investering en de opbrengst van deze investering) – zien dat de kosten slechts een fractie van de opbrengsten zijn. De ‘return on investment’-getallen die in de literatuur genoemd worden, lopen uiteen van 8:1 tot 30:1. Kortom: Fagan-inspecties zijn een zeer goede investering.
De cijfers in het kader zijn slechts momentopnamen. Direct nadat met Fagan-inspecties wordt begonnen, zijn er echter al sterke verbeteringen te verwachten zijn, die zich doorzetten. Als voorbeeld mag Raytheon Electronic Systems dienen. Bij dit bedrijf is de productiviteit van het coderen in een periode van vier jaar met 140 procent gestegen [3]. Daarbij is sprake van een praktisch lineaire stijging. Verder zijn in de eerste maanden na het beginnen met Fagan-inspecties de herstelkosten met een factor 1,6 gedaald, en met een factor 4 over een periode van vier jaar.
Genoemd bedrijf heeft in dezelfde periode het aantal fouten per 1000 regels code teruggebracht van 17,2 naar 4.0 [3].
Invoering
Beginnen met Fagan-inspecties betekent het introduceren van het basisproces (zie kader) en het verzamelen van een aantal basisgegevens (metrieken). De praktijk laat zien dat het resultaat van Fagan-inspecties sterk afhangt van de nauwkeurigheid waarmee het proces uitgevoerd wordt. Daarom is het belangrijk dat de mensen die ermee beginnen, getraind zijn in het uitvoeren van Fagan-inspecties. Een andere randvoorwaarde is het opzetten van een minimale infrastructuur. Deze moet bestaan uit standaard inspectieformulieren, controlelijsten en een database om de gegevens in op te slaan. De gegevens zijn in een later stadium noodzakelijk om het Fagan-inspectieproces te kunnen optimaliseren.
Als deze ingrediënten eenmaal aanwezig zijn, kan men op kleine schaal begonnen worden met Fagan-inspecties. Vervolgens is het belangrijk de eerste ervaringen en successen te communiceren. Dit zal voor groeiende interesse en toenemend gebruik zorgen. Daarbij is het wel belangrijk dat ook de nieuwkomers getraind worden in het toepassen van het Fagan-inspectieproces. Dit voorkomt dat ze vanaf het begin op de verkeerde manier te werk gaan.
Code leent zich goed voor het beginnen met Fagan-inspecties. Als er een softwareproduct wordt ontwikkeld, wordt er immers altijd code gemaakt; dat geldt niet altijd voor ontwerpen en documentatie. De inspectie van alleen code heeft ook een nadeel: De opbrengst van het inspecteren van projectplannen, systeemeisen- en ontwerpdocumenten is vele malen groter is. Een ontwerpfout die tijdens het testen wordt ontdekt, leidt namelijk tot aanpassing van het ontwerp, de documentatie en de implementatie. Bij een codeerfout hoeft alleen de code aangepast te worden.
Waarom worden Fagan-inspecties niet op grotere schaal toegepast? Bij een onderzoek naar deze vraag gaf 40 procent van de ondervraagden te kennen nog nooit van Fagan-inspecties gehoord te hebben.
Hieronder volgt een aantal cijfers over problemen die men bij invoering tegenkwam:
- 60 procent wil hun werkwijze niet veranderen;
- 56 procent van de auteurs vonden het moeilijk om zich los te koppelen van hun werk;
- 48 procent van de uitvoerenden hebben niet de nodige training gekregen;
- 47 procent van de mensen waren bang dat de gegevens tegen hen gebruikt zouden worden;
- 40 procent van het management stelde niet de nodige middelen beschikbaar;
- 30 procent van de opstartkosten waren hoger dan verwacht;
- 20 procent van de beoogde gebruikers waren niet op de hoogte van de voordelen.
Bewezen techniek
Fagan-inspecties hebben ondertussen een historie van ruim twintig jaar. In deze tijd heeft de techniek zich meerdere malen bewezen. Getoond is dat het toepassen van Fagan-inspecties onder andere geld, een hogere productiviteit en een product met minder fouten kan opleveren. De kosten bedragen slechts een fractie van de opbrengsten .
De invoeringsproblemen die velen hebben ondervonden, zijn problemen die niet specifiek bij de Fagan-inspectietechniek horen. Het zijn eerder problemen die bij veranderingen in het algemeen overwonnen moeten worden. Ze zijn van eenzelfde soort als die waarvoor bedrijven zich geplaatst zagen die in de begin jaren negentig CMM adopteerden. Sinds die tijd is de ervaring in de automatiseringsbranche met veranderingsmanagement almaar toegenomen.
Binnen de automatiseringsbranche groeit de interesse voor methoden als CMM en PSP om grip te krijgen op automatiseringsprojecten nog steeds. Bovendien ontstaat een steeds bredere aandacht voor veranderingsmanagement. Hierdoor zal de kans op succesvolle invoering van de bewezen techniek van Fagan-inspecties aanzienlijk groter zijn dan twintig jaar geleden.
Drs. C.F.W. Hendriks, adviseur bij Alert Automation Services
Literatuur
[1]. Boehm, B.W.: Improving Software Productivity, Computer, Vol. 20, 9, (september 1987)
[2]. Wheeler, D.A., Brykczynski, B., Meeson, R.N. Jr.: Software Inspection, an industry best practice, IEEE Computer Society Press, 1996, ISBN 0-8186-7340-0
[3]. Haley, T., Ireland, B., Wojtaszek, E., Nash, D., Dion, R.: Raytheon Electronic Systems experience in software process improvement, Software Engineering Institute Technical Report CMU/SEI-95-TR-17, Carnegie Mellon University, USA
Het Fagan-inspectieproces
Bij een Fagan-inspectie inspecteren drie tot zes mensen een (tussen)product, bijvoorbeeld een ontwerp of code. Het doel van een Fagan-inspectie is het vinden en corrigeren van fouten in een (tussen)product voordat het project naar een volgende fase doorgaat. De personen vervullen een rol als moderator, inspecteur, notulist of auteur. Het Fagan-inspectieproces dat ze doorlopen bestaat uit zes stappen, zie hieronder.
De kern van het succes van Fagan-inspecties is het gebruik van start- en eindcriteria. Er wordt pas begonnen aan een stap als is voldaan aan bepaalde startcriteria; een stap is pas afgerond als voldaan is aan de eindcriteria. De moderator controleert dit. Het gebruik van deze criteria onderscheidt Fagan-inspecties van andere technieken als bijvoorbeeld reviews.
Bij het inspecteren wordt gecontroleerd of het product voldoet aan de ‘hogere documenten’ en de standaarden. In de ‘hogere documenten’ staan de randvoorwaarden beschreven waaraan voldaan moet worden. Zo is bijvoorbeeld een gedetailleerd ontwerp het ‘hogere document’ van code. Verder wordt tijdens de inspectie gebruik gemaakt van controlelijsten die deelnemers voorschrijven waarop gelet moet worden of welke activiteiten uitgevoerd moeten worden.
Een Fagan-inspectie resulteert in een gecorrigeerd product en gegevens voor het projectmanagement. Bij een volledig afgeronde Fagan-inspectie zeggen de gegevens onder andere dat het product voldoet aan de gestelde eisen, hoeveel fouten gevonden en opgelost zijn en hoeveel tijd dat heeft gekost. De betrouwbaarheid van de gegevens wordt gewaarborgd door het gebruik van start- en eindcriteria.
De zes stappen van het Fagan-inspectieproces zijn: planning, aftrap, voorbereiding, inspectie, herstel en afronding.
Planning.
De moderator plant de inspectie. Gecontroleerd wordt of het product klaar is voor inspectie, het inspectie team wordt samengesteld, de bijeenkomsten worden gepland en het benodigde materiaal wordt verspreid.
Aftrap.
Dit is een optionele stap. Als het inspectie team niet vertrouwd is met het te inspecteren product, wordt het toegelicht door de auteur.
Voorbereiding.
De leden van het inspectieteam bereiden zich individueel voor op de inspectiebijeenkomst. De inspecteurs bestuderen het product en zoeken daarbij met name naar fouten die het best gevonden kunnen worden vanuit de eigen expertise. Daarbij maken ze gebruik van de ‘hogere documenten’ en de controlelijsten. Na afloop vullen ze de gevonden fouten en de benodigde tijd in op het individuele bevindingenformulier. De moderator bereidt zich voor op zijn rol die erin bestaat het team door het product heen te leiden. Daarbij maakt hij gebruik van de individuele bevindingenformulieren.
Inspectie.
Het inspectieteam zoekt, bespreekt en classificeert gezamenlijk de fouten in het te inspecteren product. De moderator leidt het team door het te inspecteren product. Belangrijke aandachtspunten hierbij zijn dat er naar fouten gezocht moet worden – niet naar oplossingen – en dat de auteur niet aangevallen wordt op de gevonden fouten. De notulist noteert de gevonden fouten op een registratieformulier. De auteur licht het product toe als dat nodig is. Aan het einde van de inspectie bepaalt het team of het product geaccepteerd kan worden, indien de gevonden fouten verwijderd zijn.
Herstel.
De auteur herstelt alle gevonden ernstige fouten en houdt bij welke fouten gecorrigeerd zijn en hoeveel tijd het heeft gekost.
Afronding.
De moderator controleert of de auteur het herstelwerk goed heeft gedaan en of het product aan de eindcriteria voldoet. Verder maakt de moderator een korte samenvatting van de inspectie waarin onder andere worden vermeld het aantal deelnemers, de bestede tijd per stap, het aantal fouten en of het product geaccepteerd is.
Resultaten
Resultaten Fagan-inspecties bij verschillende bedrijven:
AT&T:
HP:
NASA:
IBM:
ICL:
BNR:
