Page 152 -

CHAPTER 5 SOFTWARE PROJECT PLANNING 123

organizations have multiple constituencies that require access to the SEE, a project
planner must prescribe the time window required for hardware and software and
verify that these resources will be available.
When a computer-based system (incorporating specialized hardware and software)
is to be engineered, the software team may require access to hardware elements being
developed by other engineering teams. For example, software for a numerical con-
trol (NC) used on a class of machine tools may require a specific machine tool (e.g.,
an NC lathe) as part of the validation test step; a software project for advanced page-
layout may need a digital-typesetting system at some point during development. Each
hardware element must be specified by the software project planner.

5.5 SOFTWARE PROJECT ESTIMATION

In the early days of computing, software costs constituted a small percentage of the
overall computer-based system cost. An order of magnitude error in estimates of
“In an age of software cost had relatively little impact. Today, software is the most expensive ele-
outsourcing and ment of virtually all computer-based systems. For complex, custom systems, a large
increased cost estimation error can make the difference between profit and loss. Cost overrun
competition, the can be disastrous for the developer.
ability to estimate
more accurately . . . Software cost and effort estimation will never be an exact science. Too many vari-
has emerged as a ables—human, technical, environmental, political—can affect the ultimate cost of
critical survival factor software and effort applied to develop it. However, software project estimation can
for many IT groups.”
be transformed from a black art to a series of systematic steps that provide estimates
Rob Thomsett
with acceptable risk.
To achieve reliable cost and effort estimates, a number of options arise:

1. Delay estimation until late in the project (obviously, we can achieve
100% accurate estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and
effort estimates.
4. Use one or more empirical models for software cost and effort estimation.

Unfortunately, the first option, however attractive, is not practical. Cost estimates
must be provided "up front." However, we should recognize that the longer we wait,
the more we know, and the more we know, the less likely we are to make serious
errors in our estimates.
The second option can work reasonably well, if the current project is quite simi-
lar to past efforts and other project influences (e.g., the customer, business condi-
tions, the SEE, deadlines) are equivalent. Unfortunately, past experience has not
always been a good indicator of future results.
The remaining options are viable approaches to software project estimation. Ide-
ally, the techniques noted for each option should be applied in tandem; each used as