Wanneer je software ontwikkelt, wil je natuurlijk dat je zo efficiënt en zo rendabel mogelijk te werk gaat. De kromme van Boehm is een handig middel om te gebruiken als je kosten wilt besparen (of te hoge kosten wilt voorkomen).
Waar komt de kromme van Boehm vandaan?
Barry W. Boehm (1935) is een bekende software-ingenieur uit Amerika. Hij heeft een grote bijdrage geleverd op het gebied van software engineering. Boehm staat bekend om zijn visuele curve: de kromme van Boehm. Hiermee geeft hij in een curve weer waarom het duurder is om fouten te repareren naarmate ze later worden gevonden.
In de grafiek hieronder zie je een visualisatie van zijn curve. De opeenvolgende fasen van een software ontwikkeling staan op de horizontale as. De verticale as staat voor de hoogte van de kosten. De kromme van Boehm laat een exponentieel verband zien tussen de herstelkosten en de benodigde tijd. Daarom worden de relatieve kosten steeds hoger naarmate het project zich in een latere fase bevindt. Wij vinden het altijd belangrijk bij onze opdrachtgevers om hier extra op attent te zijn en wijzen het er dan ook op.
Verschillende varianten op de kromme van Boehm
De curve is in de loop der jaren aangepast en verbeterd en er is een tweede exponentiële relatie aan toegevoegd met een kleinere helling die is aangewezen voor ‘kleinere softwareprojecten’.
Andere software-ingenieurs hebben het diagram in de daaropvolgende jaren verder gewijzigd in andere versies, zoals piramides en histogrammen. Maar de essentie is altijd gebleven. Hoe eerder je start met vinden van fouten, hoe kostenefficiënter de reparatie is.
Hoe later je begint met het opsporen van fouten, hoe hoger de kosten zullen oplopen
Direct aan het begin van een project kan een probleem worden opgelost door met gebruikers te overleggen en de vereisten dienovereenkomstig aan te passen. Later, wanneer de software al in gebruik is, is het hele proces veel complexer en vandaar ook duurder om bij te sturen geworden. Wanneer gebruikers bijvoorbeeld problemen ondervinden in de software moet dit door het projectteam worden geanalyseerd. Daarna moet de defecte of foutieve code worden gevonden en daarna moet het worden geschreven.
De impact van die wijzigingen moet dus beoordeeld worden; daarna komen codering, integratie, tests etc. Deze patch moet worden geïmplementeerd, gecertificeerd door gebruikers en uiteindelijk live gaan. Je snapt inmiddels wel dat het dus een flink gedoe is welke je het beste wilt vermijden.
Een ‘late fout’ kost niet alleen veel tijd, maar ook veel geld. De kosten stijgen exponentieel. In vergelijking met een fout die tijdens de specificatiefase wordt gevonden is een fout welke in de productiekosten wordt gedetecteerd niet slechts twee of drie keer zo duur maar deze herstelkosten kunnen tot wel vijftig keer hoger zijn.
Verkorten van de feedbackcyclus
De wet van Boehm adviseert ons ook om de feedbackcyclus te verkorten. Projectinformatie moet zo snel mogelijk worden gecontroleerd op consistentie en volledigheid. Gebruikers (inclusief zakelijke gebruikers) moeten lid worden van het team, zodat de vereisten kunnen worden begrepen en geverifieerd voorafgaand aan het coderen (prototyping en BDD – Behaviour Driven Development – kunnen worden gebruikt om deze activiteiten te ondersteunen, lees hier meer over BDD).
Alle code wijzigingen moeten automatisch worden getest, zowel op unit- als systeemniveau. Dit is mogelijk door gebruik te maken van continue integratie en TDD – Test Driven Development). Ten slotte moet elke code levering aan gebruikers worden gepresenteerd, zodat het team feedback over hun werk kan krijgen en indien nodig kan corrigeren.
Volgens de kromme van Boehm is het dus verstandig om zo vroeg mogelijk een fout op te lossen in een proces. Zo voorkom je later kosten die tot wel vijftig keer hoger zijn!
Door een goed feedbacksysteem op te stellen kun je de fouten op latere stages voorkomen en dus heel veel geld en tijd besparen.
