Sie sind auf Seite 1von 1

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 an age of
“ In
an
age
of
outsourcing and increased competition, the ability to estimate more accurately . . . has emerged
outsourcing
and
increased
competition,
the
ability
to
estimate
more
accurately
.
.
.
has
emerged
as
a
critical
survival
factor
for
many
IT
groups.
Rob
Thomsett

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

software cost had relatively little impact. Today, software is the most expensive ele-

ment of virtually all computer-based systems. For complex, custom systems, a large

cost estimation error can make the difference between profit and loss. Cost overrun

can be disastrous for the developer.

Software cost and effort estimation will never be an exact science. Too many vari-

ables—human, technical, environmental, political—can affect the ultimate cost of

software and effort applied to develop it. However, software project estimation can

be transformed from a black art to a series of systematic steps that provide estimates

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