Fagan inspecties op programmacode, heeft dat nog nut?

Het uitvoeren van Fagan inspecties levert zo mogelijk nog betere resultaten op dan het uitvoeren van reviews. Net als bij een review toets je bij een inspectie een deliverable aan de normen die de organisatie zelf voor deze producten heeft vastgesteld. Om inspecties uit te kunnen voeren is het dus noodzakelijk dat de organisatie al een zeker kwaliteitsbewustzijn heeft. Er zijn een aantal belangrijke verschillen tussen reviews en inspecties, een inspectie wordt meestal slechts door één goede collega uitgevoerd en de resultaten worden t.b.v. statistische doeleinden geregistreerd.

In de automatisering werden inspecties in eerste instantie toegepast door programmeurs die elkaars program­macode controleerden op regelmatig gemaakte fouten. Op deze manier worden namelijk niet alleen voor de test al veel fouten gevonden, maar er worden ook fouten gevonden die er bij het testen niet zouden uitgekomen. Dit zijn fouten die na een langere produc­tiepe­ri­ode wel problemen zouden opleveren. Met andere woorden, inspecties werken preventief.

Moderne ontwikkeltools

Met het huidige gebruik van ontwikkeltools wordt het hard coderen van programmatuur een steeds kleiner wordend onderdeel van de realisatiefase. Veel van de business rules zitten al in het tool en kunnen zo naar code gegenereerd worden. Het programmeerwerk komt vaak nog als de gebruikersinterface op maat gemaakt moet worden. Daarnaast zijn er nog veel bedrijven en ontwikkelaars die zweren bij het zelf coderen omdat je het resultaat dan zelf in de hand hebt. Tenslotte ontkom je in de meeste legacysystemen niet aan programmeerwerk.

Inspecties en software ontwikkelen

Het daadwerkelijke programmeerwerk zien velen nog altijd als het echte automatiseren want dan komt het programma echt tot stand. Dit is echter slechts ten dele waar. Het belangrijkste werk is namelijk reeds tijdens de informatie-analyse en het ontwerp gedaan. In de bouwfase is het wel mogelijk dat er nog vragen t.a.v. het voorliggende werk rijzen. Dat deze vragen voorkomen moet je echter zien als onvolkomenheden aan de informatie-analyse en het ontwerp. Onvolkomenheden die zijn ontstaan als gevolg van het onvoldoende omzetten van verwachtingen in eisen en een onvoldoende kritisch oordeel tijdens de ontwerpreviews. Bij de start van de bouwfase krijgen de programmeurs het ontwerp in handen en gaan dit interpreteren. Veel informatie die de ontwerper alleen in zijn hoofd heeft gaat daarbij verloren zodat een onvolledig beeld ontstaat.

Het verkeerde ontwikkelplatform

Omdat het ook wel eens voorkomt dat de ontworpen oplossing niet eens op het gekozen platform kan worden gerealiseerd is het verstandig om de programmeur vanaf het begin van het project mee te laten lopen. Zodoende weet hij wat te verwachten is en weet hij waarom bepaalde ontwerpbeslissingen zijn genomen. In eerste instantie zal deze extra tijd van de program­meur op het project drukken. Dit verdient zich echter later ruimschoots terug. In veel organisaties zijn de functies systeemanalist en programmeur tot één functie, de ontwikkelaar, gecombineerd zodat deze problemen niet meer voorkomen.

De inspectie van programmacode

Door fouten in een zo vroeg mogelijk­ stadium m.b.v. inspecties te ontdekken zijn ze nog zonder al te hoge kosten te herstellen. Inspecties passen dus ook in een kwaliteitsverbe­tersysteem. De statistieken die op basis van de geregistreerde inspectieresultaten kunnen worden gemaakt kunnen worden gebruikt om de zwakke plekken in de projectproducten op te sporen en het softwareproces zodanig aan te passen dat blijvende verbeteringen kunnen worden doorgevoerd. Het uitvoeren van inspecties heeft alleen zin als je een goede checklist gebruikt.

Hoewel je Fagan inspecties op alle projectproducten kunt toepassen is de beoordeling van program­macode de meest voor de hand liggende. Dit komt omdat voor de opzet van programma’s heel goed een standaard voor een organisatie is op te zetten. De mogelijk­heden voor het opzetten van een standaard worden door de huidige ontwikkeltools en de grafische interfaces alleen nog maar groter.

Planning van inspecties

Het moment waarop een programma-inspectie plaatsvindt ligt vlak na het gereed komen van het programma en hoeft vaak niet ingepland te worden. Wel moet er in de planning voldoende ruimte worden opgenomen voor de programma-inspecties. De tijd die verloren gaat aan Fagan inspecties kan je in een later stadium ruimschoots terug verdienen door betere testresultaten en minder onderhoud. Belangrijk is dat je alleen die programma’s inspecteert waarvan de maker zegt dat ze af en foutloos zijn.

Tijdens de inspectie mag ook niet meer aan het programma worden gewerkt. Het aantal programma-inspecties dat tijdens een project plaatsvindt is niet alleen afhankelijk van het aantal programmamodules maar is tevens afhankelijk van de kwaliteit van de ontwerpen en de program­ma’s zelf. Slechte ontwerpen leiden immers tot programma’s die niet aan de verwachtingen van de gebruikers voldoen. Deze programma’s worden bij de acceptatie­test afgewezen. Een slecht programma wordt al tijdens de inspectie afgewezen. Voor beide gevallen geldt dat er na aanpassing weer een inspectie zal volgen.­

Bij een programma-inspectie kan je controleren op:

• Een juiste opzet wat betreft de programma­struc­tuur.
• Het juist gebruik van voorgeschreven variabele namen.
• Een juiste toepassing van de programmacode.
• Een juiste benadering van de bestanden.
• Het gebruik van de juiste programmacode voor formules (nuldelingen).
• Een juiste invulling van de programmado­cumentatie.
• Een juiste opzet t.a.v. performance.
• In beperkte mate is te controleren of alle ontworpen functie zijn opgenomen.

Het eindrapport van een inspectie zal zich in de meeste gevallen beperken tot een ingevulde checklist. De laatste checklist zal bij de overige programmadocumentatie worden gearchiveerd. Voor statistische doeleinden kan je de registraties van de eerdere Fagan inspecties wel bewaren.

Andere benamingen voor programma-inspecties zijn Deskchecking, Codereading en Statische Programma Test.

De uitgangspunten van Fagan inspecties

Makalle Fagan heeft de inspectiemethode zo’n 35 jaar geleden ontwikkeld en heeft de volgende uitgangspunten gedefinieerd:

• Inspecties kan je het beste toepassen op het moment dat een product nog zonder al te hoge kosten is aan te passen.
• De maker van het product is verantwoordelijk voor de kwaliteit van het product.
• De oorzaak van de meeste fouten in een product is onvoldoende organisatie van het proces (door ontwikkeltools gegenereerde software hoef je dus eigenlijk niet meer te inspecteren).
• Om natuurlijke weerstanden en uiteindelijk om de tuin leiden te voorkomen inspecte­ren naaste collega’s elkaars producten.
• T.b.v. van overdracht en later gebruik dient ieder product zelfverklarend en eenduidig te zijn.
• Registratie van de inspectieresultaten t.b.v. verbetering van het maak- en het inspectiepro­ces.

De betrokkenen bij Fagan inspecties

Doorgaans voert een goede collega van de programmeur de inspectie uit. Dit versterkt niet alleen het onderling vertrouwen, maar heeft tevens een leereffect. Men leert als het ware van elkaars fouten. Een bijkomend voordeel is dat het ontwikkelteam de vuile was niet buiten hoeft te hangen. De kwaliteit van de programmatuur zal tevens gelijkmatig zijn. De meest ervaren programmeur zal in veel gevallen ook de meest gevraagde inspecteur zijn, hij kent immers het klappen van de zweep.

Tijdens de inspectie wordt­­ door de inspecteur een checklist ingevuld waardoor een eenduidige wijze van beoordelen ontstaat.

De inspectie-beheerder.

• De inspectie-beheerder houdt toezicht op de inspectieresultaten. Hij is zelf niet rechtstreeks betrokken bij een inspectie doch voert de statistische beoordeling uit en adviseert over verbeterin­gen in het softwareproces. Tevens kan hij verbeteringen op de checklisten doorvoeren.

De programmeur.

• De programmeur biedt zijn programma aan bij de inspecteur en geeft daarbij tevens de ontwerpen en de overige documentatie. Indien nodig geeft hij nog een mondelinge toelichting voor specifieke aandachtspunten.

De inspecteur.

• De inspecteur is een ervaren automatiseerder die de inspectie uitvoert. Hij beoordeelt het product en volgt daarbij de checklist. Tevens stelt hij het inspectierap­port op.

De projectleider.

• De projectleider neemt kennis van de inspectie resultaten t.b.v. de voortgangsregistra­tie van het project.

De Fagan inspectie activiteiten

Het houden van een inspectie valt uiteen in een aantal activiteiten. Naast het houden van de Fagan inspecties zelf is ook onderhoud nodig op de wijze waarop de inspecties zijn opgezet.

De inspectie zelf kent de volgende fasen :

1 Intake programma

Het vaststellen van:

• De status te inspecteren programma.
• Volledigheid onderliggende ontwerp.
• Volledigheid bijhorende programmadocumentatie.
• Toe te passen checklisten.

2 Programma beoordeling

• Vaststellen van de volledigheid van de programma-code.
• Beoordeling van de juistheid van de programma-code.
• Vaststellen van de consistentie van de programma-code.
• Het invullen / verwerken van de checklisten.

3 Terugkoppeling inspectie

• Opstellen van het inspectierapport.
• Het rapport door laten nemen door de betrokken programmeur.
• De rapporten archiveren.
• Toezien op naleving van de adviezen.
• Opnemen van het inspectieresultaat in het statistisch systeem.

Discussieer mee op LinkedIn.