De onvoorspelbaarheid van het ontwikkelen van geautomatiseerde systemen
Redactie | Verschijningsdatum 01-03-2012 | 99x bekeken
De onvoorspelbaarheid van het ontwikkelen van geautomatiseerde systemen
• Een behoorlijk aantal grote projecten mislukt voor aanzienlijke bedragen. De Tweede Kamer discussieerde daar in 2007 en 2008 over (Oosterhout, 2007) en zal in de loop van 2012 een parlementair onderzoek starten.
• Ook bij systemen die wel worden opgeleverd en ingevoerd zijn regelmatig te hoge kosten gemaakt. Dit artikel geeft enig inzicht in de omvang daarvan.
• Het is waarschijnlijk dat de suboptimale productiviteit bij de ontwikkeling van systemen zich doorzet naar het onderhoud en het beheer van die systemen in de verdere levenscyclus.
Er wordt op veel plaatsen gesproken over de productiviteit bij het ontwikkelen van geautomatiseerde systemen. Dat gebeurt zeker bij het management van ICT-afdelingen en van ICT
Niet in de hier gehanteerde definitie van inspanning zijn opgenomen de inspanningen in het voortraject, de inspanning van de acceptatietest en de verdere inspanningen van de lijnorganisatie.Gegevens van de auteur leren dat de inspanning ongeveer het dubbele bedraagt als deze onderdelen ook worden meegenomen. De inspanning is dus: uren feitelijke systeemontwikkeling per functiepunt. Waar gesproken wordt over doorlooptijden zijn deze ook tot de aangegeven fasen beperkt.
Gegevens over systeemomvang, kosten en doorlooptijden, nodig voor de planning van de ontwikkeling van een systeem, zijn zowel overvloedig beschikbaar als niet beschikbaar:
• Overvloedig beschikbaar . Er is een zeer grote hoeveelheid boeken, artikelen en data over systeemomvang, kosten en doorlooptijden gepubliceerd. In 2007 waren wereldwijd van meer dan 25.000 voltooide projecten de gegevens in combinatie met een functiepunttelling publiek bekend. De resultaten zijn ‘verpakt’ in de adviesproducten van bijvoorbeeld Gartner en QSM. Of in de vorm van analyses beschikbaar in de boeken van bijvoorbeeld Capers Jones en Larry Putnam. Of in de vorm van beschikbare databanken zoals de repository van de International Software Benchmarking Standards Group (ISBSG). Deze bronnen leveren een algemeen beeld op van de kosten voor het ontwikkelen van een softwareproduct. Dit algemene beeld heeft een aanzienlijke bandbreedte.
• Niet beschikbaar . Voor een nadere precisering zijn gegevens nodig van de organisatie waarin het project zal worden uitgevoerd. In veruit de meeste gevallen ontbreken deze gegevens. Amerikaans onderzoek wees uit dat maar van 10 procent van de uitgevoerde projecten accuraat de gegevens werden bijgehouden, en dat gebeurde in maar 5 procent van de opdrachtgevende organisaties. De Nederlandse overheid lijkt het niet veel beter te doen. Dat moest ook de Rekenkamer constateren toen zij in 2007 een kwantitatief beeld probeerde op te bouwen van het slagen en falen van ICT-projecten.
• De ISBSG-repository levert de verzameling van referentieprojecten. De ISBSG-repository is een wereldwijde dataverzameling van voltooide softwareprojecten, die met name gevuld wordt door nationale organisaties op het gebied van functiepunttellingen. Hieruit zijn de voltooide nieuwbouwprojecten genomen, dit betreft een aantal van 460 systemen, met een gezamenlijke omvang van circa 340.000 functiepunten, waarvan de realisatie ruim 3,5 miljoen mensuren heeft gekost.
• De gegevens van de Nederlandse overheid betreffen circa 120 voltooide systemen. Het materiaal is afkomstig uit de praktijk van de auteur, vanuit een projectverantwoordelijkheid of vanuit beoordelingen en evaluaties op project-of organisatieniveau. Deze groep van circa 120 systemen heeft een gezamenlijke omvang van ruim 100.000 functiepunten en werd gerealiseerd met een gesommeerde inspanning van ruim 2,1 miljoen mensuren. De systemen werden ontwikkeld binnen 17 overheidsorganisaties, van een aantal organisaties komen meer dan 5 voltooide systemen voor.

Dat betekent dat er nog een grote bandbreedte overblijft, ook na correctie voor technische en methodische kenmerken. De ISBSG-repository kent een tool waarmee de realiteitswaarde van een planning kan worden gecheckt tegen de aanwezige data. Als voorbeeld een systeem van 1000 functiepunten, lineair te ontwikkelen in 4 GL op een midrange computer:
• optimistisch: 2080 uur inspanning in een doorlooptijd van 5 maanden;
• pessimistisch: 20.500 uur inspanning en een doorlooptijd van ruim 22 maanden. Deze variatie is nog beperkt gebleven door de betrouwbaarheid van de raming op 80 procent te houden.
Zonder nadere informatie vanuit de organisatie waar wordt ontwikkeld, zou in een af te geven planning met deze bandbreedte moeten worden volstaan. In meer dan 90 procent van de Nederlandse overheidsorganisaties zou dus bij ‘kosten en doorlooptijden’ in het projectplan van een vergelijkbaar systeem moeten staan: ‘de kosten zullen liggen tussen de 2 en de 20 miljoen, de opleverdatum is tussen de 4 en de 22 maanden na de start’. Een dergelijke eerlijkheid over de onzekerheid van de planning komt men echter bij niet-registrerende organisaties zelden in de startdocumenten van projecten tegen.
• Het kent een hoog percentage mislukkende projecten. Dat percentage is de afgelopen twee decennia nauwelijks verbeterd (Oosterhout, 2007),
• Ondanks het feit dat het een onmisbare productiefactor is en er veel druk staat op snelle en goedkope levering, is de productiviteit in de afgelopen decennia nauwelijks gestegen,
• Over organisaties heen is een enorme spreiding in kosten per eenheid waar te nemen van een factor 10 (1000 procent!) of meer.
Blijkbaar zijn er sterke en divergerende krachten van invloed op het proces van het ontwikkelen van systemen. De belangrijkste van deze krachten worden hierna beschreven.
• Het specificeren . Dat is het optimaliseren van de bedrijfsprocessen, zoals ze met geautomatiseerde ondersteuning moeten gaan verlopen. Specificeren levert de beschrijving op van die geoptimaliseerde processen en een beschrijving van de daarbij benodigde geautomatiseerde ondersteuning. Een belangrijke noot hierbij is dat deze beschrijvingen niet een absolute waarheid zijn, maar de keuze van de organisatie om ‘het zo te gaan doen’.

• Niet een van beide ambachten heeft automatisch de leiding. In de praktijk komt zowel aansturing vanuit de opdrachtgevende organisatie als aansturing vanuit de ICT voor.
• Vanuit de specificatie is niet altijd voldoende vastgelegd welke functionaliteit er moet komen (en waartoe men zich moet beperken).
• Binnen de opdrachtgevende organisatie verschuift de betrokkenheid: van management (inrichting van processen) naar eindgebruikers (ontwerp schermen). En de doelen van het management (efficiëntie, korte doorlooptijd) zijn niet altijd dezelfde als die van eindgebruikers (gebruikersgemak en behoud baan).
De ‘marktwerking’ in beide ambachten draagt niet bij tot efficiëntie in de prestatie en tot kwaliteit van het resultaat. Allereerst het specificeren, het ontwerpen en beschrijven van nieuwe bedrijfsprocessen. Door de aard van het ambacht (modelleren van bedrijfsprocessen om bedrijfsmatige voordelen te genereren met eigenaarschap bij de organisatie) is het eigenlijk alleen geschikt voor goede en ervaren informatieanalisten. Maar wie heeft er last van als een minder gekwalificeerd persoon een kwalitatief minder resultaat oplevert? Die last valt, nauwelijks te onderscheiden van onvermijdelijk veranderende specificaties, bij het volgende ambacht, de realisatie.
En het ambacht van de realisatie wordt veelal beoefend door commerciële ICT-bedrijven, rechtstreeks of via inhuur. En voor het commerciële bedrijf betekent efficiëntie minder uren werk en dus minder omzet. Als er verder geen prikkels zijn, zullen ze dat niet nastreven. En zal de commerciële drive naar meer omzet overheersen. Voor interne ontwikkelafdelingen geldt een vergelijkbare productiviteitsparadox.
De grondlegger van het kwantificeren van het verband tussen tijdsdruk en de productiviteit van bij de ontwikkeling van software is Larry Putnam. Vanuit de QSM-repository met voltooide projecten ontwikkelde hij al in het begin van de jaren negentig de wiskundige verbanden tussen het verkorten van doorlooptijden en de daardoor stijgende omvang van de ontwikkelteams. Hij neemt daarbij ook de toenemende kans op fouten bij het werken met grotere ontwikkelteams in beschouwing. In 1991 is Putnam in Nederland en geeft in zijn college een gestileerd praktijkvoorbeeld waarbij de effecten op doorlooptijd, teamgroottes en defecten zijn gebaseerd op zijn wiskundige modellen (zie kader hieronder).
Het voorbeeld betreft de ontwikkeling van een administratief systeem in COBOL ter grootte van 75.000 Lines of Code (ruim 700 functiepunten), door een organisatie met een gemiddelde systeemontwikkelingproductiviteit. Het verloop van de discussie tussen de lijnmanager en de externe systeemontwikkelaar:
- De systeemontwikkelaar maakt een optimale planning voor de ontwikkeling, waarin met een doorlooptijd van 13,6 maanden en een maximale omvang van het ontwikkelteam van 6 personen, het systeem voor $ 416.000 ontwikkeld zal worden. Bij een dergelijke aanpak is een Mean Time To Defect te verwachten van 4,8 dagen.
- De opdrachtgever heeft echter grote haast met het systeem en geeft opdracht een planning op te stellen met minimale doorlooptijd. Deze komt uit op een doorlooptijd van 8,3 maanden. Om deze tijd te halen is een team nodig dat tijdens de realisatie bestaat uit 66 personen. De kosten stijgen daardoor naar $ 3.000.000.
- Gezien de potentiële revenuen van het systeem gaat de opdrachtgever met deze begroting akkoord.
- Wat men hem echter niet had verteld, is dat bij een dergelijke teamgrootte een veel hogere kans op fouten is. Dat blijkt bij de oplevering: de Mean Time To Defect is 0,4 dagen. Dat is natuurlijk niet acceptabel, een systeem dat gemiddeld meer dan 2 keer per dag “plat” gaat.
- De werkzaamheden om het systeem de oorspronkelijk gedachte betrouwbaarheid te geven (een MTTD van 4,8 dagen) blijkt een extra doorlooptijd van 4 maanden nodig, en de kosten daarvan bedragen $ 1.600.000.
Het resultaat is dat het systeem ruim 11 keer zo duur is geworden, terwijl de bespaarde tijd 1,3 maanden bedraagt ten opzichte van de oorspronkelijk begrootte 13,6 maanden.

Bij grotere systemen wordt in de praktijk naar verhouding minder doorlooptijd beschikbaar gesteld en moet daarom met veel grotere teams gewerkt worden. De grotere teams zijn minder efficiënt. De verhoging van de tijdsdruk leidt dus door middel van grotere teams tot hogere kosten per functiepunt. Bij productieve organisaties is het effect veel minder sterk.
Bij de uitbesteding van ICT-projecten in de handel, industrie en overheid (in Finland) werd daar veel minder ruimte aan geboden. Dit betekent (als de softwareontwikkeling op zich in beide groepen even productief is) dat de hoeveelheid werk in omgevingen met meer wijzigingen in de specificaties gemiddeld het dubbele bedraagt dan in omgevingen met weinig wijzigingen in de specificaties. Hierdoor wordt de tijdsdruk dus aanzienlijk opgevoerd.
Dit betreft factoren van technische en methodische aard, maar vooral ook een aantal factoren van menselijke en organisatorische aard. Wanneer alle beïnvloedende factoren ‘vrij spel’ hebben, zijn de kosten van systeemontwikkeling zo goed als onvoorspelbaar (een factor 10 tussen optimistisch en pessimistisch).
Het is de vraag of het mogelijk is om door het uitschakelen van divergerende factoren toch tot beperking van de variatie en daarmee tot voorspelbare systeemontwikkeling te komen. Dat uitschakelen zou kunnen door een betere inhoudelijke kwaliteit van specificaties. Of door technisch uniform te werken, met steeds een vaste aanpak.
Of door te werken met teams van een optimale grootte en een bekende vaste productiviteit. In het overheidsmateriaal van voltooide projecten komen enkele organisaties voor met meer dan vijf voltooide projecten. Twee van deze organisaties komen in hoge mate overeen: vrijwel dezelfde technische basis (database en ontwikkeltools) en zij ontwikkelen beide hetzelfde type administratieve systemen. In figuur 4 worden de voltooide projecten van deze twee organisaties uitgelicht.

In figuur 4 is al te zien dat de variatie in productiviteit (uren per functiepunt) bij organisatie 2 aanzienlijk groter is dan bij organisatie 1. Figuur 5 geeft deze variatie voor beide organisaties weer. Bij organisatie 1 worden de projecten voltooid met een inspanning die ligt tussen de 3 en de 8 uur per functiepunt. Bij organisatie 2 ligt de productiviteit van voltooide projecten tussen de 8 en de 38 uur per functiepunt. In het materiaal van voltooide projecten is ook nog een tweede organisatie te zien waar de voltooide projecten eenzelfde voorspelbaar beeld te zien geven als de in de figuur getoonde organisatie 1. Daarmee lijkt de conclusie gerechtvaardigd dat het sommige organisaties lukt om ‘regie te krijgen’ op de factoren die in andere organisaties voor veel variatie in de productiviteit zorgen.

a. Er is een enorme variatie van een factor 10 tot 15 in de kosten per eenheid waar te nemen bij voltooide systemen. Het beeld bij de Nederlandse overheid komt grotendeels overeen met het beeld van de systemen in andere sectoren en landen (mogelijk licht ongunstiger voor de Nederlandse overheid). Daarbij dient wel te worden aangetekend dat het materiaal geen van ‘de grote ICT-projecten’ bevatte.
b. De kosten van softwareontwikkeling worden beïnvloed door een groep factoren die onderling afhankelijk zijn en elkaar kunnen versterken. Productiviteit en omvang van het ontwikkelteam, verkorting van de doorlooptijd en veranderende specificaties vormen interacterende en niet afzonderlijk te kwantificeren ‘drivers’ voor toenemende kosten en doorlooptijden.
c. In de meeste overheidsorganisaties leiden deze factoren tot een grote variatie in kosten en doorlooptijden bij de ontwikkeling van systemen. In deze organisaties zouden eigenlijk geen planningen meer afgegeven mogen worden, maar alleen bandbreedtes in kosten en doorlooptijd die gebaseerd zijn op beschikbare kennis.
d. Het goede nieuws is dat in de portfolio van systemen van de Nederlandse overheid enkele organisaties voorkomen die de divergerende factoren bij de voorspelbaarheid van kosten en doorlooptijden hebben weten buiten te sluiten.
e. De directe kosten van deze suboptimaal dure systeemontwikkeling zijn voor de Nederlandse overheid fors. In de paragraaf ‘Sommige organisaties weten de divergerende krachten te beteugelen’ werden de projecten getoond van een overheidsorganisatie die de verstorende factoren wel wist uit te sluiten. Als de gehele portfolio van 120 systemen van de Nederlandse overheid met deze ‘best in class’ productiviteit zou zijn uitgevoerd, dan was maar 30 procent van het nu gespendeerde bedrag van 260 miljoen euro nodig geweest.
Comstock, C., Z. Jiang & P. Naudé (2008). Risk analysis in software development. Proceedings of the 8th conference on Applied Informatics and Communications, AI’C08, Stevens Point, Wisconsin.
Dekker, V. (2008). ICT is bij de overheid één groot zwart gat.Trouw , 12 maart 2008.
ISBSG (2000). The Benchmark, release 6: an analysis of factors that affect the productivity, delivery, time, quality and cost of software projects. International Software Benchmarking Standards Group.
Jones, C. (2007). Estimating Software Costs, Bringing Realism To Estimating (2nd ed.). McGraw-Hill Osborne.
Kemerer, C.F. (1993). Reliability of Function Points Measurement, a field experiment. Communications of the ACM , Volume 36, Issue 2. Maxwell, K.D. (1998). Benchmarking software development productivity: statistical analysis by business sector. Project Control for 2000 and Beyond . Maastricht: Shaker Publishing.
Maxwell, K.D. & P. Forselius (2000). Benchmarking Software Development Productivity, IEEE Software , Volume 17, Issue 1.
Oosterhout, B. van (2007). Het ICT-drama: hoe de overheid miljarden verspilt. Intermediair , 12 december 2007.
Putnam, L.H. (1991). Measuring Software Process Improvement and Controlling Development. NOVI-conferentie Productiviteitsverbetering in softwareontwikkeling, Amsterdam, december 1991.
Verhoef, C. (2006). Explosief mengsel. Digitaal Bestuur , april 2006.