Softwarekwaliteit goed te meten

Voor de kwaliteit van het op te leveren softwareproduct en de daarmee verbonden ontwikkel- en beheerprocessen is het van groot belang dat er structureel gemeten en geanalyseerd wordt. Wat kunnen we meten aan het product software en aan de processen waarin het product tot stand komt en wordt gebruikt? Welke rol speelt meten binnen de theorie en praktijk van softwarekwaliteit? En, waarom is er te weinig aandacht voor meten?
Bij het meten aan een product denken we in eerste instantie aan het meten van fysieke eigenschappen zoals volume, gewicht, snelheid et cetera. Een softwareproduct kent niet of nauwelijks dit soort fysieke eigenschappen. Dat betekent dat we andere eigenschappen moeten meten.
Een softwareproduct heeft, zoals zoveel gebruiksproducten, dynamische en statische eigenschappen. De bekendste vorm van meten van de dynamische eigenschappen van software is testen. Daarbij wordt vooral functionaliteit gemeten door een groot aantal nauwkeurig beschreven testgevallen af te lopen. Zoals bekend kunnen we met testen wel de aanwezigheid van fouten/problemen aantonen, maar nooit de afwezigheid. Want, omdat we vrijwel nooit alle toestanden van het programma kunnen testen, verkrijgen we niet de garantie dat een programma absoluut zonder fouten is.
Naast functionaliteit zijn er ook andere dynamische eigenschappen die kunnen worden gemeten, zoals performance, capaciteitsbeslag, beschikbaarheid, aantal incidenten tijdens gebruik et cetera.
Sinds jaar en dag wordt er ook gemeten aan statische eigenschappen van software, door het inspecteren van programmacode en documentatie. Bij programmacode kunnen diverse statische eigenschappen worden gemeten (zie kader). Vanwege de weinig gestructureerde vorm van documentatie is het lastig meten op dit terrein. Met behulp van checklists kunnen kenmerken als volledigheid, de actualiteit en de inhoudelijke kwaliteit in kaart worden gebracht. Ook het meten van een eventuele discrepantie tussen documentatie en programmacode is lastig, omdat er geen formele relatie tussen beide bestaat.
Binnen de levenscyclus van een softwareproduct zijn ruwweg twee fasen te onderscheiden: de ontwikkelfase en de gebruiksfase (beheerfase). Van oudsher wordt er in beide fasen veel aandacht besteed aan het meten van de gerealiseerde productiviteit. Dat betekent dat gemeten wordt wat er geproduceerd wordt, en in welke tijd. Wat er geproduceerd wordt, wordt vaak gemeten via de omvang van het softwareproduct. Daarbij moet een beslissing worden genomen over hoe de omvang zal worden gemeten: in bytes, in regels code of in functiepunten. Vaak wordt een eenheid als LOC verkozen, omdat het aantal regels code eenvoudig geautomatiseerd te meten is. Daarnaast moet de bestede tijd worden gemeten, het liefst tot op het niveau van basale activiteiten zoals het ontwerpen, coderen en testen.
In de gebruiksfase wordt de productiviteit van de beheerders gemeten. Daarbij wordt de tijdsduur gemeten van activiteiten zoals het oplossen van incidenten en het doorvoeren van gevraagde wijzigingen.

Een interessante vraag is nu welke rol de meetbare eigenschappen spelen in de theorie rond de kwaliteit van software en de daarmee verbonden processen. Er is en wordt veel geschreven over het begrip ‘softwarekwaliteit’. Volgens de huidige theorie spelen daarbij drie factoren een rol: het product, het proces en de resources.
Een van de meest bekende modellen aangaande de kwaliteit van een softwareproduct is de ISO/IEC-9126 standaard. In deze standaard worden ruim twintig verschillende kwaliteitsattributen benoemd en gegroepeerd in zes rubrieken. De attributen hebben zowel betrekking op het dynamische als het statische gedrag van het product. Voor ieder attribuut wordt binnen de standaard een nadere omschrijving gegeven, maar die is niet ‘geoperationaliseerd’, dat wil zeggen: er wordt niet aangegeven op welke manier via meting kan worden vastgesteld of het product aan een van tevoren gestelde norm voldoet. Er bestaat dus niet een heldere relatie tussen de genoemde attributen en de eerdergenoemde meetbare eigenschappen van een product. Daarmee kan de standaard helaas niet zonder meer worden ingezet voor een op metingen gebaseerde beoordeling van de kwaliteit van een product.

De kwaliteit van het proces van ontwerpen, bouwen en testen van software is al lange tijd een punt van aandacht binnen software-engineering. Er zijn tal van procesmodellen en methodieken ontwikkeld die de activiteiten in deze fase nauwkeurig benoemen, van de watervalmethode van Boehm tot en met de iteratieve methoden van nu, zoals DSDM, XP en RUP. In het wetenschappelijke bedrijf zou je verwachten dat de keuze voor een specifieke ontwikkelmethode empirisch onderbouwd wordt met bijvoorbeeld het expliciet meten van de kwaliteit van de opgeleverde producten, de productiviteit van de medewerkers, de effectiviteit van de ondersteunende tools. Voor zover mijn waarneming strekt, is dit maar in beperkte mate gebeurd. Daarmee krijgen de discussies over de voors en tegens van een methode meer het karakter van een geloofsstrijd dan van een wetenschappelijk debat.
Specifieke aandacht voor de processen rond het beheren en onderhouden van software is van recenter datum. Algemeen bekend zijn de procesframeworks als ITIL, ASL en BiSL. Met een procesframework wordt een aantal processen en hun onderlinge samenhang benoemd, maar wordt de feitelijke invulling overgelaten aan de werkvloer. Die invulling kan worden ontleend aan zogenaamde best practices: voorbeelden uit de praktijk. De genoemde procesframeworks bevatten geen (beschrijvingen van) expliciete meetprocessen. Het meten van de kwaliteit en effectiviteit van de ingerichte processen blijft daarmee helaas onderbelicht.
Aparte aandacht verdient CMMi als proceskwaliteitsmodel. Binnen CMMi wordt, net als bij de eerdergenoemde procesframeworks, een aantal processen met doelen en eigenschappen benoemd, en deze processen worden gerangschikt in vijf volwassenheidsniveaus (maturity levels). Op CMMi level 2 bevindt zich het Measurement and Analysis-proces. Dat geeft aan dat al op level 2 een organisatie geacht wordt een meetproces ingericht te hebben en zich bezig te houden met de analyse van meetdata. De procesbeschrijving geeft niet concreet aan wat er gemeten moet worden, maar hiervoor worden wel suggesties gedaan. Verder wordt er als eis gesteld dat er zorgvuldig gemeten en geanalyseerd wordt.

Onder de noemer resources vallen zowel mensen als ondersteunende tools. Ontwerpers en bouwers van hoge kwaliteit zijn, zoals in alle engineeringdisciplines, een noodzakelijke voorwaarde voor het ontwikkelen van een kwalitatief goed product. Daarnaast bepaalt de kwaliteit van de medewerkers uiteraard voor een belangrijk deel de productiviteit, en daarmee de kosten van ontwikkel- en beheerprocessen. Het meten van kwaliteit van medewerkers kan gebeuren op basis van hun opleiding en ervaring. Tegenwoordig spelen ‘verworven competenties’ een belangrijke rol bij het bepalen van het opleidingsniveau.
De ICT’er van nu staan allerlei hulpmiddelen ter beschikking, van syntaxgestuurde editors via programmaframeworks naar geïntegreerde ontwerpomgevingen. Net als bij ontwikkelmethoden geldt ook hier: het is lang niet altijd duidelijk in welke mate het oordeel over deze tools is gebaseerd op daadwerkelijk gemeten eigenschappen en resultaten.
We kunnen meten: er zijn metrieken, we hebben instrumenten om te meten. Desondanks lijkt de indruk gerechtvaardigd dat het inrichten van een meetproces niet tot de standaardactiviteiten van de doorsnee-ICT-organisatie behoort. Hetgeen met het oog op de kwaliteit van software buitengewoon onverstandig is (zie kader ‘Aanbevelingen’).

Jacob Brunekreef is als lector Softwarekwaliteit verbonden aan het Instituut voor Informatica van de Hogeschool van Amsterdam (j.j.brunekreef@hva.nl). Tevens is hij consultant bij Getronics PinkRoccade.
Dit artikel is een samenvatting van de door hem op 1 november in Amsterdam uitgesproken openbare les met de titel: ‘Een grijs gat – meten aan software(kwaliteit)’.

Voor reacties en nieuwe bijdragen van deskundigen: h.ester@sdu.nl of (070) 378 03 97.

Meten aan programmacode
Bij programmacode kunnen onder meer de volgende eigenschappen worden gemeten.
▪ Omvang
Het is verrassend om te zien hoeveel meeteenheden er zijn om de omvang van programmacode in uit te drukken. Waar in de fysieke wereld een lengtemaat als de meter een onbetwist uitgangspunt is om de omvang van een object te bepalen, zien we in de virtuele wereld van de software meeteenheden die gebaseerd zijn op verschillende uitgangspunten: bytes, regels code (LOC), functiepunten et cetera.
▪ Structuur
De structuur van programmatuur kan gemeten worden aan de hand van eigenschappen als ‘modulariteit’, ‘koppeling’ en ‘cohesie’. Er bestaan metrieken die deze eigenschappen uitdrukken in een getal. Aan de hand van die getallen kan de kwaliteit van een programma beoordeeld worden.
▪ Complexiteit
De bekendste complexiteitsmetriek is de cyclometrische complexiteit van McCabe. Deze metriek telt in essentie niets meer dan het aantal executiepaden binnen de code en is daarmee eenvoudig te meten. Programma’s met een hoge McCabe-complexiteit zijn doorgaans moeilijk te begrijpen en daarmee moeilijk te onderhouden. Deze metriek speelt dan ook een belangrijke rol bij het vaststellen van de onderhoudbaarheid van code.
▪ Kwaliteit
Onder deze noemer valt een groot aantal aspecten: gebruik commentaar, programma lay-out, gebruik naamgeving, correct gebruik taalconstructies et cetera. Het meten van deze aspecten is doorgaans lastig: er zijn geen eenduidige meetvoorschriften en normen, de meetresultaten zijn subjectief. Met het gebruik van checklists met concrete aandachtspunten kan zo goed als mogelijk geprobeerd worden deze bezwaren te ondervangen.

Aanbevelingen
▪ Meten aan software is minder eenvoudig dan het lijkt. Dit heeft alles te maken met het specifieke karakter van software. Gericht onderzoek op dit terrein is noodzakelijk.
▪ Veel van de huidige software-metrieken zijn nog onvoldoende objectief gedefinieerd (denk bijvoorbeeld aan de langlopende discussies over de objectiviteit van functiepunten). Dat maakt ze beperkt bruikbaar. Bestaande metrieken moeten geobjectiveerd worden.
▪ Productstandaards (ISO 9126) en procesframeworks (ITIL, ASL, BiSL) kennen geen empirische (op metingen gebaseerde) kwaliteitsnormen. Dit belemmert een objectieve discussie over de kwaliteit van producten en processen. Kwaliteitsnormen moeten geoperationaliseerd worden.
▪ Meten wordt in het ICT-werkveld nog te veel gezien als een verstoring van het proces, te weinig als een essentieel onderdeel ervan. Het meten en analyseren van meetresultaten moet in werkprocessen geïntegreerd worden.