Geautomatiseerd toetsen van acceptatiecriteria

De acceptatie van maatwerkprogrammatuur is vaak gebaseerd op functionele requirements. Kwaliteitsaspecten zoals de onderhoudbaarheid van de programmatuur verdienen echter ook aandacht. Na in productiename van de programmatuur is de schade – zeker in geval van uitbestede ontwikkelprocessen – heel lastig te herstellen. Geautomatiseerde toetsing van acceptatiecriteria biedt een instrument voor regie en verlicht en objectiveert het werk van applicatiebeheerders. Klik op de volgende link voor om een uitgebreidere versie van dit artikel te lezen Geautomatiseerd toetsen van acceptatiecriteria.

(i.s.m. Bart de Best)

Introductie geautomatiseerd toetsen van acceptatiecriteria

Steeds meer bedrijven besteden het maken van maatwerkapplicaties uit aan gespecialiseerde softwarebedrijven. Deze aanpak buiten de deur bespaart kosten, door efficiëntere inzet van personeel en andere bedrijfsmiddelen. Vaak is er echter geen zicht op de kwaliteit die wordt gerealiseerd. Deze moet dan aan het einde van het ontwikkelproces bepaald worden. Er blijft dan meestal alleen een acceptatie over die gericht is op de functionaliteit die vanuit een gebruikersperspectief wordt gemeten. Als de applicatie eenmaal in productie is, dan blijkt vaak dat functionele gebreken snel zijn op te lossen. Het kost wel veel tijd en geld om kwaliteitsgebreken, zoals het niet beschikbaar zijn en slechte performance, te verhelpen. Er dient daarom een strakkere regie te worden gevoerd bij het laten bouwen en in beheer nemen van een applicatie.
Bij outsourcing is het dus de verantwoordelijkheid van de afnemer om vooraf heldere specificaties op te stellen. Daarnaast dient hij na oplevering een gedegen acceptatieprocedure te volgen. Vaak realiseert men zich te laat dat competenties op dit vlak aanwezig moeten zijn om van outsourcing een succes te maken.

Acceptatie kan sneller en objectiever worden uitgevoerd als de toetsing van acceptatiecriteria wordt geautomatiseerd. Een bijkomend voordeel van deze automatisering is dat de acceptatiecriteria al tijdens de ontwikkelfase kunnen worden getoetst en gevolgd. Dat voorkomt verrassingen in een later stadium. Het Eindhovense bedrijf TIOBE (zie www.tiobe.com) levert gespecialiseerde tools om softwarekwaliteit automatisch te meten en te verhogen.

GSA-stappenplan

De aanpak van TIOBE kan worden verduidelijkt met het GSA ­stappenplan (zie figuur 1). GSA staat voor Generieke en Specifieke Acceptatiecriteria. Steeds meer organisaties hanteren dit stappenplan om op basis van onderkende risico’s acceptatiecriteria te bepalen voor nieuw te ontwikkelen informatiesystemen of wijzigingen aan bestaande informatiesystemen. Binnen dit stappenplan worden zeven stappen doorlopen (zie artikel acceptatiecriteria). De belangrijkste stappen die van toepassing zijn bij de acceptatie van maatwerkprogrammatuur zijn de risicoanalyse (GSA 3), het opstellen van de acceptatiecriteria (GSA 4) en het toetsen hiervan (GSA 7).

De toepassing van het GSA-stappenplan

Risicoanalyse (stap 3)

Bij het in productie nemen van maatwerkprogrammatuur moeten vier prominente risico’s bewust worden genomen of zijn beheerst. Elk risico (hoog, middel en laag) wordt vastgesteld op basis van de bedreiging, de impact van de bedreiging en de kans (hoog, middel en laag) dat de bedreiging werkelijkheid wordt. Een risico is dus de kans maal de impact. In tabel 1 worden vier bedreigingen en de bijbehorende impact benoemd.

R#	Bedreiging	Kans	Impact	Risico
R1	Dekkingsgraad:De programmatuur is niet volledig getest, waardoor de kwaliteit van het te accepteren object niet vastgesteld is.	H/M/L	De gebreken worden pas in productie zichtbaar.	H/M/L
R2	Instabiliteit: Niet alle mogelijke paden voor alle mogelijke waarden worden getest, waardoor de programmatuur in productie instabiel blijkt te zijn.	H/M/L	De beschikbaarheids-­ en/of performance­ SLA ­normen worden niet gehaald.	H/M/L
R3	Uitbreidbaarheid: Het uitbreiden van de programmatuur is lastig vanwege de complexiteit van de sourcecode en is derhalve kostbaar.	H/M/L	De doorlooptijd van wijzigingen is te lang en de wijzigingen kosten te veel geld.	H/M/L
R4	Onderhoudbaarheid: De programmatuur is niet onderhoudbaar.	H/M/L	De oplostijd van incidenten is te lang. Er treden veel gevolgincidenten op na het doorvoeren van de wijzigingen.	H/M/L

Tabel 1, Bedreigingen en hun impact

Acceptatiecriteria (stap 4)

Voor elk van de onderkende risico’s moet gekozen worden tussen risico’s nemen en ze beheersen. Voor het beheersen van de risico’s moeten tegenmaatregelen worden gedefinieerd. Deze tegenmaatregelen dienen als criteria op basis waarvan het informatiesysteem geaccepteerd wordt. De acceptatiecriteria zijn dus bedoeld om te toetsen in welke mate de risico’s beheerst zijn. In tabel 2 staan bedreigingen genoemd met hun acceptatiecriterium en automatische metriek.

R#	Bedreiging	GSA	Acceptatiecriterium	Automatische metriek
R1	Dekkingsgraad	SA­-01	De test coverage bedraagt minimaal 80 procent.	Test coverage
R2	Instabiliteit	SA­-02	De programmatuur bevat geen enkele dynamische overtreding, zoals vastgesteld door de gehanteerde tooling.	null dereference, array out of bounds exceptions, oneindige loops en delen door nul
R3	Uitbreidbaarheid	SA­-03	De gemiddelde cyclomatische complexiteit voor functies is kleiner dan 5.	Cyclomatische complexiteit
R4	Onderhoudbaarheid	SA-04	De confidencefactor is minimaal 80 procent	Regels uit de gehanteerde codeerstandaard

Tabel 2, Bedreigingen met hun acceptatiecriterium en metriek

Confidencefactor Met de confidencefactor (zie figuur 1) die TIOBE Software samen met architecten van Philips en Océ heeft ontwikkeld, is toch een overkoepelend beeld te krijgen van de mate waarin een applicatie voldoet aan een codeerstandaard. Deze factor geeft met een percentage tussen 0 en 100 aan hoe onderhoudbaar de code is. Wanneer een applicatie een confidencefactor van 100 procent heeft, is er geen enkele overtreding van de codeer­ standaard; een confidencefactor van

0 procent betekent dat zo’n beetje op elke plek elke mogelijke overtreding is gemaakt die gemaakt kon worden. De factor houdt rekening met de grootte van de applicatie, de zwaarte van de geconstateerde overtredingen en de hoeveelheid regels waaruit een standaard bestaat.

De factor wordt normaliter elke dag berekend. ’s Nachts wordt de overdag aangemaakte en/of aangepaste sourcecode geanalyseerd op kwaliteitscriteria. De crux van deze factor is dat de regievoerder op eenvoudige wijze grip krijgt op een deel van de kwaliteitbeheersing, zonder dat hij diepgaande kennis nodig heeft van applicatietechnologie. Om afwijkingen van de confidencefactor te beoordelen is specifieke vakkennis nodig. Deze is het domein van de systeemontwikkelaars en applicatiebeheerders. Al een aantal jaar controleert TIOBE elke dag meer dan 600 miljoen regels programmatuur voor meer dan 2500 applicaties op softwarefouten. Op basis van deze gegevens blijkt dat een confidencefactor van 80 procent realistisch is zonder onderhoudbaarheid een doel op zich te maken. Veelgebruikte gereedschappen om codeerstandaarden automatisch te checken zijn bijvoorbeeld PMD en FindBugs voor Java en FxCop voor C#.

Toetsing (stap 7)

De acceptatiecriteria zijn zodanig gekozen dat ze automatisch gemeten kunnen worden. Dit heeft als grote voordeel dat er geen noemenswaardige inspanning te beheersen. Het wel of niet voldoen aan de acceptatiecriteria en de mate waarin hiervan wordt afgeweken kunnen namelijk al tijdens de ontwikkelfase worden vastgesteld. Dergelijke geautomatiseerde toetsing van acceptatiecriteria tijdens ontwikkeling leidt ertoe dat er al in een heel vroeg stadium kan worden bijgestuurd indien de gestelde normen dreigen te worden overtreden. Uit onderzoek van Barry Boehm is gebleken dat de kosten van rework op deze manier exponentieel kunnen worden verminderd: rework kost tien keer meer per latere fase waarin een afwijking van een van de criteria wordt hersteld.

Best practices

Het is aan te raden de volgende, op de praktijk gebaseerde adviezen voor het geautomatiseerd accepteren van informatiesystemen op te volgen.

• Begin in een zo vroeg mogelijk stadium met het geautomatiseerd meten van de acceptatiecriteria en sla de meetwaarden op in een database.
• Laat zowel de ontvangende partij als de leverende partij de metingen uit­ voeren.
• Meet de acceptatiecriteria tijdens zowel de ontwikkelfase als de beheer­ fase.
• Zorg ervoor dat de publicatie van de meetgegevens bekend en toegankelijk is.
• Hanteer de confidencefactor als acceptatiecriterium bij het uitbesteden van applicatiebouw en als SLA­norm voor het applicatiebeheer.
• Zorg dat de confidencefactor bij een change en/of release in elk geval niet lager wordt bij het herstellen van bestaande programmatuur met een confidencefactor van minder dan 80. Het is vaak te kostbaar om de kwaliteit in zo’n geval in één keer te verbeteren.
• Hanteer de confidencefactor niet als doel, maar als middel om de kwaliteit van applicatieprogrammatuur te meten.

Meer informatie

Boek van Bart de Best: Acceptatie Criteria ISBN: 9789071501784
Artikel: ITBM 2009 nr.5 Geautomatiseerd toetsen van acceptatiecriteria

Discussieer mee op LinkedIn.