De onvoorspelbaarheid van het ontwikkelen van geautomatiseerde systemen

Een groot en toenemend aantal processen bij de overheid kan niet meer worden uitgevoerd zonder geautomatiseerde systemen. Dat betekent dat gewenste nieuwe diensten en processen of aanpassingen in lopende diensten en processen pas kunnen worden ingevoerd als de software voor de systemen werkend is. En met de ontwikkeling van die systemen is bij de overheid het een en ander mis:

• 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.

 

Dit betekent dat een groot deel van de jaarlijkse ICT-uitgaven van de centrale overheid in Nederland, zo’n 8 tot 10 miljard euro (Dekker, 2008), sterk beïnvloed wordt door de productiviteit bij de ontwikkeling van systemen. En een verbeterpotentieel van misschien wel enkele miljarden per jaar moet in dit tijdsgewricht van financiële schaarste aanspreken.
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

bedrijven. Dat gebeurt, tamelijk indringend, aan de vergadertafel van de stuurgroep van het project wanneer er over een verhoging van het budget en een uitstel van de opleverdatum gesproken wordt. En dat gebeurt nu ook in de vergaderzaal van de Tweede Kamer, omdat het functioneren van de overheid lijdt onder mislukkende projecten en te laat opgeleverde systemen. Verrassend genoeg ligt de vraag vrijwel nooit op de vergadertafel van het topmanagement van overheidsorganisaties. Verrassend, omdat de kwestie daar ook van invloed is op het totale functioneren van de organisatie. En omdat alleen daar de maatregelen getroffen kunnen worden om de ontwikkeling van systemen goedkoper, sneller en meer voorspelbaar te maken.

 

De planning van de ontwikkeling van een systeem gebeurt in twee stappen. In de eerste stap wordt een raming gemaakt van de omvang van het te realiseren systeem. Vervolgens worden op basis daarvan de inspanning en doorlooptijd geraamd. Voor de omvang van systemen is het aantal functiepunten de (wereldwijd) meest gebruikte maat. Het aantal functiepunten wordt bepaald door de gebruikersfuncties en (logische) gegevensverzamelingen van een systeem te vermenigvuldigen met normgetallen (op basis van complexiteit) en te tellen. Met onafhankelijke, goed opgeleide tellers is de bepaling ervan in hoge mate betrouwbaar (Kemerer, 1993). Voor het bepalen van de inspanning is een goede definitie nodig om goed en eerlijk te kunnen vergelijken: is dit alleen de inspanning van de ICT’ers of ook die van de materiedeskundigen, is dit inclusief het voortraject en inclusief de acceptatietest? In dit artikel is de inspanning gedefinieerd als de inspanning van de ICT’ers in de fasen systeemontwerp en bouw (inclusief systeemtest).
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.

 

Waar in dit artikel een kwantitatief beeld wordt geschetst voor de Nederlandse overheid, gebeurt dat door de systemen (in omvang en inspanning) weer te geven tegen een achtergrond van gerealiseerde systemen uit een internationale benchmark over alle marktsectoren:

• 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.

 

 

In figuur 1 is van de beide groepen voltooide projecten de combinatie van omvang in functiepunten en de gerealiseerde inspanning weergegeven. De wereldwijde benchmark van ISBSG en de systemen van de Nederlandse overheid geven in verdeling en bandbreedte in grote lijnen hetzelfde beeld te zien (de resultaten van projecten van de Nederlandse overheid zijn iets in ‘minder productieve’ richting doorgeschoven). Opvallend is de enorme spreiding van de productiviteit in beide groepen. Het duurste (of minst productieve) project is ruim een factor 30 duurder dan het goedkoopste project. Bandbreedtes van deze orde van grootte worden ook door andere auteurs vanuit andere repository’s gemeld (Jones, 2000; Maxwell & Forselius, 2000).

 

 

Bij verschillen tussen softwareprojecten is de eerste reactie om deze verschillen te verklaren aan de hand van technische factoren, zoals de softwarehulpmiddelen waarmee het systeem ontwikkeld wordt, de gehanteerde ontwikkelmethodiek en het computerplatform waarvoor het systeem ontwikkeld wordt. Historische vakliteratuur vermeldde destijds grote verbeteringen door nieuwe ontwikkelhulpmiddelen of nieuwe methodieken. We hebben dat gezien met de 4GL-tools (literatuur: factor 3 tot factor 20 productiever), met RAD (literatuur: factor 3 tot 12 productiever). Deze tools en methodieken zijn op grote schaal in de praktijk ingevoerd, met aanzienlijke investeringen. Echter, uit onderzoek blijkt dat de productiviteit bij het ontwikkelen van systemen in diezelfde periode ongeveer gelijk is gebleven (Jones, 2000). De technische en methodische kenmerken verklaren maar een deel van de enorme variatie; onderzoek naar de Finse Laturi-repository gaf aan dat ieder van de geregistreerde technische en methodische factoren maar 3 tot 15 procent van de variatie verklaart (Maxwell, 1998).
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.

 

Er zijn meerdere signalen die aangeven dat het ontwikkelen van software voor bedrijfstoepassingen in (overheids)organisaties een moeilijk proces is:

• 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.

 

In figuur 2 wordt het proces van de ontwikkeling van software voor maatwerkapplicaties ontleed. Deze ontleding is conceptueel, in de verschillende methodieken is de naamgeving anders, en dat geldt vaak ook voor de grenzen van een fase. Conceptueel is ook het volgtijdelijke verloop van de fasen, die in evolutionaire methoden gelijktijdig worden uitgevoerd. Het proces bestaat uit een combinatie van twee ambachten:

• 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’.

 

• Het realiseren . In deze fase wordt de functionele beschrijving omgezet naar de technische beschrijving, de database, de schermen en de koppelingen worden ontworpen en gerealiseerd.

 

Beide ambachten overlappen elkaar in een fase waarin het beschrijven van de gewenste ondersteuning van de bedrijfsprocessen al wel plaatsvindt in een vorm die de mogelijkheden van realisatie beïnvloedt. Of andersom, waar de technische vorm van de functionaliteit de inhoudelijke kwaliteit van de ondersteuning kan verbeteren. Deze fase waarin er een overlap is in ambachten, lijkt een belangrijke ‘kraamkamer’ voor veranderende specificaties (los van wijzigingen die ‘van buiten’ komen):

• 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).

 

Het specificeren en het realiseren van software zijn in de uitvoering moeilijke ambachten die veel discipline en vakmanschap vragen. Goed programmeren vereist een goede opleiding, ervaring en discipline (zowel van de programmeur als van de organisatie of het team). En dan hebben we het nog niet gehad over de kunst van de gebruikersinteractie. Goed herontwerpen van bedrijfsprocessen, zodanig dat zij straks inderdaad sneller en met minder kosten gaan verlopen, is ook een moeilijk ambacht. Zeker als het resultaat van het ontwerp niet alleen een rapport maar ook het ‘doorleefde’ eigendom door de organisatie moet zijn.
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.

 

Sinds de competities tussen programmeurs die DeMarco organiseerde, is bekend dat er grote verschillen in productiviteit bestaan tussen individuele programmeurs. Ook tussen teams van programmeurs bestaan dergelijke verschillen. In een recent onderzoek naar ruim 4000 voltooide projecten werden verschillen van een factor 13 waargenomen tussen efficiënte en niet-efficiënte teams (Comstock, Jiang & Naudé, 2008). De verschillen in productiviteit tussen teams maken het moeilijk om aan te geven op welk moment het effect van een te hoge tijdsdruk optreedt.
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).

 

 

Bij de grote ICT-projecten van de Nederlandse overheid (vaak ICT-projecten voor de invulling van grote politieke ambities) wordt de opleverdatum vaak al vastgesteld op 1 januari van het derde zittingsjaar van een kabinet, voordat de feitelijke inhoud van het systeem bekend is (Verhoef, 2006). Het is niet ondenkbaar dat in een aantal van deze gevallen het door Putnam beschreven scenario voorkomt, maar dan desastreuzer.

 

Grotere systemen blijken in de meeste studies duurder per functiepunt. Nadere studie geeft echter aan dat grotere systemen ook worden ontwikkeld met grotere teams (Jones, 2000). Doorlooptijden worden in de praktijk op een andere basis gekozen dan vanuit het oogpunt van budgetoptimalisatie! Sommige stelselwijzigingen kunnen bijvoorbeeld alleen op 1 januari worden ingevoerd, politieke ambities kunnen een snelle oplevering vragen. Figuur 3 geeft een beeld van de teamgrootte en doorlooptijd die in de praktijk ontstaan bij oplopende systeemomvang. Dit beeld is uitgesplitst naar het meest productieve kwart en het gemiddelde van de organisaties.

 

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.

 

Het is in de praktijk zo goed als uitgesloten dat de tevoren opgestelde specificaties in de realisatie voor honderd procent correct blijken te zijn. Er is altijd wel een scherm waarop een data-element vergeten is. Of één scherm blijkt bij nader inzien te ingewikkeld, men heeft toch liever twee wat rustiger schermen. Als het bij enkele en voornamelijk cosmetische wijzigingen blijft, is er niets aan de hand. Maar er zijn ook projecten met veel wijzigingen en uitbreidingen. Deze wijzigingen en uitbreidingen resulteren maar voor een deel in een uitbreiding van de omvang in functiepunten, met dat deel beïnvloeden ze de productiviteit dus niet. Maar voor een belangrijk deel komen de wijzigingen in de plaats van al gemaakte functionaliteit. Dan is er dus een inspanning nodig zonder dat er omvang aan het systeem wordt toegevoegd. Goede registraties van de hoeveelheid wijzigingen en van de bijbehorende inspanning vinden zelden plaats. Hoewel het effect van veranderende specificaties dus niet direct gemeten is, zijn er wel waarnemingen die aannemelijk maken dat dit effect aanzienlijk is. In Finland werd een verschil van een factor 2 in productiviteit waargenomen tussen het bank- en verzekeringswezen enerzijds en de sectoren handel, industrie en overheid anderzijds. Het bank-en verzekeringswezen kwam tot twee keer hogere kosten voor systeemontwikkeling doordat er in de intern uitgevoerde projecten meer mogelijkheden waren om specificaties te wijzigen.
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.

 

Een groot aantal factoren is van invloed op de productiviteit van de ontwikkeling van software. De literatuur geeft meer dan 250 factoren waarvan is vastgesteld dat zij de productiviteit van systeemontwikkeling beïnvloeden (Jones, 2007).
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.

 

Figuur 4. De voltooide systemen van twee Nederlandse overheidsorganisaties verbijzonderd

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.

 

Figuur 5. Uren per functiepunt in de twee overheidsorganisaties

 

Het voorgaande leidt tot de volgende conclusies:
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.

 

Dit leidt tot de volgende aanbeveling:

Er zijn organisaties waar systemen volgens planning worden ontwikkeld. Bij die organisaties zijn, op basis van de steekproef uit dit artikel, de kosten maar een derde van het gemiddelde bij overheidsorganisaties. Dit gegeven zou moeten leiden tot grote nieuwsgierigheid bij het topmanagement van overheidsorganisaties, zeker bij de organisaties waar de processen en diensten afhankelijk zijn van ICT. De eerste stap voor dat nieuwsgierige topmanagement zou moeten zijn om binnen de eigen organisatie een ‘meet- en regelsysteem’ voor ICT-toepassingen te eisen. Een tweede stap zou moeten zijn om de kenmerken te bestuderen van de organisaties die ‘best in class’ opereren, en de wijze waarop het management daar met ICT omgaat.

 

Reviewer Wijnand Westerveld

 

Ir. Lauran Matthijssen is senior adviseur bij Het Expertise Centrum. E-mail: l.matthijssen@hec.nl.

 

Literatuur
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. (2000). Software Assessment, Benchmarks and Best Practices . Addison Wesley Longman.
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.