Orde in een kluwen van software

Grote computersystemen zijn zo ingewikkeld dat ze niet één-twee-drie aan te passen zijn. Daarom is bijvoorbeeld het invoeren van een nieuw zorgstelsel een zware klus voor verzekeringsmaatschappijen. Het onderzoek van RECONSTRUCTOR haalt kluwens van software uit elkaar.

Prof.dr. Arie van Deursen laat een plaatje zien met een heleboel doosjes en een grote wirwar aan pijlen daartussen. ‘Dit is het systeem van een groot financieel bedrijf. Er zijn ongeveer honderd onderdelen die op allerlei manieren van elkaar afhankelijk zijn. Als je op één plek iets wijzigt, heeft dat op allerlei andere plekken gevolgen. In dit plaatje kun je zien op welke plekken. Maar veel bedrijven hebben zo’n plaatje niet eens. Ze hebben geen flauw idee wat er gebeurt als ze een onderdeel van hun software aanpassen.’

De ingewikkeldheid van software wordt door twee dingen veroorzaakt. Ten eerste kan de sofware complex zijn, omdat het op te lossen probleem complex is. Daar valt niet veel aan te doen. Maar veel vaker komt de complexiteit door evolutie van het systeem. Eerst is het gebouwd. Toen aangepast. Toen nog een keer aangepast. Toen nog een keer. Het resultaat is een ware lappendeken van stukjes programmacode waar niemand meer overzicht over heeft.

Dit is de uitdaging die de onderzoekers van RECONSTRUCTOR (Reconstructing Software Architecture for System Evaluation Purposes) hebben opgepikt. Hoe maak je de structuur van die lappendeken inzichtelijk? Als je de structuur weet, kun je namelijk met veel minder moeite de software aanpassen. Dat scheelt geld. Bij een multinational gaat het al gauw om miljoenen euro’s.

‘Ik vergelijk het graag met een mozaiek’, vertel Van Deursen. ‘Als je van dichtbij kijkt, zie je alleen een verzameling gekleurde steentjes. Pas als je van een afstandje kijkt, zie je een plaatje. Een groot computersysteem valt te vergelijken met een mozaiek van enkele voetbalvelden groot. Wat wij doen, is door de oogharen naar zo’n systeem kijken en het totaalplaatje schetsen.’

Handleiding

Bij Van Deursen kun je bij wijze van spreken binnenlopen met een harde schijf vol software en zeggen: ‘De handleiding is zoek, we snappen niet meer hoe het werkt. We wilden iets veranderen, maar toen deed-ie het niet meer.’

‘Wij gaan dan kijken hoe de software is opgebouwd’, vertelt de hoogleraar van de TU Delft. ‘Dat doen we door de broncode te bestuderen, te kijken welke stukjes programma naar elkaar verwijzen, welke databestanden ze gebruiken. Daarvoor hebben we gereedschap ontwikkeld dat heel veel van de analyse automatisch doet.’

Stel bijvoorbeeld dat een bedrijf twee systemen had, met elk een eigen inlogprocedure. Op een gegeven moment werden die systemen samengevoegd. Er ontstond één systeem met twee modules. Toen hadden ze eigenlijk één nieuwe inlogprocedure moeten schrijven, maar dat hebben ze niet gedaan. In plaats daarvan geeft één module steeds het password door aan de andere. Dat werkt prima. Maar dan besluit men voortaan langere passwords te gebruiken. De hoofdmodule wordt aangepast. Maar die geeft nog steeds het password door aan de andere module. Die is niet ingesteld op langere passwords. Gevolg: de helft van het systeem werkt niet, want de login daarvan mislukt.

Het analysegereedschap van RECONSTRUCTOR spoort de tweede inlogmodule, die door iedereen vergeten was, op. Een belangrijke stap daarbij is het letterlijk maken van een plaatje. Daarin worden de dingen die bij elkaar horen, bij elkaar gezet. Zo kun je zien dat de ene module erg afhankelijk is van een andere. De boel aanpassen, zodat het weer wel werkt, blijft mensenwerk.

Van Deursen is ervan overtuigd dat bedrijven er baat bij kunnen hebben hun systemen te analyseren. Een commercieel bedrijf gebruikt de analysesoftware, die ontwikkeld werd aan de TU’s van Delft en Eindhoven, inmiddels om andere bedrijven te helpen met softwareproblemen. Het leidt geen twijfel dat de vraag ernaar in de komende jaren alleen maar zal toenemen.

Laatste vraag: waarom laten bedrijven dat rommeltje in hun software eigenlijk ontstaan? Van Deursen: ‘Het is erg duur om bij iedere wijziging het hele systeem te stroomlijnen. Bovendien vindt men het eng. Als je alles overhoop haalt, loop je op korte termijn toch meer risico’s dan wanneer je ergens iets erbij plakt.’

×