zoeken binnen de website

Goede software is geen luchtspiegeling

door: Freek Blankena | 15 oktober 2015

Het komt maar al te vaak voor: een ICT-project bij de overheid dat niet van de grond komt, (mede) omdat de ontwikkelde software bij nader inzien kwalitatief onder de maat blijkt. Bestuurders/opdrachtgevers weten vaak niet wat die maat inhoudt. Maar er is wel degelijk meer grip op softwarekwaliteit mogelijk. “Elke nieuwe auto heeft toch ook een airbag?”

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.


Logo-special-Goed Geregeld, iBestuur magazine 16
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.”

reacties: 2

tags:

  • Paul Dijkstra, Software Tester #

    16 oktober 2015, 10:15

    Geachte redactie,

    ISO-standaarden zijn handig als kapstok bij het opstellen van gebruikerseisen, maar gebruikerswensen zijn niet altijd van te voren te voorzien en vast te leggen. De grip op de kwaliteit van software kan ook nog op andere manieren worden verbeterd.
    Kwaliteit van software kan, zowel door leverancier als opdrachtgever, worden gewaarborgd door middel van het testen van software door testprofessionals. Deze professionals toetsen op een gestructureerde wijze de eisen en wensen die de leverancier en de opdrachtgever overeen zijn gekomen voor en tijdens de totstandkoming van het eindproduct. Voordat dit traject start, zouden beide partijen afspraken kunnen maken aan de hand van de kwaliteitsattributen voor software zoals die in ISO-standaarden beschreven staan. Het is dus aan te raden een leverancier te vinden die het testproces in zijn ontwikkelproces heeft opgenomen. Daarnaast is de opdrachtgever ook verantwoordelijk voor de kwaliteit en moet hij ook testen in een testomgeving die zijn productieomgeving benadert. Verder is het belangrijk dat de opdrachtgever continue betrokken blijft bij de ontwikkeling van de software. Er kan onderling worden afgesproken de software in kleine stapjes te maken en te presenteren aan de klant. Mochten er tijdens de presentatie discrepanties zijn tussen de verwachtingen van de klant en het opgeleverde tussenproduct, dan kunnen er nog tijdig wijzigingen worden aangebracht, zodat er niet op het eind pas onvolkomenheden naar boven komen drijven die met veel tijd en geld opgelost moeten worden.

    Met vriendelijke groet:

    Paul Dijkstra,
    Testprofessional

  • Thomas Peters - Omnext #

    20 oktober 2015, 12:55

    Een uitstekend artikel! Gelukkig ontstaat er steeds meer bewustwording (soms helaas door schade en schande) om naast functionaliteit, maar ook naar kwaliteit te kijken. De volgende stap is het in kaart brengen van deze software kwaliteit. Door deze vóór aanvang van het project af te stemmen en gedurende de ontwikkeling te monitoren kunnen grote tegenslagen en uit de hand lopende software projecten worden voorkomen.

    Met een (automatische) broncode analyse kunnen onder andere op de ISO-25010 kenmerken, industrie standaarden en best practices snel inzichtelijk worden gemaakt. Door een ‘drill-down’ in deze informatie tot op code niveau mogelijk te maken kan je geconstateerde problemen gelijk aanwijzen en verbeteren.

Reactieformulier

De met een * gemarkeerde velden zijn verplicht. U ziet eerst een voorbeeld en daarna kunt u uw bijdrage definitief plaatsen. Uw e-mailadres wordt niet op de site getoond. Reacties zonder achternaam worden verwijderd. Anoniem reageren alleen in uitzonderlijke gevallen in overleg met de redactie. U kunt bij de vormgeving van uw reactie gebruik maken van textile en er is beperkt gebruik van html mogelijk.