Page 143 -

114 PART TWO MANAGING SOFTWARE PROJECTS

QUICK implemented, and the cost, effort, been completed. However, if you have experience
LOOK and time involved for each is and follow a systematic approach, generate esti-
generated. A list of required pro- mates using solid historical data, create estimation
ject resources is also produced. data points using at least two different methods,
How do I ensure that I’ve done it right? That’s hard, and factor in complexity and risk, you can feel con-
because you won’t really know until the project has fident that you’ve given it your best shot.

5.1 OBSERVATIONS ON ESTIMATING

A leading executive was once asked what single characteristic was most important
when selecting a project manager. His response: "a person with the ability to know
what will go wrong before it actually does . . ." We might add: "and the courage to
estimate when the future is cloudy."
Estimation of resources, cost, and schedule for a software engineering effort
requires experience, access to good historical information, and the courage to com-
“Good estimating mit to quantitative predictions when qualitative information is all that exists. Esti-
1
approaches and solid mation carries inherent risk and this risk leads to uncertainty.
historical data offer Project complexity has a strong effect on the uncertainty inherent in planning. Com-
the best hope that
reality will win over plexity, however, is a relative measure that is affected by familiarity with past effort.
impossible The first-time developer of a sophisticated e-commerce application might consider
demands.” it to be exceedingly complex. However, a software team developing its tenth
Capers Jones e-commerce Web site would consider such work run of the mill. A number of quan-
titative software complexity measures have been proposed [ZUS97]. Such measures
are applied at the design or code level and are therefore difficult to use during soft-
ware planning (before a design and code exist). However, other, more subjective
assessments of complexity (e.g., the function point complexity adjustment factors
described in Chapter 4) can be established early in the planning process.
Project size is another important factor that can affect the accuracy and efficacy of
estimates. As size increases, the interdependency among various elements of the
2
software grows rapidly. Problem decomposition, an important approach to esti-
mating, becomes more difficult because decomposed elements may still be formida-
Project complexity, ble. To paraphrase Murphy's law: "What can go wrong will go wrong”—and if there
project size, and the are more things that can fail, more things will fail.
degree of structural The degree of structural uncertainty also has an effect on estimation risk. In this
uncertainty all affect context, structure refers to the degree to which requirements have been solidified,
the reliability of
estimates. the ease with which functions can be compartmentalized, and the hierarchical nature
of the information that must be processed.

1 Systematic techniques for risk analysis are presented in Chapter 6.
2 Size often increases due to the “scope creep” that occurs when the customer changes require-
ments. Increases in project size can have a geometric impact on project cost and schedule (M.
Mah, personal communication).