Page 149 -

120 PART TWO MANAGING SOFTWARE PROJECTS

to develop CLSS software would be dramatically different if function remains the same
(i.e., put boxes into bins) but performance varies. For instance, if the conveyor line
average speed increases by a factor of 10 (performance) and boxes are no long spaced
evenly (a constraint), software would become considerably more complex—thereby
requiring more effort. Function, performance, and constraints are intimately connected.
Software interacts with other elements of a computer-based system. The planner
considers the nature and complexity of each interface to determine any effect on
development resources, cost, and schedule. The concept of an interface is interpreted
A consideration of to include (1) the hardware (e.g., processor, peripherals) that executes the software
software scope must and devices (e.g., machines, displays) indirectly controlled by the software, (2) soft-
include an evaluation ware that already exists (e.g., database access routines, reusable software compo-
of all external nents, operating system) and must be linked to the new software, (3) people that
interfaces.
make use of the software via keyboard or other I/O devices, and (4) procedures that
precede or succeed the software as a sequential series of operations. In each case,
the information transfer across the interface must be clearly understood.
The least precise aspect of software scope is a discussion of reliability. Software
reliability measures do exist (see Chapter 8) but they are rarely used at this stage of
a project. Classic hardware reliability characteristics like mean-time-between-failures
(MTBF) can be difficult to translate to the software domain. However, the general
nature of the software may dictate special considerations to ensure "reliability." For
example, software for an air traffic control system or the space shuttle (both human-
rated systems) must not fail or human life may be lost. An inventory control system
or word-processor software should not fail, but the impact of failure is considerably
less dramatic. Although it may not be possible to quantify software reliability as pre-
? What is the cisely as we would like in the statement of scope, we can use the nature of the proj-
primary
source of ect to aid in formulating estimates of effort and cost to assure reliability.
information for If a System Specification (see Chapter 10) has been properly developed, nearly all
determining information required for a description of software scope is available and documented
scope? before software project planning begins. In cases where a specification has not been
developed, the planner must take on the role of system analyst to determine attrib-
utes and bounds that will influence estimation tasks.

5.4 RESOURCES

The second software planning task is estimation of the resources required to accom-
plish the software development effort. Figure 5.2 illustrates development resources
as a pyramid. The development environment—hardware and software tools—sits at
the foundation of the resources pyramid and provides the infrastructure to support
the development effort. At a higher level, we encounter reusable software compo-
nents—software building blocks that can dramatically reduce development costs and
accelerate delivery. At the top of the pyramid is the primary resource—people. Each
resource is specified with four characteristics: description of the resource, a state-