Alleen softwarekwaliteit door prominentere rol beheerder

Onder het motto “laat de methodenstrijd links liggen” wordt een pleidooi gehouden om minimaal tijd en geld te steken in discussies over het inrichten van het ontwikkelproces en de te kiezen architectuur, maar de aandacht met name te richten op de kwaliteit van het op te leveren product. Meer specifiek: op de kwaliteit van de broncode. In een reactie daarop propageren Ben Slijk, Hans Keller en Iwan Eising in de Automatisering Gids van 8 december 2006 een separaat intern controleproces, waarin zowel de kwaliteit van het ontwikkelproces als de kwaliteit van het product dat ontstaat, wordt bewaakt.
In dit artikel wil ik enkele kanttekeningen plaatsen bij deze stellingnames en een ander aspect van het begrip softwarekwaliteit naar voren brengen: vroegtijdige aandacht voor de rol van een specifieke stakeholder, de beheerder.

Broncode
In hun artikel vullen Klerkx en Krom het begrip ‘kwaliteit van broncode’ in met kwaliteitsmetrieken betreffende complexiteit van code, architectuurissues, codeerstandaarden et cetera. Deze criteria vallen grosso modo in de categorie ‘technische’ kwaliteit. Maar, zoals ook al opgemerkt door Slijk c.s., technisch goede broncode leidt niet per definitie tot een goede applicatie. De geleverde functionaliteit blijft immers buiten beschouwing, en dit is toch het eerste criterium waarop een applicatie door gebruikers beoordeeld wordt.
Een tweede punt is dat er pas gemeten kan worden als er ook iets te meten valt, oftewel: als er broncode geproduceerd is. Dat betekent dat de eerste fase van een ontwikkeltraject, waarin gespecificeerd en ontworpen wordt, buiten beschouwing blijft. En juist in deze fase wordt de kiem gelegd voor veel problemen: onvolledige specificaties, onduidelijke ontwerpen, onwerkbare architectuurkeuzes kunnen zorgen voor bijna onoplosbare problemen in een latere fase.
Een praktisch bezwaar tegen het auditen van broncode in de ontwikkelfase is dat tijdens het ontwikkelen vaak de nodige ‘bouwsteigers’ in de code aanwezig zijn: debugconstructies, testcode, stubs. Die kunnen de uitkomsten van metrieken en daarmee het kwaliteitsbeeld fors beïnvloeden.
In een ontwikkeltraject staan projectmedewerkers voortdurend onder druk om planningen te halen. Onder deze druk kan de verleiding groot worden om af te wijken van eerder vastgelegde kwaliteitsnormen, soms met grote gevolgen. Slijk c.s. geven aan dat een intern controleproces deze gevolgen tijdig kan detecteren en correctieve acties kan initiëren.
De duale aanpak (creatieproces en controleproces naast elkaar) zal goed werken als de nadruk ligt op controle van de op te leveren producten. Een controle op het proces zal alleen werken als het proces zelf niet onder druk staat. Maar, in veel ICT-projecten is dat juist wel het geval: onder druk van planning en budget wordt helaas te snel besloten om bepaalde processtappen af te raffelen of over te slaan. Een intern controleproces heeft niet de positie om dit bij te sturen. De uitvoerders van het controleproces (een interne QA-afdeling?) worden doorgaans niet gezien als relevante stakeholders met betrekking tot het product in ontwikkeling. Zij hebben geen aanwijsbaar belang bij het project en/of het product. Dat maakt dat hun inbreng in meer of mindere mate gemarginaliseerd kan worden door stakeholders als opdrachtgevers en projectmanagers. Als de voortgang van een project onder druk komt te staan worden al snel pragmatische oplossingen gekozen die op gespannen voet staan met aanbevelingen vanuit een separaat controleproces.

Kernvraag
Terug naar de kernvraag van de discussie: Hoe maak je software die kwalitatief goed is? Kwaliteit is een begrip met meerdere dimensies: flexibiliteit, functionaliteit, betrouwbaarheid et cetera. De verschillende kwaliteitsdimensies worden bewaakt door verschillende stakeholders (partijen) in de softwarelifecycle. Zo zal een opdrachtgever meer oog hebben voor flexibiliteit, een gebruiker voor functionaliteit, een beheerder voor betrouwbaarheid.
De aanwezigheid van meerdere kwaliteitsdimensies en meerdere stakeholders is niet uniek voor het terrein van softwareontwikkeling. Het bovenstaande is van toepassing op iedere bedrijfstak waar producten geproduceerd worden voor gebruik: de bouw, de chemische industrie, de auto-industrie et cetera. Wat wel afwijkend is in de lifecycle van een softwareproduct, is de prominente rol van onderhoud en beheer. Een aanzienlijk deel van de totale kosten van de lifecycle van een applicatie wordt gemaakt in de beheerfase. Dat maakt het opmerkelijk dat beheerpartijen vaak niet of nauwelijks betrokken worden bij het creatietraject. Ik wil een pleidooi houden om deze situatie te veranderen.
De situatie nu: een softwareproduct wordt ontwikkeld en, hopelijk na grondig testen door onder andere de toekomstige gebruikers, in productie genomen. Daarbij worden broncode en productdocumentatie (specificaties, ontwerpen, handleidingen) overgedragen aan de beheerder. Soms heeft dit het karakter van ‘over de muur gooien’, soms vindt een meer zorgvuldige overdracht plaats. Een algemene karakterisering van de kwaliteit van hetgeen wordt overgedragen is de volgende (wellicht enigszins een karikatuur):
• Een product dat werkt, maar waar nog wel wat aan te verbeteren valt. Een softwareproduct is vaak nog niet helemaal gereed op de geplande opleverdatum. Onder druk van de opdrachtgever en/of projectmanager wordt toch opgeleverd, een aantal onvolkomenheden wordt geaccepteerd en het verhelpen ervan wordt alvast ingepland voor komende releases.
• Documentatie die niet compleet en up-to-date is. Onder druk van een tijdige oplevering is de documentatie vaak de klos. Dit geldt met name voor de documentatie die voor beheer van belang is: specificaties, ontwerpen, testdocumenten.
De gevolgen voor beheer zijn: een product waar op korte termijn flink aan gesleuteld moet worden, met onvoldoende documentatie. Voorwaar geen goed startpunt voor optimaal beheer. Die situatie kan verbeterd worden door beheer te betrekken bij het ontwikkeltraject.

Beheer
In het verleden (laten we zeggen, tot voor 10 jaar geleden) werd aan het eind van een ontwikkeltraject het applicatiebeheer vaak belegd bij (een deel van) de ontwikkelaars: de bouwers bleven hun product trouw. Tegenwoordig wordt algemeen erkend dat beheer een specifiek vakgebied is, met eigen processen en standaarden (ITIL, ASL, BiSL). Beheer is geprofessionaliseerd en wordt uitgevoerd door specifiek opgeleide vakmensen.
Door een opdrachtgever of projectmanager wordt doorgaans pas nagedacht over het inrichten en beleggen van het beheer als een product (bijna) gereed is. Een beheerder komt in beeld kort voor of tijdens de overdracht van het product. Dan rest nog slechts de mogelijkheid om in het kader van een acceptatieprocedure het product af te wijzen of aan te (laten) passen. Door met name applicatiebeheer eerder bij de ontwikkeling te betrekken kan de technische kwaliteit van het op te leveren product, en daarmee de beheerbaarheid, verhoogd worden. Dat betekent concreet dat niet een externe partij of een aparte QA-afdeling maar een direct betrokken stakeholder (applicatiebeheer) invulling gaat geven aan de controle op de technische kwaliteit van een product in de ontwikkelfase.
Hoe zou het betrekken van applicatiebeheer bij een ontwikkeltraject vorm moeten krijgen? De volgende suggesties vormen een eerste antwoord op deze vraag.
1. Leg al in een vroeg stadium van een ontwikkeltraject vast waar (bij welk onderdeel van de organisatie, bij welke applicatiebeheerder) het applicatiebeheer na oplevering belegd gaat worden.
2. Betrek applicatiebeheer bij de verschillende fasen van het ontwikkeltraject. Laat hem de technische kwaliteit van de geproduceerde code en de kwaliteit van de beheerdocumentatie reviewen. Daarmee bouwt de applicatiebeheerder kennis op van de applicatie die hij in een later stadium moet gaan onderhouden en beheren, bovendien kan hij zo de kwaliteit bewaken.
3. Maak een positief oordeel van de applicatiebeheerder tot een noodzakelijke voorwaarde voor het in productie nemen van een applicatie, net zoals een positief oordeel van de toekomstige gebruiker dat is.

Erg lastig
Er zijn factoren die het bovenstaande bemoeilijken, zo niet onmogelijk maken. Als de ontwikkeling en het beheer van een product zijn belegd bij verschillende leveranciers, dan wordt het erg lastig om een gemeenschappelijk traject in te vullen. Zeker in deze tijden van outsourcing en offshoring komt dit in toenemende mate voor. Maar zelfs dan is het wenselijk om al in een vroegtijdig stadium een manier te vinden om de betrokkenheid van toekomstig beheer bij het ontwikkelen van een product vorm te geven.
Het vroegtijdig aanwijzen en inzetten van een beheerder kost geld, dat is duidelijk. Maar, het mag ook duidelijk zijn dat het geld oplevert: er ontstaat een kwalitatief beter product dat tegen minder kosten beheerd kan worden. Bovendien is de beheerder ingewerkt op het moment dat de applicatie in productie gaat en daarmee verminderen de aanloopkosten.

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.