Quantify the cost of reworking bugs?

Yikes ... while I was looking at Barry Boehm's classic Software Engineering Economics just then, I looked a little closer at the cost of change curve and I realise where I went wrong when I calculated the factor of 13.5.

Choosing 50 as the average cost of change is too high.  That assumed that most of the project's requirements changes occurred in Acceptance testing, which is daft.

A quick summary of the data points from the curve:

Phase	Approx Relative Cost (midpoint)
Requirements	1.5
Design	4
Code	10
Development Test	20
Acceptance Test	50
Operation	100

When I rework my calculation using 20 as the average cost of change, it gives us:

a medium-sized project with 25% change takes 5X as long to complete [i.e. X + (.25 * 20) X = X + 4X = 5X]

So, working backwards, a year long project could be completed in about 2.5 months if rebuilt retrospectively.  That feels a little better. 

But.  It's still only taking into account the requirements changes and we know that the cost of change also applies to bug fixes.  If we could prevent all bugs, or at least find them much sooner, then that 2.5 Months would be much smaller still.  Does anyone have any figures they could share that quantify the cost of reworking bugs?

Comments

[Johanna Rothman]

I have measurements from a few clients. Since they didn't track defects in requirements and design phases, I couldn't estimate. But I could estimate from code, system test, and post-release. The data I had was surprisingly (to me) similar, given that the projects ranged from embedded systems to multi-tier architectures to transaction processing systems. The costs were: about one person-day in coding, about 3 person-days in system test, and 4-5 person-weeks post release. I've also written about this. See http://www.jrothman.com/Papers/Costtofixdefect.html and http://www.stickyminds.com/se/S3223.asp

The thing to remember with cost to find and fix a defect is that the better your preventative measures are, the longer it will take you to *find* a defect. The more reactive you are, the longer it will take to *fix* a defect.