Page 255 -

226 PART TWO MANAGING SOFTWARE PROJECTS

QUICK What is the work product? The How do I ensure that I’ve done it right? When
LOOK Software Configuration Manage- every work product can be accounted for, traced,
ment Plan defines the project and controlled; when every change can be
strategy for SCM. In addition, when formal SCM tracked and analyzed; when everyone who needs
is invoked, the change control process produces to know about a change has been informed—
software change requests and reports and engi- you’ve done it right.
neering change orders.

into operation. Software configuration management is a set of tracking and control
activities that begin when a software engineering project begins and terminate only
when the software is taken out of operation.
A primary goal of software engineering is to improve the ease with which changes
can be accommodated and reduce the amount of effort expended when changes
must be made. In this chapter, we discuss the specific activities that enable us to man-
age change.

9.1 SOFTWARE CONFIGURATION MANAGEMENT
The output of the software process is information that may be divided into three broad
categories: (1) computer programs (both source level and executable forms); (2) doc-
uments that describe the computer programs (targeted at both technical practition-
ers and users), and (3) data (contained within the program or external to it). The items
that comprise all information produced as part of the software process are collec-
tively called a software configuration.
As the software process progresses, the number of software configuration items
(SCIs) grows rapidly. A System Specification spawns a Software Project Plan and Soft-
ware Requirements Specification (as well as hardware related documents). These in
“There is nothing turn spawn other documents to create a hierarchy of information. If each SCI simply
permanent except
spawned other SCIs, little confusion would result. Unfortunately, another variable
change.”
enters the process—change. Change may occur at any time, for any reason. In fact,
Heraclitus
500 B.C. the First Law of System Engineering [BER80] states: “No matter where you are in the
system life cycle, the system will change, and the desire to change it will persist
throughout the life cycle.”
What is the origin of these changes? The answer to this question is as varied as
the changes themselves. However, there are four fundamental sources of change:
• New business or market conditions dictate changes in product requirements
or business rules.
• New customer needs demand modification of data produced by information
systems, functionality delivered by products, or services delivered by a
computer-based system.