Decomposing by Phase

When working in a linear phased, or waterfall, approach, it is common to decompose into development phases and estimate those.

“We’ll spend a month on the System Requirements and another month on the Software Requirements. Then, we’ll hand those to the Solution Analysts who’ll have a month for the Analysis Phase. They’ll give it to the Software Architects who’ll have a month for Program Design. That’s four months, so we’ll give the programmers eight months for Coding and the Testers two months Testing. Just to be on the safe side, we’ll add another two months for remediation of any problems the Testers might find.”

The advantage of decomposing by phase is that, when you’re working according to a phased software development lifecycle, you’ve already got the phases laid out for you. And they’re the same from project to project. You can take the estimation from your previous project and edit it for this one. Most likely you’ll keep some phases the same, and multiply others by a factor representing your hunch of relative complexity. You’ll quickly check off the box for “Rough Order of Magnitude Estimation Document.”

The disadvantage is that it will be a long time before you can test the accuracy of that estimate. The early planning and design phases typically just produce documents, so it can be rather difficult to determine how “done” they are. That makes it temptingly easy to declare them “done” when the estimated time allotment has expired. When programming and testing are treated as separate phases, the same strategy is casually applied, too often, to programming, too. By the end of the coding phase, the program has to look like it works to the programmer and casual observers. This is admittedly harder than producing a document, but are we really sure that it’s done in the time allotted in the plan?

Only testing, coming at the end of the chain, is sure to exceed its estimated time allotment. That’s where the mistakes and holes in the programming phase are discovered. That’s where it may be found that the programmers accurately implemented an unsuccessful design. That’s where omissions and inaccuracies in the Requirements and Analysis phases are discovered. Testing has to absorb all the rework in planning, design, and programming that has gone unnoticed in the interest of “meeting the estimates.”

If a phase has errors and omissions, can it really be said to be done, even if we stop working on it after the estimated period of time? It can look like our estimate was accurate, but we can’t verify that until later, when we find out whether or not it was satisfactorily completed. Estimates that can’t be compared to actuals until the end are a huge risk. If there’s no way to be sure that an isolated part of the work is truly done, then there’s no way to validate the estimates along the way. We’ll explore this ongoing validation in more detail in Chapter 8, ​Planning for Incorrect Predictions​.