Software Engineering van de koude grond

Velen denken dat als je maar genoeg hardware koopt, en er dan
nog even de juiste software opgooit, dat je dan je bedrijfsprocessen
volledig onder controle hebt.  Immers: alles zit op de computer.
Een heel exact ding, met alleen maar enen en nullen.  Dus dat
kan niet anders dan begrijpelijk wezen.

Nu is software, soft.  En dat soft wil zeggen dat het plooibaar,
kneedbaar, vormbaar, veranderbaar is.  Als een idee geboren
wordt, bijvoorbeeld een taal om koffiezetapparaten te
programmeren, kan dat zomaar vervormen in een Internet taal.
Software is kennelijk zo soft, dat alleen de naam Java nog
aan koffie doet denken.  Daarmee is een artefact als software
ook heel bijzonder, en heeft het heel bijzondere eigenschappen,
in zichzelf, maar ook het productieproces, dat software
engineering heet.

Het fenomeen dat onderweg de specs veranderen heet in software
engineering terminologie: requirements creep.  Namelijk nadat
de requirements zijn vastgelegd, blijven er allerlei nieuwe
en andere dingen inkruipen.  Dit is zo endemisch dat het
meetbaar is.  Ruw weg is er sprake van een groei van 2% per
maand, tijdens een project nadat de requirements al vastgelegd
zijn.

Wat betekent dat eigenlijk?  Stel je eens voor dat er een
systeem van 10000 functiepunten gemaakt wordt.  Denk aan zo'n
miljoen regels C of Cobol bij zoveel functiepunten.  De
doorlooptijd van een dergelijk project is al gauw een maandje
of 40.  Als de groei 2% per maand is, dan levert dat 12000
functiepunten extra op.  Dat is dus ruim 2 keer zoveel
functionaliteit als in den beginne bedacht was.

Dat heeft een paar gevolgen: de doorlooptijden worden vele
langer, de kosten worden veel hoger, er is andere functionaliteit
opgeleverd.  Van die functionaliteit weten we eigenlijk niet
of alle stakeholders het wel wilden hebben.  Bovendien is er
geen afweging gemaakt tijdens het engineeren van de requirements,
en heeft de functionaliteit dus een onvoorspelbare interactie
met de niet functionele zaken zoals:  onderhoudbaarheid,
beveiliging, performance, betrouwbaarheid, en was dies meer
zij.  Software engineering van de koude grond.

Maar er is nog iets belangrijks aan de hand: meer dan 50% van
de requirements is uiteindelijk nergens gedocumenteerd.  Want
die fase hadden we al gehad, en door autonome ongecoordineerde
groei is er van alles bij gekomen.  En wegens haast en druk,
krijg je een systeem opgeleverd (als dat al lukt natuurlijk),
waarin al een hoop kennis en kunde is versleuteld in de
software.

Als een dergelijk systeem dan in productie gaat, en men gaat
onderhoud plegen, dan neemt de hoeveelheid versleutelde
bedrijfskennis alleen nog maar toe, en de kwaliteit van de
documentatie, en het begrip van wat de software nu eigenlijk
doet neemt al maar af.  Zodra er werkelijk grote wijzigingen
nodig zijn, breekt de hel los: dan is begrip noodzakelijk, al
is het maar om bijvoorbeeld precies te weten wat allemaal
aanwezig is, waar dankbaar gebruik van gemaakt kan worden.

En de systemen waarvan we door hun leeftijd het minste meer
afweten blijken in onze samenleving de meest waardevolle
systemen te zijn: daar draait de economie op.  Die systemen
zijn van onschatbare waarde, en om er nog lang en gelukkig
van te kunnen profiteren, is het nuttig en nodig om als een
soortement van archeoloog door lagen van software heen te
bikken, om de werkelijke betekenis van al die versleutelde
kennis bloot te leggen.  Bovendien moeten de uiteengevallen
geraamtes dan weer met nette draadjes aaneengeregen worden,
zodat er weer goede structuur in het geheel komt.  Uiteindelijk
vatten we dan stukje bij beetje wat die software doet, en
kunnen we dat vergelijken met watie nu behoort te doen.  Dit
defossilizeren is een grote onderzoeksuitdaging.

Uiteraard heeft de overheid zich over dit soort problematiek
goed laten adviseren in dure rapporten.  Daarin staat dat
Nederland uiteraard een kennisland is, maar:  de software die
men produceert komt niet efficient tot stand en in de
eindresultaten zitten te veel fouten.  Software engineering
is absoluut noodzakelijk voor het ontwikkelen van ICT applicaties
en het vergroten van de efficiency, aldus het rapport.  Hierdoor
wordt de positie van Nederland als kennisintensieve economie
gewaarborgd.  En daarvoor is een injectie nodig.  Het rapport
noemt de meer dan noodzakelijke ontwikkeling van legacycompetences
op academisch niveau en om dat aan te pakken ziet men een
investering van 40 miljoen die besteed moet worden aan een
kenniscentrum voor software engineering en legacy systemen.
Dat was November 2000 over de belangrijke thema's voor een
impuls in de kenniseconomie uit de aardgasbaten.

Nu horen we ineens van de Minister van OC&W dat Nederland te
klein zou zijn voor software engineering onderzoek.  Bij het
Ministerie van LNV is er een andere aanpak: hun Directie
Wetenschap en Kennisoverdracht coordineert en regiseert het
programmeringsprocess binnen LNV, en zet daarvoor een budget
van jaarlijks 100 miljoen Euro uit bij de Nationale
kennisinfrastructuur; dat is 2666 promovendi.  Niks, Nederland
te klein.  Bij een onderkend strategisch onderwerp blijkt het
zonder meer mogelijk om fondsen vrij te maken voor onderzoek.
Als dat ook begrepen was voor software engineering, zou er
bijvoorbeeld substantieel onderzoek uitgevoerd kunnen worden
om de 26 politieregios met dito software te standaardiseren,
te integreren, en te migreren.  Zonder dat er een grote kans
bestaat dat de 450 miljoen Euro die ervoor uitgetrokken is,
achteraf toch weer doorgetrokken blijkt te zijn.

X

Meer weten over de wondere wereld van ICT 
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica 
aan de Vrije Universiteit in Amsterdam.  Hij schrijft      
maandelijks een column in AG II.  Deze tekst is 
copyright SDU.  Niets van deze uitgave mag zonder
schriftelijke toestemming van de uitgever worden
overgenomen of worden gepubliceerd.