De spaghetticode voorbij?

Vorig jaar trok de Sociale Verzekeringsbank de stekker uit de ontwikkeling van het Multi Regelingen Systeem (MRS) na een investering van minimaal 43 miljoen euro. In Zembla sprak professor Jan Friso Groote – hoogleraar embedded systemen aan de TU Eindhoven – een vernietigend oordeel uit over andere software van dezelfde leverancier: “Beginnerscode.” “De codeerstijl was rampzalig”, vult hij aan als iBestuur hem belt. “De makers lijken niet eens de intentie gehad te hebben om kwaliteit te leveren. Dan houdt het natuurlijk op.”

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!

“Tja, als ik zoiets hoor, moet ik altijd aan een uitspraak van professor Bemelmans denken”, zegt Dr. Hans Mulder, professor bij de Universiteit Antwerpen, directeur van de Viagroep en mediator in IT-geschillen: “Met goede mensen maakt de methode niet zoveel uit, met slechte mensen helpt geen methode.”
Maar in welke mate dragen methodieken, geautomatiseerd testgereedschap en ISO-normen nu wél bij aan betere producten en minder faalkosten? We spreken daarvoor met de wetenschappers Mulder en Groote en met oud-lector softwarekwaliteit Jacob Brunekreef, inmiddels consultant bij IT-adviesbedrijf Inspearit.
Dit is geen gebied van simpele antwoorden, maken ze alle drie gelijk duidelijk. “Zoals ik ook aan de commissie-Elias vertelde”, zegt Mulder. “Er is helaas geen silver bullet. Maar uit onderzoek naar IT-projecten kun je wel belangrijke lessen trekken. Knip bijvoorbeeld grote projecten op in kleinere delen, maar dan wel op zo’n wijze dat je stapsgewijs bruikbare onderdelen kunt opleveren.” En dan zijn er nog al die andere faalfactoren zoals de commissie-Elias die keurig opsomt.

ISO-normen

Wat leerde Jacob Brunekreef, jarenlang lector softwarekwaliteit bij de HvA en Fontys, zijn studenten? “Traditioneel was de enige eis die aan software werd gesteld dat die werkte. Ik wees er altijd in het eerste college op dat goed programmeren meer inhield. Tot vijf jaar terug ging de aandacht daarbij vooral uit naar onderhoudbaarheid: was de code begrijpelijk, zat die netjes in elkaar, was die goed gedocumenteerd? Sinds enkele jaren is security een belangrijk thema geworden.”
Volgens Brunekreef is de ISO 25010 norm nu in ‘softwarekwaliteitsland’ hét instrument waar iedereen naar grijpt. “Het is natuurlijk niet echt een norm in de zin dat er meeteenheden of grenswaarden worden benoemd. Maar mijn ervaring is wel dat die ISO-norm een prima instrument is om in gesprek te gaan met opdrachtgevers: welke kwaliteitsaspecten vind je echt belangrijk? Wat moeten we daarover vastleggen?”
Ook Mulder ziet het nut van de ISO-norm. “Die draagt eraan bij dat in een ontwikkelteam meer nadruk wordt gelegd op kwaliteitsborging. Maar zo’n leidraad op zich is niet zaligmakend.”
Groote is cynischer. “Normen gaan vaak vooral over gedrag: poets je je schoenen als je naar je werk gaat en je tanden voor je naar bed gaat.” Hij wijst op de totale mislukking van de CMM-niveaus (Capability Maturity Model – het niveau van het softwareontwikkelprocés bij een organisatie): “Je kon het toplevel 5 halen als je aan een hele waslijst van eisen voldeed; maar dat bleek geen enkele garantie op succes.”

Naar de bron

Mulder: “Het lezen van broncode is uitermate complex. De opdrachtgever kijkt vooral naar de buitenkant. Als je een auto koopt is dat geen probleem, omdat je weet dat een leverancier ongenadig wordt afgestraft als zich een fout voordoet. Maar bij softwareontwikkeling is dat niet zo; bovendien raakt de opdrachtgever gaandeweg medeverantwoordelijk voor het resultaat. Dan kun je maar beter een onafhankelijke partij laten toezien op het hele bouwproces.”
Deze derde partijen werken met geautomatiseerde testgereedschappen. Volgens Groote controleren die vooral de makkelijke dingen. “Als je meer diepgang wilt, moet je toch echt visueel naar de code kijken.”
Mulder is positiever: “Wat zulke geautomatiseerde tools goed doen is controleren of de code goed is gestructureerd. Dat is een belangrijk aspect van de kwaliteit.”

Die ISO-norm is een prima instrument om in gesprek te gaan met opdrachtgevers

“Vroeger werden zulke tools vooral ingezet om een kwaliteitsoordeel over legacysoftware te geven”, vult Brunekreef aan. “Gaandeweg is dat verschoven naar controle op opgeleverde software. En nu worden dergelijke gereedschappen ingezet om tijdens het ontwikkelproces op dagelijkse basis naar de kwaliteit te kijken. Vooral wat betreft het aspect onderhoudbaarheid zijn die tools flink doorontwikkeld; wat betreft security nog minder.”
Maar ook Brunekreef wijst op de beperkingen: “Het is een valkuil om je alleen op die tools te beroepen. Wat wij bij Inspearit altijd doen is een combinatie: een geautomatiseerde én visuele inspectie. In de broncode kijken dus. Maar ook dan haal je natuurlijk niet alles eruit.” Een opdrachtgever heeft volgens Brunekreef altijd recht om de kwaliteit van de code op die manier te (laten) beoordelen.

Agile

Tijdens de ontwikkeling van het MRS-systeem betaalde de SVB tientallen miljoenen euro zonder dat er een werkende applicatie was opgeleverd. Brunekreef: “Traditioneel leunen overheden na de opdrachtverlening te veel achterover. Dat maakt het voor leveranciers makkelijk om tijdens de bouwperiode lange tijd geruststellende tussenrapportages te laten landen.” Groote: “Ik heb het vermoeden dat sommige grotere dienstverleners heel blij zijn met dit model. Die kunnen uren blijven schrijven terwijl de opdrachtgever medeverantwoordelijk wordt.”
Brunekreef wijst erop dat de opdrachtgever bij de agile methodiek wel min of meer verplicht wordt voortdurend mee te kijken. “Idealiter spreekt deze bij elke iteratie een oordeel uit. En dan hebben we het alleen nog over de functionaliteit. Als hij het echt goed doet, heeft hij bij elke stap ook aandacht voor de kwaliteit.”
Bij de termen agile en scrum loopt bij Groote de ergernis op: “Van dat hele scrummen gaat men nog heel hard terugkomen. Vergelijk het met het bouwen van een huis. Je kunt best met alle betrokkenen de inrichting van een huis scrummen. Maar als je zo per verdieping een heel flatgebouw bij elkaar scrumt, kom je er bij de bouw achter dat de fundering te licht is, je bredere riool- en waterleiding had moeten gebruiken enzovoort.” Alles staat of valt volgens Groote met een goede voorbereiding: het werk van de architect.

“Wat het management niet regelt kan de Auditdienst niet oplossen”

Anneke van Zanen-Nieberg is algemeen directeur van de Auditdienst Rijk. Haar dienst onderzoekt onder meer het beheer van de departementen. Het is volgens haar inherent aan de rol van haar dienst om ook informatiesystemen te betrekken bij de audits, omdat deze ondersteunend zijn bij de activiteiten bij elk departement. Zij is blij met aandacht voor het onderwerp softwarekwaliteit. “Het is niet vanzelfsprekend dat die kwaliteit altijd goed is. Het is natuurlijk primair de verantwoordelijkheid van het management dat systemen laat ontwikkelen dat ook de broncodes goed zijn. Wij zouden vanuit onze rol kunnen onderzoeken of de kwaliteit voldoende is getoetst. Als auditors zouden we daar nadrukkelijk(er) naar moeten vragen en wellicht zelfs in gevallen naar moeten kijken. Maar wat blijft is dat de auditor achteraf niet kan oplossen wat het management niet regelt.”
Van Zanen vraagt daarbij ook nadrukkelijk aandacht voor de niet-functionele kwaliteitsaspecten, in het bijzonder voor onderhoudbaarheid en veiligheid.
“Voor het uiteindelijk betrouwbaar en veilig functioneren van informatiesystemen is aandacht voor het gehele palet aan kwaliteitseisen van belang. Inbedding vooraf en toetsing door het management op naleving van bijvoorbeeld het principe ‘security by design’ vragen nadrukkelijk aandacht.”

Mulder: “Groote heeft gelijk. Bovendien; die agile methodiek wordt nu heel erg geprezen. Maar ook daar geldt dat de kwaliteit van de ontwikkelaars doorslaggevend is. Bovendien moet je met kleine teams werken. Neem nu die problemen met het PGB. Wat mij bij de softwareontwikkeling daarvan opviel is dat men erg trots was op de agile aanpak, maar dat er heel veel mensen tegelijk aan werkten. Ik denk zelf dat er aan een agile team een maximum van ongeveer acht zit. Vaak leiden agile ontwikkeltrajecten toch tot een Big Bang-oplevering.”
Software bouwen is ontzettend ingewikkeld, benadrukt Groote nog maar eens. En met elke wijziging die je aanbrengt wordt het complexer. “Voor je het weet, waad je als programmeur door dikke stroop. Vanaf dag één moet je structuur helder zijn, anders kosten die laatste meters onevenredig veel inspanning. Dat hebben we bij gebouwen wel onder controle, maar bij software niet. Maar het kan niet zo zijn dat we software blijven maken op de huidige manier.”

Software-architectuur

Bij deze hartenkreet sluit Mulder zich graag aan. “We moeten naar duurzame informatiesystemen toe. Veel relatief nieuwe systemen moeten nu na een aantal jaren al weer worden vervangen, omdat ze niet kunnen worden aangepast aan nieuwe technologie en gebruikerseisen.
Hij pleit daarom voor een geheel andere manier van softwareontwikkeling, gebaseerd op een genormaliseerd componentmodel. Met deze terminologie verwijst hij naar het onderzoeksveld van de ‘normalised systems’, zoals die bij de Universiteit Antwerpen – onder leiding van de professoren Jan Verelst en Herwig Mannaert – in gang is gezet.

Het kán niet zo zijn dat we software blijven maken op de huidige manier

Het gaat daarbij om een zeer fijnmazig modulaire architectuur. Applicaties bouwen start dan met het ontwerpen van een architectuur, een bouwplaat, waarop vervolgens de juiste ‘genormaliseerde’ bouwstenen worden geplaatst. Mulder schetst het visioen: “Geen unieke grote projecten meer, maar kleine teams van materiedeskundigen en ontwikkelaars, die als het ware continu onderhoud plegen om de organisatie en systemen te laten aansluiten op de veranderende omgeving.”
Dit is de theorie voorbij. De groep uit Antwerpen doet momenteel een pilot bij een Nederlandse overheidsorganisatie. Mulder is daarbij betrokken: “Uit eerdere cases kwam naar voren dat verouderde systemen van honderden tot enkele duizenden functiepunten in slechts enkele weken tot maanden konden worden opgeknipt en genormaliseerd. De eerste resultaten bij deze pilot zijn veelbelovend. Ten eerste bleek het gerealiseerde systeem schaalbaar. En ten tweede ook duurzaam. We hebben een oude applicatie omgezet, daar vervolgens vijftien jaar aan wijzigingen doorgevoerd zonder dat dat bij elke nieuwe wijziging steeds meer moeite kostte.”
Maar het scheelt natuurlijk, voegt hij ter relativering toe, dat er heel goede en zeer gemotiveerde mensen aan werken. “Met zulke IT’ers zouden er bij elk project minder problemen zijn.” Softwareontwikkeling: het blijft mensenwerk.