COCOMO-model uitgelegd: formule, typen en kostenraming voor software

Ben je weleens gevraagd hoelang een softwareproject gaat duren en besefte je dat je beste antwoord eigenlijk een gok was?

Zo pakten de meeste teams in de jaren 70 software-engineering kostenraming aan. Projecten liepen regelmatig over budget en over deadline, en de methoden die gebruikt werden—voornamelijk expertinschatting en grove analogieën—hielden geen stand naarmate systemen groter en complexer werden.

COCOMO is ontwikkeld om dat te verhelpen. Het staat voor COnstructive COst MOdel. Barry W. Boehm introduceerde het in zijn boek uit 1981, Software Engineering Economics, waarbij hij de formules baseerde op echte projectdata in plaats van intuïtie. Het werd een van de meest onderwezen algoritmische schattingsmodellen in het vakgebied. Boehm, die in augustus 2022 overleed, besteedde decennia aan het verfijnen van de onderliggende ideeën.

In deze tutorial leg ik uit hoe het model werkt, wat de verschillende typen en niveaus betekenen, en loop ik een volledig rekenvoorbeeld door zodat de getallen in de praktijk logisch zijn.

Wat is het COCOMO-model in software-engineering?

COCOMO is een parametrisch model voor softwarekostenraming. Het neemt één primaire input—de geschatte omvang van een softwareproject in duizenden regels code (KLOC)—en gebruikt die om drie dingen te voorspellen: totale inspanning in persoonsmaanden (PM), ontwikkeltijd in maanden, en het benodigde aantal mensen.

Het model gaat ervan uit dat projectomvang de primaire voorspeller van inspanning is. Boehm bepaalde de constanten van het model door regressieanalyse uit te voeren op echte historische projectdata.

Dat gezegd hebbende: COCOMO schat niet direct de monetaire kosten. Het schat inspanning. Om persoonsmaanden naar euro’s te vertalen, vermenigvuldig je met de gemiddelde loonkosten per persoonsmaand binnen jouw organisatie. Het model levert de inspanning; jij levert het tarief.

Waarom het COCOMO-model is ontwikkeld

Boehm werkte als Director of Software Research and Technology bij TRW Aerospace, en de frustratie was direct en praktisch. Volgens een later eerbetoon van de National Academy of Engineering zei een vice-president van TRW tegen Boehm na het beoordelen van een concurrerende software-offerte: "Ik wil nooit meer een software-offerte hoeven goedkeuren puur op basis van vertrouwen. Ga en verzin een manier om de kosten voor de ontwikkeling van een softwareproduct geloofwaardig te ramen."

Die opdracht werd COCOMO. Boehm bestudeerde 63 afgeronde projecten bij TRW, variërend van 2.000 tot 100.000 regels code, geschreven in talen van assembly tot PL/I, allemaal gebouwd volgens het watervalmodel. De regressieanalyse op die dataset leverde de constanten op die in COCOMO I worden gebruikt, en in 1981 werd het model openbaar gemaakt.

COCOMO-modelformule en hoe het werkt

De wiskunde achter Basic COCOMO I is eenvoudig zodra je begrijpt waar elke term voor staat.

De formule voor inspanning is:

Hier wordt inspanning gemeten in persoonsmaanden, KLOC is de geschatte software-omvang in duizenden regels code, en a en b zijn constanten die afhangen van het type project waaraan je werkt.

De ontwikkeltijdformule volgt uit de inspanningsschatting:

De constante d varieert per modus, terwijl c in alle drie vast staat op 2,5. Veel tutorials hebben dit mis door te suggereren dat alle vier de constanten veranderen. Zodra je zowel Effort (inspanning) als hebt, kun je het gemiddeld benodigde aantal mensen schatten:

De onderstaande tabel toont de geverifieerde constanten voor Basic COCOMO I:

De sleutelvariabele hier is b. Voor Organic-projecten is b = 1,05, wat betekent dat de inspanning bijna lineair groeit met de projectomvang. Voor Embedded-projecten is b = 1,20, wat een aanzienlijke diseconomie van schaal oplevert: een verdubbeling van de omvang van een embedded-project vereist meer dan een verdubbeling van de inspanning.

Typen COCOMO-model (COCOMO I)

COCOMO I deelt softwareprojecten in drie ontwikkelmodi in. Elke modus weerspiegelt een andere combinatie van teamervaring, projectcomplexiteit en operationele beperkingen. De modus die je kiest, bepaalt welke constanten je in je formules gebruikt.

Op voorhand goed om te weten: deze drie modi gelden alleen voor COCOMO I. COCOMO II, de update uit 2000, verving ze door een andere aanpak.

Drie COCOMO I-modi visueel vergeleken. Afbeelding door de auteur.

De drie modi liggen op een schaal van toenemende complexiteit en beperking. Het projecttype en de teamcontext maken meestal duidelijk welke van toepassing is.

Organic-modus

De Organic-modus omvat kleine tot middelgrote projecten waarbij het team veel ervaring heeft met het toepassingsdomein, de requirements relatief goed begrepen zijn en er geen grote externe druk is vanuit hardwarebeperkingen of regelgeving. Een salarissysteem, een dataverwerkingstoepassing of een voorraadbeheertool valt hier doorgaans onder.

Omdat het team ervaren is en het domein bekend, blijft de communicatie-overhead laag, ook als het project groeit. Daarom is de b-exponent de kleinste van de drie modi.

Semi-detached-modus

De Semi-detached-modus zit in het midden. Teams in deze categorie hebben gemengde ervaring: sommige leden kennen het domein goed, anderen niet. Het project heeft een gemiddelde complexiteit en er kan enige interactie zijn met nieuwe hardware of externe systemen.

Compilerontwikkeling, transactieverwerkende systemen en middensegment-bedrijfsapplicaties zijn veelvoorkomende voorbeelden. De diseconomie van schaal is hier duidelijker, met b = 1,12.

Embedded-modus

De Embedded-modus is van toepassing op projecten met strikte operationele beperkingen: strenge hardware-eisen, realtimedoorvereisten, normeringen of eisen vanuit lucht- en ruimtevaart en defensie. Het team kan groot en technisch vaardig zijn, maar de complexiteit van integratie, testen en validatie drijft de inspanning sterk op naarmate de projectomvang toeneemt.

Met b = 1,20 kennen embedded-projecten de sterkste diseconomie van schaal van de drie modi. Embedded gaat bovendien niet over projectgrootte. Zelfs een relatief klein embedded-systeem valt hieronder als het onder zware beperkingen opereert.

Basic vs. Intermediate vs. Detailed COCOMO

Naast de drie projectmodi kent COCOMO I drie niveaus van detail in de raming. De modi vertellen je welke constanten je gebruikt; de niveaus geven aan hoe diep je het project modelleert. Elk niveau bouwt voort op het vorige door meer factoren toe te voegen, wat de nauwkeurigheid verhoogt ten koste van meer inputdata.

Zie het als een spectrum: Basic COCOMO geeft je snel een grove schatting, terwijl Detailed COCOMO precieze planning op fase-niveau mogelijk maakt.

COCOMO I-niveaus naar diepte van raming. Afbeelding door de auteur.

Lager op de piramide voeg je meer factoren toe aan de berekening, wat de nauwkeurigheid verhoogt maar ook meer inputdata vereist om te starten.

Basic COCOMO

Basic COCOMO gebruikt alleen de projectomvang in KLOC en de projectmodus. Je voert KLOC in, past de constanten voor je gekozen modus toe en krijgt een schatting van de inspanning. Dit is handig voor vroege haalbaarheidsinschattingen wanneer je nog geen gedetailleerde informatie hebt over je team of ontwikkelomgeving.

Intermediate COCOMO

Intermediate COCOMO introduceert een Effort Adjustment Factor, meestal geschreven als EAF. De volledige lijst met kostenstuurfactoren (multipliers) staat in de COCOMO II Model Definition Manual. De inspanningsformule wordt dan:

De EAF is het product van 15 kostendrijvers, elk beoordeeld op een schaal van Very Low tot Extra High. De drijvers vallen in vier categorieën: productattributen (betrouwbaarheid, complexiteit, databasegrootte), hardwareattributen (beperkingen qua uitvoeringstijd en opslag), personeelsattributen (teamervaring en -capaciteit) en projectattributen (tools, planningsdruk en ontwikkelpraktijken).

Één ding om te weten over Intermediate COCOMO: de a-constante verandert ten opzichte van de Basic-waarden. Voor de Organic-modus wordt a 3,2 (niet 2,4). Voor de semi-detached-modus blijft die 3,0. Voor de Embedded-modus daalt die naar 2,8. De b-, c- en d-exponenten blijven hetzelfde in zowel Basic als Intermediate.

Personele kostendrijvers werken omgekeerd: hogere capaciteit betekent een kleinere multiplier, wat de inspanningsschatting verlaagt. Een team van ervaren programmeurs heeft simpelweg minder persoonsmaanden nodig om een project af te ronden dan een team van beginners.

Detailed COCOMO

Detailed COCOMO, ook wel Advanced COCOMO genoemd, past inspanningsmultipliers toe op het niveau van individuele fasen in plaats van over het hele project. Dit betekent dat de kostendrijvers voor requirementsanalyse, gedetailleerd ontwerp, coderen en integratie en testen afzonderlijk worden beoordeeld.

Dit is het meest nauwkeurige niveau, en ook het meest tijdrovend om te gebruiken. Het is logisch voor grote projecten waar verschillende teams eigenaar zijn van verschillende fasen en waar de inspanningsverdeling over fasen belangrijk is voor de planning.

COCOMO II: de moderne versie

Halverwege de jaren 90 begon COCOMO I te verouderen. Softwareontwikkeling verschoof van watervalprojecten op mainframes naar objectgeoriënteerd programmeren, herbruikbare componentbibliotheken, snelle prototyping en gedistribueerde desktopsystemen. Het toepassen van projectdata uit de jaren 70 op softwareomgevingen uit de jaren 90 leverde onbetrouwbare ramingen op.

Boehm en zijn collega’s bij het USC Center for Software Engineering hebben het model vanaf de basis opnieuw opgebouwd. Het resultaat was COCOMO II, gepubliceerd in 2000 in het boek Software Cost Estimation with COCOMO II, gekalibreerd tegen een dataset van 161 projecten—meer dan het dubbele van de 63 uit het oorspronkelijke model.

De drijfveren achter COCOMO II waren objectgeoriënteerde en componentgebaseerde ontwikkeling, softwarehergebruik en integratie van commercieel verkrijgbare componenten, iteratieve en spiraalvormige ontwikkelmodellen en moderne tooling. Een veelvoorkomend misverstand om te verduidelijken: COCOMO II is niet gebouwd voor Agile-ontwikkeling. Agile zoals we dat nu kennen bestond nauwelijks toen het model tussen 1995 en 2000 werd ontwikkeld.

De drie submodellen van COCOMO II

COCOMO II biedt drie submodellen, elk geschikt voor een andere fase in de levenscyclus van een project.

Het Application Composition Model is ontworpen voor vroege prototyping, met name wanneer teams GUI-builders en componentbibliotheken gebruiken. In plaats van KLOC gebruikt het Object Points: schermen, rapporten en third-generation language-componenten gewogen naar complexiteit en aangepast voor verwachte hergebruik. Dit is een lineair model zonder schaalfactoren of exponentiële aanpassingen.

Het Early Design Model wordt gebruikt voordat de architectuur is vastgesteld. Het neemt Unadjusted Function Points als input, zet die om naar equivalente broncode-regels met behulp van taalspecifieke tabellen en past zeven kostendrijvers toe. Het geeft een redelijke schatting wanneer je weet wat het systeem moet doen, maar nog niet hoe het gebouwd wordt.

Het Post-Architecture Model is het meest rigoureus van de drie. Het wordt ingezet nadat de softwarearchitectuur is vastgelegd, met Thousands of Source Lines of Code (KSLOC) of function points als input, 17 kostendrijvers en vijf schaalfactoren. De inspanningsformule is:

Waarbij E een dynamische exponent is die als volgt wordt berekend:

En de planningsformule is:

Waarbij:

De constanten 2,94, 0,91, 3,67 en 0,28 komen uit de COCOMO II.2000-kalibratie. Sommige oudere bronnen noemen 2,5 in plaats van 2,94; dat is een pre-2000-kalibratiewaarde en hoort niet gebruikt te worden met het huidige model. De USC COCOMO II Web Tool op softwarecost.org is een gratis, live-implementatie van het Post-Architecture-model als je ramingen wilt draaien zonder de wiskunde handmatig te doen.

Kostendrijvers en schaalfactoren in COCOMO

Twee mechanismen maken dat COCOMO II anders werkt dan COCOMO I: schaalfactoren en kostendrijvers. Dit is wat elk ervan doet.

In COCOMO I staat de exponent b vast per modus: je kiest Organic, semi-detached of Embedded, en je krijgt een vooraf ingestelde waarde. COCOMO II vervangt dit door vijf continu beoordeelde schaalfactoren die de exponent berekenen op basis van jouw beoordeling van elk ervan.

De vijf schaalfactoren in COCOMO II zijn precedentedness (PREC), ontwikkelflexibiliteit (FLEX), architectuur- en risicobeheersing (RESL), teamcohesie (TEAM) en procesvolwassenheid (PMAT). Elk wordt beoordeeld op een schaal van Very Low tot Extra High, en hun gecombineerde som bepaalt E in de inspanningsformule. Een hogere som betekent een minder volwassen, minder vertrouwd en risicovoller project, wat resulteert in een hogere exponent en meer inspanning.

Schaalfactoren beïnvloeden de vorm van de inspanningscurve. Kostendrijvers daarentegen zijn multiplicatieve aanpassingen op de basisinspanning. COCOMO II heeft 17 kostendrijvers in het Post-Architecture-model, vergeleken met 15 in Intermediate COCOMO I. De toevoegingen in COCOMO II omvatten factoren voor vereiste herbruikbaarheid (RUSE), documentatie-eisen (DOCU), platformvolatiliteit (PVOL), personeelscontinuïteit (PCON), applicatie-ervaring (APEX), platformervaring (PLEX), taal- en toolexpertise (LTEX) en ontwikkeling op meerdere locaties (SITE).

Een kostendrijver die het vermelden waard is, is SCED, die de vereiste ontwikkelplanning dekt. Als je een planning aanzienlijk comprimeert, stijgt de multiplier boven 1,0, wat betekent dat je eigenlijk meer persoonsmaanden nodig hebt om sneller klaar te zijn. Dit komt overeen met wat de meeste engineers al uit ervaring weten: een team forceren tot sprinten leidt tot coördinatie-overhead, fouten en rework die vaak meer kosten dan de gewonnen tijd.

Voordelen van het COCOMO-model

De voornaamste kracht van het model is transparantie. In tegenstelling tot proprietaire schattingstools publiceert COCOMO al zijn vergelijkingen, constanten en kalibratiemethodologie. Iedereen kan de inputs controleren en de outputs verifiëren. Dit maakt het nuttig in overheid, defensie en lucht- en ruimtevaart, waar wiskundige controleerbaarheid vaak een wettelijke of contractuele eis is.

Het model kan ook worden herkalibreerd. Organisaties die hun eigen projecthistorie verzamelen, kunnen de constanten aanpassen aan hun specifieke omgeving, teamopbouw en technologiestack. Dit is belangrijk omdat de standaardconstanten afkomstig zijn uit datasets die inmiddels decennia oud zijn.

De driedelige opbouw (Basic → Intermediate → Detailed) is een ander praktisch voordeel. Vroeg in een project, wanneer weinig bekend is, gebruik je Basic voor een grove raming. Naarmate het project volwassen wordt en er meer bekend is over het team en de omgeving, ga je naar Intermediate of Detailed voor verfijndere planning.

Beperkingen van het COCOMO-model

De grootste beperking is COCOMO’s afhankelijkheid van KLOC. Om COCOMO te gebruiken, moet je de omvang van een project in regels code schatten voordat je enige code schrijft. In de vroege stadia van een project—juist wanneer raming het belangrijkst is—is dit berucht lastig nauwkeurig te doen.

Zelfs wanneer KLOC kan worden geschat, komen de constanten in COCOMO I uit 63 projecten die tussen 1968 en 1979 volgens het watervalmodel zijn gebouwd. De constanten in COCOMO II komen uit 161 projecten uit de jaren 90. Geen van beide datasets bevat cloud-native systemen, mobiele applicaties, microservices-architecturen of moderne DevOps-pijplijnen. Het direct toepassen van deze constanten op een modern project zonder lokale kalibratie levert onbetrouwbare ramingen op.

Een studie uit 2025 zette hier cijfers op. Een ongekalibreerde Basic COCOMO toegepast op een NASA-projectdataset leverde een gemiddelde relatieve fout op van ongeveer 100%, zonder voorspellingen binnen 25% van de werkelijke inspanning. Dat is geen kleine foutmarge; het weerspiegelt een model dat buiten de condities wordt gebruikt waarvoor het is gebouwd.

Het model gaat ook niet goed om met iteratieve ontwikkeling. COCOMO veronderstelt een redelijk sequentiële lifecycle. Agile-teams die in korte sprints werken met evoluerende backlogs passen niet in de watervalveronderstellingen die in COCOMO’s structuur zijn ingebakken.

Er is ook een dieper probleem. Een paper gepubliceerd in Frontiers in Artificial Intelligence in maart 2026 stelde dat COCOMO II fundamenteel niet aansluit op AI-ondersteunde softwareontwikkeling—niet alleen qua kalibratie maar structureel. Wanneer AI-codetools een aanzienlijk deel van een codebase genereren, wordt KLOC als proxy voor menselijke inspanning misleidend. De inspanning verschuift naar verificatie, architecturale governance en securityreview—zaken die COCOMO’s kostendrijverframework niet is ontworpen om te vangen.

COCOMO-model vs. andere schattingstechnieken

COCOMO is niet de enige optie. De alternatieven kennen helpt je de juiste aanpak te kiezen voor een gegeven situatie.

Function Point Analysis (FPA) meet systeemcomplexiteit vanuit gebruikeringangen en -uitgangen, onafhankelijk van programmeertaal. Het werkt goed wanneer je solide requirements hebt maar nog geen KLOC-schatting. Het Early Design-model van COCOMO II accepteert function points als input, dus de twee kunnen samen worden gebruikt.

Story points zijn standaard in Agile-omgevingen. Teams beoordelen user stories op relatieve complexiteit en volgen vervolgens de velocity om de voortgang te projecteren. Ze zijn snel en teamspecifiek, maar leveren niet de totale-kostenbasis die inkoop en langetermijnplanning vereisen. COCOMO en story points dienen verschillende doelen.

Parametrische tools zoals SEER-SEM en SLIM gebruiken proprietaire kalibratiedatabases en bredere parametersets. Studies vinden dat ze ongekalibreerde COCOMO II verslaan qua nauwkeurigheid. Het voordeel van COCOMO is transparantie en open beschikbaarheid, wat telt in academische of controleerbare contexten.

Machine learning-gebaseerde raming is een actief onderzoeksgebied. Een studie uit januari 2026 vond dat ensemblemodellen die random forests, support vector regression en neurale netwerken combineren, COCOMO-familie modellen overtroffen op Agile-projectdata op alle vier de standaard evaluatiemetrics. Deze benaderingen passen zich aan hun trainingsdata aan in plaats van te vertrouwen op decenniaoude constanten.

COCOMO-modelvoorbeeld (uitgewerkte berekening)

Weten waar COCOMO past ten opzichte van andere methoden is nuttig, maar de beste manier om te begrijpen hoe het echt werkt is door de cijfers te draaien. Laten we een complete Basic COCOMO I-berekening doorlopen met de Organic-modus en een project geschat op 50 KLOC.

De constanten voor de Organic-modus zijn: a = 2,4, b = 1,05, c = 2,5, d = 0,38.

Stap 1: Bereken inspanning

Om 50^1.05 te berekenen, gebruik je het feit dat .

Stap 2: Bereken ontwikkeltijd

Stap 3: Bereken benodigde mensen

Samenvatting:

Twee dingen die het vermelden waard zijn. Persoonsmaanden en kalendermaanden zijn verschillende eenheden: 145,8 persoonsmaanden over 16,6 kalendermaanden betekent ruwweg 9 mensen die parallel werken. En omdat dit Basic COCOMO is, gebruikt het alleen omvang en modus. Het toevoegen van echte kostendrijverbeoordelingen via EAF zou de inspanningsschatting vanaf daar omhoog of omlaag verschuiven.

COCOMO-model in software-engineeringinterviews

COCOMO komt voor in academische cursussen, universitaire examens en interviews voor rollen in overheid, defensie en systems engineering. Het duikt zelden op bij agile consumententechbedrijven.

De meest voorkomende vraag is COCOMO I versus COCOMO II: vaste modi en vooraf ingestelde constanten uit 63 projecten versus vijf continue schaalfactoren op een grotere, modernere dataset. Als je dat onderscheid, de basisformules en de drie modenaam kent, ben je meestal gedekt. Interviewers vragen soms om een voorbeeldberekening, dus het uitgewerkte voorbeeld hierboven is het oefenen waard.

Conclusie: is het COCOMO-model nog relevant?

COCOMO blijft nuttig waar de aannames gelden: sequentiële ontwikkeling, formele inkoop en academische studie. Waar moderne software daarvan afwijkt, valt het uiteen.

Gebruik Basic COCOMO voor een snelle ordegroottecheck vroeg in een project. Gebruik Intermediate COCOMO wanneer je gegevens hebt over team en omgeving. Kalibreer op je eigen projecthistorie voordat je in een echte offerte of planning op een output vertrouwt. Zoals ik in het gedeelte Beperkingen besprak, levert het toepassen van de standaardconstanten op een modern project zonder kalibratie fouten op die te groot zijn om op te handelen.

COCOMO III is sinds circa 2015 in ontwikkeling bij de Boehm CSSE, zonder publieke release per maart 2026. Het origineel uit 1981 en de update uit 2000 blijven de maatstaf.

Wil je verder met softwareontwikkeling? We hebben cursussen over Software Engineering Principles in Python, Software Development with Cursor en Software Development with GitHub Copilot om je te helpen bouwen op wat je hier hebt geleerd.