Page 256 -

CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 227

• Reorganization or business growth/downsizing causes changes in project
priorities or software engineering team structure.
• Budgetary or scheduling constraints cause a redefinition of the system or
product.
Software configuration management is a set of activities that have been devel-
oped to manage change throughout the life cycle of computer software. SCM can be
viewed as a software quality assurance activity that is applied throughout the soft-
ware process. In the sections that follow, we examine major SCM tasks and impor-
tant concepts that help us to manage change.

9.1.1 Baselines
Change is a fact of life in software development. Customers want to modify require-
ments. Developers want to modify the technical approach. Managers want to mod-
Most software changes ify the project strategy. Why all this modification? The answer is really quite simple.
are justified. Don’t As time passes, all constituencies know more (about what they need, which approach
bemoan changes. would be best, how to get it done and still make money). This additional knowledge
Rather, be certain that is the driving force behind most changes and leads to a statement of fact that is dif-
you have mechanisms
in place to handle ficult for many software engineering practitioners to accept: Most changes are justi-
them. fied!
A baseline is a software configuration management concept that helps us to con-
trol change without seriously impeding justifiable change. The IEEE (IEEE Std. No.
610.12-1990) defines a baseline as:
A specification or product that has been formally reviewed and agreed upon, that thereafter
serves as the basis for further development, and that can be changed only through formal
change control procedures.

One way to describe a baseline is through analogy:
Consider the doors to the kitchen in a large restaurant. One door is marked OUT and the
other is marked IN. The doors have stops that allow them to be opened only in the appro-
priate direction.
If a waiter picks up an order in the kitchen, places it on a tray and then realizes he has
selected the wrong dish, he may change to the correct dish quickly and informally before
he leaves the kitchen.
If, however, he leaves the kitchen, gives the customer the dish and then is informed of
his error, he must follow a set procedure: (1) look at the check to determine if an error has
A software occurred, (2) apologize profusely, (3) return to the kitchen through the IN door, (4) explain
engineering work the problem, and so forth.
product becomes a A baseline is analogous to the kitchen doors in the restaurant. Before a software
baseline only after it
has been reviewed and configuration item becomes a baseline, change may be made quickly and informally.
approved. However, once a baseline is established, we figuratively pass through a swinging one-
way door. Changes can be made, but a specific, formal procedure must be applied to
evaluate and verify each change.