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:
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?
