Wat kost 1 fout in de requirements eigenlijk?

Kosten foutieve requirements

 

Slechte requirements kosten ‘zakken met geld’.Denk alleen maar eens aan herstelkosten, extra inhuur van medewerkers , uitloop of stopzetten van projecten en juridische procedures.

En hoe later in de ontwikkeling van een product een fout wordt ontdekt, des te duurder is het om deze te herstellen. Tot wel 1000x meer wanneer een fout pas wordt gevonden in productie. Deze wetmatigheid werd al in 1978 aangetoond door Barry W. Boehm.

Maar zonder harde cijfers zijn managers vaak moeilijk te overtuigen om meer aandacht en prioriteit te geven aan het opstellen en toetsen van requirements. Zeker in tijden van crisis. Probleem is echter dat er vaak geen harde cijfers bijgehouden worden voor projecten in de eigen organisatie.

Om de kosten van slechte requirements toch snel inzichtelijk te maken hebben Tom King en Joe Marasco, op basis van heel veel data en statistieken uit de praktijk,een formule ontwikkeld voor software projecten.

Deze formule berekent wat het gemiddeld kost om één fout in de requirements te herstellen die pas wordt ontdekt  tijdens de systeemtest en/of acceptatietest.

Deze formule bestaat uit de volgende 6 stappen:

A.  Schat de hoeveelheid zuivere ontwikkeltijd- en kosten in, dus zonder herstelwerkzaamheden, projectmanagement en/of analyse tijd.Een vuistregel die je hiervoor kunt gebruiken is: Vermenigvuldig het totaal aantal verwachte schermen en rapportages in het eindproduct met 4 werkweken (= ontwikkeltijd in weken) en vermenigvuldig dit met de gemiddelde weekkosten van één lid van het ontwikkelteam (= ontwikkelkosten).

B.  Schat het aantal verwachte gebreken in tijdens de testfase.
Uit onderzoeken blijkt dat je gemiddeld voor elke week ontwikkeltijd één gebrek kunt verwachten. Kortom, het aantal te verwachten gebreken is gelijk aan de ontwikkeltijd in weken (= A).

C.  Schat het aantal gebreken in dat zijn oorsprong heeft in de requirements.
Ga daarbij uit van tenminste de helft van al je verwachte gebreken (= 0,5 X B), want uit onderzoek van James Martin blijkt dat 56% van alle gebreken in software zijn oorsprong heeft in de requirements.

D.  Schat de kosten in voor herstelwerkzaamheden.
Een vuistregel is dat projecten 30% van hun zuivere ontwikkelkosten (=A) nodig hebben voor herstelwerkzaamheden, ongeacht de oorsprong van de gebreken.

E.  Schat de herstelkosten in voor fouten in de requirements.
Het herstellen van gebreken die hun oorsprong hebben in de requirements kost vaak meer dan andere gebreken. Uit onderzoek van o.a. het Chaos Report blijkt namelijk dat zij ergens tussen de 70 en 85% van de totale herstelkosten (=D) voor hun rekening nemen. Reken dus tenminste met 75%.

F.  Bereken nu de kosten voor één foutieve requirement, door de herstelkosten voor foutieve requirements (= E) te delen door het aantal foutieve requirements (=C ).

Een rekenvoorbeeld: Voor een project dat een applicatie ontwikkelt dat bestaat uit 25 schermen en rapportages en waarvan de gemiddelde weekkosten van 1 ontwikkelaar €2.500 bedragen, zullen de totale herstelkosten voor 50 fouten in de requirements zo’n €56.250 bedragen

Oftewel, elke fout in de requirements die je pas ontdekt tijdens de testfase kost je €1.125 (en later zelfs nog meer!).

Tot slot, met deze formule kun je voor managers per project heel concreet maken wat bij benadering de kosten zullen zijn van fouten in de requirements die je pas tijdens de testfase ontdekt. En dat dit 30-70x meer is dan wanneer je ze ontdekt voordat je begint met het bouwen van de applicatie.

Investeren in goede trainingen, processen en extra tijd voor het opstellen en vroegtijdig toetsen van requirements kost geld. Maar deze kosten zijn een fractie van de kosten voor het herstellen van slechte requirements die pas laat ontdekt worden.

Reacties zijn welkom!

No comments yet.

Leave a Reply