Goede softwarekwaliteit is belangrijk voor onder meer betaalbaar onderhoud en veiligheid. Het is een breed begrip dat zeker ook bestuurders aangaat. De verschillende invalshoeken werden besproken tijdens een volledig volgeboekt iBestuur symposium op 23 november in Nieuwspoort.
Bob Papenhuijzen, directeur Logius, opende het symposium: “Voor Logius is het vooral van belang dat software zich goed laat overdragen!”
Wat is softwarekwaliteit eigenlijk, vraagt middagvoorzitter Maarten Hillenaar tijdens het symposium Goed geregeld – grip op softwarekwaliteit. Meestal wordt dit uitgedrukt in functionele kwaliteit, zo wordt gesteld: doet de software wat hij moet doen? “Zo heb ik er als CIO Rijk ook altijd naar gekeken”, erkent Hillenaar. “Maar met de kennis die ik nu heb, zou ik breder kijken. Want softwarekwaliteit gaat ook over of software goed aan te passen en te onderhouden is. Over aspecten als veiligheid, overdraagbaarheid en zelfs energieverbruik door software.” Het goede nieuws is: de kwaliteit van software is te controleren en te meten. Dat wordt door verschillende partijen op diverse manieren gedaan; zij leggen tijdens het symposium met praktijkvoorbeelden uit hoe dat werkt. Controle achteraf en tijdens het ontwikkelproces blijkt nodig, maar eigenlijk zou je willen dat het leveren van kwaliteit zit ingebakken in het proces omdat programmeurs goed werk leveren. “Je kunt dus stellen dat softwarekwaliteit ook en misschien wel vooral gaat over vakmanschap”, stelt Hillenaar.
Lekker rommelig bouwen
Bob Papenhuijzen, directeur van Logius, schetst in zijn keynote hoe hij de ontwikkeling van het programmeervak zelf meemaakte. Aanvankelijk als onderzoeker bij TNO, waar we “lekker rommelig bouwden in C. Dat bouwproces had een eigen dynamiek en weinig structuur, we begonnen met wat we het leukste vonden. Ik kan u vertellen dat deze stroming later behoorlijk groot is geworden.” Als opdrachtgever keek hij later anders aan tegen softwareontwikkeling en in zijn huidige rol bij Logius speelt softwarekwaliteit een grote rol. “Voor Logius is het vooral van belang dat software zich goed laat overdragen, omdat wij daar veel mee te maken hebben. We focussen ons qua softwarekwaliteit nu op twee aspecten: onderhoudbaarheid en veiligheid. Controle op overdraagbaarheid hebben we nog niet geoperationaliseerd.” De ISO-norm 25010 voor softwarekwaliteit bevat in totaal acht aspecten. “We hebben er dus nog zes te gaan”.
‘Softwarekwaliteit gaat misschien wel vooral over vakmanschap’
ICTU vertaalde alle aspecten uit de ISO-norm in een eigen kwaliteitssysteem, vertelt Jan Peter Jansen, teamleider technical project leads bij ICTU. In een presentatie samen met Jan Ruijter van Inspectie SZW vertelt hij over hoe ICTU een “één miljoen regels code groot applicatielandschap” van de Inspectie overnam in onderhoud, doorontwikkeling en beheer. Hiervoor werd een nieuw ontwikkelteam binnen ICTU samengesteld, die in het afgelopen jaar in vijf releases nieuwe functionaliteit bouwde. Het was een wens van de Inspectie om vaker en sneller nieuwe functionaliteit ter beschikking te stellen en dat is gelukt dankzij de agile/scrum- werkwijze van het ontwikkelteam bij ICTU. Jansen vertelt dat er wordt gewerkt in sprints van drie weken, waarop een oplettende luisteraar in de zaal vraagt hoe dit zich verhoudt tot vijf releases in een jaar. “Dat komt omdat de beheerorganisatie nog niet gewend is aan agile werken. Wij bundelen onze resultaten en zij nemen deze mee in hun eigen proces”, antwoordt Jansen.
Toppertjes
Wat opvalt in de presentatie van ICTU met de Inspectie SZW is de grote nadruk op de kwaliteit en de inzet van programmeurs. Jansen spreekt over “toppertjes”: “We selecteerden samen met de Inspectie programmeurs voor het nieuwe ontwikkelteam, waarbij we keken naar mensen die het bouwen van functionaliteit en kwaliteit gelijk op laten gaan. Mensen die een teamspeler zijn en die bijvoorbeeld de testers helpen als die achterlopen.”
Jan Peter Jansen van ICTU en Jan Ruijter van Inspectie SZW: “De kwaliteit van het systeem is beter geworden.”
De kwaliteit van hun werk wordt gemeten in het kwaliteitssysteem en teruggekoppeld, “de sprintpunten zijn meetbaar en daarmee brengen we het rendement van het team in kaart”. De Inspectie is een tevreden klant, zegt Ruijter: “De kwaliteit van het systeem is beter geworden, we hebben geen verstoringen meer gehad, er is een mobiele inspectie-app ontwikkeld en ik kan nu vertrouwen op een voorspelbaar en gestroomlijnd proces van nieuwe releases. De codekwaliteit is aangepakt en getoetst door Institute for Software Quality (IfSQ), dat heeft laten zien dat het nu ook echt beter is.”
ISO-norm is slechts papier
Veiligheid is een ander aspect van softwarekwaliteit. Ferdinand Vroom, security officer NN Group, vertelt hierover in een interview door Frans van Buul, solution architect HP Fortify. Vroom schetst diverse manieren van testen en de voor- en nadelen daarvan. Over dynamisch en statisch testen, over automatisch testen en code reviews. Een conclusie die voor al deze manieren van testen geldt: “Je kunt een blok code invoeren in een systeem en op ‘start’ drukken, maar dan krijg je lang niet alles te zien. Je moet weten hoe een applicatie in elkaar zit om goed te kunnen testen.” Een uitdaging die NN tegenkomt bij het controleren van softwarekwaliteit is de lastige integratie met een agile omgeving. Vroom: “We hebben redelijk veel tijd nodig voor een check, dat past niet goed in het tempo van sprints.” Een oplossing kan zijn om de codecontrole als een externe dienst af te nemen. “Het nadeel daarvan is echter dat je de kennis en daarmee de kwaliteit van je eigen programmeurs vergroot als ze zelf betrokken zijn bij de controle van softwarekwaliteit. Dat verlies je als je het extern laat doen.”
‘Je moet weten hoe een applicatie in elkaar zit om goed te kunnen testen’
NN Group ontwikkelde zijn eigen beleid voor softwarekwaliteit, vertelt Vroom: “We werken niet met de ISO-norm, want het zegt niet zoveel als organisaties daar aan voldoen. Een leverancier van ons had alle stempels en toch ging er heel veel mis. Op papier kun je alles op orde hebben, maar het gaat om wat je doet in de praktijk.”
Vroom is bestuurslid van Open Web Application Security Project (OWASP), een ngo die zich inzet voor het delen van kennis over de beveiliging van webapplicaties. Hij zou graag zien dat de Nederlandse overheid een eigen chapter opricht binnen OWASP, om zich te buigen over specifieke beveiligingsvraagstukken zoals privacy. Ad Reuijl, directeur Centrum Informatiebeveiliging en Privacybescherming (CIP), reageert vanuit de zaal dat het CIP samen met OWASP een kader ontwikkelde voor secure software development. “Daarmee kan een opdrachtgever een opdrachtnemer scherp aansturen.”
Rollend materieel
In de presentatie van SYSQA en Wilbert Wijns, programmamanager Sprinter Nieuwe Generatie bij NS, gaat het over een heel andere invalshoek van softwarekwaliteit. De NS gebruikt het om zijn opdrachtgeverschap goed in te vullen, door kwaliteit al vanaf het prille begin van het project mee te nemen. Dat project is de aanschaf van de nieuwe sprinter, “rollend materieel” in NS-termen en goed voor 20.000 nieuwe zitplaatsen. Nieuwe treinen zitten vol met software, vertelt Wijns, en daarom is het goed om de kwaliteit daarvan vanaf het begin te controleren en te borgen. “We liggen onder het vergrootglas, dit project moet in één keer goed gaan. Dat bereik je niet door na het afsluiten van het contract achterover te leunen en te wachten tot de treinen worden opgeleverd.” Hij schetst een aanpak van veel samenwerken, elkaar leren kennen en in elkaar verdiepen. De leverancier is Baskisch en de teams van beide kanten hebben zich zelfs verdiept in elkaars taal en cultuur om de samenwerking makkelijker te maken. Bij SYSQA noemen ze dat “proactief opdrachtgeverschap”, vertelt Sven van Galen, senior manager IT QA bij SYSQA: “We merken in de praktijk dat het best een uitdaging is om alle belanghebbenden ervan te overtuigen om veel energie te steken in de samenwerking met de leverancier. Toch is dat ontzettend belangrijk om een project te laten slagen.”
Lintjes
Inzicht in de kwaliteit van software geeft belangrijke informatie voor de keuze voor renovatie of nieuwbouw van een systeem. Dat is een andere invalshoek van softwarekwaliteit, die wordt belicht in de presentatie van SIG. Coen Donders, projectmanager bij de Kanselarij der Nederlandse Orden, vertelt in een video-interview over de analyse en afwegingen die werden gemaakt over DAISY. Dit Decoratie-, Advies- en Informatiesysteem is cruciaal voor het werk van de Kanselarij en de uitgifte van Koninklijke onderscheidingen. Het was echter al een tijd niet onderhouden en de Kanselarij liet SIG onderzoeken welke kwaliteit het systeem had, om te kunnen bepalen of men er mee verder kon. Op basis van de analyse die SIG deed besloot het bestuur om het systeem te vervangen. Hans Kuijpers, senior consultant bij SIG: “We hebben voor DAISY drie scenario’s naast elkaar gelegd, met de geschatte onderhoudskosten voor de komende tien jaar als uitgangspunt. Daarmee zag het bestuur wanneer de kosten van handhaven van het systeem, renovatie van het systeem of nieuwbouw waren terugverdiend.”
Kuijpers laat ook een afbeelding zien van de kwaliteit van overheidssystemen ten opzichte van die in andere sectoren. Uit de benchmark van SIG blijkt dat de softwarekwaliteit van overheidssystemen dezelfde variatie kent als die in de markt. Als je sectoren vergelijkt dan staat de overheid op de derde plaats qua softwarekwaliteit: na financieel en logistiek, voor sectoren als telecom en industrie.
Het rode pennetje
Tijdens de laatste presentatie wordt duidelijk hoe het controleren van de softwarekwaliteit de opdrachtgever kan helpen op de leverancier scherp te houden. Rik Driessen, projectmanager Tweede Kamer, vertelt samen met Graham Bolton van IfSQ over de moeizame ontwikkeling van een nieuw parlementair informatiesysteem, Parlis. Driessen: “De ontwikkeling van dit systeem duurde vier jaar en toen we het wilden invoeren bleken er grote performanceproblemen. We hebben de code toen laten reviewen door IfSQ.” Men ging met de uitkomsten daarvan naar de leverancier, die moest erkennen dat de kwaliteit abominabel was en vervolgens op eigen kosten alle fouten uit het systeem haalde. “Toen Parlis in 2008 live ging draaide het goed. Het is sinds die tijd een goed en stabiel systeem gebleken, we werken er nog steeds naar tevredenheid mee,” zegt Driessen.
‘Er wordt in ontwikkelprojecten te veel de nadruk gelegd op tijd en functionaliteit’
Bolton heeft een grote stapel papier meegenomen, zoals hij ook deed in de Zembla-uitzending over de ‘spaghetticode’ van de systemen van de SVB. De code reviewers van IfSQ gaan letterlijk met een rood pennetje door stapels code heen en bespreken wat ze hebben gevonden met de programmeurs die de software schreven. Ze zien vaak slordig geschreven code. Dat werpt de vraag op hoe het kan dat programmeurs zoveel fouten maken.
Dagvoorzitter Maarten Hillenaar, Rik Driessen, projectmanager Tweede Kamer, en Graham Bolton bespreken de moeizame ontwikkeling van een nieuw parlementair informatiesysteem, Parlis.
Bolton: “Er wordt in ontwikkelprojecten te veel de nadruk gelegd op tijd en functionaliteit. Kwaliteit is echter de derde hoek in deze driehoek. Als niemand daarop stuurt dan zie je dat programmeurs op tijd en functionaliteit focussen.” Dat is iets dat opdrachtgevers zichzelf aan mogen rekenen, is een conclusie. Hoe borg je dat kwaliteit wel de aandacht krijgt die nodig is? Bolton: “Door beheer al op dag twee van een ontwikkelproject een vast onderdeel van het project te maken.” Driessen zegt dat dit binnen de Tweede Kamer is gebeurd: “Wij hebben code-inspectie als standaard onderdeel opgenomen in onze aanbestedingen. En we hebben kwaliteit in ons werk geïncorporeerd, we overleggen met de programmeurs waar hun werk uiteindelijk op wordt beoordeeld. Dat werkt het best.” Vanuit de zaal wordt opgemerkt dat in de meeste organisaties de ‘quality insurance officer’ is verdwenen en dat een terugkeer van deze functionaris ook kan helpen om kwaliteit weer op de kaart te krijgen.
Softwarekwaliteit in de Arbit
Papenhuijzen riep in zijn keynote inkopers bij de overheid op om meer aandacht voor softwarekwaliteit te hebben en bestaande normen, zoals de ISO-norm, in de Arbit (Algemene Rijksvoorwaarden bij IT-overeenkomsten) op te nemen. Kees Stuurman, hoogleraar Normering van Informatietechnologie aan de Universiteit van Tilburg, reageert tijdens de afsluitende discussie: “Als jurist hoor ik hier in essentie twee problemen. We gebruiken de middelen die er zijn om softwarekwaliteit te controleren niet goed genoeg en we nemen onvoldoende de tijd om de kwaliteit van software goed te specificeren. Dat komt omdat de normen nog onvoldoende praktisch toepasbaar zijn. ISO is te abstract, er wordt gewerkt aan een praktijkrichtlijn om dit te vertalen. Mijn oproep als jurist aan u als opdrachtgever en als softwareleverancier is dan ook: gebruik wat er al is en formuleer normen en instrumenten die wij als juristen kunnen inzetten.” Wat is hier precies de taak van de opdrachtgever? André Regtop, algemeen directeur ICTU: “Een focus op softwarekwaliteit begint bij de opdrachtgever, je moet dit vanaf het begin in elk ontwikkeltraject meenemen door er goede afspraken over te maken.”
Het doel van dit iBestuur symposium was het agenderen van softwarekwaliteit als een essentieel onderdeel van IT-projecten. De grote zaal in Nieuwspoort zit barstensvol, dus er is bij i-bestuurders zeker interesse voor dit onderwerp, concludeert Hillenaar tijdens de afsluiting: “Het woord heeft een lading gekregen.” Wordt softwarekwaliteit een vast onderdeel waarop IT-projecten worden getoetst? Saam de Mooij, ministerie van Binnenlandse Zaken en bureau BIT: “Wij kijken naar de belangrijkste risico’s in projecten. Als softwarekwaliteit een risico is, dan duiken we daar zeker in.”
Interessante meeting! Grip op software kwaliteit heeft een lading gekregen. Echter het waren te veel onderwerpen over hetzelfde: grip op de kwaliteit van software die we zelf (laten) ontwikkelen.
Een volgende keer wat mij betreft gaat het ook over grip krijgen op de kwaliteit van bestaande software pakketten. Immers, we kopen toch nog altijd veel meer bestaande software dan dat we (laten) ontwikkelen, toch?