Een brug tussen twee werelden

Bij het bouwen en onderhouden van software gaapt vaak een kloof tussen de wereld van de analisten die de eisen opstellen, en de technici die de software bouwen. Zo kan bijvoorbeeld een kleine verandering in wetgeving ervoor zorgen dat studenten te laat hun studiefinanciering krijgen, omdat de aanpassing van het systeem meer tijd kostte dan verwacht. De missie van QuadREAD is het dichten van de kloof tussen deze twee werelden.

Ongeveer een derde van de ict-projecten mislukt op de een of andere manier. Dat kost overheden en bedrijfsleven jaarlijks miljarden euro’s. Heel vaak mislukken projecten, omdat het systeem niet doet wat van tevoren bedacht was.

De IB-groep, die studiefinanciering uitkeert aan studenten, kreeg enkele jaren geleden van de Rekenkamer een gele kaart, omdat haar systeem niet deed wat de bedoeling was en bovendien niet op tijd in bedrijf. Dat kwam onder meer doordat de eisen eraan steeds veranderden als gevolg van veranderende wetgeving. De lijst is lang. Dezer dagen bestaan bijvoorbeeld vragen over de fraudegevoeligheid van software in stemmachines. Een geval uit het verleden zijn röntgenmachines die veel hogere doses straling afgaven dan bedoeld. Daardoor zijn in de Verenigde Staten verschillende doden gevallen. Er is dus reden genoeg om dit verschijnsel uiterst serieus te nemen.

‘Een van de problemen is dat het bij het opstellen van de eisen en de technische uitvoering vaak om totaal verschillende mensen gaat’, vertelt dr.ir. Klaas van den Berg van de Universiteit Twente, projectleider van QuadREAD (Quality-Driven Requirements Engineering and Architectural Design). ‘De ontwikkelaars zijn vaak informatici met een neiging vooral naar de computerkant te kijken. Maar de informatie-analisten die in de specificaties vastleggen wat de software moet doen, zijn bijvoorbeeld jurist of arts. De vraag is hoe je die twee groepen, ieder met hun eigen manier van communiceren, beter op elkaar kunt laten aansluiten.’

Deze aansluiting zit niet alleen in de mensen, maar ook in de methoden die zij gebruiken. Van den Berg: ‘Dus wij willen niet alleen de communicatie tussen de analisten en ontwikkelaars verbeteren, maar ook middelen die de communicatie ondersteunen. Dat moet de kwaliteit van het ontwikkelproces verhogen en daarmee de kwaliteit van de software.’

iPod

Een voorbeeld van geavanceerde hulpmiddellen zijn traceability-tools. Die leggen precies vast welk deel van de specificaties geïmplementeerd is in welk deel van de programmacode. Deze informatie zit nu vaak alleen in de hoofden van de programmeurs, en is dan niet makkelijk beschikbaar als de software aangepast moet worden.

‘Neem bijvoorbeeld een iPod’, zegt Van den Berg. ‘De marketeers bedenken daarvoor allerlei functionaliteiten, zoals muziek selecteren, luisteren en downloaden. De technici vertalen al die eisen naar software. Na een poosje bedenken de marketeers een nieuwe functionaliteit. Ze willen bijvoorbeeld dat je voortaan ook muziek kunt downloaden via Bluetooth.’

‘Dan is het handig wanneer je precies weet waar je deze mogelijkheid in de bestaande software moet inhaken. Er moet een menukeuze komen, er is verband met de downloadoptie en er moeten dingen op het schermpje getoond worden. Eigenlijk zou het zo moeten zijn dat je de specificaties direct kunt herleiden naar te wijzigen onderdelen van de software. Dat wordt wel forward traceability genoemd.’

Regelmatig komt het voor dat de specificaties niet helemaal compleet zijn. Daardoor moeten de programmeurs tijdens het schrijven van de software keuzes maken, die niet direct zijn te herleiden naar de specificaties. Het zou bijvoorbeeld zo kunnen zijn dat de programmeurs zich genoodzaakt zagen het aantal downloadmethoden te beperken tot één. Bluetooth toevoegen is dan helemaal niet mogelijk, terwijl de marketeers denken van wel: zij hebben er in hun specificaties immers helemaal niets over gezegd.

Ook voor het constateren van dit soort conflicten tussen specificaties en technische uitvoering bestaan methoden, die bekend staan als backward traceability. Dergelijke methoden trekken aan de bel bij situaties waarin onmogelijke wijzigingen worden voorgesteld.

Van den Berg waarschuwt wel dat, hoeveel hulpmiddelen je ook ontwerpt, er altijd een belangrijk menselijk aspect blijft bestaan: ‘Hulpmiddelen ontwikkelen kunnen we hier aan de universiteit wel. Inbedden van nieuwe ontwikkelmethoden in de organisatie is iets anders. Daaraan zal de organisatie toch vooral zelf moeten werken, door mensen te trainen en heldere procedures af te spreken.’

×