Het moment waarop software wordt vrijgegeven wordt nu nog al te vaak bepaald door degene met de grootste overtuigingskracht en is niet op feitelijke informatie gebaseerd. Hans Sassenburg biedt een methode om programmatuur welbewust de wereld in te sturen.
Ik geloof dat er een behoorlijke maatschappelijke relevantie is voor dit onderzoek.” Sassenburgs hand rust op een stevig boekwerk, pocketuitgave, waarin zijn studie naar de manier waarop software wordt vrijgegeven, en hoe dat idealiter zou moeten gebeuren, staat beschreven. “Het is zo dik, omdat ik op een rijtje heb gezet welke economische en sociaal/psychologische theorieën bij deze besluitvorming een rol spelen”, klinkt het, welhaast verontschuldigend.
Het sociale belang ziet hij bijna dagelijks om zich heen. Bugs in programmatuur zijn een geaccepteerd verschijnsel, terwijl dat wereldwijd toch kostenposten van miljoenen euro’s oplevert. Als het om embedded software gaat, staan er zelfs mensenlevens op het spel: auto’s moeten wel bestuurbaar blijven en medische apparatuur moet naar behoren functioneren. De keren dat voertuigen worden teruggeroepen naar de garage stijgen volgens de statistieken beduidend; in Engeland en Duitsland elk 150 keer in 2003. En in toenemende mate vanwege softwareproblemen.
Krachtenspel
Het moment waarop software wordt vrijgegeven, zo is Sassenburg tijdens zijn studie bij zeven organisaties in Nederland en Zwitserland (waar hij woont) gebleken, vindt veelal niet plaats op grond van informatie. Dat gaat op voor softwarefabrikanten, maar ook voor ontwikkelstraten binnen eigen organisaties. “Er is altijd een krachtenspel dat dat moment probeert te beïnvloeden. Marketing zal proberen zo snel mogelijk een product op de markt te zetten om maar geen potentiële klant te missen, terwijl de ontwikkelgroep altijd het gevoel zal blijven houden dat er misschien nog wel een paar testgevallen hadden moeten worden uitgeprobeerd. De mensen die verantwoordelijk zijn voor het onderhoud zien de bui al hangen en willen nog meer zekerheden. Een besluit tot vrijgeven van de programmatuur gebeurt dan vaak intuïtief. Het is niet gebaseerd op feitelijke informatie.”
Exacte wetenschap
Hij geeft toe dat het een lastig parket is. “Het is geen exacte wetenschap. Je weet niet van tevoren dat als je nog eens 76 testen uitvoert, nog een maandje doorontwikkelt, dat je dan 31 fouten eruit haalt en perfecte software oplevert. Dat weet je niet, maar je kunt wel met dergelijke onzekerheden omgaan.”
Hoe dat gebeurt, heeft hij geleend uit de economische en sociaal/psychologische theorieën. Daarmee is het krachtenspel beheersbaar. “En zorg je ervoor dat het vrijgavebesluit op grond van toetsbare informatie wordt genomen, en niet meer op basis van intuïtie”, stelt Sassenburg. “Zo simpel is het eigenlijk.”
Nadat hij zijn methodologie had ontwikkeld, heeft hij deze getest bij drie organisaties in Nederland. Eén daarvan mag hij noemen, en dat is op zich niet zo gek, omdat het Centrum voor ICT van de Belastingdienst goed uit de bus komt. Deze ploeg heeft een nieuw salarissysteem ontwikkeld voor het ministerie van Economische Zaken. “Ook hier was de druk om het goed te doen erg groot. De imagoschade zou immers niet te overzien zijn geweest als de Belastingdienst daar steken laat vallen, nota bene bij een salarissysteem. Het is echter een succes geworden en achteraf heb ik kunnen bepalen waarom dat het geval was: alle belanghebbende partijen zijn vanaf het begin bij dit strategische project betrokken geweest, tot en met de ingebruikneming. Ze hebben gezamenlijk de specificaties opgesteld en ervoor gezorgd dat de vinger aan de pols werd gehouden; precies zoals ik met mijn methodologie aanbeveel.”
Formele methoden
In de loop der jaren zijn testmethoden (ook van embedded software) en de kwaliteit van het ontwikkelproces (denk aan CMMI) al aanzienlijk verbeterd. Maar dat is nog niet genoeg, zelfs al zouden die methoden worden toegepast, vindt Sassenburg. Zijn methode geeft aan hoe te komen is tot een weloverwogen keus van het moment waarop een applicatie de deur uit mag.
Dat zegt echter nog niks over de manier waarop software tegenwoordig wordt geproduceerd. Dat zou naar Sassenbergs overtuiging veel beter kunnen. “We zijn de laatste jaren eigenlijk alleen maar met suboptimalisatie bezig. Er zou een doorbraaktechnologie moeten komen om tot goede software te komen. Een heel andere manier van ontwikkelen.”
Daarbij kijkt hij met een schuin oog naar Formele Methoden, een soort wiskundige beschrijvingen om software te testen en valideren om te bereiken dat er zo min mogelijk fouten in zitten. Dit is bijvoorbeeld gebruikt bij het schrijven van de software voor de Maeslantkering bij Hoek van Holland. De programmatuur moet besluiten wanneer de stormvloedkering gesloten moet worden. Te vroeg heeft nadelige gevolgen voor de Rotterdamse haven, te laat betekent op zijn minst natte voeten in het Westland.“
Er wordt altijd naar Formele Methoden gekeken als een manier om met wiskundige precisie een algoritme van drie regels te bewijzen. Maar dat is een beeld van vroeger. Het kan nu veel makkelijker, maar niet minder nauwkeurig. Hier ligt een oplossing om tot betere software te komen”, vindt Sassenburg.
Zelfstandig adviseur
Dr. ir. Hans Sassenburg (Rotterdam, 1960) is zelfstandig adviseur en werkt drie dagen in de week bij het Software Engineering Institute. Hij is afgestudeerd elektrotechnicus en heeft altijd een eigen consultancybedrijf gehad. Dit is in 2000 verkocht aan de TAS-Groep, die is overgenomen door PinkRoccade, dat is samengegaan met Getronics.
Hij is ook universitair docent geweest aan de Technische Universiteit Eindhoven.
Zijn promotieonderzoek aan de Rijksuniversiteit Groningen, faculteit Economie, vakgroep Business & ICT is hij gestart in najaar 2002. Op 5 januari heeft hij zijn proefschrift succesvol verdedigd.
Methodologie
De methodologie onderscheidt vier procesgebieden:
* Vrijgave Definitie. De methode voorziet in een economische evaluatie om alternatieven te vergelijken. Er is specifieke aandacht voor karakteristieken van softwareproducten, zoals betrouwbaarheid en onderhoudsmogelijkgeheden. Alle betrokkenen dienen gezamenlijk de (dynamische) criteria op te stellen en te bewaken.
* Vrijgave Informatie. Deze geeft een handreiking om tijdig en actief informatie te verzamelen over het product en ondersteunende producten (zoals handleidingen).
* Vrijgave Besluit. Aan het besluitvormingsproces dienen alle betrokken partijen deel te nemen. Een besluit wordt liefst in consensus genomen. Allen dienen over kwalitatief voldoende informatie te beschikken om ongewenste politieke krachten in het proces te elimineren.
* Vrijgave Implementatie. Een ‘gooi-maar-over-de-muur-cultuur’ is te vermijden door de uitvoerder van een besluit te laten deelnemen aan het besluitvormingsproces, vooraf voldoende budget (geld, mensen) te reserveren voor de besluitimplementatie, en de implementatieploeg pas te ontslaan van zijn verplichting als het product goed functioneert in de operationele omgeving.
