Zet je niet af, maar stel een doel

Introductie

Met regelmaat lezen we in de krant over vertraagde IT-projecten, waarbij de kosten uit de hand lopen. Ook storingen verschijnen consequent in het nieuws: opnieuw heeft een mobielbankieren-app een storing of klanten kunnen door een technisch probleem niet meer pinnen. We kunnen hieruit concluderen dat de realisatie en werking van IT-applicaties, waar we dagelijks mee in aanraking komen, niet zonder problemen en foutloos is.

Het management van organisaties wil niet met dit soort zaken geconfronteerd worden. Als gevolg hiervan worden er rond IT-programma’s en -projecten maatregelen genomen. De focus ligt daarbij vaak op de wijze waarop het IT-project wordt aangepakt. Dit heeft geleid tot een veelheid aan projectmethodieken en daarmee samenhangende opleidingen rondom deze methodieken. Om echter de genoemde problemen van IT-applicaties te voorkomen, is een aanpak met daarin ruimte voor kwaliteitscontroles en testen essentieel.

Bij de kwaliteitscontrole wordt veel aandacht besteed aan de vraag of de gekozen methodiek in de daadwerkelijke aanpak wordt gevolgd. Is er een budgetcontrole? Zijn de mijlpalen daadwerkelijk bereikt? Worden er reviews uitgevoerd van de kwaliteit van de documentatie?

Daarnaast is er aandacht voor het voorbereiden van de verschillende tests. Wordt daar voldoende tijd aan besteed, is er tijd ingepland om testbevindingen op te lossen en komt het testen bij uitloop van andere onderdelen niet onder tijdsdruk te staan? Is de functionele diepgang van de tests voldoende? Wordt er ook aan niet-functionele eisen, zoals de performance en beveiliging, gedacht?

Een apart team binnen het project, of onafhankelijke adviseurs, schrijven rapporten vol met bevindingen en geven daarbij aan of het project zich nog op het goede pad bevindt. Vaak worden hierbij aanbevelingen gedaan om de projectbeheersing te verbeteren en de kans op problemen te verkleinen. Omdat voorspellen moeilijk is, wagen deze rapportages zich veelal niet aan een vooruitblik; zeker niet zolang het project zich nog langs de gewenste lijnen ontwikkelt. Omdat aangetoond is dat goede processen bijdragen aan het succes van IT-projecten zijn deze onderzoeken zinvol. Het is echter vooral belangrijk om naar de kwaliteit van het product zelf te kijken, ook tijdens de ontwikkelingsfase.

Softwarekwaliteit: de binnenkant en de buitenkant

Als het gaat om de kwaliteit van software, is er een onderscheid te maken tussen de binnenkant en de buitenkant. Bij de buitenkant richt men zich op de werking van de software: biedt het product de functionaliteit die wordt gevraagd? Ontwikkel je bijvoorbeeld rekensoftware, dan wil je er zeker van zijn dat het programma berekeningen correct uitvoert. Door uitvoerig te testen, kan de functionaliteit van de software gewaarborgd worden. Daarnaast is de aantrekkelijkheid van het product van belang. Ziet de applicatie er goed uit en is de werking intuïtief en gebruiksvriendelijk? Kortom, het evalueren van de buitenkant is gericht op de praktische toepassing ervan, waarbij de ervaring van de gebruiker centraal staat.

Traditioneel ging de aandacht in testprocessen voornamelijk uit naar de buitenkant, maar tegenwoordig is deze ook op de binnenkant gericht. Dit is een terechte ontwikkeling: problemen met betrekking tot de veiligheid en betrouwbaarheid vinden vaak hun oorsprong aan de binnenkant.

Deze binnenkant draait om wat er ‘achter’ de applicatie zit. Dit heeft betrekking op het perspectief van de ontwikkelaar en het ontwikkelproces. Denk bijvoorbeeld aan de leesbaarheid of complexiteit van de broncode. Om de kwaliteit te evalueren, is broncodeonderzoek populair. Hierbij wordt met geautomatiseerde hulpmiddelen de broncode geanalyseerd en zo gekeken of het ontwikkelteam zich aan de afgesproken ontwikkelstandaarden en good practices heeft gehouden.

De kwaliteit van de binnenkant is van groot belang om het systeem op lange termijn te onderhouden en onvermijdelijke wijzigingen te integreren. Gezien de constante verandering waaraan de softwaremarkt onderhevig is, is dit ook essentieel voor de positie van de applicatie in de markt.

Figuur 1. Enkele van de kwaliteitsaspecten volgens de ISO 25010-standaard [ISO14], weergegeven naar externe en interne aspecten. [Klik op de afbeelding voor een grotere afbeelding]

Het nut van benchmarking

Aandacht voor zowel de binnenkant als buitenkant is essentieel voor goede software. Het verband tussen verschillende kwaliteitsaspecten en de gevolgen voor onder meer de projectduur, het aantal bugs en de realisatiekosten was in het verleden niet direct inzichtelijk. Inmiddels is naar veel van dit soort verbanden uitgebreid onderzoek gedaan. Indrukwekkend is bijvoorbeeld het werk van Capers Jones [Jone12]. Hij bracht, mede mogelijk gemaakt door zijn werkgever IBM, de gegevens van meer dan 13 000 softwareprojecten bij elkaar. Een enorme berg gegevens: van het aantal storingen in hardware, metingen van projectvoortgang, backlog, gebruikerstevredenheid, bugs, teamomvang, kosten en opbrengsten. Capers Jones vindt alles wat je maar kunt vastleggen van groot belang.

In twee dikke boeken [Jone08], [Jone12] worden de resultaten van zijn analyses en benchmarks gepresenteerd. Deze resultaten zijn uiteenlopend, zo wordt bijvoorbeeld een vergelijking gemaakt tussen de tijdsbesteding van een softwareontwikkelaar bij een ‘gewoon’ of ‘tijdkritisch’ project. De aandacht wordt voornamelijk getrokken door het gevonden verband tussen de omvang van het systeem, de softwarekwaliteit en productiviteit van de ontwikkelaar (veelal als equivalent van de kosten van een project). Zo blijkt dat in alle fasen (dus ook tijdens de ontwerpfase) van softwareontwikkeling fouten worden geïntroduceerd. Daarbij geldt: hoe later deze in het project worden ontdekt, hoe hoger de herstelkosten. Daarnaast blijkt de productiviteit (uitgedrukt in functiepunt per medewerkersmaand) van een softwareontwikkelaar behoorlijk af te nemen bij de realisatie van grote systemen.

De interessante bevindingen van Capers Jones leiden ook tot een duidelijke waarschuwing: vergelijk een individueel systeem niet te snel met een ander systeem of benchmark. Ten eerste worden systemen in deze onderzoeken op veel verschillende manieren ingedeeld. Dit is niet alleen op basis van de functionele omvang, maar onder meer ook naar technisch platform, ontwikkelmethodiek en gebruikersgroep. Deze indeling blijkt relevant en telkens tot (iets) andere resultaten te leiden. Ten tweede worden bij de resultaten de spreiding en onzekerheidsmarges weergegeven. Deze statistische benadering geeft aan dat er weliswaar een verband is, maar dat het ook regelmatig voorkomt dat een individueel systeem afwijkt van het gemiddelde. Het maken van software blijkt niet eenvoudig tot vergelijkbare uitkomsten te leiden.

Een benchmark kan zinvol zijn, maar men dient de context waarin deze ontwikkeld wordt goed te duiden om tot een bruikbare vergelijking te komen. Deze context, waaronder het beoogde gebruik van het systeem valt, heeft impact op de manier waarop de software ontwikkeld wordt. Voor sommige systemen bestaat er geen of slechts een beperkte groep vergelijkbare systemen – er is bijvoorbeeld een gering aantal bevolkingsregistraties of systemen voor het aansturen van de Deltawerken. Bij het ondersteunen van een marketingcampagne wil je bovendien juist de uniciteit van het product uitstralen.

Software bouwen is geen wedstrijd

De noodzaak om al tijdens de ontwikkelingsfase aandacht te besteden aan de verborgen aspecten van softwarekwaliteit heeft geleid tot een focus op de metriek die vanuit de broncode van de software kan worden bepaald. En terecht! Veel van deze automatisch te meten aspecten bieden inzicht in met name de ‘onderhoudbaarheid’ (zoals gedefinieerd in de ISO/IEC 25010-standaard [ISO14], zie ook het kader hierover op pagina 52). Onderhoudbaarheid is weer een belangrijke voorspeller voor de aanpasbaarheid van de software en daarmee (onder meer) van de onderhoudskosten.

Het blijkt dat, wellicht onder druk van het management, het erg verleidelijk is om met behulp van benchmarking een vergelijking tussen systemen tot stand te brengen. Op dit moment is het in Nederland gebruikelijk dat als er een benchmarkingscore wordt behaald die aangeeft dat het systeem op onderhoudbaarheidsmetrieken tot de beste twintig procent behoort de software op dit aspect ‘goed’ is.

Hiermee wordt volledig voorbijgegaan aan de context waarin de software wordt ontwikkeld. Software bouwen is dan ook geen wedstrijd. Het moet draaien om het met aanvaardbare inspanning (kosten, doorlooptijd, et cetera) leveren van waarde gedurende de levensduur van het systeem. Wat deze waarde betekent, kan sterk verschillen per project.

Het is daarom weinig zinvol om de metriek van softwarekwaliteit te vergelijken met benchmarks, mede omdat de grenswaarde van de beste twintig procent bij een algehele kwaliteitsverbetering opschuift. Met andere woorden: software die vandaag ‘goed’ is, hoeft dat volgend jaar niet meer te zijn. Daarnaast leidt het vergelijken van software met uiteenlopende functionaliteit niet tot aanknopingspunten voor structurele verbetering. Bepaalde aspecten moeten voor het ene project zwaarder wegen dan voor het andere. Denk daarbij bijvoorbeeld aan de aanpasbaarheid van de software bij een voorziene levensduur van zes maanden versus een van tien jaar. In een vergelijking met de benchmark gaat deze nuance verloren.

Het vergelijken van softwarekwaliteit op basis van benchmarks leidt tot een situatie waarin men streeft om een hogere rank te verkrijgen en bij de beste twintig procent te horen, terwijl juist het leveren van waarde centraal zou moeten staan. Vergelijkingen op basis van benchmarks kunnen gebruikt worden om het vak van softwareontwikkeling beter te begrijpen en daarin verbeterpunten te vinden, maar niet om de competitie tussen ontwikkelteams vorm te geven.

Richt kwaliteitsmanagement in

Sturen op de kwaliteit van software is vanaf het allereerste begin van een systeem belangrijk. Wij adviseren dan ook om de metriek vanuit de broncode transparant te maken voor de ontwikkelaars en stakeholders. Dit is vrijwel altijd goed mogelijk met beperkte middelen. De bestaande tooling is dermate ontwikkeld dat de locatie van een eventueel probleem in de broncode wordt aangegeven. Met behulp van deze aanwijzingen wordt de ontwikkelaar ondersteund om de kwaliteit van de software te verbeteren. Aanvullend legt de tooling de ontwikkeling van de kwaliteitsmetriek in de loop van de tijd vast.

Met behulp van deze gegevens kan de organisatie dan kwaliteitsdoelen stellen en tracken. Dit hoeft niet ingewikkeld te zijn; er is eenvoudig een aantal ‘good practices‘ te vinden. Vervolgens kan met de gebruikte tooling worden bepaald of aan deze doelen wordt voldaan. Mochten de doelen niet behaald zijn, dan leidt dat tot heldere aanknopingspunten om de kwaliteit te verbeteren. Als de monitoring wordt voortgezet, volgt vanzelf de kwaliteitscirkel van Deming [Demi86], waarmee een continu verbeteringsproces tot stand wordt gebracht.

In de praktijk is aangetoond dat deze aanpak niet alleen werkt voor systemen in de beginnende fase, maar ook voor systemen waar al een aantal jaar aan gewerkt wordt en die nog een aantal jaar moeten functioneren. Vrijwel altijd treffen we een afstand aan tussen de kwaliteitsdoelen en de daadwerkelijke kwaliteit van de broncode. Door echter gestaag te werken aan verbetering, naast het reguliere softwareontwikkelwerk, wordt de broncode steeds beter. Op deze wijze worden op termijn de kwaliteitsdoelen wél gehaald.

Door het inrichten van een kwaliteitssysteem met een ‘monitor’ kan men er zeker van zijn dat de onderhoudbaarheid van de software goed is en blijft, onafhankelijk van een vergelijking met andere ontwikkelteams aan de hand van een benchmark.