Goede software is geen luchtspiegeling

‘Van de BRP-software is zeer beperkt documentatie beschikbaar. Tevens bevat de code rond het datamodel een aantal bevindingen ten aanzien van complexiteit, cyclische afhankelijkheden en codeduplicatie. Dit vormt een beperking voor de onderhoudbaarheid van deze code.’ Zomaar een passage uit een beoordeling door KPMG (september 2014) van de kwaliteit van de software van het gewraakte mGBA-project, dat inmiddels is omgedoopt tot Operatie BRP. Dergelijke klachten over softwarekwaliteit zijn helaas exemplarisch voor ICT-projecten bij de overheid.

Zonder goede software geen succesvolle overheids-ICT. De kwaliteit van software is een onderwerp dat bestuurders aangaat. Software is niet tastbaar, maar je kunt de kwaliteit ervan wel degelijk controleren. Dat inzicht geeft een opdrachtgever houvast om zijn rol goed in te vullen en verkleint daarmee de risico’s op ICT-falen. Maar in de praktijk gaat het vaak anders. ‘Goed geregeld’ is een verzameling artikelen waarin iBestuur een poging doet een vinger achter deze problematiek te krijgen.
Onder redactie van Maarten Hillenaar en Jan Polkerman!

Op 23 november organiseert iBestuur een symposium in Nieuwspoort over softwarekwaliteit. Gratis toegang voor deelnemers uit de publieke sector!

Dat geldt overigens ook voor andere sectoren. Uit een recent onderzoek van het Europese agentschap voor netwerk- en informatiebeveiliging ENISA bleek dat van de 137 grote storingen in de Europese telecomsector ongeveer een derde was toe te schrijven aan gebreken (bugs) in de gebruikte software. Maar het gaat bij de overheid wel erg vaak mis. Een beleidsprobleem moet snel worden opgelost en de software die dan wordt gebrouwen moet vooral dáárvoor de functionaliteit leveren. Onderhoudbaarheid, veiligheid, interoperabiliteit? Zit dat er niet vanzelf in dan? De commissie-Elias adviseerde vorig jaar al meer aandacht te besteden aan softwarekwaliteit en deze factor op te nemen in het Rijks ICT Dashboard.

Kloof

“Voor bestuurders geldt dat het bouwen van software, de code, iets heel abstracts is”, is de ervaring van Maarten Hillenaar, voormalig CIO Rijk en nu werkzaam bij PBLQ. “En IT’ers hebben jarenlang hun best gedaan om het te verpakken in een soort jargon.” Een dergelijke kloof is er in andere sectoren veel minder, constateert hij. Hij mag graag de auto als metafoor nemen. “Die mag pas de weg op als er 47 certificaten zijn afgegeven. Maar over de kwaliteit van software, wat zo langzamerhand toch het DNA van onze samenleving is, kunnen we ons nauwelijks een beeld vormen.”

Het enkele feit dat de software functioneert is niet genoeg

Softwarekwaliteit is geen zwart-witbegrip, relativeert hij. “Je kunt software maken die functioneel prima in orde is, maar die wel problemen oplevert op het moment dat je die moet gaan onderhouden en de ontwikkelaar er niet meer is.” Als je dat laatste niet belangrijk vindt omdat een applicatie niet lang mee hoeft te gaan, ook prima, wil hij maar zeggen. Maar het probleem is dat een bestuurder dat maar al te makkelijk kan vinden. “Hij moet nog een slag dieper. Het enkele feit dat het functioneert is niet genoeg. Die auto brengt mij echt wel van a naar b, die ene keer. Maar doet ’ie het de volgende keer ook nog?”

Beheerpijn

ICTU, dat voor diverse overheden ICT-projecten uitvoert, merkt wel degelijk dat de opdrachtgevers aandacht hebben voor softwarekwaliteit. “Veel van hen belanden daarom ook juist bij ICTU”, zegt Hans Verweij, hoofd Delivery Management van ICTU. “Ze kijken dan scherp of we verstand hebben van software bouwen en willen ons kwaliteitssysteem zien. Maar dat zien we vooral bij opdrachtgevers die meer in een beheerorganisatiehoek zitten. Bij beleidsopdrachtgevers hangt het ervan af. Als ze nauwelijks ICT-projecten onder hun hoede hebben, hebben we meer discussie over het belang van softwarekwaliteit.”

Bij ICTU wordt de agile-scrummethodiek ‘volgens het boekje’ gevolgd, zegt Verweij, in combinatie met een geautomatiseerd kwaliteitssysteem waarmee ook onderhoudbaarheid, veiligheid, privacy en sinds kort ook de gebruikerservaring voortdurend in de gaten worden gehouden. Agile is daarbij goed voor de kwaliteit, is zijn overtuiging. “Je zit dicht op elkaar en bestuurders kunnen zo heel snel bijsturen en vaststellen wat ze zonder toeters en bellen kunnen realiseren om op tijd op te leveren.”

Afspraken

Jan Polkerman, chief technology officer bij Belastingdienst/Centrum voor Applicatieontwikkeling en -onderhoud (B/CAO), steekt zijn frustratie niet onder stoelen of banken. “Het lijkt wel of software steeds minder lang houdbaar wordt.” De legacysystemen van dertig jaar geleden doen het nog prima, want die zijn gebouwd door mensen met een goede ontwikkelopleiding. “Dan leerde je dat als de software fout liep, dat die dan op een ordentelijke wijze moest aangeven wát er fout was. Die mocht niet zomaar stoppen.” Maar dat soort opleidingen ziet Polkerman niet meer. “Als je een webapplicatie bouwt, hoort daar bijvoorbeeld gewoon security in te zitten. Dan moet je niet zeggen dat de opdrachtgever daar niet om gevraagd heeft. Je hoort dat te weten vanuit je vakmanschap.”

Bij beleidsopdrachtgevers hebben we vaker discussie over softwarekwaliteit

Er mist iets in de softwarewereld, vooral als het om onderhoudbaarheid gaat, en daar hebben ook bestuurders last van. “Als je thuis een storing hebt met de elektrische installatie zal de monteur toch niet zeggen ‘ja, ik weet het ook niet’? Er zijn afspraken gemaakt over hoe het er in een meterkast uit hoort te zien. Maar bij software is de kwaliteit op dat vlak steeds slechter geworden. Als je een nieuwe auto koopt, krijg je die niet meer zonder airbags. Dat zou ook bij software zo moeten zijn.”

Acht eigenschappen

Het rare is: er is wel een bruikbare kwaliteitsstandaard voor softwarekwaliteit – en daar kwam Hillenaar ook pas tijdens zijn CIO-schap achter. De ISO 25010-standaard uit 2011 kijkt naar acht kwaliteitseigenschappen, waarvan functionaliteit er slechts één is en onderhoudbaarheid een belangrijke andere, met in totaal 31 subeigenschappen. (Zie pagina XX.) Aan de hand van dat lijstje zouden opdrachtgever (bestuurder) en uitvoerder (ontwikkelaar) kunnen afspreken waarop de één de ander afrekent en hoe dat gemeten wordt, desnoods met hulp van buitenaf. Zo blijft bijvoorbeeld ook ‘beveiligbaarheid’ in beeld. Veiligheid is vaak een voortschrijdend inzicht en een kwestie van aanpassing aan steeds veranderende dreigingen van buitenaf. Die aanpassingen worden een stuk moeilijker als de software moeilijk te doorgronden en slecht onderhoudbaar is.

Hillenaar: “Mijn ontdekking is dat er sinds een aantal jaren standaarden zijn die iets zeggen over de kwaliteit van de software, en dat je software wel degelijk tastbaar kunt maken.” In de ISO-standaard zitten elementen die goed meetbaar zijn en andere die minder goed meetbaar zijn, zoals gebruikersgemak, “maar waar je wél wat van kunt vinden. We moeten naar die kwaliteit durven kijken en IT’ers moeten dus ook met de billen bloot. En aan software die bedrijfskritisch is stel je uiteraard andere eisen dan aan een app die je na drie maanden weer weggooit.”

Polkerman: “Softwarekwaliteit is nooit zwart-wit. Maar je hebt wel een kapstok nodig en dan helpt zoiets als ISO 25010 enorm. Dan heb je iets op basis waarvan je bewuste keuzes kunt maken en waarlangs je kunt toetsen, met externe partijen die dat kunnen objectiveren. Maar als iemand maar wat heeft aangerotzooid, waarom zou je dan meten?” Bij de Belastingdienst wordt voortdurend gemeten. “Als je de normering niet haalt, hoor je in een onderhoudsplan aan te geven hoe je met die kwaliteit wilt omgaan. Het kan zijn dat je die kwaliteit accepteert en dus de bijbehorende hogere onderhoudskosten.”
Hans Verweij van ICTU: “Bestuurders zijn echt vaak onbewust onbekwaam op dit vlak. En ik vind het onze rol om ze bewust onbekwaam te maken, zodat ze weten welke toekomstige risico’s ze lopen als ze niet letten op softwarekwaliteit.”

Jong vak?

Uiteindelijk blijft software bouwen nog steeds een ambacht. Verweij: “Je ziet vaak dat iemand heel goed is in zo’n scrumteam; die krijgt automatisch de rol dat hij de kern van een applicatie maakt.” Polkerman: “Richtlijnen zeggen niet alles. In de bouw doen ze dat slimmer, met een meester-gezelconstructie. Daar is ook niet alles tot op het bot beschreven. Dingen leer je toch in de praktijk.”
Vaak wordt er gewezen op ‘de jongheid van het vak’, als excuus voor de gebreken. Polkerman vindt dat achterhaald; zo jong is het vak niet meer. En: “Software is vluchtig en kost gruwelijk veel geld, en dan zou die niet meetbaar zijn! Het gaat erom dat je iets wederzijds als een norm accepteert en afspreekt. Softwarebouwers zouden die uit zichzelf moeten leveren. En opdrachtgevers moeten die formaliseren, in ieder geval in de opdracht.”

Verweij is het daarmee eens: “Ik zou het toejuichen als we binnen de overheid meer met normen als ISO 25010 gaan werken. Over hoe je software bouwt, hoe je die toetst en waar die aan moet voldoen. En ook hoe software van de ene naar de andere partij kan worden overgedragen.”
Alle drie de deskundigen verwonderen zich over het feit dat ‘de markt’ zelf zo weinig laat zien welke kwaliteit software ze leveren. Polkerman: “De branche zelf zou ook moeten zeggen ‘we willen gewoon kunnen aantonen dat we goed werk hebben geleverd’.”

De borging van softwarekwaliteit zal toch vooral vanuit de overheid zelf moeten komen. Een beetje bestuurder weet wel dat er met ICT nogal snel dingen mis kunnen gaan. “Maar het gaat nu vaak van ‘vertrouw ik mijn projectmanager?’” zegt Hillenaar. “Dat is nogal subjectief. Je hebt er allebei baat bij als je het kunt objectiveren.” Niet dat alles dan meteen goed gaat. “Het is toch vooral even ‘het deksel optillen’; er blijven nog steeds andere dingen over die mis kunnen gaan. Maar het formaliseren van softwarekwaliteit helpt wel enorm om die dialoog tussen bestuurder en IT’er te voeren.”