Fagan inspecties op programmacode, heeft dat nog nut??

Met het huidige gebruik van ontwikkeltools wordt het hard coderen van programmatuur een steeds kleiner wordend onderdeel van de realisatiefase. Veel van de businessrules 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.

Het daadwerkelijke programmeerwerk wordt door velen nog altijd gezien 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 echter worden gezien als onvolkomenhe­den 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. 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 gecombineerd zodat deze problemen worden voorkomen.

De inspectie van programmacode

 Het uitvoeren van inspecties levert zo mogelijk nog betere resultaten op dan het uitvoeren van reviews. Net als bij een review wordt bij een inspectie een projectproduct getoetst 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.

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 van een goede checklist gebruik wordt gemaakt.

Hoewel inspecties op alle projectproducten kunnen worden toegepast 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.

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 inspecties wordt in een later stadium ruimschoots terug verdient door betere testresultaten en minder onderhoud. Belangrijk is dat alleen programma’s worden geïnspecteerd 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 worden gecontroleerd op:
• Een juiste opzet wat betreft de programma­struc­tuur;
• Een juist gebruik van voorgeschreven variabele namen;
• Een juiste toepassing van de programmacode;
• Een juiste benadering van de bestanden;
• Een juiste programmacode voor formules (nuldelingen);
• Een juiste invulling van de programmado­cumentatie;
• Een juiste opzet t.a.v. performance;
• In beperkte mate kan tevens worden gecontroleerd 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 zullen de registraties van de eerdere inspecties wel worden bewaard.

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

De uitgangspunten Fagan inspectie

 Makalle Fagan heeft de inspectiemethode zo’n 35 jaar geleden ontwikkeld en heeft de volgende uitgangspunten gedefinieerd :
•    Inspecties worden toegepast 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 meeste fouten in een product worden veroorzaakt door onvoldoende organisatie van het proces (door ontwikkeltools gegenereerde software hoeft dus eigenlijk niet meer geïnspecteerd te worden).
•    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.
•    De inspectieresultaten worden geregistreerd t.b.v. verbetering van het maak- en het inspectiepro­ces.

De betrokkenen Fagan inspectie

 Een inspectie wordt doorgaans door een goede collega van de programmeur uitgevoerd. 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. De inspecteur 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 inspecties zelf moet ook de wijze waarop de inspecties zijn opgezet worden onderhouden.

De inspectie zelf kent de volgende fasen :

1    Intake programma.
• Vaststellen status te inspecteren programma.
• Vaststellen volledigheid onderliggende ontwerp.
• Vaststellen volledigheid bijhorende programmadocumentatie.
• Vaststellen checklisten.

2    Programma beoordeling.
• Vaststellen volledigheid van programma-code.
• Vaststellen juistheid van programma-code.
• Vaststellen consistentie van programma-code.
• Invullen / verwerken checklisten.

3    Terugkoppeling inspectie.
• Opstellen inspectierapport.
• Rapport door laten nemen door betrokken programmeur.
• Rapport archiveren.
• Toezien op naleving adviezen.
• Vaststellen inspectieresultaat in statistisch systeem.

Boeken over dit onderwerp

Teksten Vreemdelingenrecht – 2016-2017

Auteur: Paul Vos
Dit boek bevat de belangrijkste wetgeving met betrekking tot het nationale vreemdelingenrecht, alsmede de Procesregeling bestuursrecht 2013.
Europrijs: 56,52
Bestellen

Aan de slag met software testen

Auteur: Hossein Chamani
‘Aan de slag met software testen’ helpt ICT-studenten om al tijdens hun studie testexpertise te ontwikkelen voor de beroepspraktijk.
Europrijs: 32,5
Bestellen

Meer boeken over code reading vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Dit artikel heeft een aanvulling

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Programma structuur (code-reading) 41 vragen.
Programma performance (codereading) 11 vragen.
Database benadering (codereading) 13 vragen.
Programma commentaar (codereading) 15 vragen.
Programmeer-techniek (codereading) 39 vragen.
Sidebar