56 SCM: Basic Concepts

of software at a discrete point in time is known as a baseline. Each baseline serves

as a point of departure or reference for the next development stage.
A software baseline is a set of software items formally designated and fixed at
a specific time during the software life cycle. A baseline, together with all approved
changes to the baseline, represents the current approved configuration. Usually,
baselines are established after each life cycle phase at the completion of the formal
review that ends the phase. Thus we have such baselines as the requirements base-
line, the design baseline, and the product baseline, as shown in Chapter 2.
A baseline provides the official standard or point of reference on which subse-
quent work is based and to which only authorized changes are made. After an initial
baseline is established, every subsequent change made to the CIs is done using the
configuration control process or, in other words, using formal change management
procedures. Whenever an item is changed, all the processes involved in making the
change—change initiation to change requests2 to change disposition and implemen-
tation—are recorded. Then, the item that is being changed is reviewed and saved as
a new version of the item. For all these change management processes, the baseline
serves as a reference point.
Baselines should be established at an early point in the project. However, bring-
ing all items under configuration control too early will impose unnecessary pro-
cedures and will slow the programmers’ work. This is because before a software
CI becomes part of a baseline, changes may be made to it quickly and informally.
For example, consider a programmer developing a program. After he or she has
completed coding, while doing the unit testing, the programmer stumbles on a
better algorithm to accomplish some task in the program. Because the program is
not part of a baseline, the programmer can make the necessary change to the pro-
gram, recompile it, and continue with the testing. However, if the same situation
occurs after the program is checked-in or has become part of a baseline, then the
programmer will have to make a change request and follow the change management
procedures to make the change.
So when should baselines be established? There are no hard and fast rules on
this issue. It depends on the nature of the project and the thinking of the SCM sys-
tem designers (the people who designed the SCM system and wrote the SCM plan).
Establishing baselines involves a trade-off between imposing unnecessary procedures
(thus reducing productivity) and letting things go uncontrolled (which will result in
project failure). So these two factors should be kept in mind when deciding when to
baseline. As long as the programmers can work on individual modules with little
interaction, a code baseline is not needed. As soon as integration begins, formal
control is essential.
So prior to a CI becoming a controlled item, only informal change control3 is
applied. The developer of the item can make whatever changes are justified by project

2. Change request (CR) is a request to make a change or modification. A CR form is a paper or electronic
form that is used to initiate a change and that contains the details of the change such as the name of the
change originator, the item to be changed, and the details of changes.
3. Informal change control is applicable when the developers can make changes to their programs without
following the SCM procedures. This is possible when the item has not been checked in and is not under
SCM control.

6518 Book.indb 56 12/30/14 1:24 PM

 Check-In and Check-Out57

and technical requirements, as long as these changes do not conflict with the system
requirements.4 However, once the object has undergone formal technical review and
has been approved, a baseline is created. Once the CI becomes a baseline, project
level change control or formal change control is implemented.
Even though the most common baselines are the requirements, design, and
product baselines, a baseline can be established whenever a need is felt. For exam-
ple, many projects have many more baselines than the three mentioned above. A
new baseline is not necessarily established each time a CI is modified or added to
the library. The number of baselines that a project has is determined by the SCM
team, the project’s needs, and what is advantageous. The information about when
to create a baseline will be in the SCM plan.
You can have a baseline at the start of each phase, if you so choose. As for
trade-offs, the only time there is a real need to establish a baseline is, if after it is
done, a copy of the baseline leaves SCM control in some fashion (i.e., to a test lab
or deployment)—that is the minimum for creating a baseline. You must know the
“set” of software that starts a phase or is deployed so that you know what changes
should be made to it later. In considering how to control the number of baselines,
ask the following questions:

• What are the requirements from the customer vis-à-vis providing demonstrable
progress reporting?
• What are the needs and requirements internal to your organization or project
about status and progress reporting?
• What metrics do your customers, management, and project leadership need
to see?

The answers to these questions can help you establish a baseline schedule.

Check-In and Check-Out

We have seen that once a CI is developed, reviewed, and approved, it is kept in a

controlled library or repository. This process of reviewing, approving, and moving
an item into the controlled environment is called check-in.
Once an item is checked in, it becomes a controlled item, and all change manage-
ment procedures apply to it. It cannot be taken out and modified whenever a pro-
grammer feels like doing so, even if he or she is the author or developer of the item.
For making changes to an item that is in the controlled library, the change man-
agement process, which is discussed in detail in Chapter 7, must be followed. That
is, a change request has to be submitted and approved, among other things. Once
the change request is approved, the configuration manager will copy the item (and

4. Developers can find out whether the changes they make to their programs conflict with the system
requirements by going through the system design specifications and HLD documents. For example, in a
program, whether the developer first calculates the tax and subtracts it from the earnings or multiplies
the earnings with the (1-tax/100) does not conflict with the system requirements. This is a decision that
the programmer takes according to his or idea about which is the best algorithm.

6518 Book.indb 57 12/30/14 1:24 PM

 58 SCM: Basic Concepts

Figure 5.1 Check-in and check-out.

other impacted items, if any) from the controlled library so that modifications can
be made. This process is called check-out. Thus, to make a change to an item that
is under SCM control, it has to be checked out of the controlled library. After the
changes are made, the item or items are again tested and reviewed and, if approved,
proceed to be checked in to the controlled environment. The check-out/check-in
process is shown in Figure 5.1. Today’s SCM tools have made this whole process
of check-in and check-out an easy task. Many tools allow programmers to work on
CIs without physically checking out the items. Also, today’s SCM tools allow more
than one person to simultaneously work on the same CI (concurrent development).
These facilities provided by modern SCM tools are discussed later in this chapter.

Versions and Variants

During the software development life cycle, the CIs evolve until they reach a state
where they meet the specifications. This is when the items are reviewed, approved,
and moved into the controlled environment. However, we have seen that the story
does not end there. The item will undergo further changes (due to various reasons
such as defects and enhancements) and to make those changes, the change control
procedures must be followed. The items have to be checked out, and the changes
need to be implemented, tested, reviewed, approved, and again moved back to the
controlled library. This change process produces a new version or revision of the item.
A version is an initial release or rerelease of a CI. It is an instance of the system
that differs in some way from the other instances. New versions of the system may
have additional functionality or different functionality. Their performance charac-
teristics may be different, or they may be the result of fixing a bug that was found
by the developer, tester, user, or customer.

6518 Book.indb 58 12/30/14 1:24 PM

 Parallel Development and Branching59

Some versions can be functionally equivalent but may be designed for different
hardware or software environments. In such cases, they are called variants. For
example, two different instances of the same item—e.g., one for Windows and the
other for Linux—can be called variants rather than different versions. Unlike a
version, one variant of an item is in no sense an improvement on another variant.
As we have seen, the items once moved into the controlled environment can be
changed only by using SCM change control methods. Each such change produces a
revision or version. So each change to a controlled item produces a new version, and,
except for the first, each version has a predecessor. Similarly, except for the most
recent, each version has a successor. The different versions of an item represent its
history. It explains how an item got transformed or evolved from its initial form or
stage to its current form. Usually, a new version of an item is created by checking
out the most recent copy and making changes to it.

Parallel Development and Branching

So far we have seen that an item is checked out, and changes are made and then
tested, reviewed, approved, and checked in. So the versions will form a linear line
as shown in Figure 5.2.
In real life, however, this linear development might not always be possible.
In such cases we use what is called a branch. Branches (Figure 5.3) are deviations
from the main development line for an item. They are a convenient mechanism for
allowing two or more people to work on the same item at the same time—parallel,
concurrent development—perhaps for different goals. A common scenario is hav-
ing one person working to add new features to the product, while a second is doing
bug fixes on prior versions.
The version numbers of branches can be a little confusing, so they warrant a
quick discussion. Version numbers on the main development line have only two
parts—a major and minor number. Branches have four parts to their numbering
scheme. The first two parts represent the point at which the branch splits off the
main line. The third number indicates which of the many possible branches it is.
For example, in Figure 5.3, we have only one branch originating from 1.3. As such,

Figure 5.2 Version numbers.

Figure 5.3 Branching for parallel development.

6518 Book.indb 59 12/30/14 1:24 PM

 60 SCM: Basic Concepts

Figure 5.4 Multiple branches.

its numbering starts at 1.3.1.0 and proceeds from there. If a second branch is later
formed from 1.3, then its numbering will begin with 1.3.2.0, as shown in Figure 5.4.
Branches can also extend from existing branches. For example, a branch can
be formed from 1.3.1.1. This branch will have a six-part numbering scheme start-
ing with 1.3.1.1.1.0 as shown in Figure 5.5. The first four parts represent the point
at which the branch split off from the parent branch. The fifth number indicates
which of the many possible branches it is. For example, in Figure 5.5 we have only
one branch originating from 1.3.1.1. As such, its numbering starts at 1.3.1.1.1.0
and proceeds from there. If a second branch is later formed from 1.3.1.1, then its
numbering will begin with 1.3.1.1.2.0.
Branches are often used as a temporary means of allowing parallel and concur-
rent development on a single file. Sooner or later, the edits made to the branched
line must be incorporated into the main evolutionary line for the file. When doing
this, the changes made by the different persons have to be merged. If the changes
are made at different parts of the item, then the merge is an easy task. However, if
two people have changed the same lines of an item, then a decision has to be reached
about how the merge is to take place. The person who does the merging should
decide which one to keep and which one to discard. SCM tools have automatic
merging facilities that allow interactive merging, in which the tool will compare
the changed portions of the two changed files to the original file (usually called the

Figure 5.5 Branch from an existing branch.

6518 Book.indb 60 12/30/14 1:24 PM

 Source and Derived Items61

ancestor), and the user can choose which change to accept. In the author’s opinion,
however, it is always better to do an interactive or manual merge, because human
judgment is better that the judgment afforded by the algorithms used by the tools.
After the merge occurs, the branches have outlived their utility and no longer
need to evolve separately.

Naming of Versions

We have seen that all CIs have to be named and that the name has two parts: a
number part, which changes with each version, and the name of the item (including
the project, type, and other details). The names should be descriptive. For example,
in a large project with many modules and subsystems, a simple name for a CI is
not a good idea. In such cases, the name should have elements of the project, sub-
system, module, and other components in it so that it can be easily identified with
a project or subsystem. The number part of the name should be designed in such a
way as to determine its relative position in the version hierarchy. For example, we
have seen that the first version will be identified as 1.0 and subsequent revisions
1.1, 1.2, 2.0, 2.1, and so on. A branch from version 1.1 will be identified as 1.1.1.0
and its subsequent versions 1.1.1.1 and so on. A second branch will be identified
as 1.1.2.0 and so on.

Source and Derived Items

An item that is created from another item or set of items is called a derived item.
The items from which a derived item is created are called source items. For example,
an executable program is a derived item—an item that is derived from the source
code using a compiler. In the case of derived items, the details, such as the list of
source items used to derive the item, the tool or tools used to derive the item, and
the environment in which the derivation was done, are important and should be
documented. This is important from the point of view of reproducibility and repeat-
ability. For example, if you want to derive the particular version of a derived item,
you will need all the above information to do so. Also, if a problem is detected with
a version of the derived item, then the following questions need to be answered to
solve the problem:

• Which versions of which source elements (name and version of each source
item) were used to build the item?
• Which tools were used for the process?
• What environment variables and parameters (such as compile and link-edit
options) were used to by the tools while building the item?

These are the first questions one must answer if a problem occurs, and a good
SCM system should be able to provide the answers to these questions, as these are
the answers that fully describe a derived item.

6518 Book.indb 61 12/30/14 1:24 PM

 62 SCM: Basic Concepts

System Building

System building is the process of combining “source” components of a system into

components, which execute on a particular target configuration. The system or
parts of it have to be rebuilt after every change in the “source.” The following fac-
tors must be considered:

• Have all components that make up the system been included in the build
instructions (e.g., dependencies resolved and include paths set), and do they
have the proper version?
• Are all required ancillary files (data and documentation, e.g.) available on
the target machine?
• Are the required tools (e.g., the compiler or linker) available, and do they
have the right version?

The system is built using a command file that specifies such factors as the com-
ponents of the system (both source and derived), their versions, their location in
the controlled environment, the system building tools (e.g., a compiler and a linker)
and their versions, and the options and environmental parameters that were set. In
the IBM mainframe, this file is usually a JCL file; in UNIX, it is a shell script; in
modern integrated development environments such as Visual C++ and Visual Basic,
it is a make file or project file. These command files are also CIs and are necessary
for reproduction of the particular configuration.
The build management facility of many SCM tools automates the process of
constructing the software system and ensures that the systems are built completely
and accurately at any time. These configuration builders save time, shorten build
cycles, and eliminate build errors by providing repeatable, automated builds of
the software development projects. In most cases, the system building tools work
with the version management tools and extract the correct versions of development
objects from libraries. This simplifies the system building process and eliminates
errors when building complex versions on multiple operating systems.

Releases

A release consists of more than just the executable code. It includes installation files,
data files, setup programs, and electronic and paper documentation. A system release
is the set of items that is given to the customers. Each system release includes new
functionality or features or some fixes for the faults found by customers, develop-
ers, or testers. Usually, there are more revisions of a system than system releases.
Revisions or versions, as mentioned before, are created for internal use and may
never be released to customers. For example, a revision may be created for testing.
When a release is produced (using the system building process), as we have
seen, it is important to record the environment in which it was produced, including
the operating system, versions of the components used, and other parameters such

6518 Book.indb 62 12/30/14 1:24 PM

 Deltas63

as compile and link-edit options. This is important from the SCM point of view,
because at a later stage, it might become necessary to reproduce the exact configu-
ration that was released. For example, consider a bug that is discovered after the
system is released. The easiest way to find the source of the problem is to find out
what components were changed. The problem could be either due to a bug in one
of the changed components or due to some environmental variables being changed
(like some compiler or linker options). Accordingly, if we have a record of the com-
ponents and the environment details used for the release, then it is easy to track the
source of the defect. One merely needs to compare the details of the current release
with the previous release and see what has been changed. Thus, it is imperative that
a proper mechanism to record the details of each and every release be instituted.
A release to a client or a system release should contain identifiers indicating
the release or version number. It should also include a release note containing the
following information:

• Installation requirements (e.g., required operating system, memory, and pro-

cessor specifications);
• How to install the system and how to test the system to ensure that the instal-
lation was successful;
• How to upgrade from an earlier version of the system;
• The key or serial number of the product, if such a number is required for
installation;
• A list of known faults and limitations of the particular version of the system
and a list of the faults that were fixed in the current release;
• New features introduced in the release;
• Instructions for contacting the supplier of the system for technical support
or if problems arise.

Today, most of the above-mentioned activities, including the registration of the

product, are done by installation programs, so release notes are not as important
as they once were.

Deltas

In an ideal situation, all changes made to the CIs should be recorded and all of the
different versions of the items should be kept, because in a software system not all
users will be using the latest version. So, even though the system may be in version
6.0, some users will still be using version 1.0 or 2.1. Accordingly, CM systems should
be able to produce the details of the latest as well as past versions and to reproduce
the components of every version. For example, years after a system is released, a
request for a component in the first version can come up. Even if the system is cur-
rently in its seventh or eighth version, companies cannot ignore a client that still
uses the initial version.
Ideally, copies of all versions should be in a repository. However, this is not
practical, because of the amount of disk space required. Instead, we create what is

6518 Book.indb 63 12/30/14 1:24 PM

 64 SCM: Basic Concepts

Figure 5.6 Use of deltas.

known as a delta. When a new version is created, the difference between the new
and the previous version is called delta. With this method, instead of storing full
copies of all versions, one version and the deltas are stored, so that at any point in
time the required version can be derived by applying the relevant deltas to the base
version. Figure 5.6 illustrates the concept of deltas.
Deltas are smaller than the source code of a system version, so the amount of
disk space required for version management is greatly reduced. The two types of
delta storage are forward deltas and reverse deltas, as shown in Figure 5.7.

Figure 5.7 Forward and reverse deltas.

6518 Book.indb 64 12/30/14 1:24 PM

 SCM Database65

The principle of forward delta storage is that the system maintains a complete
copy of the original file. After this, whenever a new version is checked in, the two
versions are compared and a delta report is produced. Then, this delta report is
stored instead of storing the full copy of the new version. Whenever the new version
is required, the delta is applied to the original to get the new version.
In the case of reverse delta storage, only the most recent version of the module is
kept in the complete form. Whenever a new version is checked in, it is compared to
the previous version and the delta is created. Then, the previous version is deleted,
and the new version is stored.
The problem with forward delta storage is that as more revisions are added,
more computation is required to obtain the latest revision. So the greater the num-
ber of revisions, the longer the retrieval time will be. This is because in the case of
the forward delta, the change manager must always start with the original version
and then apply the deltas one at a time to create the latest version. In the case of the
reverse delta option, no computation is required to get the latest version, because
it is stored in its full form.
Using deltas is a classical space-time trade-off—deltas reduce the space consumed
but increase access time. However, an SCM tool should impose as little delay as
possible on programmers. Excessive delays discourage the use of version controls,
or induce programmers to take shortcuts that compromise system integrity.
The decision to go in for delta storage as opposed to storing copies of all versions
should be made with respect of amount of storage space required and cost of storage
and retrieval. With the cost of storage systems coming down, storing copies of all
versions can be considered, thus eliminating the need of deltas. Another factor that
decides whether or not to use delta storage is the accuracy in rebuilding the required
versions using the deltas vis-à-vis the cost of storage and the time taken to retrieve
an archived item from the backup mechanism. Whether to use delta storage or not is
a subject of debate among SCM professionals. In my opinion, if the complete copies
can be stored at a reasonable price and be retrieved as fast as recreating using the
delta storage, then it is better to eliminate delta storage or to limit it to text files.
The decision to go in for forward delta storage or reverse delta storage depends
on the nature of the project. If the latest versions are more frequently required,
then it is always better to use the reverse delta. In the real world, more than 75%
of archive accesses are for the latest version, and this explains the popularity of
reverse delta storage among the change management tools. Many tools also offer
the facility to use delta storage or keep the complete copies. So depending on the
nature, size, and type of CIs in the project, tool administrators can select a method
to suit their preference.

SCM Database

We have seen that the properties, characteristics, and interdependencies of the CIs
should be recorded in a database—the CM database. The CM database is used to
record all relevant information related to configurations. The principal functions
of such a database are to assist in assessing the impact of system changes and to
provide information about the SCM process. The CM database, in addition to the

6518 Book.indb 65 12/30/14 1:24 PM

 66 SCM: Basic Concepts

details about the CIs, contains information about change requests (which are also
CIs), their status, and information regarding the review and audit processes.
The contents and structure of the CM database should be defined during the
SCM system design stage and should be documented in the SCM plan. In modern
CASE environments, the configuration database is part of the system and the details
of the items are automatically recorded. In the case of manual SCM systems, the
details have to be entered manually into the system. The system should have neces-
sary precautions and safety mechanisms to prevent bypassing the procedures and
thus corrupting the data and making it useless. If a CI is added without an entry
in the database, then the integrity of the data in the database and the usefulness of
the database are lost.
A CM database should be able to provide answers to queries such as the following:
• What is the current configuration? What is its status?
• Which person has taken delivery of a particular version of the system?
• What hardware and operating system configuration are required to run a
given system version?
• How many versions of a system have been created and what were their cre-
ation dates?
• What changes have been made to the software, documentation, and other
items in the project? Who made them, and when were they made?
• Were the changes approved by somebody or just informally done?
• What versions of a system might be affected if a particular component is
changed?
• How many change requests are pending on a particular item?
• How many reported faults exist in a particular version?
• Can I recreate the original from the changed version or the changed version
from the original?
• Can I find out what happened to a specific item at some point in time, such
as what changes were made to it and so on?
• Does my change affect others?
With the increasing popularity of SCM tools, the necessity for a configuration
database is decreasing. SCM tools have their own repositories where they can store
SCM-related information. The advantage of these systems is that SCM informa-
tion is captured automatically as and when each activity is performed. So there is
no need to enter details manually in such situations as when a change request is
initiated, when an item is released, or when a change is made. This feature saves
considerable time and effort and reduces the chance of creating errors that can
occur during manual data entry. Also, with the facility to automatically capture
SCM information, such as when the activities happen, the SCM tool user has the
ability to capture comprehensive SCM information without any additional effort.

SCM Activities

Configuration identification, the first activity of CM, is the process of defining each
baseline to be established during the software life cycle and describing the software

6518 Book.indb 66 12/30/14 1:24 PM

 Summary67

CIs and their documentation that make up each baseline. First, the software must
be grouped into CIs. Once the CIs and their components have been selected, some
way of designating the items must be developed. This is done by the development of
a numbering and naming scheme that correlates the code and data items with their
associated documentation. Finally, each CI must be described by the documentation
in terms of its functional, performance, and physical characteristics.
Configuration control is the process of evaluating, coordinating, and deciding on
the disposition of proposed changes to the CIs and includes implementing approved
changes to baselined software and associated documentation. The change control
process ensures that changes that have been initiated are classified and evaluated,
approved, or disapproved, and that those approved are implemented, documented,
and verified.
Configuration status accounting is the process used to trace changes to the soft-
ware. It ensures that status is recorded, monitored, and reported on both pending
and completed actions affecting software baselines.
Configuration auditing is the process of verifying that a deliverable software
baseline contains all of the items required for that delivery and that these items have
themselves been verified to determine that they satisfy requirements.
We will examine these activities in greater detail in Chapters 6–9.

Summary

This chapter details the various CM concepts and SCM terminology. It explains
SCM activities and how they relate to one another. Further, it provides readers with
an understanding of the fundamental concepts of SCM such as versions, variants,
branching, merging, deltas, system building, and releases.
In today’s business environment, where competition is fierce and one has to
constantly improve and innovate to stay ahead of the competition, SCM can give
an organization a strategic advantage over its competitors. An organization that
uses SCM has a definitive edge over others that do not use SCM or that use it inef-
ficiently or ineffectively.

References

[1] IEEE, IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610–
1990), IEEE Standards Collection (Software Engineering), Piscataway, NJ: IEEE, 1997.
[2] Bersoff, E. H., V. D. Henderson, and S. G. Siegel, Software Configuration Management:
An Investment in Product Integrity, Englewood Cliffs, NJ: Prentice-Hall, 1980.
[3] Pressman, R. S., Software Engineering: A Practitioner’s Approach (5th Edition), New
York: McGraw-Hill, 2001.

Selected Bibliography

Babich, W. A., Software Configuration Management: Coordination for Team Productivity,

Boston, MA: Addison Wesley, 1986.

6518 Book.indb 67 12/30/14 1:24 PM

 68 SCM: Basic Concepts

Ben-Menachem, M., Software Configuration Guidebook, London: McGraw-Hill International,

1994.
Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons, 1992.
CM Crossroads™: The Configuration Management Community (http://www.cmcrossroads.
com/).
Conradi, R. (ed.), Software Configuration Management: ICSE’97 SCM-7 Workshop Proc.,
Berlin: Springer-Verlag, 1997.
IEEE Standards Collection, Software Engineering, New York: IEEE, 1997.
Magnusson, B. (ed.), System Configuration Management: ECOOP’98 SCM-8 Symp. Proc.,
Berlin: Springer-Verlag, 1998.
Pressman, R. S., Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill,
1997.
Sommerville, I., Software Engineering, Reading, MA: Addison-Wesley, 1996.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

6518 Book.indb 68 12/30/14 1:24 PM

 Chapter 6

Configuration Identification

Introduction

Configuration identification is the basis for subsequent control of the software con-
figuration. The software configuration identification activity identifies items to be
controlled, establishes identification schemes for the items and their versions, and
establishes the tools and techniques to be used in acquiring and managing controlled
items. These activities provide the basis for the other SCM activities [1].
The configuration identification process involves the selection, designation, and
description of the software CIs. Selection involves the grouping of software into CIs
that are subject to CM. Designation is the development of a numbering or naming
scheme that correlates the software components and their associated documenta-
tion. Description is the documentation of functional, performance, and physical
characteristics for each of the software components.
IEEE [2] defines configuration identification as an element of CM, consisting
of selecting the CIs for a system and recording their functional and physical char-
acteristics in technical documentation. In other words, configuration identification
is the process whereby a system is separated into uniquely identifiable components
for the purpose of SCM. This is the first major SCM function that has to be started
in a project (the design of the SCM system and the preparation of the SCM plan
are done before configuration identification begins). Effective configuration identi-
fication is a prerequisite for other SCM activities, all of which use the products of
configuration identification.
The software under control is usually divided into CIs, also known as com-
puter software CIs (CSCIs). A CI is an aggregation of software that is designated
for CM and is treated as a single entity in the SCM process. In other words, CI
is the term used for each of the logically related components that make up some
discrete element of software. A variety of items, in addition to the code itself, are
controlled by SCM. Software items with potential to become CIs include plans,
specifications and design documentation, testing materials, software tools, source
and executable code, code libraries, data and data dictionaries, and documenta-
tion for installation, maintenance, operations, and software use. For example, if a
system contains several programs, each program and its related documentation and
data might be designated a CI. Determining what characteristics must be captured
so that the properties and requirements of the product are correctly reflected is an
important decision.
The configuration identification process should capture all characteristics of
the software to be controlled—its content, the content of documents that describe

69

6518 Book.indb 69 12/30/14 1:24 PM

 70 Configuration Identification

it, the different versions as the contents are changed, the data needed for operation
of the software, and any other essential elements or characteristics that make the
software what it is. A CI can contain other CIs and these are sometimes referred
to as computer software components (CSCs) and computer software units (CSUs).
A CSC is a functional or logically distinct part of a computer software CI. CSCs
may be top-level (TLCSCs) or lower-level (LLCSCs). A CSU is the smallest logical
entity or the actual physical entity of the system.
The software product shall be organized as one or more CSCIs. Each CSCI is
part of a system, subsystem, or prime item and shall consist of one or TLCSCs. Each
TLCSC shall consist of LLCSCs or CSUs. LLCSCs may consist of other LLCSCS or
CSUs. TLCSCs and LLCSCs are logical groupings. CSUs are the the smallest logical
entities and the actual physical entities implemented in code. The static structure
of CSCIs, TLCSCs, LLCSCs, and CSUs shall form a hierarchical structure as illus-
trated in Figure 6.1. The hierarchical structure shall uniquely identify all CSCIs,
TLCSCs, LLCSCs, and CSUs.
To accomplish configuration identification, it is necessary to perform the fol-
lowing steps:

• Develop the criteria for selecting items to be placed under configuration

control.
• Select CIs and define the relationships between the CIs.
• Establish a software item hierarchy (structure and elements of the complete
software system) and define the interrelationships between the CIs. The

Figure 6.1 CSCI structure.

6518 Book.indb 70 12/30/14 1:24 PM

 Introduction71

structural relationships among the selected CIs, and their constituent parts,
affect other SCM activities or tasks, such as software building or analyzing
the impact of proposed changes. Proper tracking of these relationships is also
important for supporting traceability verifications.
• Develop an identification or naming scheme for identifying the CIs clearly
and unambiguously.
• Select configuration documentation to be used to define configuration base-
lines for each CI.
• Establish a release/version management system for configuration documentation.
• Define and document interfaces to and between CIs.
• Define and establish baselines to be used.
• Establish the procedure for a baseline’s acquisition of the items.
• Assign identifiers to CIs and their associated configuration documentation,
including version numbers where appropriate.
• Check that the marking or labeling of items and documentation with their
applicable identifiers enable correlation between the CI and other associated
data. The documents that capture the functional and physical characteristics
of the CI and the corresponding documentation will become part of the CI.
The naming of those items should be consistent with that of the CI for easy
association. For example, if the name of the documentation for a program
PGM XYZ is DOC XYZ it will help in better correlation.
• Ensure that applicable identifiers are embedded in the software and on its
storage media. For example, the source code of the program named PGM
XYZ can contain the name PGM XYZ. (Consider a COBOL program named
PGM XYZ; here the program name can be embedded in the source code as
PROGRAM ID in the IDENTIFICATION DIVISION.)

There are no hard and fast rules as to the order in which the above steps must
be performed. It depends on the organization, project, and the SCM system design-
ers and implementers.
EIA-649 [3] identifies configuration identification as the basis from which the
configuration of products are defined and verified; products and documents are
labeled; changes are managed; and accountability is maintained. Configuration
identification affords many benefits and purposes, including the following:

• To select products based on functionality, verifiability, supportability, com-

plexity, risk, and management activity;
• To determine the structure (hierarchy) of a product and the organization
and relationships of its configuration documentation and other product
information;
• To document the performance, interface, and other attributes of a product;
• To determine the appropriate level of identification marking of product and
documentation;
• To provide a unique identity to a product or to a component part of a product;
• To provide a unique identity to the technical documents describing a product;
• To modify the identification of product and documents to reflect incorpora-
tion of major changes;

6518 Book.indb 71 12/30/14 1:24 PM

 72 Configuration Identification

• Maintenance of release control of documents for baseline management;

• To distinguish between product versions;
• To correlate a product to related user or maintenance instructions;
• To manage information including that in digital format;
• To correlate individual product units to warranties and service life obligations;
• To correlate document revision level to product version/configuration;
• To provide a reference point for defining changes and corrective actions.

Impact of CI Selection

Selecting CIs is an important process that must achieve a balance between providing
adequate visibility for project control purposes and providing a manageable num-
ber of controlled items. Poor CI selection can adversely affect costs and scheduling
and can become an unnecessary administrative and technical burden during and
after software development. The number of CIs in a system is a design decision—a
decision made by the people who design the SCM system. They are the people who
decide which items should be brought under configuration control.
This process should be done carefully, because the selection of CIs needs to
be correct: You should not select more or less than what is necessary. However,
with the introduction of SCM tools, this issue—the number of CIs—is not very
important. Modern tools can efficiently and effortlessly handle any number of CIs
without any problems. Still, the tools can only reduce the workload of managing
the CIs; other problems, such as reduced visibility, too much documentation, and
inefficient design, cannot be solved by the tools. Hence, the selection of the CIs is
still important. Technology can only help do things like automating processes, per-
forming repetitive and monotonous tasks, and reducing the workload of managing
the CIs. The question of what items should be made into CIs is still a management
decision based on experience and judgment—a decision that can be made only by
a person or group of persons who have the required knowledge about the project
and who have the relevant experience and expertise.

Effects of Selecting Too Many CIs

Selection of too many CIs may result in hampered visibility and management rather
than improved control. Examples of such difficulties include the following:

• Increased administrative burden in preparing, processing, and reporting of

changes, which tends to be proportional to the number of CIs.
• Increased development time and cost as well as potential creation of an inef-
ficient design. When there are too many CIs, the documentation and other
procedures increase and take valuable time that could be devoted to design
and development. As a result, too many CIs will result in increased develop-
ment time, and once the concentration is shifted from design and develop-
ment to maintaining the SCM records, the chances of creating an inefficient
design arise.

6518 Book.indb 72 12/30/14 1:24 PM

 Baselines73

• Potential increase in management effort, difficulties maintaining coordina-

tion, and unnecessary generation of requirements, design, test, and system
specifications for each selected CI.

Effects of Selecting Too Few CIs

Too few CIs can result in costly logistics and maintenance difficulties, such as these:

• Loss of visibility down to the required level to effect maintenance or modifica-

tion. For example, if CIs are chosen only at the module level, then maintaining
a function in that module will be quite difficult, because finding the subrou-
tine will be difficult when there are not any records in that name. Because
the CIs are defined only at the module level, only the modules will be visible.
• Difficulty in effectively managing the changes (for example, managing changes
to individual items, which are part of a CI). If there are too few CIs, say, only at
the module level, then check-in and check-out and change implementation will
be difficult because check-out happens at the CI level, and a lot of unwanted
items will also need to be checked out, tested, verified, and checked back in.

Baselines

As the CIs go through their development process, more and more components are
developed until the final CIs are available for use. Generally, the life cycle process
will first result in a set of requirements, then a design, then code for individual ele-
ments of the CI, and then integrated code with test cases and user manuals. The
definition of SCM contains the concept of identifying the configuration of each CI
at discrete points in time during the life cycle process, and then managing changes
to those identified configurations.
The configuration of software at a discrete point in time is known as a baseline.
Thus, a baseline is the documentation and software that make up a CI at a given
point in its life cycle. It includes the user documentation (if any), the specifications
document (or the document that contains the functional and physical characteristics),
and software (if any) that make up the CI at a given point. Each baseline serves as a
point of departure or reference for the next development stage. Baselines are usually
established after each life cycle phase at the completion of the formal review that
ends the phase. Thus, we have the requirements baseline, design baseline, and prod-
uct baseline. Chapter 2, and specifically Figure 2.1, gives an overview of baselines.
Each baseline is subject to configuration control and must be formally updated
(using the change management procedures) to reflect approved changes to the CI as
it goes through the next development stage. A baseline, together with all approved
changes to the baseline, represents the current approved configuration. At the end
of a life cycle phase, the previous baseline and all approved changes to it become
the new baseline for the next development stage. The term baseline management is
often used to describe this control process. Baseline management is the discipline
of controlling a series of baselines as they evolve and are then merged into the next

6518 Book.indb 73 12/30/14 1:24 PM

 74 Configuration Identification

baseline to be defined. The SCM system provides the policies, procedures and tools
for exercising baseline management [4].
Baselines are established and placed under CM when it makes good management
sense to start controlling subsequent changes to the CIs. When to start baselining
is a management decision. Establishing a baseline does not mean that the software
development is brought to a halt. It only means that subsequent changes to the CIs
will be subject to formal change management procedures. Normally, the first base-
line consists of an approved software requirements document and is known as the
requirements baseline. The requirements baseline is the initial approved technical
documentation for a CI [2]. The requirements baseline contains the details regarding
what the system or software must accomplish. Through the process of establishing
a baseline, the requirements and other requirements described in the requirements
document become the explicit point of departure for software design. The require-
ments baseline is usually the first established baseline in the SCM process. When the
requirements baseline is established at the conclusion of the requirements analysis
phase of a project, the formal change control process commences. The requirements
baseline is also the basis against which the software is authenticated.
The design baseline is comprised of the initial approved specifications governing
the development of CIs that are part of a higher level CI [5]. The design baseline
represents the next logical progression from the requirements baseline and represents
the link between the design process and the development process. The requirements
baseline describes the functions that the system should have. Then, the software
system is designed by allocating the various functions to various components or
subsystems.
Based on the RDD (part of the requirements baseline), the different functions
of the software product are determined, and during the design process these vari-
ous functions—user interfaces, database operations, error handling, and input data
validation—are allocated to the various subsystems and components. This alloca-
tion of the different functionality happens during the design phase, and at the end
of the design phase the design baseline is established where the components of the
system would have their functionality assigned to them. So at the design baseline
stage, the functionality, or requirements defined in the requirements baseline, is
allotted to CIs in the form of design documentation (high-level and low-level),
which is now managed within the design baseline. So at the design baseline stage,
the functionality, or requirements defined in the requirements baseline, is allotted
to CIs in the form of design documentation (high-level and low-level), which is now
managed within the design baseline.
The product baseline corresponds to the completed software product delivered
for system integration. The product baseline represents the technical and support
documentation established after successful completion of the functional configura-
tion audit and physical configuration audit. The product baseline [6] is the initial
approved technical documentation (including source code, object code, and other
deliverables) defining a CI during the production, operation, maintenance, and
logistic support of its life cycle. The product baseline is sometimes known as the
deliverables baseline.
According to Ben-Menachem [4], the process of establishing baselines describes
the construction of the aggregates (the software system) from the components (the

6518 Book.indb 74 12/30/14 1:24 PM

 CI Selection75

CIs). So the baselines also define such things as how the aggregates must be con-
structed, what tools should be used, which parts are connected and which are not,
and what the nature of these interconnections is. As mentioned previously, once the
item is tied into a baseline, changes can be made only through the formal change
management process. Thus, baselines define the state of a system at a given point
in time, and the proper recording of this information is absolutely critical for the
success of any project.

CI Selection

A software system is generally split into a number of CIs that are independently
developed and tested, and then finally put together at the software system integra-
tion level. Each CI essentially becomes an independent entity as far as the SCM
system is concerned, and the SCM functions are carried out on each CI. The divi-
sion of the software into CIs may be contractually specified or may be done during
the requirements analysis or preliminary design phase. As a general rule, a CI is
established for a separable piece of the software system that can be designed, imple-
mented, and tested independently. Some examples of items that are to be identified
include project plan, requirements specifications, design documents, test plans and
test data, program source codes, data, object code, executables, EPROMS, media,
make files, tools, user documentation, quality manual, and SCM plan.
CI selection is not an easy process as there are no hard and fast rules to it. The
selection process should involve all the major stakeholders of the project—includ-
ing company management, software team leader, SCM administrator or manager,
QA representative, testers, maintenance and support team members (if identified),
and client representatives.

Checklist for Selection of CIs

When a software project or system is broken down into components (the structural
decomposition), we can create a sort of tree structure. The decomposition can be,
for example, project-modules-sub modules-programs-functions-link libraries-icons
and other small minor components and so on. Decomposition to this detail is neither
necessary nor advisable because it will create many problems in managing the CIs
and will create too many specifications and documentation. However, if we reduce
the number of CIs by limiting the system decomposition to, say, the second level
(module level), it will result in poor visibility of the overall design and development
requirements.
The number of CIs is determined by the system granularity desired by the SCM
system’s designers. The granularity decides the level of decomposition of the software
system. There are no hard and fast rules here. It varies from project to project and
is a decision that has to be made by the SCM system development team.
We have seen that there are no firm rules when choosing CIs, but the following
questions can be used as a guide:
• Is the item critical or high-risk or a safety item?
• Is the item to be used in several places?

6518 Book.indb 75 12/30/14 1:24 PM

 76 Configuration Identification

• Will the item be reused or designated for reuse?

• Is the system already a CI?
• Is the item borrowed from some other project or system?
• Would the item’s failure or malfunction adversely affect security, human safety,
or the accomplishment of a mission or have significant financial implications?
• Is the item individual, and can it be designed, developed, tested, and main-
tained as a stand-alone unit?
• Is the item newly developed? For example, a system or subsystem might be
developed to add certain requested enhancements.
• Will the item be maintained by diverse groups at multiple locations?
• Does the item incorporate new technologies?
• Is the item purchased off-the-shelf—COTS?
• Is the item supplied or developed by a subcontractor?
• Is the item highly complex, or does it have stringent performance requirements?
For instance, does the item have complicated algorithms, or does it need to
meet a stringent performance requirement such as having a small footprint?
• Does the item encapsulate interfaces with other software items that currently
exist or are provided by other organizations?
• Is the item installed on a different computer platform from other parts of the
system?
• Does it interface with other CIs whose configuration is controlled by other
entities, for example, a system that interfaces with an off-the-shelf package?
• Is it likely to be subject to modification or upgrading during its service life?
Is the item subject to modification at a rate that is much higher than that of
the other items? For example, consider an interface that reads data from some
external source. Every time the external source changes (assuming that data
formats will be subject to frequent changes), the item has to be modified.
• Is there a requirement to know the exact configuration and status of changes
made to an item during its service life? This refers to the criticality of the
item. Some items in a system are critical or more important than others. So
project management will necessarily be more interested in those types of items.
• Is the size of the item manageable? Can it be made by a small but efficient
development team in a reasonable time? If not, should it become two items
instead of one?

If the majority of these questions can be answered, “No,” the item should prob-
ably not be a CI. If the majority of questions can be answered, “Yes,” the item should
probably be a CI. However, there are no definitive rules and no magic formulas to
help in CI selection. The bottom line is that selection of CIs is a management deci-
sion based on experience and good judgment.

Designation: Naming of CIS

Each software component must be uniquely identified. According to IEEE [3], the
identification methods could include naming conventions and version numbers
and letters. The identification system or the naming convention should facilitate

6518 Book.indb 76 12/30/14 1:24 PM

 Acquisition of CIs77

the storage, retrieval, tracking, reproduction, and distribution of the CIs. A good
naming system will make it possible to understand the relationship between the CIs.
A good naming system uses numbers or alphabets to represent the position of
the CI in the hierarchy. For example, an item labeled 1.4 is definitely created after
an item with the label 1.2 and before one with the label 1.6. Note that the num-
ber is only a part of the name-the time–related part that changes when the item
undergoes revisions. The other part of the name, which defines the item, is usually
derived from the project or system and the type of the item and the item name. It
can be a simple name such as “PGMPAY” indicating that it is the payroll calcula-
tion program named PGMPAY or it can be a composite name like “PRJ_MOD
PGM_SRC PGMPAY” indicating the project, module, CI type, and name. The
decision on the complexity and detail of the names will depend on the size and
complexity of the project.
One important thing to remember is that the naming system should be developed
in such a way that the derived names do not produce duplicates, because this can
create chaos and confusion. For large and complex projects that have thousands of
CIs the naming system is usually quite detailed to facilitate easy identification and
tracking. As we have seen, the name part of the identification system will remain
constant over time for each item, whereas the number part will undergo changes.

CI Description

Software components are described in specifications (i.e., software requirements

specifications, software architectural design specifications, software-detailed design
specifications, interface control documents, and software product specifications).
The description of the component becomes more detailed as the design and devel-
opment proceeds through the life cycle. The description forms the basis for con-
figuration control and configuration status accounting. The description is also the
basis for the configuration audits and reviews, which ensure that the software is
complete and verified. The documents or portions of documents that describe each
CI must be identified and made part of the CI. I have frequently found a document
in use by several different companies (large and small) called the CI description (or
specification). Generally, it is not much more than a listing of CIs, by configura-
tion identifier, and an indication of the owner or programmer, next higher CI name
(parent), controlling baseline, fit into the hierarchy (CSCI, subsystem, or segment
name), and perhaps some other general information. This document forms a handy
reference for the CIs.

Acquisition of CIs

The last activity of the configuration identification function is the acquisition of

the CIs for configuration control. Following the acquisition of a CI, changes to the
item must be formally approved as appropriate for the CI and the baseline involved,
as defined in the SCM plan. This means that the CIs—both intermediate and final
outputs (e.g., source code, executable, user documentation, design documents,

6518 Book.indb 77 12/30/14 1:24 PM

 78 Configuration Identification

databases, test plans, test cases, test data, project plan, and SCM plan), and the
elements of the environment (such as compilers, operating systems, and tools)—
should be acquired and stored in a controlled environment (controlled software
libraries) so that they can be retrieved and reproduced when required and access can
be restricted. A software library is a controlled collection of software and related
documentation designed to aid in software development, use, and maintenance [4].
IEEE [6] specifies that for each such library the format, location, documentation
requirements, receiving and inspection requirements, and access control procedures
must be specified. Once the CIs are acquired and placed in the controlled library,
as we have seen, the configuration control procedures will apply to them.

Summary

Configuration identification is the process of selecting the CIs for a system and
recording their functional and physical characteristics in technical documentation.
We have seen why it is important to select the CIs, how to select them, and how
to establish baselines. Configuration identification is one of the important phases
of SCM, because it decides the level of granularity or detail to which SCM will be
performed in a project.

References

[1] Alain Abran, A., and J. W. Moore (eds.), SWEBOK: Guide to the Software Engineering
Body of Knowledge (Trial Version), Los Alamitos, California: IEEE Computer Society,
2001.
[2] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610–1990),
IEEE Standards Collection (Software Engineering), Piscataway, NJ: IEEE, 1997.
[3] EIA, National Consensus Standard for Configuration Management (EIA-649), Arlington,
VA: Electronics Industries Alliance, 1998.
[4] Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York:
John Wiley & Sons, 2002.
[5] Ben-Menachem, M., Software Configuration Guidebook, London: McGraw-Hill Inter-
national, 1994.
[6] IEEE Standard for Software Configuration Management Plans (IEEE Std-828–2012),
Piscataway, NJ: IEEE, 2012.

Selected Bibliography

Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons, 1992.
Dart, S., “Concepts in Configuration Management Systems,” Technical Report, Software Engi-
neering Institute, Carnegie-Mellon University, 1994.
Feiler, H. P., “Software Configuration Management: Advances in Software Development Envi-
ronments,” Technical Paper, Software Engineering Institute, Carnegie-Mellon University,
1990.

6518 Book.indb 78 12/30/14 1:24 PM

 Summary79

IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
Magnusson, B. (ed.), System Configuration Management: ECOOP’98 SCM-8 Symp. Proc.,
Berlin: Springer-Verlag, 1998.
Quality Management-Guidelines for Configuration Management, ISO 10007:1995(E), Geneva,
International Standards Organization, 1995.

6518 Book.indb 79 12/30/14 1:24 PM

6518 Book.indb 80 12/30/14 1:24 PM
 Chapter 7

Configuration Control

Introduction

IEEE [1] defines configuration control as an element of CM, consisting of the evalu-
ation, coordination, approval or disapproval, and implementation of changes to CIs
after formal establishment of their configuration identification. So once the CIs of
a project or system have been identified, the next step is to bring in some degree
of control. Restrictions have to be implemented, and rules regarding who can do
what to these CIs have to be formulated. This aspect of SCM is handled by the
configuration control function or the “change management and control system.”
Changes to all items identified in the configuration identification phase—CIs—
should be controlled. To properly control change, procedures have to be established,
guidelines have to be implemented, roles and authorities have to be defined, and all
workflow processes of the change management system—including change identifica-
tion, change requisition, change approval or disapproval, change implementation,
and testing—have to be designed, documented, and implemented. How these pro-
cedures and guidelines apply to the different CIs such as source code, documents,
specifications, third-party software, and subcontracted items also has to be estab-
lished. These activities fall under the purview of configuration control.
Of the SCM functions, configuration control is the one that is performed most
often. Configuration identification, as we saw in Chapter 6, is done only once at the
beginning of the SCM implementation. Status accounting, which is the recording and
reporting of the SCM activities, is done on a regular basis. Configuration audits are
performed when a configuration is complete or before a system is released. However,
the configuration control activities have to be done whenever a change request (CR)
is initiated. Requests for changes will be quite frequent during the software develop-
ment phase and after the system is released. Requests for new features, functional
enhancements, and bug and defect reports can all initiate a change.
The different activities of configuration control lend themselves to automation.
For example, all activities from change initiation to change disposition can be easily
automated. Thus, configuration control is one SCM function that can be automated
very efficiently and effectively. In fact, it is imperative that one use some sort of
change management tool, because except in the case of very small single-person
projects, change management and control is too repetitive and monotonous, and
hence, more prone to error and not worth the effort for manual processing. Many
software tools are available—covering almost all available platforms and develop-
ment environments—to automate configuration control. In fact, it was one of the

81

6518 Book.indb 81 12/30/14 1:24 PM

 82 Configuration Control

first functions of CM that was automated, which is evident from the number of
change management tools available on the market.
Configuration control is not an easy task. It involves a lot of people and a lot of
procedures, making it difficult to manage. The configuration control activities will
increase as the project evolves, because more and more items will undergo change,
more and more people will be inducted, requirements will change, new modules
and subsystems will be added, and different versions will have to be maintained—
among other challenges. However, if designed intelligently, planned properly, and
supported well by a good software tool it can be an easy, if not exciting, task.

Change

Change is one of the most fundamental characteristics in any software development

process. All phases of the software development process from requirements analysis
to production or maintenance are always subject to change. Making changes to soft-
ware is easy. In fact, it is one of best features of software—that it can be changed
at will. However, if changes are made at will, without any proper planning, chaos
will result. Making changes is easy; managing those changes—the uncontrolled
changes—is not, because there is no way of knowing what was changed and hence
what to manage.
Software development is a continuously evolving process. You cannot freeze
one phase of software development and then go to the next phase. Even though
early development models like the waterfall model were developed based on the
compartmentalization of the various phases, the real-life situation is quite differ-
ent. You cannot freeze analysis and go to design and freeze design and then go to
development. A great deal of overlap occurs between these phases. This is because
software development is a complex process that involves many variables, all of which
can change. Changes to the requirements drive the design, and the design changes
affect the code. Testing then uncovers problems that result in further changes, which
might force us to return to the requirements phase. So change is something that
cannot be avoided. Managing the change process is a complex but essential task.

Proposing Changes to the Customer

In some instances, a change affects the customer’s agreement with the developer.
These changes (sometimes known as major changes) can affect the terms and con-
ditions of a contract or purchase order related to cost, delivery schedules, or other
milestone events. Other changes can affect the statement of work, specifications,
or other requirement documents to which the customer has asked the developer to
adhere. Thus, when these types of changes occur, a CR is prepared and submitted
to the customer for approval.
Incorporation of such proposed changes cannot be implemented until the cus-
tomer has given approval to do so. The procedure for processing these changes is
the same as the normal change management procedures (Figure 7.1). A point to
remember is that once a major change is approved, it is actually an amendment to

6518 Book.indb 82 12/30/14 1:24 PM

 Change and Configuration Control83

the developer’s contract. In addition, the customer normally pays for the cost of
preparing the changes and incorporating them into the system and conducting the
prescribed tests. Such changes may also require reidentification of the change units
or modules and may, in addition, affect those of which they are a part.

Deviations and Waivers

In addition to changes that may affect the functionality of the software product,
developers may also run into situations where they must deviate from the prescribed
specification due to a temporary inability to meet a given requirement. The con-
straints imposed on a software development effort or the specifications produced
during the development activities might contain provisions that cannot be satisfied
at the designated point in the life cycle. The customer may approve such deviations
up to an agreed on point in time or in some instance may approve a permanent
deviation without requiring a major change to be submitted.
A deviation is an authorization to depart from a provision prior to the develop-
ment of the item. A waiver is an authorization to use an item, following its develop-
ment, that departs from the provision in some way. In these cases, a formal process
is used for gaining approval for deviations to, or waivers of, the provisions [2].
Waivers may also be granted to cover temporary problems in meeting specifica-
tions or contract requirements. Instances include delivery of the product without
having completed all the prescribed testing or delivery of the product without cer-
tain units or modules included, due to a delaying action. A waiver, however, has a
specified time factor that must be met in order to satisfy contractual or agreed on
requirements. The procedure to be followed when requesting for authorized devia-
tions and waivers are normally specified in the contract or agreement.

Change and Configuration Control

Change is inevitable during the software development life cycle. Changes to soft-
ware come from both external and internal sources. External changes originate
from users, from evolution of operational environments, and from improvements
in technology, among other factors. Internal changes come from such impetuses as
improved designs and methods, incremental development, and correction of errors.
A properly implemented configuration control process is the project manager’s best
friend and provides potential salvation when coping with change.
Configuration control (or change management and control) is thus the process
of evaluating, coordinating, and deciding on the disposition of proposed changes
to the CIs and implementing the approved changes to baselined software and asso-
ciated documentation and data. The change control process ensures that changes
that have been initiated are classified and evaluated and approved or disapproved
and that those that are approved are implemented, documented, tested, verified,
and incorporated into a new baseline.
Configuration control is the set of techniques used to ensure that the components
in a system achieve and maintain a definite structure (where the relationships between

6518 Book.indb 83 12/30/14 1:24 PM

 84 Configuration Control

the components are established) throughout the system life cycle. To this end, change
management and control provide the necessary procedures, documentation, and
organizational structure to make sure that all items identified in the configuration
identification phase, the details of the changes made to them, and other related
information are available to all who need to see it (or have the necessary authority)
throughout the system life cycle. In other words, configuration control provides the
necessary mechanism to orchestrate change—but in a controlled manner.

Problems of Uncontrolled Change

We have seen that uncontrolled or unmanaged change can create problems serious
enough to create project failures. In its mildest forms, these changes can create con-
fusion and chaos. Change management and control solves the four most common
(and dangerous) software development and maintenance problems: communications
breakdown, shared data, multiple maintenance, and simultaneous update problems.
In any development environment, the same code, say a program, function, or
subroutine, is often shared by different programmers. This sharing of common
items—source code or data or documentation—reduces development costs because
it avoids the problem of reinventing the wheel. If a function or a program or a com-
ponent library that suits one’s needs is already available, then it is prudent to use
it, rather than coding it again. Similarly, in the case of documentation, such as an
RDD or SDD, the entire project uses the same document. So, what is wrong with
sharing data, code, or documents? As long as nobody makes any changes to these
shared items, there are no problems. However, if changes are made to any shared
item without a proper control mechanism, trouble can arise, as detailed in Chapter 3.
In the case of a properly implemented change management system, all changes
made to the components of a software system are made after proper analysis and
review. Because changes can be made only with proper authorization, and since
the authorization is done by a separate entity that is responsible for managing the
changes to all the items, the chances of effort getting duplicated or two people solv-
ing the same problem in isolation do not occur. Also, the problem of one person
overwriting another person’s efforts does not occur, because the changes are made
to items that are stored in a controlled environment, where records of who is mak-
ing changes to what items are kept. Accordingly, if a person is making changes on
an item, that fact is known to all the people in the project. Also, the information
regarding a change is reported to all concerned. Thus, a good change management
system solves the abovementioned software problems and can bring discipline into
the development process and improve development productivity, because a lot of
time that would otherwise be spent on debugging and reworking can be saved. The
following sections describe how this is accomplished.

Configuration Control

We have seen the dangers and problems of unmanaged and uncontrolled changes.
So how do we to avoid them? We should have a good change management and

6518 Book.indb 84 12/30/14 1:24 PM

 Configuration Control85

control system. The system should define a process and the necessary procedures
to ensure that all events—from the identification of a change to its implementation
and baselining—are done in a systematic, scientific, and efficient manner (i.e., fol-
lowing SCM principles).
To make this happen, procedures should be established for requesting a change
once the need has been identified and people authorized to decide whether the
requested change needs to be implemented. Once the decision to implement the
change has been made, a mechanism should be in place for analyzing which other
resources are affected by the proposed change and then assigning the task of effect-
ing the change to the resource (and if necessary to any impacted resources). The
necessary facilities to test, verify, and validate the changed resources also need to be
in place; in other words, the changed function or program needs to be tested, veri-
fied, and approved so that it can be incorporated or promoted as the new version.
An orderly change process is necessary to ensure that only approved changes are
implemented into any baselined document or software. Figure 7.1 shows a simple
overview of the change management and control process. The steps mentioned here
are very generic and will vary from one company to another and even from one
project to another.
The steps within the overall process can be grouped into the following categories:

• Change initiation;
• Change classification;
• Change evaluation or change analysis;
• Change disposition;
• Change implementation;
• Change verification;
• Baseline change control.

These seven steps in change control are individually discussed in the following
sections. We will first look at how configuration control is done manually. As a
minimum, it is suggested that the following data elements always be included (as
applicable) in any change control communication:

• Project name, date, requestor name, and priority (high, medium, or low);
• Name, number, and description of element(s) needing change;
• Description of change(s) required or made;
• Suggested fixes or fixes made with supporting data if needed;
• Disposition of change by a review board or person;
• Approval signatures of review board or person;
• Date of incorporation;
• Date of verification of the incorporated changes.

If one is using a change management tool or SCM tool, then most of these
processes will be done automatically. For example, processes such as the change
requisition, verification of the details, assignment of CR numbers, intimation of the
CR evaluators, intimation of the change control board members, voting on the CR,
and informing the result could be done automatically. Project managers should be

6518 Book.indb 85 12/30/14 1:24 PM

 86 Configuration Control

Figure 7.1 Overview of change management and control process.

careful, however, when selecting a tool that the one under consideration fits the job
at hand and that the project team does not have to change form, fit, and function
of the job to fit the tool. There are any number of consultants and tool reference
guides available to help a project or firm, select the type of tools that will enhance
productivity and maintain good change control. This topic is detailed in Chapter 15.

Change Initiation
Requests for change to software and documents come from many sources. A CR
can be submitted by the developer, a member of the QA team, a reviewer, or a user.
Each project should set up a CR form for documenting the proposed change and
its disposition. Sometimes a CR is also called a problem report (PR) or a specifica-
tion change notice (SCN).

6518 Book.indb 86 12/30/14 1:24 PM

 Configuration Control87

Problem reports, which we will discuss later in the chapter, are a special kind
of CR where the cause of the change is a defect or bug in the system. However,
problem reports necessitate change, so the procedures for resolving problem reports
and for requesting an enhancement or a new product feature are the same. Fig-
ure 7.2 shows a sample CR form. The sample contains the basic information that
should be included in a CR/PR/SCN form; however, the actual form for a particular
project must correspond to the planned SCM process. Note that electronic forms,
containing the same information, are being used increasingly as direct interfaces
to SCM support tools.
Each project should also name an individual—the CM officer (CMO) or a mem-
ber of the SCM team—to receive the CR form, assign it a tracking number, and
classification, and route it for processing. This person receives the CR and reviews
it for clarity and completeness. If the CR is not complete, it is returned to the origi-
nator. Once complete, the CR is assigned a unique identifier for tracking purposes,
and the information about the CR is recorded in the CR tracking database or files.
In an automated environment the elements of the CR form are available online
and simply require the originator to bring the form up and enter the necessary data.

Figure 7.2 Sample CR form.

6518 Book.indb 87 12/30/14 1:24 PM

 88 Configuration Control

There are many ways to make this easier than the manual entry, especially when
redlining the changes to be made on a source or object listing.

Change Classification
Changes to software and associated documentation are classified according to the
impact of the change and the approval authority needed. Depending on the critical-
ity, impact, and cost involved, there will be a hierarchy of people who can approve
the changes. At the top of the hierarchy is the CCB, which is detailed later in this
chapter. Major changes need the approval of the CCB, whereas minor changes can
be done with the approval of the project manager or development manager. This
is usually done to speed up (fast-track) the change management process. The exact
mechanism of the change classification and the approval should be defined in the
SCM plan. (See Chapter 13 for more on SCM plans.)
The changes are classified into different categories with different priorities. Clas-
sification methods can be based on such factors as severity, importance, impact,
or cost involved. For example, a CR for fixing a bug that could result in system
failure will have higher priority than a request for a cosmetic change. A functional
enhancement request that comes from a user may not be in the same category as a
CR from a member of the development team. However, the classification criteria
(how to classify a change) should be spelled out very clearly in the SCM plan.
The individual who proposes the change may suggest a classification for that
change. The CMO or the receiving authority reviews suggested classes and assigns
a working or tentative classification. After assessment of the impact of the CR, the
CCB or the approving authority will assign the final class.

Change Evaluation/Analysis
One important aspect of the configuration control process is that it provides adequate
analysis of changes in terms of impact to system functionality, interfaces, utility, cost,
schedule, and contractual requirements. Each change should also be analyzed for
impact on software safety, reliability, maintainability, transportability, and efficiency.
The project CMO routes the CR to the software engineering staff for evaluation.
In some cases, project procedures require that the CR be screened before it is
analyzed. Some CRs will not have any chance of approval due to considerations
(e.g., costs or schedules) of which the change initiator may not be aware. In some
cases, management may decide not to take any action in the case of changes that
fall into some category or meet some predefined criteria. This information might not
be or need not be communicated to all the people involved in the project. So when
such CRs—the CRs that do not have any chance of approval are submitted—they
will get rejected in the pre-evaluation screening itself. This approach saves the cost
of analysis for changes that do not have any chance of approval.
The analysis produces documentation (like that shown in Figure 7.3), which
describes the changes that will have to be made to implement the CR, the CIs and
documents that will have to be changed, and the resources required to effect the
change. This documentation becomes part of the change package, along with the
CR. After completion of the analysis, the change package is sent to the CCB.

6518 Book.indb 88 12/30/14 1:24 PM

 Configuration Control89

Figure 7.3 Sample change analysis document.

Change Disposition
Disposition of changes to baselined items are usually done by a CCB. The CCB
evaluates the desirability of a change versus the cost of the change, as described in
the documentation of the analysis. The CCB may approve, disapprove, or defer a CR.
Sometimes the CCB may have to request more information and additional analysis.
Items for which decisions have been made are sent to the CMO for action.
Rejected items are sent to the originator along with the CCB’s rationale for rejec-
tion. CRs needing further analysis are sent back to the analysis group with the
CCB’s questions attached. Deferred CRs are filed, to be sent back to the board at
the proper time.
Remember that the CCB may not be the change approving/disapproving author-
ity in all cases. In some cases the project leader, the CMO, or any other designated
person could make the decision. The exact mechanism of change disposition varies
from one organization to another and will be usually documented in the SCM plan.
The CMO sends approved items to the development team. The CMO also pre-
pares and distributes the meeting minutes and records the current status of the CR.
This information is added to the tracking database or recorded in files.

6518 Book.indb 89 12/30/14 1:24 PM

 90 Configuration Control

Today, with the use of change management tools, physical CCB meetings are
rare. In today’s development environment, e-mail or some other messaging system
connects everybody in the organization. So it is possible to hold CCB meetings with-
out the CCB members actually meeting. The CRs and the necessary information
(such as evaluation reports and impact analysis reports) can be sent electronically
to all CCB members, and the CCB members can convey their responses in the same
way. Thus, today it is possible to hold virtual CCB meetings and have online voting
on CRs. The SCM tools make change disposition and management an easy task.

Change Implementation
Approved CRs are either used directly as a change authorization form or result in a
change directive being prepared by the CMO. In either case, approval results in the
issuance of instructions that authorize and direct the implementation of the change
in the software and associated documentation.
The development team schedules the resources to make the change. It must get
official copies of the baselined component to be changed from the program library.
For code changes, design has to be developed, code has to be written, testing has to
be done, and the correctness of the change has to be verified. Moreover, the asso-
ciated documentation has to be revised to reflect the change. Once the change has
been made and local testing completed, the revised component and documents are
returned to the control of the program library. After verification, the new version
takes its place in the sequence of baselines.

Change Verification
The implemented changes, which have been tested at the unit level, must be veri-
fied at the system level. This may require the rerun of tests specified in the test
plan or the development of additional test plans. Regression testing will usually
have to be included in the test to ensure that errors have not been introduced in
existing functions by the change. Once the verification is complete, the review-
ing team submits evidence of it to the program library, which will then accept
the changed items for inclusion in the SCM controlled files that make up the new
version of the baseline.
After the successful implementation and testing of the change described in
the CR, the CMO will record the occurrence of this process into the CR track-
ing database or files. Also, a change history (or patch history) is maintained. The
change history is a recording of the events that occurred to an item from the state
before change to the one after. The details to be incorporated include (but are not
limited to) name of the originator and receiving authority, date received, name of
the individual who performed the analysis, date of analysis, approving authority’s
name, date, names of the persons who effected the change, testing, review and audit,
reasons for change, and a short description of change.
If an SCM or change management tool is used, then such steps as the process
of recording the change implementation information and the task of changing the
status of the CR do not have to be done manually. All of these activities will be
taken care of by the tool. As mentioned before, the tools capture all the information

6518 Book.indb 90 12/30/14 1:24 PM

 File-Based versus Change-Based Change Management91

as the events are happening and will record them automatically. So, details such as
when the change was initiated, when it was evaluated, when it was reviewed, who
initiated the change, who reviewed it, who approved it, when the implementation
started, when it was finished, and who performed the implementation will auto-
matically be captured by the tool. Accordingly, in a project where SCM tools are
used the abovementioned activities (the activities that are performed by the CMO or
SCM team members in a manual SCM system) are done automatically and without
human intervention. However, all these features—the complete automation of the
change control process—are available only in the more advanced and sophisticated
SCM tools.

Baseline Change Control

Changes to software are not complete until the code and data changes have been
implemented and tested, the changes to associated documentation have been made,
and all of the changes have been verified. To minimize the number of versions and
the frequency of delivery of software components, changes to software are usually
grouped into releases. Product release is the act of making a product available to
its intended customers [3]. Each release contains software and documentation that
has been tested and controlled as a total software system.
There are other reasons for product releases. One would be to satisfy a customer
by customizing a software system to meet the specific needs of that customer. This
is called a customer-specific release. For properly incorporating emergency fixes (a
fix that was done without following any change management procedures due to the
urgency of the problem or situation), a release might be made after the emergency
fix has been properly incorporated. Alpha and beta releases are also used for alpha
and beta testing.
Companies also do major and minor releases. Major releases are done when
there is a significant increase in the product’s functionality, whereas minor releases
are done when the release is to correct a bug or fault in the program or system. The
decision on the when and how of the releases is usually made by the CCB, because
it is the ultimate authority for making decisions about configuration control and is
represented by all functions of the organization.

File-Based versus Change-Based Change Management

In a file-based change management system, to make a change the change initiator

identifies the file he or she wants to change and initiates the change management
process. The CR is then analyzed, the impacted files are identified during the CR
evaluation phase, and the decision to approve or reject the CR is made. If the CR is
approved then the file (or files if more than one file is impacted) is checked out and
the necessary changes are made to it. Then the file is tested, verified, and checked
in. Thus, if there is more than one file for the same CR then they are not associated
with one another except for what is recorded in the evaluation report.
The major drawback of the file-based system is that it fails to capture the relation-
ships between the items that are changed due to a CR. In real life, a typical change

6518 Book.indb 91 12/30/14 1:24 PM

 92 Configuration Control

is rarely limited to a single file; in most cases more than one file needs to be changed
to implement a CR. However, the problem with a file-based change management
system is that once the files are checked in there is no way to determine which files
were modified as a result of a particular CR. Yes, the person who has implemented
the change might know or there might be some informal records somewhere, but
there are no formal methods to track all the files that were modified in response to
a single change or CR. This creates a lot of problems, because people often forget
the details of all the files they changed and often forget to include some of them
during the system building, resulting in build failures.
To avoid the drawbacks of file-based change management, SCM practitioners
started to use change-based change management. In this system, all the files required
to perform a task or to implement a CR are considered to be a single entity. Here
we are tracking logical changes rather than individual file changes. However, the
technology of making all the files of a CR into a single logical unit is not new.
Some mainframe systems tracked changes in this manner as early as the 1970s,
and companies such as IBM, Control Data Corporation, Unisys, and Tandem have
used logical change-based software tracking systems for years [4]. In 1983, SMDS
(now True Software) released Aide-de-Camp as the first commercial SCM system
that tracked logical changes rather than physical file changes [5].
Since then, many commercial SCM systems have added the ability to track logical
changes rather than individual file changes, including Synergy/CM from Telelogic
AB, AllFusion Harvest CM from Computer Associates, Dimensions from Merant,
and ClearCase from Rational. SCM tools like Merant’s PVCS and StarBase’s StarT-
eam have the ability to mark a source code change with the corresponding defect
report or enhancement request.
The method of tracking software by units of logical change is a more logical
and practical model, because the items that are changed because of a single CR are
logically linked. They are checked out together, they are tested together, they are
reviewed and approved as a group, and they are checked in and promoted together.
According to Weber [6], not all SCM systems use the same name for the logical
unit of change. For example, ADC/Pro uses the term “change set,” AllFusion Har-
vest CM uses “package,” Synergy/CM and Dimensions use “task,” CIearCase uses
“activity,” PCMS uses “work package,” and StarTeam uses “subproject.”
Furthermore, not all SCM systems implement the ability to track changes in
the same way. Two very different implementations have emerged—change sets and
change packages. Systems that treat a logical change as the individual lines of code
typically refer to the unit of change as a change set. Systems that treat a logical
change as the set of file versions that contain the code changes are called change
packages. For a detailed discussion of change sets and change packages, readers
should refer to the following texts:

• Burrows, C., S. Dart, and G. W. George, Ovum Evaluates: Software Con-

figuration Management, London: Ovum Limited, 1996.
• Cagan, M., and D. W. Weber, “Task-Based Software Configuration Man-
agement: Support for ‘Change Sets’ in Continuus/CM,” Technical Report,
Continuus Software Corporation, 1996.

6518 Book.indb 92 12/30/14 1:24 PM

 Emergency Fixes93

• Weber, D. W., “Change Sets Versus Change Packages: Comparing Implementa-

tion of Change-Based SCM,” Proc. 7th Software Configuration Management
Conf. (SCM7), Boston, MA, May 1997, pp. 25–35.
• Weber, D. W., “Change-based SCM Is Where We’re Going,” Technical Report,
Continuus Software Corporation, 1997.

Escalation and Notification

Escalation can be defined as the process of increasing the intensity or magnitude

of an issue. In the change management process, there are times when issues need
escalation. For example, consider a CR for which the evaluation report was for-
warded to all CCB members for their decision. If a CCB member has not conveyed
a decision within the specified time period, then the person has to be reminded
about it. However, if, even after the reminder, nothing happens, then the issue has
to be brought to the attention of the senior member of the CCB, so that necessary
corrective action can be initiated.
The escalation process is equally applicable for most of the change management
processes such as change evaluations, impact analysis, and change implementation.
Also, we have seen that the CRs can be accepted, rejected, or deferred. In the case of
deferred CRs, a time period can be set after which it has to be revisited. So once the
specified time is over, the CR is again reviewed. This process of keeping track of the
deferred CRs and then bringing them back for review is another form of escalation.
Today’s change management tools are capable of performing problem escalation
and notification automatically based on predefined rules and criteria. For example,
the change management tools could be programmed to escalate an issue (like failure
to convey the decision on a CR) after a specified number of days.
Multiple levels of escalation are also possible. For example, if the CCB member
fails to respond to the reminders, then the issue could be escalated to his or her
superior, and if there is still no action after a specified period, the next person in the
organizational hierarchy could be informed about the issue. Here, such factors as
the levels of escalation, the time period before escalation, and the people who are to
be informed can be predefined, and the tools will do the rest. This is an important
aspect that will improve the efficiency and productivity of the SCM team, since
it will not have to keep track of each and every CR; the tools will automatically
perform the necessary actions when something is not happening according to the
rules and schedules.

Emergency Fixes

Some CRs or problem reports need immediate action and will not allow enough
time to follow all change management and control procedures. For example, an
emergency request from a client or a distress call from a customer cannot wait for
steps such as the change evaluation, CCB meeting, or change disposition. Efforts
to correct these difficulties are referred to as emergency fixes. These are not change

6518 Book.indb 93 12/30/14 1:24 PM

 94 Configuration Control

management processes in the conventional sense, because the sole focus of an emer-
gency fix is to resolve the customer’s difficulties right away. The most important
distinction is that these emergency fixes invalidate the version of the components
that they fix, because they are temporary measures taken when there is not enough
time or resources to process them in the proper manner. When time permits, these
emergency fixes will be taken through the proper change management procedures
and the required tasks will be completed.

Problem Reporting and Tracking

We have seen how the change management and control process works, starting with
the initiation of the CR and the subsequent processing to effect the change. A CR
can result from many things. It can be the result of a user needing a new feature, it
can be the result of some enhancements of the existing functionality, or it can be due
to an anomaly in the software system. An anomaly is any condition that deviates
from expectations based on such information as that contained in the requirements
specifications, design documents, or user documents, or someone’s perceptions or
experiences. Anomalies may be found during, but not limited to, the review, test,
analysis, compilation, or use of software products or applicable documentation
[7]. In common usage, the terms error, fault, flaw, gripe, glitch, defect, problem,
and bug are used to express the same meaning. In this section we deal with PRs or
software PRs (SPRs). The SPR or PR is a type of CR—a request that is the result
of an anomaly in the system.

Problem Reports and CRs

An SPR usually will get more and quicker attention than a CR because it is the
result of a problem that has to be fixed. It is not some cosmetic change that can
wait. Also, a single SPR can create or result in more than one CR. This is because
a problem or bug (for example, navigation not working properly) can be the result
of faults in two different subsystems that require different skills to fix and thus
need two different persons or teams to do the job. Moreover, it might be better to
keep the two subsystems separate if there are no direct relationships or dependen-
cies between the two. Accordingly, it is quite possible that a PR or SPR can initiate
more than one CR.
We saw that SPRs can result in one or more CRs. In the author’s opinion, the
disposition of a fault or PR should follow the same process as that of the enhance-
ment requests once the CRs associated with the PR have been created. In other
words, the processing of the PR and the enhancement request become the same.
In the case of a PR, however, before the creation of the CR and after the change
management process is set into motion, some activities need to done. These activi-
ties are intended to prevent the same type of mistakes from recurring and to create
a knowledge base of the anomalies. Figure 7.4 shows the problem reporting and
tracking process.

6518 Book.indb 94 12/30/14 1:24 PM

 Problem Identification95

Figure 7.4 Problem reporting and tracking process.

Problem Identification

We know that a problem, bug, or defect can go undetected and can remain in the
software system. It is not possible to say that a software system is 100% defect-free.
Nevertheless, we need to try to reduce the number of defects in a system and, more
importantly, reduce the number of critical defects. We know about the existence of
a defect when, for example, something goes wrong, the system starts misbehaving,
the performance of the system is not what it is supposed to be, or the system stops
performing.
Once the problem is identified, it should be reported and fixed, and the fixed
version should be reviewed, approved, and baselined. So, the first step after the
detection of an anomaly or defect is to report it. Figure 7.5 shows a PR form. PRs
are usually handled by the SCM team, so the PR is also received by the CMO or a
representative of the SCM team. Once the PR is received, it is checked for clarity
and completeness and if the necessary details are specified, the PR is assigned a PR
number. This number serves as the identifier for the PR.
Once the problem is known and the report is received, the report is given to
qualified professionals (people from the project team or QA department who have
the necessary technical knowledge of the system and the problem analysis method-
ologies) for analysis. These people will analyze the problem with the objective of
determining the severity of the problem; its nature; its impact; the cause, the cat-
egory; its place of origin; the items affected; and the cost, time, and skills required
for fixing the problem. The analysis will also classify the defect (based on its seri-
ousness and impact) and will create the CRs for fixing the problem. As mentioned
previously, a PR can result in more than one CR.
The analysis team will report their findings in the problem analysis document.
Figure 7.6 shows a sample problem analysis document. This document forms the

6518 Book.indb 95 12/30/14 1:24 PM

 96 Configuration Control

Figure 7.5 Sample PR form.

basis of causal analysis, which is discussed later in this chapter. The CRs that are
created as a result of the problem analysis are processed as discussed in the previ-
ous sections.

Defect Classification

The classification of a defect is dependent on the phase in which it occurs. The fol-
lowing is a general classification of defects during the various phases of a project.

Requirements Analysis
• Incorrect requirements. This occurs when a requirement or part of it is incor-
rect. This may result from a misunderstanding of the user expectations.
• Undesirable requirements. The requirement stated is correct but not desirable
due to technical feasibility, design, or implementation cost considerations.

6518 Book.indb 96 12/30/14 1:24 PM

 Defect Classification97

Figure 7.6 Sample problem analysis report.

• Requirements not needed. The user does not need the stated functionality
or feature. Adding this requirement does not significantly increase the utility
of the project.
• Inconsistent requirements. The requirement contradicts some other
requirement.
• Ambiguous or incomplete requirements. The requirement or part of it is
ambiguous. It is not possible to implement the stated requirement.
• Unreasonable requirements. The requirement cannot be implemented due to
cost, hardware, or software considerations.
• Standards violation. The standards set for analysis have not been followed.

Design Phase
Design defects may relate to data definition, the user interface, the module inter-
face, or processing logic. Each of these may be incorrect, incomplete, inconsistent,
inefficient, or undesirable, or they may violate standards.

6518 Book.indb 97 12/30/14 1:24 PM

 98 Configuration Control

Coding and Testing Phase

Coding and testing defects may relate to such factors as logic, boundary conditions,
exception handling, performance, documentation, and standards violations.
The above classifications are very general, and depending on the nature of
the project and degree of detail required, a defect classification system should be
designed for each project.

Defect Severity

Severity of a defect is a measure of the impact of the defect. During the analysis,
design, and coding phases the defects might be classified as follows:

• Major defects, which have substantial impact on several processes or subsys-

tems. The correction activity involves changing the design of more than one
process or subsystem.
• Minor defects that impact only one process or subsystem. The correction
activity will be local to that process or subsystem.
• Suggestions toward improvements.

During the testing phase the defects may be classified as follows:

• Critical. These are errors that cause system failure.

• Fatal. These are fatal errors that result in erroneous output.
• Nonfatal. These are errors that are not fatal but will affect the performance
or smooth functioning of the system.
• Cosmetic. Minor errors like cryptic error messages or typos in messages,
screens, or user documentation.

During problem analysis, the analysis team classifies the defect, decides on its
severity, and records these findings in the problem analysis document.

Defect Prevention

The primary objective of the problem report is to identify the fault and fix it. The
problem analysis and CR generation and change management process achieve this.
The secondary objective (maybe one that is more critical in a long-term perspective)
is to prevent faults from recurring. This area of problem identification and tracking
is called defect prevention.
One of the main methods of defect prevention is causal analysis. The other
method is the creation of a knowledge base that contains the classified and catego-
rized defects, so that a programmer or designer can browse the knowledge base
before he or she starts the analysis, design, or development, to be forewarned of
the problems that could occur.

6518 Book.indb 98 12/30/14 1:24 PM

 CCB99

Causal Analysis
The objective of causal analysis is to analyze defects and problems to determine and
record the cause and initiate corrective actions so that the defects will not occur
again. The primary document or the basis of the causal analysis is the problem
analysis document. This document contains information such as the causes of the
defects, where they occurred, and their severity.
By studying the analysis reports, the person doing the causal analysis will be
able to come up with cause patterns. For example, some of the causes for the defects
are insufficient input during the analysis stage, inadequate standards, inadequate
skill levels, lack of training, lack of documentation, lack of communication, over-
sight, and inappropriate methodology or tools. For example, in a project if the
causal analysis reveals that the reason for most of the defects is lack of knowledge
of a tool that is used to generate the code, the team members can be given training
on the tool so that the problem can be prevented. Thus, causal analysis plays an
important role in defect prevention.

Defect Knowledge Base and Help Desks

When a problem analysis document is submitted, it should result in the creation
of CRs and problems being fixed. It will also form the basis of causal analysis.
Its contents should also find their way into the defect knowledge base—a knowl-
edge base that stores defects in an organized way, classified and categorized. This
knowledge base should have a search facility where one can search for defects by
such aspects as category, phase of origin, cause, and severity. Details of the defects
such as the project, the defect description, the cause, and the solution should be in
the knowledge base.
This knowledge base will be tremendously valuable because it will serve as a
road map and guidebook for analysts, designers, programmers, and people who
do the testing and maintenance. For analysts, designers, and programmers, it will
serve as a guide, telling them, for example, what to do, what to avoid, and what
mistakes can happen. The people who do the testing can create better test cases
and test data if they know about the defects that escaped testing and how that
happened. People who do the problem fixing will find similar problems and can
see how they were fixed. This information will be very useful for people who are
managing the help desks and for the technical support team. In addition, as new
problems get added to the system, it will become more and more comprehensive,
and its usefulness will increase.

CCB

We have seen that once the CIs are identified, acquired, and baselined, they come
under the purview of configuration control, and formal change control procedures
come into effect. This means that once the items are brought into the SCM system,
the changes to it are done through a formal change management process. Previous

6518 Book.indb 99 12/30/14 1:24 PM

 100 Configuration Control

sections have described the exact mechanism of this process. Since the SCM is
one of the essential means of communication, changes to agreed-on baselines or
points of departure should be reviewed and approved to ensure that the integrity
of a baseline has not been altered by a given change. In addition, such a review and
approval should be made for all internal changes so that communication among
the development team members can be maintained.
We have also learned that there should be a body for making decisions such
as what changes should be made to a CI and which CRs should be rejected This
approving authority is known as the CCB or the change control authority (CCA).
The IEEE [1] defines the CCB as a group of people responsible for evaluating and
approving or disapproving proposed changes to CIs and for ensuring implemen-
tation of approved changes. This also ensures that all proposed changes receive a
technical analysis and review and that they are documented for tracking and audit-
ing purposes. The board also has final responsibility for release management (e.g.,
establishing new baselines).
The basic tasks of the CCB are to declare baselines on CIs (e.g., promotions
and releases; to review changes to baselined CIs; and to approve, disapprove, or
defer their implementation. The above is a short but extremely important task list.
The CCB must have a stranglehold on the project. Nothing can be changed without
its approval except in the case of emergency fixes. For this reason, board members
must be chosen carefully.

CCB Composition
The name change control board has the connotation of being a bureaucratic setup
with many people. The composition of the CCB can vary anywhere from a single
person to a highly structured and very formal setup with many people. For exam-
ple, in small projects, the project leader alone will perform all the functions of the
CCB, but in the case of large projects like a defense project, there will be a highly
structured and formal CCB setup with well-defined procedures.
Factors such as the composition, the nature of functioning (formal or informal),
and the number of people in the CCB depend on the complexity, size, and nature
of the project. In some very large projects there can be multiple levels or hierarchies
of CCBs (CCBs for handling different types of problems) or multiple CCBs (each
dealing with a subsystem of the project). In some cases there can be a super CCB to
coordinate the activities of the CCBs and to act as an arbitrator to solve conflicts
between CCBs of equal status and authority.
Irrespective of the size and nature of the CCBs, their function is the same: to
control and manage change. To manage and control change in a software system,
the CCB should be comprised of people who have knowledge about the system (its
technical, managerial, and economic aspects) and the effect and consequences of
their decisions on the system.
The CCB must be composed of representatives from all affected organizations
or departments (stakeholders). It may contain such members as a representative
from the SCM group (preferably the CMO); representatives from the project team
(project leader or his representative), QA group, company management, marketing
department, or project management; members of the functional or user community;

6518 Book.indb 100 12/30/14 1:24 PM

 CCB101

developers; test group, design group, interface group, documentation group, or opera-
tion personnel; or database administrators. In some cases, the CCB must include
the client’s representatives. The members of the CCB should be senior people who
can speak for their respective departments. Also, there should be a provision by
which the CCB can summon individuals (like the change initiator, the person who
conducted the analysis, or outside experts) if their presence is required for better
decision making. The ideal size of the CCB is around seven, but it can be more or
less depending on the organization. When all project groups are not represented, it
is the members’ responsibility to ensure that other groups are aware of the CCB’s
actions. This can be accomplished by the SCM recording minutes of the meeting
and circulating it among all the concerned parties.
Although all members of the CCB might not agree to each and every change, it
is certain that some change will affect every member of the board at some time. It
should not be difficult to recall past experiences when an unwise or costly mistake
could have been avoided if the right people had known about a proposed change.
The chair of the CCB must be from project management—a person who can unam-
biguously resolve conflicts within the board and enforce the board’s decisions on the
project. Decisions on change implementation and CI promotion translate directly
to fundamental project cost, schedule, and quality issues.
The CCB will find that its efforts are an infuriating exercise in futility if their
decisions are continually reversed or ignored by an outside entity with the real
decision-making authority. Do not let this happen; put that entity in charge of the
board. By doing so, those who have decision authority are directly coupled to those
who have expertise on the details. Decisions of the CCB should be reached by con-
sensus whenever possible. The group dynamics must reflect the cooperative nature
of a development project. The chair must nurture this cooperative vision and take
unilateral action only when all other methods have been exhausted.

Functions of the CCB

As stated in the IEEE definition, the main function of the CCB is to evaluate and
approve or disapprove the CRs and PRs that have been initiated or filed. The CCB
will also see to it that the approved changes are implemented in the correct manner.
The CRs and problem reports are evaluated before submitting them to the CCB.
This evaluation is necessary because it will save a lot of time and effort. Also, there
are some tasks that are better accomplished by a single person than a team. So the
presubmission evaluation should be done by a qualified professional, who knows
the subject well. Assigning the right person to this task is the duty of the CMO. The
evaluation report along with the CR or problem report is submitted to the CCB.
The CCB is comprised of members who are quite senior and have other respon-
sibilities and whose time is valuable. Accordingly, speedy resolution of the issue is
a must; to attain speedy resolution and better decision making, the facts should be
presented to the CCB in a clear and concise manner. It is a good idea to circulate
the agenda of the CCB meeting and the issues and the supporting documents to
the members so that they can come prepared for the meeting. This is a task that
has to be done by the CMO. The CCB members will evaluate the requests for their
technical feasibility, economical viability, impact on marketing, and other factors.

6518 Book.indb 101 12/30/14 1:24 PM

 102 Configuration Control

Depending on the pros and cons, the committee will decide to approve, reject, or
defer the CRs.
During the presubmission evaluation, the analysis focuses on factors such as
the impact of the program on other programs, the cost of implementation, the skills
required for implementing the change, and the time required. During the CCB
meeting, these factors, along with other issues such as how a particular change is
going to affect the system release schedule, how the change will affect the market-
ing strategy, and how it will affect the quality of the system, will be evaluated. In
other words, the CCB members will decide on each request looking at the overall
picture. The concerns and issues the CCB discusses include the following:

• Operational impact: What will be the effect of this change on the final product?
• Customer approval: Will the change require customer approval? Is it a major
change?
• Development effort: What is the impact of the change on interfaces and
internal software elements of the final system?
• Interface impact: Will the change affect the established interfaces of the
system?
• Time schedule: At what point is this change incorporated? What is the time
for incorporation with minimal impact on cost and schedule?
• Cost impact: What is the estimated cost of implementing the change?
• Resources impact: What resources—infrastructure, skill, people, etc.— will
be required to implement the change?
• Schedule impact: How will the processing and incorporation of the change
affect the current schedule?
• Quality impact: How will the change affect the quality and reliability of the
final product?
• Feasibility: With all the above factors, can this change be made in an eco-
nomical manner?
• Risks involved: What is the risk of implementing the change? What is the risk
of not implementing or deferring the implementation?

For example, a CR, if implemented, will delay the system release, but it is a
user interface change that the marketing department feels will improve the sales.
As a result, the CCB has to decide whether to delay the release for better sales or
to go ahead with the release and incorporate the CR in the next version. Overall,
the decisions made in a CCB meeting are strategic in nature, even though a good
technical understanding is necessary to make those decisions.

Functioning of the CCB

The CCB should have a chairman. Usually the project management representative
is given this post. In some organizations, however, the members are assigned this
post on a rotating basis. The CCB should meet at the intervals specified in the SCM
plan. There should be a provision to call an emergency meeting if need arises. This
is because certain CRs may require immediate action and cannot be delayed until
the next scheduled CCB meeting.

6518 Book.indb 102 12/30/14 1:24 PM

 Summary103

The minimum number of people who can make a decision must also be speci-
fied. The rules for the functioning of the CCB should be formulated. How will the
CCB decide on an issue? Is it by vote, and if so, what will be done in the case of a
tie? These things should be specified in the SCM plan. If they are not specified in
the SCM plan, then they should be addressed at the first meeting of the CCB.
Another important point is that all transactions that happen during the CCB
meetings should be recorded. The minutes of the meeting should be circulated among
the CCB members. The format and the style of the meeting minutes can be formal
or informal, but they should contain at least the following information:

• Members present;
• Date of the meeting;
• Agenda of the meeting;
• Action taken report (ATR) by the CMO (status of the CRs and other SCM
activities since the last CCB);
• CRs (CR number and evaluation document number) discussed at the meeting;
• Discussion details and decisions;
• Distribution list.

The approved changes will be assigned to a qualified person or team for making
the changes. If a CR is rejected, then the change initiator will be notified about the
decision and the reasons for rejection. The initiator can resubmit the request or file
an appeal, if he or she feels that the reasons are not satisfactory. The deferred CRs
are filed for later discussion, and the decision is conveyed to the initiator.
In the case of approved changes, the CCB will assign the task of implementing
the change to someone or assign the change management process to the CMO. In
such a situation, the CMO will assign the task to qualified person(s) and perform
the necessary actions to complete the change management process (review, approve,
promote, and baseline). In the next meeting of the CCB, the CMO will present the
ATR on the CRs that were approved and implemented.
As discussed earlier, the growing popularity of SCM tools, which allow CCB
meetings to be conducted electronically, is slowly eroding the need for and impor-
tance of physical CCB meetings.

Summary

This chapter discusses configuration control and why it is needed and how it is done.
Further, it details the reasons for change and how a change is requested, processed,
and implemented. It also describes the benefits of automating the change manage-
ment process.
In addition, we consider the problem reporting and tracking process and dis-
cuss defect prevention. Strictly speaking, defect prevention does not come under
the purview of SCM. In the author’s opinion, however, because defect prevention
is closely related to SCM, the SCM team must perform its associated tasks.
An integral part of any configuration control system is the CCB. Therefore, the
chapter explains the composition, functions, and working of the CCB and highlights

6518 Book.indb 103 12/30/14 1:24 PM

 104 Configuration Control

that, as change management and SCM tools become more and more popular, a lot
of activities that were performed by the SCM team members are now automated.
This automation will reduce the monotonous and repetitive nature of change man-
agement and help make the configuration control function easier. Moreover, it will
improve development productivity, because automation will allow people to con-
centrate more effort on developmental activities.

References

[1] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610-1990),

IEEE Standards Collection (Software Engineering), Piscataway, NJ: IEEE, 1997.
[2] Alain Abran, A., and Moore, J. W. (eds.), SWEBOK: Guide to the Software Engineering
Body of Knowledge (Trial Version), Los Alamitos, California: IEEE Computer Society,
2001.
[3] Bays, M. E., Software Release Methodology, Upper Saddle River, NJ: Prentice Hall PTR,
1999.
[4] Cagan, M., and D. W. Weber, “Task-Based Software Configuration Management: Support
for ‘Change Sets’ in Continuus/CM,” Technical Report, Continuus Software Corporation,
1996.
[5] Burrows, C., S. Dart, and G. W. George, Ovum Evaluates: Software Configuration Man-
agement, London: Ovum Limited, 1996.
[6] Weber, D. W., “Change Sets Versus Change Packages: Comparing Implementation of
Change-Based SCM,” Proc. 7th Software Configuration Management Conf. (SCM7),
Boston, MA, May 1997, pp. 25–35.
[7] IEEE Standard for Software Anomalies (IEEE Std-1044–2009), Piscataway, NJ: IEEE,
2009.

Selected Bibliography

Ben-Menachem, M., Software Configuration Management Guidebook, New York: McGraw-

Hill, 1994.
Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons, 1992.
Davis, A. M., 201 Principles of Software Development, New York: McGraw-Hill, 1995.
Gill, T., “Stop-Gap Configuration Management,” Crosstalk: The Journal of Defense Software
Engineering, Vol. 11, No. 2, February 1998, pp. 3–5.
Humphrey, W. S., Managing the Software Process, New York: Addison-Wesley, 1989.
IEEE Standard for Software Configuration Management Plans (IEEE Std-828–1998), Pisca-
taway, NJ: IEEE, 1998.
IEEE Standard for Configuration Management in Systems and Software Engineering (IEEE
Std-828–2012), Piscataway, NJ: IEEE, 2012.
IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
Intersolv, “Software Configuration Management for Client/Server Development Environments:
An Architecture Guide,” White Paper, Intersolv, 1998.
ISO, “Quality Management-Guidelines for Configuration Management,” Technical Report No.
ISO 10007:1995(E), Geneva, International Standards Organization, 1995.

6518 Book.indb 104 12/30/14 1:24 PM

 Summary105

NASA, “NASA Software Configuration Management Guidebook,” Technical Report SMAP-

GB-A201, NASA, 1995.
Peters, J. F., and W. Pedrycz, Software Engineering: An Engineering Approach, New York: John
Wiley & Sons, Inc., 2000.
Pfleeger, S. H., Software Engineering: Theory and Practice (4th Edition), Prentice Hall, 2009.
Pressman, R. S., Software Engineering: A Practitioner’s Approach (8th Edition), New York:
McGraw-Hill, 2014.
Sommerville, I., Software Engineering (9th Edition), Reading, MA: Addison-Wesley Publish-
ing Company, 2011.
Weber, D. W., “Change-based SCM Is Where We’re Going,” Technical Report, Continuus Soft-
ware Corporation, 1997.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

6518 Book.indb 105 12/30/14 1:24 PM

6518 Book.indb 106 12/30/14 1:24 PM
 Chapter 8

Status Accounting

Introduction

CSA is an element of CM that consists of the recording and reporting of informa-

tion needed to manage a software system and its characteristics effectively. This
information includes a listing of approved configuration identifications, the status of
proposed changes to the configuration, and the implementation status of approved
changes [1]. In other words, the status accounting function is the recording and
reporting of information needed to manage CIs effectively, including, but not
limited to, a record of approved configuration documentation and identification
numbers, the status of proposed changes, the implementation status of approved
changes, the status of pending or open CRs and PRs, and the build state of all
units of the CIs. Status accounting is the record keeping element of SCM, and the
status accounting records are the means for SCM to report the state of the soft-
ware product’s development to the project management, company management,
and the customer.
The aim of status accounting is to keep managers, users, developers, and other
project stakeholders informed about the various configuration stages and their
evolution. This implies three basic tasks: data capture, data recording, and report
generation. The status accounting activity is important for maintaining the conti-
nuity of the project and avoiding duplication of effort.
The effectiveness of CM is closely linked to the flow and availability of configu-
ration information about the product. Information is collected while performing
activities associated with the CM processes (planning and management, identi-
fication, change management, and verification and audit). CSA correlates stores,
maintains, and provides readily available views of this organized collection of
information. CSA provides access to accurate, timely information about a product
and its documentation throughout the product life cycle. CSA involves the storage
and maintenance of the following:

• Information about the configuration documentation (such as document iden-

tifiers and effective dates);
• Information about the product’s configuration (such as part numbers or
changes installed in a given unit);
• Information about the product’s operational and maintenance documenta-
tion (such as the documents affected by each change and their update status);
• Information about the CM process (such as the status of CRs).

107

6518 Book.indb 107 12/30/14 1:24 PM

 108 Status Accounting

The status accounting activity designs and operates a system for the capture
and reporting of necessary information as the life cycle proceeds. As in any infor-
mation system, the configuration status information to be managed for the evolv-
ing configurations must be identified, collected, and maintained. Various pieces of
information and measurements are needed to support the SCM process and to meet
the configuration status reporting needs of management, software engineering, and
other related activities. A good status accounting system should be able to answer
questions like the following and many more:

• What is the status of an item?

• Has a particular CR been approved?
• What is its status of pending or open CRs and PRs?
• What items were affected by a particular CR?
• When was the CR approved, and who approved it?
• Who performed the change for a particular CR, and when was it completed?
Who reviewed it? Who approved it?
• Which version of an item implements an approved CR?
• What CRs are assigned to whom?
• How many high-priority CRs are currently not implemented?
• What is different about a new version of a system?
• How many CRs are initiated each month, and what is the approval rate?
• How many PRs are filed each month, and what is the status of each of them?
• What are the major causes of the problems or defects?

The status accounting of the CIs can be compared with bank accounts, where
each CI is an individual account. All transactions that happen to the CI and all
activities that are performed on the CI are recorded. So individual transactions can
then be tracked through each account as they occur.
Some form of automated tool support is necessary to accomplish the data col-
lection and reporting tasks. This could be a database capability, such as a relational
or object-oriented database management system. This could be a stand-alone tool
or a capability of a larger, integrated tool environment.

Status Accounting Information Gathering

Since CSA information is a byproduct of all the other CM processes, the effective-
ness of CSA is dependent on the quality of CM implementation, supported by CM
processes that ensure the information is systematically recorded, safeguarded, vali-
dated, and disseminated. Decisions on the information to be captured in the CSA
system should be based on such factors as the nature of the product, the environ-
ment in which the product will be operated, the anticipated volume and complexity
of change activity, and the information needs of the customer(s) [2].
The procedure of tracking the status of the CIs should be established early
enough in the software development process to allow for data gathering. Also, the
system should be designed in such a way that the SCM activities will update the

6518 Book.indb 108 12/30/14 1:24 PM

 Status Accounting Database109

status accounting database rather than the person in charge of the status account-
ing function collecting the data regarding each and every change that is happening.
If control mechanisms are built into the process that make updating the status
accounting database a prerequisite for further processing, the data in the database
will be current and complete. For example, when a CR is initiated, that information
is recorded in the database and if a check is made to ensure that the details of the
CR have been entered in the database before it is forwarded to the CCB, the status
accounting function can be performed more effectively.
For this process to happen, people should be aware of what to do and how to
update the status accounting database. This is beneficial to the people who update
the information because they are the same people who will be asking for informa-
tion about the status of the various items at a later stage.

Status Accounting Database

The status accounting database is established to receive and process the data col-
lected regarding the evolution of the various CIs of the product during the different
phases of the software development life cycle. The amount of data collected and the
level of detail will depend on the size, complexity, and nature of the project. The
primary data of interest reflect knowledge of dates of start and completion of design
and builds. Also important is accurately knowing the changes that are being made
or that have been made and incorporated so that the up-to-the-minute status of a
configuration item can be known. The following list gives the necessary informa-
tion for a simple status accounting report:

• CI name and identification number;

• Name of the next higher level CI;
• Design start date;
• Design approval date and revision number;
• Coding start date;
• Coding finish date;
• Testing start date;
• Testing finish date;
• Build start and finish dates and revision number;
• System merge date;
• System delivery date and revision number;
• CR date, CR number, and requestor’s name;
• Change disposition date;
• Change incorporation date, implementer’s name, and revision number.

CRs also have IDs and descriptions. The database is the primary reference
point for anything one may need to know or report about the project. The database
thus should capture as much information as possible. If the database is made an
integral part of the development environment, the details necessary for effective
status accounting can be captured automatically as and when it happens. This will

6518 Book.indb 109 12/30/14 1:24 PM

 110 Status Accounting

greatly reduce the workload of the SCM team. The database should be secured and
protected from tampering by authorized or unauthorized persons during the input
of date, query or generation of reports.
An important feature of the database is the ability to trace the software system
upward and downward. This is the capability to track the relationship of the software
requirements down through the various levels (e.g., system, program, module, and
unit—a process known as drill-down in knowledge management terminology—or
in the opposite direction (i.e., track the relationship from the smallest element (unit)
upward through module, program, system, design, and ultimately, the require-
ments). This traceability feature is most helpful during audits and for determining
the impact of a change on all the interrelated elements.

Importance of Status Accounting

Status accounting refers to the information management (or data management)

functions in the SCM system. For each CI designed, developed, reviewed, approved,
released, and distributed, the activities that are done and other information such
as how they were done; why, where, and when they were done; and who did them
have to be recorded.
These details will be useful for everyone involved in the project in various
ways. The information needs of a developer are different from that of a project
manager, but each and every member of the project team and the support functions
will need at least some of the information. Status accounting is the information
gathering and dissemination component of SCM. It is also used by management
in decision making to monitor the progress of the project, and it can help identify
problems before they become critical so that project management can take cor-
rective actions.
The information provided by the status accounting function helps project man-
agement identify problems, pinpoint the source of the problem(s), and take correc-
tive action before the situation gets out of hand. From the reports that are produced
and by making ad hoc queries, project management can determine how the project
is performing and compare the performance against the plan. One can also look at
the types of changes, the rate of changes, the causes of the changes, the cost, and
many other factors and take the necessary actions.
Status accounting reports are invaluable during the maintenance phase. To
understand and identify the cause of a problem, one needs to know the history of
the CI. For example, consider a program that was working until last week but is
not working now. The easiest way to find out why is to identify the changes that
were made to the program since last week. In situations like this, the information
provided by status accounting helps resolve the problem faster.
Similarly, the information provided by the status accounting function is useful
in determining the performance characteristics of the project such as number of
CRs, approval rate, number of PRs, average time for a change resolution, average
implementation time, and cost of implementing a change. This information will
help when evaluating the performance of the project and when comparing different

6518 Book.indb 110 12/30/14 1:24 PM

 Status Accounting Reports111

projects. Also, these details will help to fine tune the estimation and costing pro-
cedures of the organization.
So when the SCM system is designed, the information that has to be gathered
by the status accounting function should be identified and selected, keeping in mind
all of the uses mentioned here. A good status accounting system should provide
information that is accurate, relevant, and timely.

Status Accounting Reports

As previously discussed, the major functions of status accounting are to record

and report information needed to manage a software system and its characteris-
tics effectively. Reported information can be used by various organizational and
project elements, including the development team, the maintenance team, project
management, and QA activities. Reporting can take the form of ad hoc queries to
answer specific questions or the periodic production of predesigned reports. Some
information produced by the status accounting activity during the course of the
life cycle might become QA records. In addition to reporting the current status of
the configuration, the information obtained by status accounting can serve as a
basis for various measurements of interest to management, development, and SCM.
Examples include the number of CRs per CI and the average time needed to imple-
ment a CR [3]. Even though it is not possible to anticipate all possible information
requests, there are several reports that every system must have. These include the
change log, the progress report, the CI status report, and the transaction log. We
will look at each of these reports in some detail a little later.
The factors that should be considered while designing the reporting require-
ments and reports of a system include the following:

• The audience for the report;

• The information contained in each report;
• The need for a routine report or a report provided on an ad hoc basis;
• The frequency of the report;
• The distribution list.

Examples of routine reports are, as we have seen, the change log and transac-
tion log. Some examples of ad hoc reports are listed as follows:

• A list of all CRs that have been approved but not implemented;
• A list of all CRs initiated in the last four months;
• A list of how many people are working on a particular CR;
• A record of how much time was needed to implement a particular change;
• The number and details of CRs that are pending.

Ad hoc reports are generated when a user requests particular information not
included in the routine reports.
Let’s take a look at some of the most common routine reports.

6518 Book.indb 111 12/30/14 1:24 PM

 112 Status Accounting

Change Log
The change log should contain all information about the CRs in the system. The
usual distribution frequency is monthly. This report should contain information
such as CR number, status, originator’s name, impacted items, origination date,
description of change, and implementer’s name.

Progress Report
The progress report, which is a summary of development progress since the last
report was issued, is used primarily by management to monitor the progress of the
project. This report should include information such as the reporting period (from
and to dates), the task ID1, a brief description of the work performed during the
period on the task, and the status of the task (e.g., complete or percent completed).

CI Status Report
This report is prepared to summarize the status of all CIs in the system and should
include information such as a list of the CIs, description, and location of the CIs
(the controlled library where they are stored). The CI description should include
the name, version number, and details of dependent items.

Transaction Log
This log contains the transactions that have happened to items, recorded in chron-
ological order. The log should contain details such as transaction number, date,
originator (person who is making the entry), nature of the entry (what the entry
regards), affected items, activity (e.g., CR, CCB approval, analysis, and PR), descrip-
tion, participants (people who are involved), impacted items (items affected by the
activity), and remarks.
The objective of the transaction log is to find out what happened during a spe-
cific period, say, “What were the activities done on mm/dd/yy?” Here, the idea is
not to provide a detailed description of how things were done, but to give someone
a snapshot of what happened during a given period.

Status Accounting and Automation

SCM tools fully automate the status accounting function. We have seen that SCM
tools capture all SCM-related information as and when it happens and does so
automatically. The SCM tools store this information in a database, so retrieval
of the information is fast and efficient. Also, the information can be generated in
any format the user wants. SCM tools can be used to generate routine reports.

1. A task is the result of a CR implementation. An approved CR can result in one or more tasks that can
be assigned to one or more persons or teams. When the task is created the CMO creates a task ID and
associates it with the CR.

6518 Book.indb 112 12/30/14 1:24 PM

 Status Accounting and Automation113

However, SCM tools deliver their full potential when they are used for generating
ad hoc reports. Users can query the system for any information they require and
get answers immediately and in the requested format.
Without SCM tools, SCM teams have to go through data such as that contained
in change logs, defect logs, CRs, and transaction logs to correlate and collate bits
and pieces of information from different sources to create a report that satisfies the
user’s requirements. This is a tedious and time-consuming process that increases
the workload of the SCM team if users start asking complex queries that involve
more than one source.
An SCM tool is an ideal solution to this situation. It is quick, accurate, and
customizable. In the case of an SCM tool, all SCM-related information is stored
in relational databases, making information retrieval easy and quick. Also, in the
case of a tool, the information will be up-to-date, as the events are recorded and
the information is captured as the activities occur.
Another advantage of using tools is the variety of information that can be
retrieved. For example, one can obtain information on such topics as all pending
CRs, all completed CRs, all CRs completed between such-and-such a date, all CRs
initiated by a particular developer, and all CRs implemented by a particular person.
The beauty of this system is that no additional cost or extra effort is required to
produce these different reports. Most SCM tools will have a set of standard reports
and then the facility to query the SCM database for other details. Most tools have
the facility to display the information in graphical form also.
Thus, SCM tools greatly enhance the capabilities of the status accounting func-
tion because they can record and retrieve minute details with speed and accuracy
to satisfy ad hoc queries. This is especially true when different users of the SCM
system have different needs. The project manager’s information requirements are
different from that of the developer’s. What the change initiator wants to know will
be different from what the project leader or a QA person wants to know. With a
manual system, people have to wait while the information is compiled from records,
whereas with a computerized system, retrieval is merely a matter of running a query.
Another advantage of a software tool is that the people concerned can be given
read-only access so that they can query the system and get the answers they need.
Here, once again, the author would like to stress the need for a computerized system.
Manual systems are fine for routine reports. However, an interactive system can
reduce the workload of the SCM staff because the people who want the information
(and have the necessary authority) can log on to the system and get the information
required. Also, routine reports provide static information. With an interactive system,
on the other hand, users can view the reports, and if they require more information,
they can drill down and get the details they want. In this way, SCM information
is more effectively used, leading to better, well-informed decisions. If an SCM tool
does not support flexible and customizable reporting features, it is of limited value.
As previously mentioned, SCM tools completely automate the status account-
ing process and make status accounting easier and accurate. However, the level of
automation possible and the capabilities offered differ among SCM tools. Most orga-
nizations use some sort of tool for performing SCM (at least tasks like change man-
agement, defect tracking, and build management), and complete manual systems are
very rare nowadays. However, to take full advantage of automation, organizations

6518 Book.indb 113 12/30/14 1:24 PM

 114 Status Accounting

need to turn to high-end sophisticated SCM tools (which cost a fortune)—and even
then, at least some of the SCM functions will require human operation.
Next, we examine some of the common report categories that are supported
by most SCM tools.

Change and Problem Tracking Reports

These reports contain details such as who made the change and when, who initiated
it, change history, and CR status. Here, the advantage, as mentioned previously, is
that the users can tailor the information retrieved in any format that they would
like. So one can generate reports of all unassigned CRs; all pending CRs; all CRs
assigned to a particular person; and CRs sorted by such factors as date, severity,
priority, classification, completion date, and status.

Difference Reporting
It is important to keep track of the differences between versions and releases, because
doing so will make it easier to incorporate changes from one version to the next.
Most SCM tools have the facility to generate difference reports, which will contain
the differences (changes) between two versions of an item or set of items.

Ad Hoc Queries
The usefulness of having ad hoc querying capabilities can never be overstated. Ad
hoc queries allow the users of an SCM system to get the information they want,
when they want it, and in the form they want. The reporting tools are so advanced
that many of them have graphical user interfaces that help users write their own
queries by choosing the items in which they are interested. Also, these reporting
tools have drill-down features, so that a user can drill down from a summary report
to the level of detail required. This feature is particularly useful for project leaders
and management.

Journals
The journal feature distinguishes SCM tools from the manual status accounting
process. A journal records all events that happen to all configuration items as they
occur, thus providing users with a complete and comprehensive picture of what
happened during a particular period in time. This is a much advanced and more
comprehensive version of manual transaction logs.
Journals provide audit trails that can be used for a variety of purposes including
configuration audits. The advantage of having the journal details in a database is
that the information contained in it can be manipulated at will. Accordingly, one
can recreate all of the events that happened during the transition of a configura-
tion item from, say, version 1 to 6 or the details of activities performed by a certain
developer. The advantage here is that the information can be retrieved quickly and
without any extra effort.

6518 Book.indb 114 12/30/14 1:24 PM

 Summary115

Summary

Status accounting is a recording activity that serves as a follow-up to the results of

the SCM activities of configuration identification and change control. It keeps track
of the current configuration identification documents, the current configuration of
the delivered software, the status of the changes being reviewed, and the status of
the implementation of approved changes.
The status accounting function plays a vital role in the efficient management and
control of projects by providing the necessary information to project management
and the project team. SCM tools automate the status accounting function and help
provide users with information that is accurate, timely, and relevant.

References
[1] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610–1990),
IEEE Standards Collection (Software Engineering), Piscataway, NJ: IEEE, 1997.
[2] EIA, National Consensus Standard for Configuration Management (EIA-649), Arlington,
VA: Electronics Industries Alliance, 1998.
[3] Alain Abran, A., and Moore, J. W. (eds.), SWEBOK: Guide to the Software Engineering
Body of Knowledge (Trial Version), Los Alamitos, California: IEEE Computer Society,
2001.

Selected Bibliography

Babich, W. A., Software Configuration Management: Coordination for Team Productivity,

Boston, MA: Addison-Wesley, 1986.
Ben-Menachem, M., Software Configuration Guidebook, London: McGraw-Hill International,
1994.
Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons, 1992.
Bersoff, E. H., V. D. Henderson, and S. G. Siegel, Software Configuration Management, An
Investment in Product Integrity, Englewood Cliffs, NJ: Prentice-Hall, 1980.
EIA, National Consensus Standard for Configuration Management (EIA-649), Arlington, VA:
Electronics Industries Alliance, 1998.
IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York: John
Wiley & Sons, 2002.
“Software Configuration Management: A Primer for Development Teams and Managers,” White
Paper, Intersolv, 1997.
“Software Configuration Management for Client/Server Development Environments: An Archi-
tecture Guide,” White Paper, Intersolv, 1998.

6518 Book.indb 115 12/30/14 1:24 PM

6518 Book.indb 116 12/30/14 1:24 PM
 Chapter 9

Configuration Verification and Audits

Introduction

The objective of configuration verification and audits is to verify that the software
system matches the CI description in the specifications and documents and that
the package being reviewed is complete. According to EIA-649 [1], configuration
verification and audit establish that the performance and functional requirements
defined in the configuration documentation have been achieved by the design and
that the design has been accurately documented in the configuration documenta-
tion. The purpose and benefits of the process include the following:

• Ensuring that the product design provides the agreed-to performance

capabilities;
• Validating the integrity of the configuration documentation;
• Verifying the consistency between a product and its configuration
documentation;
• Determining that an adequate process is in place to provide continuing con-
trol of the configuration;
• Providing confidence in establishing a product baseline;
• Ensuring a known configuration as the basis for such things as operation and
maintenance instructions, training, and spare and repair parts.

Once the software has been designed, developed, and tested, it is necessary to
establish that the software product has been built in accordance with the require-
ments and that the software is correctly represented in the documentation that is
shipped along with the software. A configuration audit (CA) is a check to verify
that the product package contains all of the components it is supposed to contain
and performs as promised.
Configuration verification and audits enable the developer and the customer to
agree that what has been designed has been built and that the testing applied to the
software product CIs proved that the requirements of the software requirements
specification (SRS) for each CI were met. The CAs are performed after software
integration and testing. In some cases, the software will be audited with the hard-
ware—after system integration. Reviews are an iterative activity that start with
receipt of a contract and culmination of an agreement and end with delivery of the
software product and its associated documentation [2].
The configuration verification and audit process includes the following:

117

6518 Book.indb 117 12/30/14 1:24 PM

 118 Configuration Verification and Audits

• Configuration verification of the initial configuration of a CI, and the incor-

poration of approved changes, to assure that the CI meets its required per-
formance and documented configuration requirements;
• CA of configuration verification records and physical product to validate that
a development program has achieved its performance requirements and con-
figuration documentation or the system/CI being audited is consistent with
the product meeting the requirements.

The common objective is to establish a high level of confidence in the configura-

tion documentation used as the basis for configuration control and support of the
product throughout its life cycle. Configuration verification should be an embedded
function of the contractor’s process for creating and modifying the CI or CSCI.
Validation of this process by the government may be employed in lieu of physical
inspection where appropriate [3]. Inputs to the configuration verification and audit
activity are listed as follows:

• Configuration, status, and schedule information from status accounting;

• Approved configuration documentation (which is a product of the configura-
tion identification process);
• Results of testing and verification;
• Physical hardware CI or software CSCI and its representation;
• Build instructions and tools used to develop, produce, test, and verify the
product.

Successful completion of verification and audit activities results in a verified

system and CI(s) and a documentation set that may be confidently considered a
product baseline. It also results in a validated process to maintain the consistency
of product to documentation.
Many organizations do not perform CAs [functional CAs (FCAs) and physical
CAs (PCAs)] and instead perform audits such as market readiness reviews (MRRs),
test readiness reviews (TRRs), or alpha and beta testing.
MRRs are conducted to confirm that the distribution, service, maintenance,
technical support, and field people are ready; that the installation, operation, and
troubleshooting manuals are ready; and that product tests and trial runs were suc-
cessful, among other purposes.
TRRs are conducted to evaluate preliminary test results for one or more CIs, to
verify that the test procedures for each CI are complete, to comply with test plans
and descriptions, to satisfy test requirements, and to verify that a project is prepared
to proceed to formal testing of the CIs. TRRs will be held for each application of
a release at the completion of the software integration test and at the completion
of the functional validation test. There are three levels of TRRs at the application
level, defined as follows:

• Development TRR: Informal TRR conducted following successful comple-

tion of unit or module testing of a given application;
• Project TRR: Formal TRR conducted following successful completion of the
software integration test (SIT) of a given application;

6518 Book.indb 118 12/30/14 1:24 PM

 Software Reviews119

• Enterprise TRR: Formal TRR conducted following successful completion of

the functional validation test (FVT) of a given application.

Alpha testing is done when the system or product has a lot of new previously
untested features. Since there is a lot of untested functionality, the development
team might be uncomfortable proceeding with the final testing and release of the
product until they get a feedback from a limited number of users or customers. So
developers use alpha testing primarily to evaluate the success or failure (or accep-
tance) of the new features incorporated into the system.
Beta testing is required when the development team decides that some level of
customer evaluation is needed prior to the final release of the product. In the case
of the beta testing, the developers are no longer looking for user inputs on func-
tionality or features. The product has all the functionality incorporated in it, so the
development team will be looking for the beta testers to uncover bugs and faults in
the system. Unlike alpha testing, beta testing is done on a much larger scale (i.e.,
the number of people doing the beta testing will be much higher than that for alpha
testing). Usually, companies distribute the beta releases free of cost to the people
who have enrolled for the beta testing program, and in many cases, the beta ver-
sions will be available for download from a company’s Web site. New products will
have alpha testing followed by beta testing. In the case of new versions of existing
products, however, either alpha or beta testing is done.
It is quite clear that these tests and reviews are not as comprehensive and thor-
ough as CAs and that they do not provide the same kind of assurance that prod-
ucts are built according to specifications and complete in all respects. CAs, on the
other hand, provide objective evidence of products’ and processes’ compliance with
standards, guidelines, specifications, and procedures.

Software Reviews

A review is a process or meeting during which a work product, or set of work

products, is presented to project personnel, managers, users, customers, or other
interested parties for comment or approval [4]. Technical reviews are a series of
system engineering activities by which the technical progress on a project is assessed
relative to its technical or contractual requirements. The reviews are conducted at
logical transition points in the development effort to identify and correct problems
resulting from the work completed thus far before problems can disrupt or delay the
technical progress. Reviews, as we have seen, are performed many times during the
development process at least, at the completion of each phase and sometimes more
often. Reviews—which include system requirements reviews, software requirements
reviews, design reviews (preliminary design reviews and critical design reviews), and
code reviews—provide a method for the performing activity and tasking activity
to determine that the development of a CI and its documentation has a high prob-
ability of meeting contract requirements.
On the other hand, audits are performed at the completion of the product to
make sure that the product is complete in all respects and that the development has
been performed in conformance with the development standards and guidelines

6518 Book.indb 119 12/30/14 1:24 PM

 120 Configuration Verification and Audits

Configuration Verification

Configuration verification is an ongoing process that is common to CM, systems

engineering, design engineering, manufacturing, and QA. It is the means by which
the design solution is verified. Verification that a design achieves its goals is accom-
plished by a systematic comparison of requirements with the results of tests, analyses,
or inspections. The documentation of a product definition must be complete and
accurate enough to permit reproduction of the product without further design effort.
The design of a product must be verified to ascertain that it has achieved specified
requirements and desired goals, that the documentation of the design is accurate,
and that the product can be produced from the documentation [1].
Conceptually, verification occurs in sequence by first determining the acceptabil-
ity of the design and then confirming that the documentation portrays that design.
In practice, it may be accomplished in separate events or audits. It is often more
practicable to verify these aspects incrementally during the course of the definition
phase and to incorporate the verification into the design and development process
flow, so that it occurs on a continuous basis.
Verification methods should be carefully planned to ensure that all requirements
are addressed and that the individual verification methods chosen are appropriate.
Requirements analysis and test tools that flow down, account for, and verify all
attributes facilitate the design verification process. Results are typically recorded
in a matrix indicating each discrete requirement, the method of verification, the
verification procedure, and the verification results. The design output, consisting of
the complete set of design information, must be accurately documented to permit
reproduction of the product without further design effort. Beyond this fundamental
requirement, other factors (such as the need to procure from other sources or future
maintenance needs) may influence the content and formality of documentation. A
product should be able to be produced from its documentation with confidence that
it will meet all requirements.
A software product should also be in compliance with published design and
coding standards so that it can be maintained, modified, and upgraded. In addition,
the following should be verified:

• The documentation library control system;

• The uniqueness of the product identifier;
• The validity of interfaces;
• The internal audit records of CM processes and procedures.

Verifying the documentation determines that it is adequate for its intended

purposes and accurately reflects compliant design. The verification of design and
documentation must be planned to permit its accomplishment at minimum cost. In
complex physical products, the comparison of the documentation with the proto-
type or test article can often be accomplished incrementally, during assembly of the
article, to avoid the need for later disassembly. These verifications are considered
complete upon resolution of discrepancies or departures found and correction of
associated documentation.

6518 Book.indb 120 12/30/14 1:24 PM

 The When, What, and Who of Auditing121

The When, What, and Who of Auditing

Audits are the means by which an organization can ensure that software development
has been performed in the correct way—that is, in conformance with development
standards and guidelines. The software configuration auditing activity determines
the extent to which an item satisfies the required functional and physical characteris-
tics. Audits vary in formality, but all audits perform the same function—they check
the completeness of the software system or product. Any anomalies found during
an audit should not only be corrected, but the root cause of the problem should be
identified and corrected to ensure that the problem does not occur again. (Here, the
defect prevention methods described in Chapter 8 are quite useful.)
Before the release of a product baseline, an FCA and a PCA of the CIs are usu-
ally conducted. The FCA ensures that the functions defined in the specifications are
all implemented in the correct manner. The PCA determines whether all the items
identified as being part of the CI are present in the product baseline.
A software audit is an activity performed to evaluate independently the con-
formance of software products and processes to applicable regulations, standards,
guidelines, plans, and procedures [4]. An audit is usually done at the end of a phase
in the development life cycle. Before the development proceeds to the next phase, it
is a good practice to conduct an audit so that the development team has the satisfac-
tion of knowing that it is working on something that is complete and approved. The
reality, however, is that audits are usually performed only before a system release.
This is because the system release is the one that will go to the customer.
Conducting the audit prior to final release gives the company and the customer
the satisfaction of knowing that what they are delivering or getting is complete in
all respects and meets the requirements specified. The CA can be performed before
the final release for projects done in-house and when the organization is follow-
ing all the development standards and guidelines and other QA procedures are in
place. Even then, however, every final major baseline or release must be audited.
Items supplied by subcontractors must be subjected to a formal auditing process.
Who should perform the CAs? Audits are usually performed by a representative
or team of representatives from management, the QA department, or the customer
or client. In some cases, the auditing is done by an external agency. An external
auditor is best, because the auditing activity requires a very high degree of objectivity
and professionalism. The person who conducts the audit should be knowledgeable
about SCM activities and functions and technically competent to understand the
functionality of the project. The SCM plan should describe the types of audits and
reviews to be applied to a specified software project. Where hardware components
are also involved, it is necessary to pay special attention to what documents and
data will be reviewed and audited and who will represent the hardware and soft-
ware engineering functions assigned to the project.
Audits may be conducted by the organization responsible for the product devel-
opment, by the customer, or by a third party designated by the customer. A chair-
person representing each party to the audit participates in audit planning and
preparation. Audit plans and agendas are reviewed and agreed to prior to the audit.
Audits of complex products may be accomplished in a series of incremental audits.

6518 Book.indb 121 12/30/14 1:24 PM

 122 Configuration Verification and Audits

During an audit, audit participants record significant questions, discrepan-

cies or anomalies, and recommended courses of action. Chairpersons review audit
findings and determine appropriate actions. Affected parties agree to action items
and the plan for effecting their successful closure. Audit minutes provide a record
of the audit findings, conclusions, recommendations, and action items. Follow-up
occurs until all required action items are complete. The necessary resources and
material to perform an audit include the following items to the extent appropriate
for the type and scope of audit:

• An audit plan and agenda;

• Adequate facilities and unencumbered access;
• Assignment and availability of personnel;
• Applicable specifications, drawings, manuals, schedules, and design data, test
results, inspection reports, process sheets, data sheets, safety procedures, and
other documentation as deemed necessary;
• Tools and inspection equipment necessary for evaluation and verification;
• Access to the product(s) and detailed parts to be reviewed.

FCA

The objective of the FCA is to verify that a CI’s actual performance agrees with the
requirements specified in the requirements definition and system design documents.
IEEE [5] defines FCA as an audit conducted to verify that the development of a
CI has been completed satisfactorily, that the item has achieved the performance
and functional characteristics specified in the functional or allocated configuration
identification, and that its operational and support documents are complete and
satisfactory. An FCA will prove, right or wrong, that the software test reports cor-
rectly state that a given requirement has been met.
The FCA team reviews the test plans, the test data, and the testing methodology
to verify that all functional parameters were tested and that the test results were
satisfactory. The audit team may ask for additional tests to be conducted, if neces-
sary. Functional audits normally involve a structured and well-defined sequence of
tests designed to ensure that the performance of the new or modified item conforms
to the requirements in the specification.
The form of the FCA will vary according to the type and extent of change
involved. In most cases, the FCA represents a review of the qualification of the item,
to ensure that it not only meets the specification requirement but that there are no
unintended consequences associated with the change. This process may include some
or all of the following forms of test, analysis, or demonstration: environmental tests,
to ensure that the new design is suitable for operation within the extremes of the
operational requirements; reliability tests; user trials; interfaces with other systems;
software testing; and stress testing.
As mentioned, the audit team consists of representatives from management,
QA, external experts, and client representatives. An audit team can be an ongoing
part of the organization or it can be constituted on an as-needed basis. Sometimes
audit teams are from an external agency that specializes in conducting audits. The

6518 Book.indb 122 12/30/14 1:24 PM

 Role of the SCM Team in CAs123

composition and structure of the audit team depends on the company and the audit-
ing standards that the company is following.

PCA

The objective of the PCA is to verify that a CI, as built, conforms to the technical
documentation that defines it. The PCA is usually done after successful completion
of the FCA. A PCA will demonstrate that the documentation for each CI and the
software system that will be delivered with the software product correctly describes
the functional and physical characteristics of the product and that the software
product specification and version description documents are consistent with the
software product. The audit team examines the design documentation with the
source code and user documentation and any other items that will accompany the
final software system. When a PCA is completed, the product baseline is established.
In other words, the successful completion of the FCA and PCA are prerequisites to
the establishment of the product baseline.

Auditing the SCM System

SCM system audits are carried out to ensure that the implementation of SCM remains
consistent with established policy and procedures. System audits are essential to
ensure that defined processes are being properly applied and controlled. General
aspects that may be considered part of a system audit are listed as follows:

• The operational change control processes, including the CCB function;

• The implementation of change requests;
• The traceability of approved changes to the original specification and
requirement;
• The availability of design data and documentation in support of approved
changes;
• The traceability of design decisions to the initiating requirement.

The auditing of the SCM system is done by management’s representatives, QA

personnel, or SCM experts. It is better to have the SCM system audits done by the
people who reviewed the SCM plan, because they are familiar with the SCM system
that is being practiced and thus are able to do a better job. The SCM system will be
audited against the SCM plan and the standards mentioned in the SCM plan. The
purpose of auditing the SCM system is to ensure that the SCM system and SCM
functions and procedures are being practiced as specified in the SCM plan and to
find out areas in the functioning of the SCM system that need improvement.

Role of the SCM Team in CAs

It is the responsibility of the SCM team to schedule the audits and find qualified
personnel to perform them. The SCM team also liaises between the audit team and

6518 Book.indb 123 12/30/14 1:24 PM

 124 Configuration Verification and Audits

the development and testing team and ensures that the audit team gets full support
from the development and testing team to carry out the audits successfully.
Sometimes, auditors need to question the development or testing team members
as part of the audit. The SCM team should act as a facilitator of such meetings and
record the points discussed; these minutes should form part of the audit report.
In addition, the SCM team should arrange for the infrastructure facilities such as
room(s), furniture, machine access, documents, and any other items required by
the audit team.
After the FCA and PCA have been completed, the SCM team reviews the audi-
tor’s comments and nonconformance reports (NCRs) and initiates necessary cor-
rective actions.

CAs and SCM Tools

SCM tools make the auditing process a lot easier than before. As we have seen,
SCM tools capture all SCM-related information in a very comprehensive manner
as the activities occur. In addition, the journal reports created by SCM tools record
all events that have happened to the CIs, thus creating an audit trail, which can be
used by auditors to perform their job. Also, the querying facility of the tools helps
the auditing team get any other information it needs.
The automated information gathering abilities of the SCM tools make audit-
ing into an incredibly simple process, because any necessary information can be
generated for verification purposes and auditors can confirm whether the system or
product they are auditing is complete and meets all the requirements.

Summary

CAs are carried out to ensure that software systems are functioning correctly and
to ensure that the configurations have been tested to demonstrate that they meet
their functional requirements and contains all deliverable entities.
The two types of audits are PCAs and FCAs. Whereas FCAs authenticate that
the software performs in accordance with the requirements and as stated in the
documentation, PCAs authenticate that the components to be delivered actually
exist and that they are complete in all respects and contain all of the required items.
SCM systems should also be subjected to auditing to ensure that the implementa-
tion of SCM remains consistent with established policies and procedures. SCM tools
automate most of the auditing tasks and make auditing an easy and painless job.

References

[1] EIA, National Consensus Standard for Configuration Management (EIA-649-B), Arling-
ton, VA: Electronics Industries Alliance, 2011.
[2] Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York:
John Wiley & Sons, 2002.

6518 Book.indb 124 12/30/14 1:24 PM

 Summary125

[3] U.S. Department of Defense, Military Handbook: Configuration Management Guidance

(MIL-HDBK-61A(SE)-2001), U.S. Department of Defense, 2001.
[4] IEEE Standard for Software Reviews (IEEE Std-1028-2012), Piscataway, NJ: IEEE, 2012.
[5] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610–1990),
IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway,
NJ: IEEE, 2003.

Selected Bibliography

Arthur, J. D., et al., “Evaluating the Effectiveness of Independent Verification and Validation,”
IEEE Computer, Vol. 32, No. 10, October 1999, pp. 79–83.
Ben-Menachem, M., Software Configuration Management Guidebook, New York: McGraw-
Hill, 1994.
Bourque, P., and R. E. Fairley (eds.), Guide to the Software Engineering Body of Knowledge,
Version 3.0, IEEE Computer Society, 2014; www.swebok.org.
EIA, National Consensus Standard for Configuration Management (EIA-649-B), Arlington,
VA: Electronics Industries Alliance, 2011.
IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
Pressman, R. S., Software Engineering: A Practitioner’s Approach (8th Edition), New York:
McGraw-Hill, 2014.
Sommerville, I., Software Engineering (9th Edition), Reading, MA: Addison-Wesley Publish-
ing Company, 2011.
U.S. Department of Defense, Military Handbook: Configuration Management Guidance (MIL-
HDBK-61A (SE)-2001), U.S. Department of Defense, 2001.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

6518 Book.indb 125 12/30/14 1:24 PM

6518 Book.indb 126 12/30/14 1:24 PM
 Chapter 10

SCM: Advanced Concepts

Introduction

This chapter discusses some of the advanced concepts in SCM, building on the basic
concepts introduced in Chapter 5 and dealing with some important SCM functions
such as interface control and subcontractor control. These topics are particularly
important when writing the SCM plan, which is discussed in Chapter 13. This
chapter also deals with the concept of software libraries and how important they
are for performing SCM activities.
The foundation of SCM is based on three components (introduced in Chapter
5): version control, system building, and release management.

Version Control

We have seen that a version is an initial release or rerelease of a CI. It is an instance

of the system that differs in some way from the other instances. A version is usu-
ally accompanied by a version description document (VDD). A VDD is a document
that accompanies and identifies a given version of a system or component. Typical
contents include an inventory of a system or its component parts, identification of
changes incorporated into this version, and installation and operating information
unique to the version described [1]. VDD is not normally required for each build or
internal release of software or a CI. Typically, a VDD is produced only for system-
level testing and for the major activities that follow the system level test (e.g., release
to client, customer, or marketing, archival purposes, rerelease, etc.). The VDD,
which may exist in hardcopy or electronic form, describes new capabilities, known
problems, and platform requirements necessary for proper product operation.
Version control is simply the automated act of tracking the changes of a par-
ticular file over time. This is typically accomplished by maintaining one copy of the
file in a repository, then tracking the changes to that file. The concepts of check-in
and check-out (described in Chapter 5) make this possible. Version control has a
number of benefits including the following:

• Preventing unauthorized access and modification to files;

• Tracing the evolution of a file from inception to the current state;
• Rolling back to a previous version of a given file in case of a problem or for
debugging;

127

6518 Book.indb 127 12/30/14 1:24 PM

 128 SCM: Advanced Concepts

• Comparing two versions of a file and highlighting differences to see what

changes are made;
• Providing a mechanism of locking or forcing serialized change to any given file;
• Creating branches that allow for parallel concurrent development and the
ability to combine the changes made by different people to a single file at a
later stage—merging;
• Maintaining an instant audit trail on each and every file: versions, modified
date, modifier, and any additional amount of metadata a system provides and
one chooses to implement.

Thus, version control makes it possible to trace the history of all CIs in a sys-
tem and to recreate any previous version of a file. This capability gives the software
organization tremendous power to identify and pinpoint the files that are creating
problems while debugging during the maintenance and support phases. When things
are not working, the files can be rolled back to previous versions, and the changes
made after the successfully working version can be inspected to find out what is
causing the error or malfunction.

System Building

IEEE defines a build as an operational version of a system or component that incor-

porates a specified subset of the capabilities that the final product will provide [1].
The building activity combines the correct versions of software items, using the
appropriate configuration data, into an executable program for delivery to custom-
ers or other recipients, such as developers, testers, and QA personnel. Build instruc-
tions ensure that the proper build steps are taken and in the correct sequence. In
addition to building software for new releases, it is usually also necessary for SCM
to have the capability to reproduce previous releases for recovery, testing, or addi-
tional release purposes.
During the development of a software product the build process will be per-
formed several—or actually, many—times. The developers, testers, and QA per-
sonnel will perform builds during the course of the development to see whether the
system that is under development performs as expected. When system development
is complete and all the items that are required for the final product are debugged,
tested, reviewed, verified, validated, and audited, the system build is performed.
The system build produces the product that is given to the client or shipped to the
customers.
Software is built using particular versions of supporting tools, such as compil-
ers. The two most essential characteristics that are needed for any build process
are repeatable and reproducible. In other words, you should be able to recreate
the exact product that was created using a build process at a later date. For this to
happen, the supporting tools and associated build scripts need to be under SCM
control to ensure availability of the correct versions of the tools. The build process
and products are often subject to SQA verification. Outputs of the build process
might be needed for future reference and may become QA records.

6518 Book.indb 128 12/30/14 1:24 PM

 Release Management129

Tools are very useful for selecting the correct versions of software items for a
given target environment and for automating the process of building the software
from the selected versions and appropriate configuration data. For large projects
with parallel development or distributed development environments, this tool capa-
bility is a must. Most software development environments provide this capability.
These tools vary in complexity and features; some use scripting languages while
others employ GUI-oriented approaches that hide much of the complexity of the
build facility.

Release Management

The term “release” is used in this context to refer to the distribution of a software
CI outside the development activity. The primary purpose of a release is to make
the application available to its end users. Thus, a release can be for internal users
as well as customers.
Release management is closely tied to build management in that a specific release
is essentially a production build of an application. In addition to putting the runtime
software in its final form, release management includes the deployment process as
well as the update of related metadata that goes into tracking a given version of a
software application. When different versions of a software item are available for
delivery, such as variants for different platforms or versions with varying capabilities,
it is frequently necessary to recreate specific versions and package the correct materi-
als for delivery of the version. The software library is a key element in accomplish-
ing release and delivery tasks. Software libraries are detailed later in this chapter.
Software release management encompasses the identification, packaging, and
delivery of the elements of a product such as the executables, documentation, release
notes, and configuration data. Software products will be subjected to changes and
enhancements on a continuous basis. Hence, one of the main considerations for
release management is determining when to issue a release. The severity of the
problems addressed by the release and measurements of the fault densities of prior
releases affect this decision [2]. Pressure from competitors, entry of new products
and technology, and other environmental factors also affect the decision on when
to release.
The packaging task must identify which product items are to be delivered and
select the correct variants of those items, given the intended application of the
product. The set of information documenting the physical contents of a release is
known as a VDD, described earlier in the chapter. The package to be released also
contains loading or upgrading instructions. The latter can be complicated by the
fact that some current users might have versions that are several releases old. SCM
tools are needed for supporting these release management functions.
Software released to customers must be comprised of items that have been
approved as fit for their intended use. Usually, this requires that the items be fully
approved by the CCB, although beta test or prototype releases may be less than
fully approved. It also requires that the correct variant of the system be issued to
clients. Variants differ only in the platform or language supported and have the

6518 Book.indb 129 12/30/14 1:24 PM

 130 SCM: Advanced Concepts

same functionality. So clients who want a Windows version of a product will not
be happy if they receive a UNIX version.

Interface Control

In today’s environment, interface design has become an important segment of the

software engineering process. One is not only faced with the normal computer
system-to-computer system interfaces, but other functions such as LANs to WANs
or workstations to files servers to mainframes. Those interfaces that affect the soft-
ware are identified and documented by the systems analyst and, in turn, are placed
under configuration control.
Interface describes the functional and physical characteristics required for a
common boundary to exist between two or more software products and computer
systems that are provided by different organizations or sources. Interface control
is the process of identifying, documenting, and controlling all performance, func-
tional, and physical attributes relevant to the interfacing of two or more products
provided by one or more organizations. Interface documentation consists of interface
control drawings or other documentation that depicts physical, functional, and test
interfaces of related or cofunctioning products [3]. An interface control document
defines the interfaces that may affect the operation of cofunctioning CIs and is used
for control as well as delineating the interface criteria and technical detail necessary
to effect an economical and viable interface [4].
For product interfaces external to the enterprise, the SCM system must establish
an interface agreement and a mutually agreed documentation of common attributes.
Product attributes include defined interfaces with products that are developed, pro-
duced, and supplied by organizations outside the enterprise. External interfaces are
documented in a product’s configuration documentation. To document and control
the interface, there must be a relationship between the interfacing organizations.
If the relationship is a buyer-seller relationship, the interface definition is included
as part of the purchase agreement (e.g., by reference to a defined catalog item or
by use of a control drawing). If there is no direct relationship, an interface agree-
ment is established between the developing enterprises. It delineates procedures
for defining and maintaining the common interface. The procedures (for defining
complex interfaces and coordinating proposed changes to them) may employ a
joint interface control working group. A mutually agreed upon interface definition
(including performance, functional, and physical attributes) is typically detailed in
an interface document or drawing.
NASA-DID-M200 provides for an interface control plan (ICP) and states in
simple terms that the purpose of the plan is to define the process by which the
developer defines and manages all external interfaces between the software and
all users—both human and software. It may be appropriate to roll out this plan
when there are major coordination concerns and risks between the developer and
the organizations responsible for the interfacing units [5].
MIL-STD-483B states that interface control is the coordinated activity required
to ensure that the functional and physical characteristics of systems and equipment
are compatible [6]. The interface control activity is responsible for ensuring that

6518 Book.indb 130 12/30/14 1:24 PM

 Subcontractor Control131

the configuration identification conforms to the functional interfaces established

by system engineering and that the affected CIs are logically compatible and can
be operated and supported as needed. The interface activity is also responsible for
controlling documentation, including an assessment of the impact of changes to
control documentation or changes emanating from other document changes that
could affect the interfaces.
Most software specifications and documents define or explain the interfaces
between the CI being identified and another CI or computer system. All of these
interfaces must be mapped so that everyone on the project will understand what
has been defined and will be able to carry out their specified tasks. SCM treats the
interface design documents and drawings in the same manner as other documen-
tation, except SCM also provides for assessment of impacts to interfacing entities.
The days of one organization developing all the components of a system are long
gone. This is the era of distributed development. Development teams from around
the world and from different organizations work jointly to produce a software
system. In such cases, interface control working groups (ICWGs) comprised of the
representatives of the participant companies or teams are established. This may be
necessary to ensure compatibility of all interfacing entities and to establish better
communication among the large number of developers and organizations that may
be participating in the design effort.
In most cases, an ICWG is formed at the start of the project. It is composed of
the interfacing developers and users and the prime developers’ SCM activity. The
SCM activity provides for the identification of all the interface specifications and
documents authorized by the ICWG and when released by the ICWG, places them
under SCM control. The change process for an interface document is the same as
that of any other CI; the only exception is that the CCB is replaced by the ICWG
[7]. The SCM activity will also maintain the status accounting of the documentation
and changes and provide periodic reports to the various participating organizations
represented on the ICWG. In addition, status accounting will provide the mechanism
for requirements traceability to enable the communication of the impact created
by such changes as they occur. Tools are now in use that map the entire software
system, including interfaces, and delineate the changes that have occurred by some
form of reference marking such as version number or version letter. Such informa-
tion can be acquired online (if SCM tools that capture this information are used)
by the SCM activity and the project for immediate information.

Subcontractor Control

A subcontractor is any supplier, distributor, vendor, or firm that furnishes supplies

or services to or for a prime contractor. Subcontractor control is another SCM
activity that is provided for in the software project’s SCM plan. It is most impor-
tant that the developing organization select qualified developers who, in turn, can
demonstrate an adequate understanding of performing the SCM process and can
meet the requirements that have been flowed down to them by the prime developer.
CM requirements appropriate to the product being acquired are passed down
(flowed down) to subcontractor(s), typically via purchase orders or other subcontract

6518 Book.indb 131 12/30/14 1:24 PM

 132 SCM: Advanced Concepts

agreement instruments. Tailoring of requirements for subcontractors is a major SCM

planning activity. The performing activity takes on the role of customer (buyer) to
the supplier. Suppliers are monitored via data reviews, configuration change man-
agement, design reviews, product test results, CAs, and SCM surveillance reviews,
as appropriate.
Data reviews typically include assessment of supplier plans, procedures, and
configuration documentation. Configuration change management typically includes
review of proposed changes to buyer-approved or -imposed configuration documen-
tation. Design reviews assess the supplier’s progress and provide a level of confidence
that the product, when developed, will meet its specified attributes. Product test
results are positive or negative indicators that required attributes will, or will not,
be satisfied. CAs verify that the required attributes have been achieved and that the
design of the product has been accurately documented. SCM surveillance reviews
verify the continuing application of supplier SCM processes.
There can be several categories of development subcontracts, including ones
under which (1) full authority is given to design, develop, build, test, and deliver
a specified CI or multiple CIs; (2) limited design authority is given, such as when
modifying existing software or performing coding and unit testing only; and (3)
no design responsibility is given and the software to be delivered is termed as a
nondevelopmental item (NDI) or COTS software.
The level of configuration change management exercised by the buyer (prime
contractor) ranges from none to total depending on the nature of the product and
the conditions of purchase. For a COTS product or NDI, the buyer generally has
no control over the product attributes, but can choose not to buy the product.
In the case of a product purchased using a buyer-prepared control drawing, the
buyer typically exercises CCA over the specified form, fit, and function attributes.
For a product developed to the buyer’s specifications, the buyer normally exercises
CCA over the product’s requirement attributes. The buyer may also exercise control
over the product design if more rigorous SCM has been flowed down to the supplier.

Software Library

The software library is the heart of the SCM. It contains everything that is impor-
tant to a software project: source code, user and system documentation, test data,
support software, specifications, project plans, and derived items [8]. The software
library must be secure. It must only be accessed in ways that are consistent with
sound SCM. Both read access and write access must be controlled, the former to
prevent unauthorized disclosure and the latter to prevent unauthorized or acciden-
tal change or deletion.
The software library is an important asset to the performance of the SCM
process, especially in carrying out change control, release management, and status
accounting activities. A software library is defined as a controlled collection of
software and related documentation designed to aid in software development, use,
or maintenance [1]. Types include development libraries, controlled libraries, and
master libraries.

6518 Book.indb 132 12/30/14 1:24 PM

 Summary133

Figure 10.1 Working of the software library.

The development library (sometimes called the dynamic library) holds newly
created or modified software entities, data units, or documentation. The production
library is the working library for the production of the source code and is usually
managed by the developers. This can be a collection of many independent librar-
ies—each owned by different developers. The items in the dynamic library are not
under configuration control.
The controlled library (sometimes called the production library) is used for
managing current baselines and for controlling changes made to them. It maintains
CI units promoted for integration. The controlled library is the entity for reten-
tion of approved or released CIs as well as the retention of approved and released
software documentation that will be delivered to the customer or distributed to
the marketplace.
The master library, also known as the static library, maintains archives of
various baselines released for general use. This library contains master copies and
authorized copies of software and documentation released for operational use.
The items in the master library should not be changed under any circumstances.
The master library usually consists of many different physical repositories or stor-
age media. The software repository is the entity that archives software and related
documentation at the close of the project. All released documentation and software
in the master library should be backed up. The working interfaces of the various
software libraries are shown in Figure 10.1.
The status accounting activity will account for all of the software documenta-
tion and code in the various library segments and report their status at any given
time, including the changes under way, approved, or incorporated.

Summary

The principles of SCM revolve around three key components: version control, system
building, and release management. Version control is simply the automated act of
tracking the changes of a particular file over time. Version control gives the ability

6518 Book.indb 133 12/30/14 1:24 PM

 134 SCM: Advanced Concepts

to trace the history of all CIs in a system and to recreate any previous version of
a file. The system build produces the product that is given to clients or shipped to
customers. Software release management encompasses the identification, packag-
ing, and delivery of the elements of a product like the executables, documentation,
release notes, and configuration data.
Two other important aspects of SCM are interface control and subcontractor
control. Interface control is the process of identifying, documenting, and control-
ling all performance, functional, and physical attributes relevant to the interfacing
of two or more products provided by one or more organizations. Subcontractor
control is an activity that establishes the procedures for ensuring the quality and
completeness of products and components of the system that are being developed
by a subcontractor or bought directly from the market. Both interface control and
subcontractor control procedures should be described in the SCM plan.
This chapter also describes the different types of software libraries and the role
they play in the practice of SCM.

References

[1] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std-610–1990),

IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway,
NJ: IEEE, 2003.
[2] Sommerville, I., Software Engineering (9th Edition), Reading, MA: Addison-Wesley Pub-
lishing Company, 2011.
[3] EIA, National Consensus Standard for Configuration Management (EIA 649), Arlington,
VA: Electronic Industries Alliance, 1998.
[4] U.S. Department of Defense, Configuration Management Data Interface (MIL-STD-2549),
1997.
[5] NASA, NASA Software Documentation Standard (NASA-STD-2100-91), Washington,
D.C.: National Aeronautics and Space Administration, 1991.
[6] Department of Defense, Configuration Management Practices for Systems, Equipment,
Munitions and Computer Programs (MIL-STD-483B), 1985.
[7] Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons,
Inc., 1992.
[8] Whitgift, D., Methods and Tools for Software Configuration Management, Chichester,
England: John Wiley & Sons, 1991.

Selected Bibliography

Ben-Menachem, M., Software Configuration Management Guidebook, New York: McGraw-

Hill, 1994.
Berlack, H. R., Software Configuration Management, New York: John Wiley & Sons, Inc., 1992.
Bourque, P., and R. E. Fairley (eds.), Guide to the Software Engineering Body of Knowledge,
Version 3.0, IEEE Computer Society, 2014; www.swebok.org.
Department of Defense, Military Handbook: Configuration Management Guidance [MIL-
HDBK-61A (SE)], 2001.
EIA, National Consensus Standard for Configuration Management (EIA 649), Arlington, VA:
Electronic Industries Alliance, 1998.

6518 Book.indb 134 12/30/14 1:24 PM

 Summary135

IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York: John
Wiley & Sons, 2002.
Pressman, R. S., Software Engineering: A Practitioner’s Approach (8th Edition), New York:
McGraw-Hill, 2014.
Sommerville, I., Software Engineering (9th Edition), Reading, MA: Addison-Wesley Publish-
ing Company, 2011.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

6518 Book.indb 135 12/30/14 1:24 PM

6518 Book.indb 136 12/30/14 1:24 PM
 C h a p t e r 11

SCM Standards

Introduction

Configuration management got its start in the U.S. defense industry as a technique to
resolve problems of poor quality, wrong parts ordered, and parts not fitting, which
were leading to inordinate cost overruns. In 1962, the U.S. Air Force published the
first standard on CM—AFSCM 375-1. The AFSCM 375-1 identified CM as the
key element in the design, development, testing, and operation of the item to be
delivered, because CM procedures facilitated better communication and prevented
uncontrolled change. In 1964, the National Aeronautics and Space Administration
(NASA) developed a CM standard (NPC 500-1) that was based on the AFSCM
375-1, for the design and development of the Saturn V spacecraft. This standard
played an instrumental role in the Saturn V and Apollo space programs. During
the same time the U.S. Army came out with its version of a CM standard (AMCR
11-26), and in 1965 the U.S. Navy followed suit with its standard NAVMATINST
4130.1 (Configuration Management Policy and Guidance Manual). In 1968, four
major standards related to CM were published:

• Department of Defense Directive (DOD D) 5010.19–Configuration

Management;
• MIL-STD-480–Configuration Control Engineering Changes, Deviations
and Waivers;
• MIL-STD-482–Configuration Status Accounting Data Elements & Related
Features;
• MIL-STD-490–Specification Practices.

These standards gave a new thrust to the practice of CM and were integrated
into defense contracts, so that not only the military used these standards internally,
but also the defense industry (the government contractors and commercial corpo-
rations who supplied materials and equipment to the military) started subscribing
and implementing these standards.
In 1971, the U.S. Air Force issued MIL-STD-483—Configuration Management
Practices for Systems, Equipment, Munitions, & Computer Programs. This was the
first standard that recognized CM of both hardware and software. Even though
the defense industry, through various associations, such as the Electronics Indus-
tries Association (EIA), the Aerospace Industries Association (AIA), the National
Security Industrial Association (NSIA), and the American Electronics Association

137

6518 Book.indb 137 12/30/14 1:24 PM

 138 SCM Standards

(AEA) were reviewing the military standards at that time, it was not until 1988
that commercial standards began to appear.
The proliferation of military standards had a number of drawbacks, and it has
been argued that the large number of standards, nearly 30,000 by 1990, imposed
unnecessary restrictions and increased costs on contractors and impeded the incor-
poration of the latest technology. In 1988, the assistant secretary of defense for
acquisition, Dr. Costello, wrote a memo indicating that the government should get
out of the standards-writing business and entrust the job of developing standards to
the organizations that were developing standards on various topics. He also stated
that the military would use the standards written by organizations like EIA, IEEE,
the Society of Automotive Engineers (SAE), ANSI, and ISO for procuring materi-
als from the commercial market. These organizations had a good track record at
developing standards. For example, EIA had written many standards on electron-
ics, electrical, and communications protocols. SAE had developed standards on
automotive development and related topics. IEEE was one of the pioneers in the
development of software standards. Thus, commercial standards on CM from these
organizations began to appear.
In 1994, responding to heightened criticism of the increasing number of mili-
tary standards, U.S. Secretary of Defense William Perry issued a memorandum that
prohibited the use of most defense standards without a waiver, and many defense
standards were subsequently canceled. In their place, the DOD encouraged the use
of industry standards. Military systems were then required to use “performance
specifications” that described the desired features of the weapon, as opposed to
requiring a large number of defense standards.
Now, there are hundreds of CM standards available, covering every aspect of
CM. A search by the author at the site of Global Engineering Documents, one of
the largest vendors of technical standards, for CM standards brought up 151 stan-
dards. Some of the popular military and commercial standards are listed as follows.

• DOD-STD-2167A—Defense System Software Development (canceled);

• DOD-STD-2168—Defense System Software Quality Program (canceled);
• MIL-STD-973—Configuration Management, 1990 (canceled);
• MIL-STD-498—Software Development and Documentation, 1994 (canceled);
• MIL-HDBK-61A (SE)—Military Handbook for Configuration Management
Guidance, 2001;
• MIL-STD-2549—Configuration Management Data Interface, 1997;
• MIL-STD-480B—Configuration Control Engineering Changes, Deviations
and Waivers, 1988 (canceled);
• MIL-STD-481B—Configuration Control Engineering Changes (Short Form),
Deviations and Waivers, 1988 (canceled);
• MIL-STD-482—Configuration Status Accounting Data Elements & Related
Features, 1974 (canceled);
• MIL-STD-483A—Configuration Management Practices for Systems, Equip-
ment, Munitions and Computer Programs, 1985 (superseded by MIL-STD-973);
• MIL-STD-973—Configuration Management, 1992 (superseded by EIA-649);
• M IL-ST D - 490A— Specification Practices, 1985 (superseded by
MIL-STD-961E);

6518 Book.indb 138 12/30/14 1:24 PM

 Introduction139

• MIL-STD-1521B—Technical Reviews and Audits for Systems, Equipment

and Computer Programs, 1985 (canceled);
• MIL-STD-961E—Defense and Program-Unique Specifications Format and
Content, 2003;
• RTCA DO/178B-92—Software Considerations in Airborne Systems and
Equipment Certification;
• NATO STANAG 4159—Configuration Management, 1992;
• STANAG 4427 Ed. 2—Introduction of Allied Configuration Management
Publications (ACMPs), 2007;
• ACMP-1 Ed. 2—NATO Requirements for the Preparation of Configuration
Management Plans, 2007;
• ACMP-2 Ed. 2—NATO Requirements for Configuration Identification, 2007;
• ACMP-3 Ed. 2—NATO Requirements for Configuration Control—Engineer-
ing Changes, Deviations and Waivers, 2007;
• ACMP-4 Ed. 2—NATO Requirements for Configuration Status Accounting
and Configuration Data Management, 2007;
• ACMP-5 Ed. 2—NATO Requirements for Configuration Audits, 2007;
• ACMP-6 Ed. 2—NATO Configuration Management Terms and Definitions,
2007;
• ACMP-7 Ed. 2—NATO Configuration Management Guidance on the Appli-
cation of ACMPs 1 to 6, 2007;
• NATO NAT-PRC-2—Software Project Configuration Management Procedures;
• UK MOD DEF-STAN 05-57/2—Configuration Management Policy and Pro-
cedures for Defense Material, 1985;
• NASA-Sfw-DID-04—Software Configuration Management Plan Data Item
Description, NASA, 1986;
• NASA D-GL-11—Software Configuration Management for Project Manag-
ers, NASA, 1987;
• IEEE-Std-24765-2010—Systems and Software Engineering—Vocabulary,
2012;
• IEEE Std-828-2012—IEEE Standard for Configuration Management in Sys-
tems and Software Engineering, 2012;
• ANSI/IEEE Std-1042-1987—IEEE Guide to Software Configuration Man-
agement, 1987 (withdrawn);
• ANSI/IEEE Std-730-2014—IEEE Standard for Software Quality Assurance
Processes, 2014;
• ANSI/IEEE Std-730.1-1995—IEEE Guide for Software Quality Assurance
Planning, 1995 (withdrawn);
• ANSI/IEEE Std-1028-2008—IEEE Standard for Software Reviews and Audits,
2008;
• ISO/IEC/IEEE 12207-2008—ISO/IEC/IEEE Standard for Systems and Soft-
ware Engineering—Software Life Cycle Processes, 2008;
• ISO/IEC/IEEE 15288-2008—Systems and Software Engineering—System
Life Cycle Processes, 2008;
• ISO 9001: 2008—Quality Management Systems—Requirements, 2008;
• ISO 9000-3—Guidelines for the Application of ISO 9001 to the Development
and Maintenance of Software, 1997 (withdrawn);

6518 Book.indb 139 12/30/14 1:24 PM

 140 SCM Standards

• ISO/IEC 90003:2004—Software Engineering—Guidelines for the Applica-

tion of ISO 9001:2000 to Computer Software, 2004;
• ISO 10007—Quality Management—Guidelines for Configuration Manage-
ment, 2003.
• ISO/IEC TR 15846:1998—Information Technology—Software Life Cycle
Processes–Configuration Management, 1998;
• EIA-649-B—Configuration Management Standard, 2011;
• EIA-836-B—Configuration Management Data Exchange and Interoperabil-
ity, 2010;
• EIA CMB4-1A-84—Configuration Management Definitions for Digital Com-
puter Programs, 1984;
• EIA CMB4-2-81—Configuration Identification for Digital Computer Pro-
grams, 1981;
• EIA CMB4-3-81—Computer Software Libraries, 1981;
• EIA CMB4-4-82—Configuration Change Control for Digital Computer
Programs, 1982;
• EIA CMB5-A-86—Configuration Management Requirements for Subcon-
tractors/Vendors, 1986;
• EIA CMB6-1C-94—Configuration and Data Management References, 1994;
• EIA CMB6-2-88—Configuration and Data Management In-house Training
Plan, 1988;
• EIA CMB6-3-91—Configuration Identification, 1991;
• EIA CMB6-4-91—Configuration Control, 1988;
• EIA CMB6-5-88—Textbook for Configuration Status Accounting, 1988;
• EIA CMB6-6-96—Textbook for Reviews and Configuration Audits, 1996;
• EIA CMB6-8-88—Data Management In-house Training Course, 1988;
• EIA CMB6-9-90—Configuration and Data Management Training Course,
1990;
• EIA CMB7-1-91—Electronic Interchange of Configuration Management Data,
1991;
• EIA CMB7-2-91—Guidelines for Transitioning Configuration Management
to an Automated Environment, 1991;
• ESA PPS-05-09 Rev. 1—Guide to Software Configuration Management,
March, 1995;
• FAA-STD-021 (Rev. A) (Chg Notice 1)—Configuration Management (Con-
tractor Requirements), 1990;
• FEI-4—Software Configuration Management, 1983;
• NIST S.P. 500-161—Software Configuration Management—An Overview;
• BS 6488-84—Code of Practice for Configuration Management of Computer-
based Systems;
• JPL D-4011—Software Configuration Management Planning, December
1988.

As indicated in their descriptions, some of the above listed standards (mainly

MIL and DOD standards) have been canceled and cannot be used or referred to in
any formal agreement or contracts. They are referenced here because they contain
valuable information. Moreover, most of them are available on the Internet free of

6518 Book.indb 140 12/30/14 1:24 PM

 Military Standards141

cost. The following sections provide an overview of a few representative standards

from the list—both military and commercial.

Military Standards

The standards published by the U.S. Department of Defense are used by all NATO
countries and by countries that use military equipment, manufactured in the United
States. The next few sections discuss the following CM-related military standards:

• DOD-STD-2167A—Defense System Software Development (canceled);

• DOD-STD-2168—Defense System Software Quality Program (canceled);
• MIL-STD-973—Configuration Management (canceled);
• MIL-STD-498—Software Development and Documentation (canceled);
• MIL-HDBK-61A (SE)—Military Handbook for Configuration Management
Guidance;
• MIL-STD-2549—Configuration Management Data Interface;
• MIL-STD-480B—Configuration Control Engineering Changes, Deviations
and Waivers (canceled);
• MIL-STD-481B—Configuration Control Engineering Changes (Short Form),
Deviations and Waivers (canceled);
• MIL-STD-482—Configuration Status Accounting Data Elements & Related
Features (canceled);
• MIL-STD-973—Configuration Management, (Superseded by EIA-649);
• MIL-STD-1521B—Technical Reviews and Audits for Systems, Equipment
and Computer Programs (canceled);
• MIL-STD-961E—Defense and Program-Unique Specifications Format and
Content;

DOD-STD-2167A
This standard (which supersedes the DOD-STD-2167—Defense System Software
Development, 1985) establishes requirements to be applied during the acquisition,
development, or support of software systems. The requirements of this standard
apply to the development of CSCIs. Even though this standard was developed for the
DOD environment, it can be tailored to handle rapidly evolving software technol-
ogy and to accommodate a wide variety of state-of-the-practice software engineer-
ing techniques. The standard allows the user to incorporate the SCM plan into the
software development plan (SDP) or to treat it as a separate document. The benefit
of handling the SCM plan as part of the SDP is that, for the projects where SCM is
either tightly tied to development life cycle or where the SCM function is relatively
small, it allows the SCM plan to be placed in the SDP where it is more appropriate.

DOD-STD-2168
This standard contains requirements for the development, documentation, and imple-
mentation of a software quality program. This program includes planning for and

6518 Book.indb 141 12/30/14 1:24 PM

 142 SCM Standards

conducting evaluations of the quality of software, associated documentation, and

related activities and planning for and conducting the follow-up activities necessary
to assure timely and effective resolution of problems. This standard, together with
other military specifications and standards governing software development, CM,
specification practices, project reviews and audits, and subcontractor management,
provides a means for achieving, determining, and maintaining quality in software
and associated documentation.

MIL-STD-498
The purpose of this standard was to establish uniform requirements for software
development and documentation. This standard merged DOD-STD-2167A, DOD-
STD-7935A, and DOD-STD-1703 to define a set of activities and documentation
suitable for the development of both weapon systems and automated informa-
tion systems. This standard supersedes DOD-STD-2167A, DOD-STD-7935A, and
DOD-STD-1703.
A conversion guide from these standards to MIL-STD-498 is provided in Appen-
dix A. Other changes include improved compatibility with incremental and evolu-
tionary development models, improved compatibility with nonhierarchical design
methods; improved compatibility with computer-aided software engineering (CASE)
tools; alternatives to, and more flexibility in, preparing documents; clearer require-
ments for incorporating reusable software; introduction of software management
indicators; added emphasis on software supportability; and improved links to sys-
tems engineering. This standard is superseded by IEEE/EIA 12207.0, IEEE/EIA
12207.1 and IEEE/EIA 12207.2

MIL-HDBK-61A (SE)
This military handbook provides guidance and information to DOD acquisition
managers, logistics managers, and other individuals assigned responsibility for CM.
It helps them plan for and implement effective DOD CM activities and practices
during all life cycle phases of defense systems and CIs. It supports acquisition based
on performance specifications, and the use of industry standards and methods to
the greatest practicable extent. Revision B of this document is currently in draft
form and is being reviewed.
This military handbook’s content is structured to provide a comprehensive
guide (roadmap). After the initial three sections—Scope, Applicable Documents
and Definitions—the handbook is divided into the following major sections:

• CM Life Cycle Management and Planning (Section 4)—Since management

and planning are the keys to effective implementation of CM, Section 4 pro-
vides the focus for the entire handbook. It contains an overview of the CM
process, a discussion of CM’s relationships to other processes, and a synopsis
of government/contractor CM during the entire program life cycle. It addresses
global CM activities applicable to all phases such as planning, process imple-
mentation, and performance measurement.

6518 Book.indb 142 12/30/14 1:24 PM

 Military Standards143

• Major CM Functions (Sections 5–9.)—In support of Section 4, Sections 5–9

contain detailed information in the form of activity descriptions, activity mod-
els, principles and concepts, and activity guides (e.g., diagrams, checklists,
and tables) for the following topics: configuration identification, configuration
control, CSA, configuration verification, and audit and data management.

Appendix F of this handbook contains a comparison of the CM standards

such as ISO 10007, IEEE Std-828, and MIL-STD-973 against EIA-649. This
matrix is very useful as it gives the relative strengths and weaknesses of the four
CM standards.

MIL-STD-2549
This document establishes a standard interface for the delivery of, or access to,
electronic CM data. This interface prescribes the data elements, the data element
definitions, and the data element relationships that define the conceptual schema for
CM data. These interface requirements have been subdivided into data information
packets to support various CM needs. This standard applies to all activities respon-
sible for procuring, recording, maintaining, and disseminating CM information.

MIL-STD-480B
This standard establishes the requirements, formats, and procedures to be utilized
in the preparation of configuration control documentation. Included are require-
ments for the following:

• Maintaining configuration control of CIs, both hardware and software;

• Preparing and submitting engineering change proposals (ECPs), requests for
deviations (RFDs)/requests for waivers (RFWs), notices of revision (NORs),
and SCNs;
• Evaluating, coordinating, and approving or disapproving ECPs and RFDs/
RFWs applicable to the DOD—NDIs or commercial items.

This standard establishes configuration control requirements and procedures

applicable to the acquisition and modification of items procured by the DOD. This
standard is to be used by contractors and government activities to do the following:

• Establish and maintain effective configuration control of the approved con-

figuration identification;
• Propose engineering changes to CIs, both hardware and software, that are
designed, developed, or modified for DOD activities;
• Request deviations or waivers pertaining to such items;
• Prepare NORs and SCNs;
• Control the form, fit, and function of privately developed items used in CIs,
including NDI items.

6518 Book.indb 143 12/30/14 1:24 PM

 144 SCM Standards

MIL-STD-481B
This standard establishes requirements, formats, and procedures for the prepara-
tion, submission, and approval or disapproval of abbreviated ECPs. Where complete
descriptions of ECPs are required, MIL-STD-480 should be specified in contracts.
The purpose of this standard is to establish configuration control requirements
and procedures applicable to the acquisition and modification of items procured
by the DOD. It is intended that this standard be applied to contracts or orders for
procurement of the following:

• Multiapplication or standard items that were not developed as subdivisions

of a specific system;
• Items fabricated in accordance with a mandatory detail design that was not
developed by the fabricator;
• Privately developed items (e.g., COTS items), when the procuring activity has
determined that the application of change control to such items is necessary
and that the short form ECP is applicable.

MIL-STD-482
To assure the use of uniform, clearly defined status-accounting management infor-
mation throughout the DOD and the DOD-defense Industry interface, this stan-
dard prescribes status-accounting standard data elements, interim (nonstandard)
data elements, and their related data items, codes, use identifiers, and data chains
(referred to as “related features”). The data elements and related features are to
be used as the content of those CSA records prepared by or for the department or
agencies of DOD in accordance with the provisions of DOD Directive 5010.19 and
DOD Instruction 5010.21.

MIL-STD-973
This standard defines CM requirements that are to be selectively applied, as required,
throughout the life cycle of any CI that fits either of the following descriptions:

• Developed wholly or partially with government funds, including NDIs when

the development of technical data is required to support off-the-shelf equip-
ment of software;
• Designated for CM for reason of integration, logistics support, or interface
control.

This standard is superseded by EIA-649.

MIL-STD-1521B
This standard, which supersedes the MIL-STD-1521 (Technical Reviews & Audits
for Systems, Equipment, & Computer Software), prescribes the requirements for
the conduct of technical reviews and audits on systems, equipment, and computer

6518 Book.indb 144 12/30/14 1:24 PM

 International/Commercial Standards145

software. The program manager shall select the following technical reviews and
audits at the appropriate phase of program development:

• System requirements review (SRR);

• System design review (SDR);
• Software specification review (SSR);
• Preliminary design review (PDR);
• Critical design review (CDR);
• TRR;
• FCA;
• PCA;
• Formal qualification review (FQR);
• Production readiness review (PRR).

Technical reviews and audits defined in this standard are to be conducted in

accordance with this standard to the extent specified in the contract clauses, state-
ment of work (SOW), and the contract data requirements list.

MIL-STD-961E
This standard, which supersedes MIL-STD-490A, establishes the format and con-
tent requirements for the preparation of defense specification and program-unique
specifications prepared either by DOD activities or by contractors for the DOD.

International/Commercial Standards

There are a host of standards by many organizations like the EIA, the Electric Power
Research Institute (EPRI), the European Computer Manufacturers Institute (ECMI),
the Federal Aviation Authority (FAA), the Institute of Nuclear Power Operations
(INPO), the European Space Agency (ESA), the Nuclear Information & Records
Management Association (NIRMA), NASA, and North Atlantic Treaty Organiza-
tion (NATO). However, the usage of these standards is limited to the members of
those organizations. The most popular international standards on CM are those by
ANSI/IEEE and ISO. The next sections will describe the following popular inter-
national and commercial standards:

• EIA-649-B—Configuration Management Standard;

• IEEE Std-828-2012—IEEE Standard for Configuration Management in Sys-
tems and Software Engineering;
• ANSI/IEEE Std-1042-1987—IEEE Guide to Software Configuration
Management;
• ANSI/IEEE Std-730-2014—IEEE Standard for Software Quality Assurance
Processes;
• ANSI/IEEE Std-730.1-1995—IEEE Guide for Software Quality Assurance
Planning;
• ANSI/IEEE Std-1028-2008—Standard for Software Reviews and Audits;

6518 Book.indb 145 12/30/14 1:24 PM

 146 SCM Standards

• ISO/IEC/IEEE 12207-2008—ISO/IEC/IEEE Standard for Systems and Soft-

ware Engineering—Software Life Cycle Processes;
• ISO/IEC/IEEE 15288-2008—Systems and Software engineering—System
life cycle processes;
• ISO 9001: 2008—Quality Management Systems—Requirements;
• ISO/IEC 90003:2004—Guidelines for the Application of ISO 9001:2000 to
Computer Software;
• ISO 10007: 2003—Quality management—Guidelines for Configuration
Management.

EIA-649-B
This standard defines five CM functions and their underlying principles. The prin-
ciples, highlighted in text boxes, are designed to individually identify the essence
of the related CM functions and can be used collectively to create a checklist of
criteria to evaluate a CM program. In describing each CM function and its prin-
ciples, this standard utilizes neutral CM terminology, while also providing equiva-
lent terms that have historically been used in various product environments. There
is no intent to express preference for any particular set of terminology. This stan-
dard uses a neutral set of names for the phases of a product’s life cycle, which are
generic enough to be easily mapped to the myriad of different life cycle models in
use. Regardless of the titles chosen for the various life cycle phases, or whether the
product is a facility, software, an airplane, or a machine screw, at some time in its
history a product will go through all or most of these phases. The phases can have
considerable overlap, or the sequence of the phases might change or be repeated
(e.g., for product improvements and enhancements). Approved configurations of a
product can be in the build, distribution, operation, and disposal phases simultane-
ously, and changes to those configurations may occur during all life cycle phases.
Appropriate application of CM functions enables a user of this standard to plan
and implement a CM program for a product, project, or enterprise. The degree to
which each of the CM principles applies to a product varies over the product’s life
cycle. Some principles do not apply during every phase of the product’s life cycle
(e.g., configuration verification and audit principles are not applicable in the concep-
tion or definition phases). The degree of rigor and techniques used in implementing
CM is commensurate with the type of product and its application environment as
defined by program requirements.

IEEE Std-828-2012
This standard establishes the minimum requirements for processes for CM in
systems and software engineering. The application of this standard applies to any
form, class, or type of software or system. This revision of the standard expands
the previous version to explain CM, including identifying and acquiring CIs, con-
trolling changes, reporting the status of CIs, as well as software builds and release
engineering. Its predecessor defined only the contents of a software CM plan. This
standard addresses what CM activities are to be done, when they are to happen in
the life cycle, and what planning and resources are required. It also describes the

6518 Book.indb 146 12/30/14 1:24 PM

 International/Commercial Standards147

content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008

(Standard for Systems and Software Engineering—Software Life Cycle Processes)
and ISO/IEC/IEEE 15288:2008 (Systems and Software Engineering System Life
Cycle Processes) and adheres to the terminology in ISO/IEC/IEEE Std. 24765 and
the information item requirements of IEEE Std. 15939.

ANSI/IEEE Std-1042-1987
This is the most comprehensive international standard available on SCM. This stan-
dard describes the application of CM disciplines to the management of software
engineering projects. SCM consists of two major aspects—planning and implemen-
tation. For those planning SCM activities, this standard provides insights into the
various factors that must be considered. Users implementing SCM disciplines will
find suggestions and detailed examples of SCM plans in this standard. This standard
introduces the essential concepts of SCM, particularly those of special significance
(for example, libraries and tools) to software engineering. It then presents the plan-
ning for SCM in terms of documenting a plan following the outline of the ANSI/
IEEE Std-828, so that a user who is unfamiliar with the disciplines of SCM can
gain valuable insights into the issues. For those preparing SCM plans, the second
part of the guide provides sample plans for consideration.

ANSI/IEEE Std-730-2014
Requirements for initiating, planning, controlling, and executing the SQA pro-
cesses of a software development or maintenance project are established in this
standard. This standard is harmonized with the software life cycle process of ISO/
IEC/IEEE 12207:2008 and the information content requirements of ISO/IEC/IEEE
15289:2011.

ANSI/IEEE Std-730.1-1995
This guide explains and clarifies the contents of each section of a SQA plan (SQAP)
that satisfies the requirements of IEEE Std-730-1989. The guide supersedes IEEE
Std-983-1986 and does not constitute further requirements than those stated in
IEEE Std-730-1989. An organization can claim compliance with IEEE Std-730-1989
without following this guide completely. This guide presents the consensus of those
in the software development and maintenance community with expertise or expe-
rience in generating, implementing, evaluating, and modifying SQAPs. The SQAP
should describe the plans and activities for the SQA staff. The SQA staff observes
the development process and reports deficiencies observed in the procedures and
the resulting products.

ANSI/IEEE Std-1028-2008
This standard provides definitions and uniform requirements for review and audit
processes. It does not establish the need to conduct specific reviews or audits; that
need is defined by local policy. Where specific reviews and audits are required,

6518 Book.indb 147 12/30/14 1:24 PM

 148 SCM Standards

standard procedures for their execution must be defined. This standard provides
definitions for review and audit purposes that are applicable to products and pro-
cesses throughout the software life cycle. Each organization should specify where
and when this standard applies and any intended deviations from this standard.
This standard defines five types of software reviews and audits, together with
procedures required for the execution of each type. It is concerned only with the
reviews and audits; it does not define procedures for determining the necessity of
a review or audit, nor does it specify the disposition of the results of the review or
audit. Review types include management reviews, technical reviews, inspections,
and walk-throughs. This standard is meant to be used either in conjunction with
other IEEE software engineering standards or as a stand-alone definition of software
review and audit procedures. In the latter case, local management must determine
the events that precede and follow the actual software reviews and audits.

ISO/IEC/IEEE 12207-2008
This standard establishes a common framework for software life cycle processes,
with well-defined terminology, that can be referenced by the software industry. It
contains processes, activities, and tasks that are to be applied during the acquisition
of a software product or service and during the supply, development, operation,
maintenance, and disposal of software products. Software includes the software
portion of firmware.
This standard applies to the acquisition of systems and software products and
services, to the supply, development, operation, maintenance, and disposal of soft-
ware products and the software portion of a system, whether performed internally
or externally to an organization. Those aspects of system definition needed to pro-
vide the context for software products and services are included. This standard also
provides a process that can be employed for defining, controlling, and improving
software life cycle processes. The processes, activities and tasks of ISO/IEC/IEEE
12207-2008—either alone or in conjunction with ISO/IEC 15288—may also be
applied during the acquisition of a system that contains software.

ISO/IEC/IEEE 15288:2008
This standard establishes a common framework for describing the life cycle of sys-
tems created by humans. It defines a set of processes and associated terminology.
These processes can be applied at any level in the hierarchy of a system’s structure.
Selected sets of these processes can be applied throughout the life cycle for managing
and performing the stages of a system’s life cycle. This is accomplished through the
involvement of all interested parties, with the ultimate goal of achieving customer
satisfaction. ISO/IEC 15288:2008 also provides processes that support the defini-
tion, control, and improvement of the life cycle processes used within an organiza-
tion or a project. Organizations and projects can use these life cycle processes when
acquiring and supplying systems. This standard concerns those systems that are
man-made and may be configured with one or more of the following: hardware,
software, data, humans, processes (e.g., processes for providing service to users),

6518 Book.indb 148 12/30/14 1:24 PM

 International/Commercial Standards149

procedures (e.g., operator instructions), facilities, materials, and naturally occur-

ring entities. When a system element is software, the software life cycle processes
documented in ISO/IEC 12207:2008 may be used to implement that system element.
ISO/IEC 15288:2008 and ISO/IEC 12207:2008 are harmonized for concurrent use
on a single project or in a single organization.

ISO 9001:2008
ISO 9001:2008, which replaced ISO 9001:2000, is a model for QA when con-
formance to specified requirements is to be assured by the supplier during design,
development, production, installation, and servicing. ISO 9001:2008 specifies
requirements for a quality management system where an organization needs to
demonstrate its ability to consistently provide product that meets customer and
applicable statutory and regulatory requirements and aims to enhance customer
satisfaction through the effective application of the system, including processes for
continual improvement of the system and the assurance of conformity to customer
and applicable statutory and regulatory requirements. This standard specifies qual-
ity system requirements for use where a supplier’s capability to design and supply
conforming product needs to be demonstrated. The requirements specified are
aimed primarily at achieving customer satisfaction by preventing nonconformity
at all stages from design through to servicing. ISO 9000 is not a standard that is
specific to software development. It is a general standard and can be tailored to any
industry. This standard does not mention the term CM anywhere in it but contains
most CM concepts. A few examples are detailed as follows:

• There should be a mechanism to control quality system documents. This

mechanism should approve documents before they are distributed, provide
the correct version of documents at points of use, review and reapprove docu-
ments whenever they are updated, specify the current revision status of the
documents, monitor documents that come from external sources, prevent
the accidental use of obsolete documents, and preserve the usability of your
quality documents.
• All design changes and modifications shall be identified, documented, reviewed,
and approved by authorized personnel before their implementation.
• The documents and data shall be reviewed and approved for adequacy by
authorized personnel prior to issue. A master list or equivalent document
control procedure identifying the current revision status of documents shall
be established.
• Where and to the extent that traceability is a specified requirement, the sup-
plier shall establish and maintain documented procedures for unique identifi-
cation of individual product or batches. This identification shall be recorded.
• Nonconforming products shall be reviewed in accordance with documented
procedures. They may be reworked to meet the specified requirements, accepted
with or without repair by concession, regarded for alternative applications,
or rejected or scrapped.
• The supplier shall implement and record any changes to the documented pro-
cedures resulting from corrective and preventive action.

6518 Book.indb 149 12/30/14 1:24 PM

 150 SCM Standards

• The organization should maintain quality system records and should be able
to prove that requirements have been met using the records. A procedure to
control the records should be developed, and it must be ensured that all the
records are useable.
• The organization should manage design and development changes by identi-
fying, recording, reviewing, verifying, validating, and approving the changes
in product design and development.
• The organization should identify and track its products by establishing, main-
taining, and recording the identity of the products.
• The organization should control nonconforming products by developing a
procedure to control nonconforming products, identifying and controlling
the nonconforming products, reverifying the nonconforming products that
were corrected, controlling nonconforming products after delivery or use,
and maintaining records of nonconforming products.
• Organizations must correct actual nonconformities by reviewing the noncon-
formities, finding out what causes the nonconformities, evaluating whether
corrective action is necessary, developing corrective actions to prevent recur-
rence, recording the results that corrective actions achieve, and examining
the effectiveness of corrective actions.

All requirements of ISO 9001:2008 are generic and are intended to be applicable
to all organizations, regardless of type, size, and product provided.

ISO/IEC 90003: 2004

The ISO 9000 series of standards were not primarily designed for software but for
manufacturing processes. ISO 9001 is the model for QA in design and develop-
ment, production, installation, and servicing (or, in other words, manufacturing
processes, which have design aspects). ISO/IEC 90003:2004 provides guidance
for organizations in the application of ISO 9001:2000 to the acquisition, sup-
ply, development, operation, and maintenance of computer software and related
support services. ISO/IEC 90003:2004 does not add to or otherwise change the
requirements of ISO 9001:2000. The guidelines provided in ISO/IEC 90003:2004
are not intended to be used as assessment criteria in quality management system
registration or certification.
The application of ISO/IEC 90003:2004 is appropriate to software that is part
of a commercial contract with another organization, a product available for a market
sector, used to support the processes of an organization, embedded in a hardware
product, or related to software services. Some organizations may be involved in
all the above activities; others may specialize in one area. Whatever the situation,
the organization’s quality management system should cover all aspects (software
related and nonsoftware related) of the business. ISO/IEC 90003:2004 identifies
the issues that should be addressed and is independent of the technology, life cycle
models, development processes, sequence of activities, and organizational structure
used by an organization.
The standard ISO 9000-3 contains guidelines for the application of ISO 9001
to the development, supply, and maintenance of software. This standard mentions

6518 Book.indb 150 12/30/14 1:24 PM

 Summary151

identification of CM procedures as a part of quality planning, mentions the need to

develop a SCM plan, and stresses the importance of bringing the various artifacts
under configuration control prior to use. For CM functions and procedures this
standards refers to ISO 10007:2003.

ISO 10007: 2003

ISO 10007:2003 gives guidance on the use of CM within an organization. It is
applicable to the support of products from concept to disposal. It first outlines the
responsibilities and authorities before describing the CM process, which includes
CM planning, configuration identification, change control, CSA, and configuration
audit. Since ISO 10007:2003 is a guidance document, it is not intended to be used
for certification or registration purposes.
ISO 10007 defines CM as a management discipline that applies technical and
administrative direction to the development, production, and support life cycle of
a CI. The main objective of CM is to document and provide full visibility of the
product’s present configuration and on the status of achievement of its physical and
functional requirements. Another objective is that everyone working on the project
at any time in its life cycle uses correct and accurate documentation.
This standard is applicable to the support of projects from concept to design,
development, procurement, production, installation, operation, and maintenance
and to the disposal of products. The application of CM may be tailored to suit indi-
vidual projects, taking into account the size, complexity, and nature of the work.

Summary

The ANSI/IEEE standards are the most widely used SCM standards, and the cov-
erage of software CM and its functions is quite elaborate and comprehensive. ISO
9000-3 and ISO 10007 provide another set of very good CM standards. The EIA-
649-B is perhaps the most readable SCM standard available. The DOD and MIL
standards are mainly used in defense industry projects, and even though they could
be tailored for any project their use is generally limited to the defense industry and
military organizations within and outside the United States.
The SCM standards (most preferably EIA-649-B) are the starting point for the
practice of CM and related functions in any project or organization. It is the first
place that one should look for guidance when one is starting a CM program. Unless
your organization does not deal in the defense industry, then it would be better
to base your SCM system on one of the commercial standards like ANSI/IEEE or
ISO. This is because these standards are written for the entire industry (whereas
the DOD standards were written for their specific segments of industry), and hence
they are more flexible and can be customized more easily to suit your needs. Also,
these standards have greater potential for timely updates than the DOD standards;
since they are used by the general industry, they must maintain relevance to the
current software engineering principles and practices or face obsolescence. The
CM standards have played a very crucial role in shaping the way in which CM is
being practiced today.

6518 Book.indb 151 12/30/14 1:24 PM

 152 SCM Standards

Selected Bibliography

Alain Abran, A., and Moore, J. W., (eds.), SWEBOK: Guide to the Software Engineering Body
of Knowledge (Trial Version), Los Alamitos, California: IEEE Computer Society, 2001.
Ben-Menachem, M., Software Configuration Management Guidebook, New York: McGraw-
Hill, 1994.
Berlack, R.H., Software Configuration Management, New York: John Wiley & Sons, Inc., 1992.
IEEE, IEEE Guide for Software Quality Assurance Planning (IEEE Std-730.1–1995), Piscat-
away, NJ: IEEE, 1995.
IEEE, IEEE Guide to Software Configuration Management (IEEE Std-1042-1987), Piscataway,
NJ: IEEE, 1987.
IEEE, IEEE Standard for Configuration Management in Systems and Software Engineering
(IEEE Std-828–2012), Piscataway, NJ: IEEE, 2012.
IEEE, IEEE Standard for Software Quality Assurance Plans (IEEE Std-730–1998), Piscataway,
NJ: IEEE, 1998.
IEEE, IEEE Standard for Systems and Software Engineering—Software Life Cycle Processes
(IEEE Std-12207-2008), Piscataway, NJ: IEEE, 2008.
IEEE, Standard for Software Reviews and Audits (IEEE Std-1028-2008), Piscataway, NJ:
IEEE, 2008.
IEEE, Systems and Software Engineering—System life cycle processes (IEEE Std-15288-2008),
Piscataway, NJ: IEEE, 2008.
Ince, D., ISO 9001 and Software Quality Assurance, London: McGraw-Hill Book Company,
1994.
ISO, Guidelines for the Application of ISO 9001:2000 to Computer Software (ISO 90003:2004),
Geneva: ISO, 2004.
ISO, Quality Management Systems—Requirements (ISO 9001:2008), Geneva: ISO, 2008.
ISO, Quality Management—Guidelines for Configuration Management (ISO 10007:2003),
Geneva: ISO, 2003.
Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York: John
Wiley & Sons, 2002.
Peach, R. W. (ed.), The ISO 9000 Handbook, New York: The McGraw-Hill Companies, Inc.,
1997.
Pressman, R. S., Software Engineering: A Practitioner’s Approach (8th Edition), New York:
McGraw-Hill, 2014.
Sommerville, I., Software Engineering (9th Edition), Reading, MA: Addison-Wesley Publish-
ing Company, 2011.
TechAmerica, Configuration Management Standard ANSI/EIA-649-B, Washington, D.C., 2011.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

6518 Book.indb 152 12/30/14 1:24 PM

 Chap te r 12

Software Process Improvement Models

and SCM

Introduction

A process is a series of interrelated activities that bring about a result or that are
directed toward a particular aim. Process improvement is the analysis and redesign
of processes to eliminate organizational problems and inefficiencies in small incre-
ments, over time, by improving one or two processes at a time. Process improvement
is done on an operational level (as opposed to radical reengineering, which is done
on a strategic level) and is carried out primarily by the people most involved in the
process. The incremental process improvement approach builds in small successes
that motivate teams to continue. Failure, if it occurs, has less potential to do serious
damage because scope is limited to one or two processes at a time.
Process improvement models define the various processes and activities that will
help an organization to move from a stage of total confusion, lack of discipline, and
ad hoc processes to a stage where the organization has well-defined and mature
processes that help the organization not only to deliver high-quality products and
services repeatedly but also to continuously improve the quality of the products and
services and efficiency of the organization.
The software process improvement models assess the current state of an orga-
nization and determine where it belongs in the process maturity scale. Then these
models give specific guidelines to move from the current state to a process maturity
level where the organizations have the necessary processes to continuously improve
its products and services.
This section describes some of the most common process assessment and
improvement models and standards. These include CMM, CMMI, ISO/IEC 15504
(formerly SPICE), BOOTSTRAP, Trillium, ITIL, COBIT, and SWEBOK. We will
examine the role of CM in process improvement and how the above-mentioned
process improvement and assessment models relate CM and process improvement.

CMM

The CMM for software describes the principles and practices underlying software
process maturity and is intended to help software organizations improve the matu-
rity of their software processes in terms of an evolutionary path from ad hoc, cha-
otic processes to mature, disciplined software processes. The CMM is organized

153

6518 Book.indb 153 12/30/14 1:24 PM

 154 Software Process Improvement Models and SCM

into five maturity levels—initial, repeatable, defined, managed, and optimizing.

A maturity level is a well-defined evolutionary plateau toward achieving a mature
software process. Each maturity level provides a layer in the foundation for con-
tinuous process improvement.
Except for level 1, each maturity level is decomposed into several key process
areas that indicate the areas an organization should focus on to improve its software
process. Key process areas identify the issues that must be addressed to achieve a
maturity level. Each key process area identifies a cluster of related activities that,
when performed collectively, achieve a set of goals considered important for enhanc-
ing process capability. CM is a key process area for level 2. So for any organization
that wants to achieve CMM level 2 or above, CM practices have to be performed
in accordance with the guidance provided by the CMM document.
According to the CMM documents, the CM practice should achieve the fol-
lowing four goals:

• Software CM activities are planned;

• Selected software work products are identified, controlled, and available;
• Changes to identified software work products are controlled;
• Affected groups and individuals are informed of the status and content of
software baselines.

To achieve the above goals the CMM requires certain commitments from the
organization—commitment to perform. The organizations should also have the
necessary resources (e.g., funding, tools, and training capabilities) to achieve these
goals—ability to perform. The CMM also specifies several activities to be performed
to achieve the goals—activities performed. The model also provides for mechanisms
for measuring, and reviewing data—measurement and analysis, and for analyzing,
statusing, and auditing—verifying implementation.

CMM Interactive (CMMI)

The CMMI project was formed to address the need that computer system devel-
opment environments were concerned with more than just software. The CMMI
product team’s mission was to combine three source models:

• The CMM for Software (SW-CMM) v2.0 draft C;

• The Systems Engineering Capability Model (SECM);
• The Integrated Product Development Capability Maturity Model (IPD-CMM)
v 0.98.

The combination of these models into a single improvement framework is intended

for use by organizations in their pursuit of enterprise-wide process improvement.
There are two types of CMMI model representations—staged and continuous.
The staged representation is the approach used in the SW-CMM. It is an approach
that uses predefined sets of process areas to define an improvement path for an
organization. This improvement path is described by a model component called

6518 Book.indb 154 12/30/14 1:24 PM

 ISO/IEC 15504155

a maturity level. A maturity level is a well-defined evolutionary plateau toward

achieving improved organizational processes for a project (i.e., the project moves
through the maturity levels).
The continuous representation allows an organization to select a specific process
area and improve relative to it. The continuous representation uses capability levels
to characterize improvement relative to an individual process area. A capability level
is a well-defined evolutionary plateau toward achieving improved organizational
processes for a particular organization. An organization moves through the capa-
bility levels until it reaches the top.
CM comes under the “support” process area of CMMI. CMMI defines CM
as a discipline whose purpose is to establish and maintain the integrity of work
products using configuration identification, configuration control, CSA, and CAs.
The CM process area supports all process areas by establishing and maintain-
ing the integrity of work products using configuration identification, configuration
control, CSA, and CAs. The work products placed under CM include the products
that are delivered to the customer, designated internal work products, acquired
products, tools, and other items that are used in creating and describing these work
products. Examples of work products that may be placed under CM include plans,
process descriptions, requirements, design data, drawings, product specifications,
code, compilers, product data files, and product technical publications.
The specific goals for CM as defined in CMMI are listed as follows:

• Establish baselines: Baselines of identified work products are established.

• Track and control changes: Changes to the work products under CM are
tracked and controlled.
• Establish integrity: Integrity of baselines is established and maintained.

The specific goals are achieved by following a number of specific practices. The
practices for each specific goal of CM are:

• Establish baselines (SG 1):

1. Identify configuration items (SP 1.1-1).
2. Establish a CM System (SP 1.2-1).
3. Create or release baselines (SP 1.3-1).
• Track and control changes (SG 2):
1. Track change requests (SP 2.1-1).
2. Control configuration items (SP 2.2-1).
• Establish integrity (SG 3):
1. Establish CM records (SP 3.1-1).
2. Perform CAs (SP 3.2-1).

ISO/IEC 15504

ISO/IEC 15504 is a process improvement and assessment standard. This standard

was developed jointly by the Joint Technical Committee 1/Sub Committee (JTC1/
SC7) of the ISO and International Electrotechnical Commission (IEC). The work

6518 Book.indb 155 12/30/14 1:24 PM

 156 Software Process Improvement Models and SCM

was assigned to a group called WG10, which established a special project called
Software Process Improvement and Capability dEtermination (SPICE). The SPICE
project, established in 1993, developed a set of draft standards that finally (after
countless reviews and revisions) evolved into the ISO/IEC 15504 standard.
The ISO/IEC 15504 process model is divided into five categories—organizational
process (ORG), management process (MNA), customer-supplier process (CUS),
engineering process (ENG), and support process (SUP). Each of these processes is
divided into several process areas. CM comes under the support process—SUP. 2.
The purpose of SUP.2 is to establish and maintain the integrity of all of the
work products of a process or project. The successful implementation of the process
should lead to the following outcomes:

• Identifying, defining, and baselining all relevant items generated by the pro-
cess or project;
• Controlling modifications and releases;
• Recording and reporting the status of the items and modification requests;
• Ensuring the completeness and consistency of the items;
• Controlling storage, handling, and delivery of the items.

The standard defines nine best practices that will lead to the successful imple-
mentation of CM system. These include developing a CM strategy, establishing a
CM system, CI identification, maintaining the CI description and history, establish-
ing formal change management procedures, managing product releases, maintain-
ing the CI history, reporting configuration status, and managing the release and
delivery of CIs.
This model has six levels (0–5) of process capability—incomplete, performed,
planned and tracked, established, predictable, and optimizing. Since this model is
continuous, the CM must be performed at the different levels. To obtain level 1, CM
must be performed in such a way that the expected outcomes are achieved. Level
2 requires placing the work products under configuration control and developing
a CM plan. To obtain level 3, the CM procedures should be documented and the
resources required for performing CM must be made available. Level 4 requires
establishing metrics for measuring the performance of CM and controlling the
performance based on the measurements. At level 5, the CM metrics are used to
improve the CM performance and again used to measure this improved performance.

BOOTSTRAP

BOOTSTRAP is a method to evaluate and to improve the quality of the software

development and management processes of an organization. BOOTSTRAP is based
on the assumption that the capabilities of an organization increase one step after
the other. The concepts behind this approach were published by Watts Humphrey
while working for the Software Engineering Institute (SEI). The CMM distinguishes
five levels of process quality, while the CMMI has six levels. This model is now the
software process standard in the United States. BOOTSTRAP uses the same basic

6518 Book.indb 156 12/30/14 1:24 PM

 Trillium Model157

principles. The reference model has been extended cover the requirements imposed
by ISO 9000. BOOTSTRAP does not only deliver the maturity level, but also a
detailed capability profile of the organization and the projects investigated.
BOOTSTRAP adopts a process model that addresses the processes and prac-
tices for the organization and the project. The process areas are categorized into
organization, methodology, and technology. The process categories are comprised
of process areas that contain activities and best practices. The methodology process
is again divided into three process areas—process engineering, product engineering,
and engineering support functions. Each of these process areas contains various
activities. Configuration and change management is an activity under engineering
support functions. The BOOTSTRAP process model contains many best practices
for the configuration and change management activity. These are very similar to
those of ISO/IEC 15504.
The BOOTSTRAP model has five maturity levels—initial, repeatable, defined,
managed, and optimizing. The process areas are not confined to a single level but
cover several levels.

Trillium Model

The goal of the Trillium Model is to provide a means to initiate and guide a con-
tinuous improvement program. The model is used in a variety of ways:

• To benchmark an organization’s product development and support process

capability against best practices in the industry;
• In self-assessment mode, to help identify opportunities for improvement within
a product development organization;
• In precontractual negotiations, to assist in selecting a supplier.

This model and its accompanying tools are not in themselves a product develop-
ment process or life cycle model. Rather, the Trillium Model provides key industry
practices that can be used to improve an existing process or life cycle. The practices
in the Trillium Model are derived from a benchmarking exercise that focused on
all practices that would contribute to an organization’s product development and
support capability. Trillium has a telecommunications orientation; provides a cus-
tomer focus; provides a product perspective; covers CMM, ISO 9001, ISO 9000-
3, Bellcore’s TR-NWT-000179 and TA-NWT-001315, Malcom Baldrige National
Quality Award criteria, IEEE, and IEC standards; includes technological maturity;
includes additional Trillium-specific practices; and provides a roadmap approach
that sequences improvements by maturity.
The Trillium Model has been developed from a customer perspective, as per-
ceived in a competitive, commercial, environment. In this context, capability is
defined as the ability of a development organization to consistently deliver a product
or an enhancement to an existing product that meets customer expectations with
minimal defects for the lowest life cycle cost, and in the shortest time. A telecom-
munications product typically includes hardware, software, documentation, train-
ing, and support services.

6518 Book.indb 157 12/30/14 1:24 PM

 158 Software Process Improvement Models and SCM

The Trillium scale spans levels 1 through 5. The levels can be characterized in
the following way:

1. Unstructured: The development process is ad hoc. Projects frequently can-

not meet quality or schedule targets. Success, while possible, is based on
individuals rather than on organizational infrastructure (risk = high).
2. Repeatable and project-oriented: Individual project success is achieved
through strong project management planning and control, with emphasis on
requirements management, estimation techniques, and CM (risk = medium).
3. Defined and process-oriented: Processes are defined and used at the orga-
nizational level, although project customization is still permitted. Processes
are controlled and improved. ISO 9001 requirements such as training and
internal process auditing are incorporated (risk = low).
4. Managed and integrated: Process instrumentation and analysis is used as a
key mechanism for process improvement. Process change management and
defect prevention programs are integrated into processes. CASE tools are
integrated into processes (risk = lower).
5. Fully integrated: Formal methodologies are extensively used. Organizational
repositories for development history and process are utilized and effective
(risk = lowest).

Each level (except level 1) contains several capability areas, which, in turn, con-
tain roadmaps that are comprised of activities. This is very similar to the CMM.
Each capability area spans multiple levels. For example, the development practices
capability area spans levels 2, 3, and 5. The development practices capability area
contains the CM roadmap among another six roadmaps (development process,
development techniques, internal documentation, verification and validation, re-
use, and reliability management). The configuration management related activities
of the Trillium model are shown in Table 12.1.

Information Technology Infrastructure Library (ITIL)

ITIL is a globally recognized collection of best practices for information technology

(IT) service management. It provides a practical framework for identifying, planning,
delivering, and supporting IT services to the business. United Kingdom’s Central
Computer and Telecommunications Agency (CCTA) created ITIL in response to
growing dependence on information technology for meeting business needs and goals.
ITIL provides businesses with a customizable framework of best practices to
achieve quality service and overcome difficulties associated with the growth of IT
systems.
The primary objective of service management is to ensure that IT services are
aligned with the business needs and actively support them. It is important that IT
acts as an agent for change to facilitate business transformation. All organizations
that use IT depend on IT to be successful. If IT processes and IT services are imple-
mented, managed, and supported in the appropriate way, the business will be more
successful, suffer less disruption and loss of productive hours, reduce costs, increase
revenue, improve public relations, and achieve its business objectives.

6518 Book.indb 158 12/30/14 1:24 PM

 Information Technology Infrastructure Library (ITIL)159

Table 12.1 CM in Trillium Model

Level Criteria Description

2 Scope Source code is under CM control
All project and product (internal and external) documents are
under CM control
Function A board having the authority for managing the project’s
product baselines [i.e., a product configuration control board
(PCCB)] exists or is established
There is a function responsible for coordinating and
implementing CM for the project
Funding Adequate resources and funding are provided for performing
the CM activities
Planning A CM plan is prepared for each project according to a
documented procedure
A documented and approved CM plan is used as the basis for
performing the CM activities
Repository A CM system is established as a repository for product
baselines
The product repository ensures secure storage of configuration
items (e.g., code units and design documents) and the secure
and controlled retrieval of current and previous versions of
CIs
The product repository ensures the secure and controlled
retrieval of current and previous baselines
The status of CIs/units is recorded according to a documented
procedure
The product repository maintains records of the status and
change history of all CIs and baselines
Traceability There is traceability between design specifications and source
code and between design specifications and integration test
cases
Change control CRs and PRs for all configuration items/units are initiated,
recorded, reviewed, approved, and tracked according to a
documented procedure
CIs and baselines are changed formally according to a
documented procedure
Baselines Baseline(s) are created and released formally
Product baseline audits are conducted according to a
documented procedure
Reporting Standard reports documenting the CM activities and the
contents of the product baselines are developed and made
available to affected groups and individuals
3 Scope Plans, descriptions, product test procedures, requirements
specifications, design specifications, review results, and test
cases (e.g., integration, system and operation) are under CM
control
All development tools are under CM control
Traceability There is full forward and backward traceability between
all configuration items (e.g., design specification forward to
code units and design specification backward to requirement
specification)
5 Scope The complete development history (e.g., design decisions
and design rationale) is captured and maintained under CM
control

6518 Book.indb 159 12/30/14 1:24 PM

 160 Software Process Improvement Models and SCM

ITIL provides guidance throughout the service life cycle to help senior busi-
ness managers and IT managers achieve the objectives of service management and
address the key issues they face in a systematic way.
ITIL guidance is structured in five life cycle phases—service strategy, service
design, service transition, service operation, and continual service improvement.
The SCM processes are under service transition stage. These processes, described
in subsequent sections, are listed as follows:

• Change evaluation;
• Change management;
• Release and deployment management;
• Service asset and CM.

Change Evaluation
The purpose of the change evaluation process is to provide a formal, standardized
means of determining the performance of a service change in the context of likely
impacts on business outcomes, and on existing and proposed services and IT infra-
structure. Change evaluation assesses the actual performance of a change against its
predicted performance and identifies risks and issues related to the change. Change
evaluation is closely linked to change management. The main output of change evalu-
ation is an evaluation report, which is used to help change management personnel
decide whether to authorize a change. Formal change evaluation is not required for
all changes, and each service provider defines when this formal process should be
used and when the evaluation can be carried out as part of change management.
The main subprocesses of change evaluation are change evaluation prior to plan-
ning, change evaluation prior to build, change evaluation prior to deployment, and
change evaluation after deployment.

Change Management
Change management controls the life cycle of all changes, enabling beneficial changes
to be made with minimum disruption to IT services. Change management ensures
that changes are recorded and evaluated and that authorized changes are prioritized,
planned, tested, implemented, documented, and reviewed in a controlled manner.
The main subprocesses of the change management process are change management
support, assessment of change proposals, request for change (RFC) logging and
review, assessment and implementation of emergency changes, change assessment
by the change manager, change assessment by the change advisory board (CAB),
change scheduling and build authorization, change deployment authorization, minor
change deployment, post-implementation review, and change closure.

Release and Deployment Management

The purpose of the release and deployment management process is to plan, schedule,
and control the building, testing, and deployment of releases and to deliver new func-
tionality required by the business while protecting the integrity of existing services.

6518 Book.indb 160 12/30/14 1:24 PM

 Control Objectives for Information and Related Technology (COBIT)161

Effective release and deployment delivers significant business value by delivering

changes at optimized speed, risk, and cost and offering a consistent, appropriate,
and auditable implementation of usable and useful services. Release and deployment
management covers the whole build, test, and implementation of new or changed
services, from planning through to early life support. The subprocesses of this phase
are release management support, release planning, release build, release deployment,
early life support, and release closure.

Service Asset and CM

The purpose of service asset and CM (SACM) is to ensure that the assets required to
deliver services are properly controlled, and that accurate and reliable information
about those assets is available when and where it is needed. This information includes
details of how the assets have been configured and the relationships between assets.
SACM supports the business by providing the information needed to manage all CIs
across the whole of the service life cycle. This contributes to the success of all service
management processes, as well as providing IT management and the business with
the information needed to get maximum value from service assets. The scope of
SACM may extend to non-IT assets and to internal and external service providers,
where shared assets need to be controlled. To manage large and complex IT services
and infrastructures, SACM requires the use of a supporting system known as the
CM system. The main subprocesses of this phase are configuration identification,
configuration control, and configuration verification and audit. More information
about ITIL can be obtained from the ITIL home at http://www.itil-officialsite.com/.

Control Objectives for Information and Related Technology (COBIT)

COBIT is a framework developed by the Information Systems Audit and Control

Association (ISACA) for IT management and IT governance. COBIT (currently
version 5) is the only business framework for the governance and management of
enterprise IT. COBIT 5 builds and expands on COBIT 4.1 by integrating other
major frameworks, standards, and resources, including ISACA’s Val IT and Risk
IT, ITIL and related standards from ISO. Some of the benefits of using COBIT are
the following:

• Availability of high-quality information to support business decisions;

• Achievement of strategic goals and realization of business benefits through
the effective and innovative use of IT;
• Achievement of operational excellence through reliable, efficient application
of technology;
• Maintenance of IT-related risk at an acceptable level;
• Optimization of the cost of IT services and technology.

COBIT contains 34 high-level IT processes described in the COBIT model that

provide excellent guidance in establishing IT controls including those for SCM. The
key management jobs for CM in COBIT are the following:

6518 Book.indb 161 12/30/14 1:24 PM

 162 Software Process Improvement Models and SCM

• To establish and maintain a configuration model;

• To define CIs, attributes, business models, and relationships;
• To approve requests for new CIs and changes to existing ones;
• To register new CIs;
• To establish and maintain a configuration repository and baseline;
• To approve changes to CIs and the CM system;
• To produce status and configuration reports;
• To verify and review integrity of the configuration repository;
• To conduct configuration audits and report nonconformances.

These activities are each assigned to a person who is responsible, accountable,

consulted, and informed to ensure that the practices are not bypassed. For example,
establishing and maintaining a configuration model is the responsibility of the
configuration manager and IT administration head, while the CIO, head archi-
tect, business process owners, and auditors are consulted on that. The head of IT
operations is accountable for ensuring that the configuration model is established
and maintained. The model provides the roles and responsibilities of the key SCM
personnel such as the configuration manager, configuration analyst, configuration
administrator, CCB, CIO, head of IT operations, head of IT administration, head
architect, head of development, and business process owners.
COBIT provides extensive guidelines and advice on how to implement the vari-
ous CM activities, how to set up a CM system (CMS), and how to assign the various
CM tasks, how to create a CM database (CMDB) and a host of other best practices
to improve the efficiency and effectiveness of the CM system. More information
about COBIT is available at ISACA’s Web site, http://www.isaca.org/COBIT/.

Software Engineering Body of Knowledge (SWEBOK)

SWEBOK, a guide that establishes software engineering as a recognized engineer-

ing discipline, is aimed at promoting a consistent view of software engineering
worldwide. The guide (SWEBOK) is not the body of knowledge, as the body of
knowledge exists in the published literature. The purpose of the guide is to describe
the portion of the body of knowledge that is generally accepted, to organize that
portion, and to provide topical access to it. The body of knowledge is subdivided
into 15 knowledge areas (KAs), which can be broadly categorized into three. The
KAs are listed as follows:

• Development processes:
–– Software requirements;
–– Software design;
–– Software construction;
–– Software testing;
–– Software maintenance.
• Supporting processes:
–– SCM;
–– Software engineering management;

6518 Book.indb 162 12/30/14 1:24 PM

 Software Engineering Body of Knowledge (SWEBOK)163

–– Software engineering process;

–– Software engineering models and methods;
–– Software quality;
–– Software engineering professional practice.
• Engineering fundamentals:
–– Software engineering economics;
–– Computing foundations;
–– Mathematical foundations;
–– Engineering foundations.

SCM is a supporting-software life cycle process that benefits project manage-

ment, development and maintenance activities, and QA activities, as well as the
customers and users of the end product.
The SCM knowledge area is further subdivided into seven subareas, described
as follows:

• Management of the SCM processes: This subarea deals with topics like orga-
nizational context for SCM, constraints and guidance for SCM, planning for
SCM, SCM plans, and surveillance of SCM.
• Software configuration identification: Software configuration identification
identifies items to be controlled, establishes identification schemes for the
items and their versions, and establishes the tools and techniques to be used
in acquiring and managing controlled items. The topics in this subarea are
identifying items to be controlled and the software library.
• Software configuration control: Software configuration control is concerned
with managing changes during the software life cycle. The topics in this sub-
area are requesting, evaluating, and approving software changes and imple-
menting software changes and deviation and waivers.
• Software configuration status accounting: Software configuration status
accounting is an element of CM consisting of the recording and reporting of
information needed to manage a configuration effectively. The main topics
in this subarea are software configuration status information and software
configuration status reporting.
• Software configuration auditing: This consists of software functional con-
figuration auditing, software physical configuration audits, and in-process
audits of a software baseline.
• Software release management and delivery: The main topics of this subarea
are software building and software release management.
• Software CM tools: This subarea discusses the SCM tools. SCM tools can
be divided into three classes in terms of the scope at which they provide sup-
port: individual support, project-related support, and company-wide process
support.

The latest version of the SWEBOK is available free of cost in HTML format
(http://www.computer.org/portal/web/swebok/htmlformat) and in PDF format
(http://www.computer.org/portal/web/swebok).

6518 Book.indb 163 12/30/14 1:24 PM

 164 Software Process Improvement Models and SCM

Summary

CM is a vital discipline for all of the process improvement efforts and models that
exist today. Process improvement models and frameworks like CMM, CMMI,
SPICE, BOOTSTRAP, Trillium, ITIL, COBIT, and SWEBOK require a CM. To
achieve certification, the existence of formal CM and procedures is a must.

Selected Bibliography

Bell Canada, Trillium: Model for Telecom Product Development & Support Process Capability
(Release 3), Bell Canada, 1994.
Bourque, P., and R. E. Fairley (eds.), Guide to the Software Engineering Body of Knowledge,
Version 3.0, IEEE Computer Society, 2014; www.swebok.org.
Caputo, K., CMM Implementation Guide, Reading, MA: Addison-Wesley, 1998.
Chrissis, B. M., M. Konrad, and S. Shrum, Introduction to CMMI, Reading, MA: Addison
Wesley, 2003.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMI SM for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1),
Continuous Representation, Technical Report (CMU/SEI-2002-TR-001), Software Engi-
neering Institute, Carnegie Mellon University, 2001.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMI SM for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1),
Staged Representation, Technical Report (CMU/SEI-2002-TR-002), Software Engineer-
ing Institute, Carnegie Mellon University, 2001.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Systems Engineering, Software Engineering, and Integrated Product and
Process Development (CMMI-SE/SW/IPPD, V1.1), Continuous Representation, Techni-
cal Report (CMU/SEI-2002-TR-003), Software Engineering Institute, Carnegie Mellon
University, 2001.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Systems Engineering, Software Engineering, and Integrated Product and
Process Development (CMMI-SE/SW/IPPD, V1.1), Staged Representation, Technical
Report (CMU/SEI-2002-TR-004), Software Engineering Institute, Carnegie Mellon Uni-
versity, 2001.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Systems Engineering, Software Engineering, Integrated Product and Process
Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1), Continuous Represen-
tation, Technical Report (CMU/SEI-2002-TR-011), Software Engineering Institute, Carn-
egie Mellon University, Software Engineering Institute, Carnegie Mellon University, 2002.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Systems Engineering, Software Engineering, Integrated Product and Pro-
cess Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1), Staged Repre-
sentation, Technical Report (CMU/SEI-2002-TR-012), Software Engineering Institute,
Carnegie Mellon University, 2002.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Software Engineering (CMMI-SW, V1.1), Continuous Representation, Tech-
nical Report (CMU/SEI-2002-TR-028), Software Engineering Institute, Carnegie Mellon
University, 2002.
CMMI Product Team, Capability Maturity Model® Integration (CMMI SM), Version 1.1:
CMMISM for Software Engineering (CMMI-SW, V1.1), Staged Representation, Technical

6518 Book.indb 164 12/30/14 1:24 PM

 Summary165

Report (CMU/SEI-2002-TR-029), Software Engineering Institute, Carnegie Mellon Uni-

versity, 2002.
Garcia, S. M., Evolving Improvement Paradigms: Capability Maturity Models & ISO/IEC 15504
(PDTR), Software Engineering Institute, Carnegie Mellon University, 1996.
Marciniak, J. J. (ed.), Encyclopedia of Software Engineering (2nd Edition), New York: John
Wiley & Sons, 2002.
Paulk, M. C., A Comparison of ISO 9001 and the Capability Maturity Model for Software,
Technical Report (CMU/SEI-94-TR-12), Software Engineering Institute, Carnegie Mel-
lon University, 1994.
Paulk, M. C., et al., Capability Maturity ModelSM for Software, Version 1.1, Technical Report
(CMU/SEI-93-TR-024), Software Engineering Institute, Carnegie Mellon University, 1993.
Paulk, M. C., et al., Key Practices of the Capability Maturity ModelSM , Version 1.1, Technical
Report (CMU/SEI-93-TR-025), Software Engineering Institute, Carnegie Mellon Uni-
versity, 1993.
Pressman, R. S., Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill,
2001.
SEI, ISO/IEC 15504: Frequently Asked Questions, Software Engineering Institute, Carnegie
Mellon University, 1998.
Sommerville, I., Software Engineering, Reading, MA: Addison-Wesley Publishing Company,
2001.
Trillium Model Home Page (http://www.sqi.griffith.edu.au/trillium/).
Weber, C. V., et al., Key Practices of the Capability Maturity Model, Technical Report (CMU/
SEI-91-TR-25), Software Engineering Institute, Carnegie Mellon University, 1991.
Zahran, S., Software Process Improvement: Practical Guidelines for Business Success, Harlow,
England: Addison-Wesley, 1998.

6518 Book.indb 165 12/30/14 1:24 PM

6518 Book.indb 166 12/30/14 1:24 PM
 Ch a p t e r 13

SCM Plans (SCMPs)

Introduction

We have seen that once the SCM system is designed, it should be documented so
that the working of the SCM system, the procedures, and the functions, duties, and
responsibilities of each member are transparent and known to all members of the
SCM team, project team, the subcontractor’s team (if any), and others. This docu-
ment is called the SCMP or simply the plan.
An initial draft of the SCMP should be created and circulated among the vari-
ous groups involved in the project during the initial phases (i.e., during the analysis
or design phase). Once feedback from the various groups—project team, QA team,
management, and others—is obtained, it can be incorporated, and the approved
SCMP can be made available so that everybody is clear about the various SCM
procedures and their duties and responsibilities.
According to Bounds and Dart [1], the CM plan is one of the three keys to the
success of attaining a CM solution (the other two are the CM system and the CM
adoption strategy). It is generally the case that an SCM solution is part of a corporate-
wide process improvement plan and, as such, the solution is coordinated with that
effort. This means that the SCMP needs to be in agreement with any other plans
related to the corporate improvement effort.
An SCMP clearly describes how SCM is accomplished and how consistency
between a system’s configuration and the configuration records is achieved and
maintained. The SCMP is a central source of information for the SCM program.
The major benefits of creating a CM plan include an assurance that the appropriate
SCM processes are applied, the responsibilities for the various SCM activities are
assigned, detailed descriptions of these responsibilities are documented, accurate
knowledge concerning required resources are available, and a foundation for con-
tinued improvement is put in place.
The objective of the SCMP is to create and document a system that will describe
and specify, as accurately as possible, all tasks that are to be performed by the
agency that is responsible for the configuration of the system or product. Thus the
main function of the SCMP is to create an awareness among the various groups
involved in a software project about the SCM functions and how they are to be
performed in that project.
SCM is not a well-known subject and in most cases people—even people who
have been in the software profession for many years—are not aware of SCM and
how an SCM system works. So in order to create awareness among the project team
members, SCM team members, and other people who are in some way related to

167

6518 Book.indb 167 12/30/14 1:24 PM

 168 SCM Plans (SCMPs)

the project (such as the QA personnel), it is necessary to create a document that

describes how SCM will be practiced for the project. Thus the SCMP forms the
basis of training the personnel who are part of the project team and SCM team. It
will be used as a reference manual for the SCM functions. It will also be used in
the resolution of conflicts regarding the practice or implementation of SCM func-
tions in the project.
The SCMP can be either created for the organization or for each project. If the
plan is created for the entire organization, its suitability should still be assessed for
each project, and necessary modifications should be made. In the case of organiza-
tions where the projects that are carried out differ in nature, complexity, and size,
it is desirable to create separate plans for each project tailored to suit the needs and
characteristics of the project.

SCMP and the Incremental Approach

Some companies adopt what is called the incremental approach to SCM implemen-
tation. In the incremental approach, SCM functions are implemented in stages. The
system starts with just some of the components, say, a change- or problem-tracking
system or a source code control and revision management system. Then slowly, as
time progresses, the other components are introduced until the full spectrum of
SCM functionality is achieved.
The natural question when considering the incremental approach is how an
SCMP can be developed when the full SCM system is not being implemented.
Another question is why an SCMP is needed since many of the components will
not be part of the plan during the first phase of implementation.
In the author’s opinion, irrespective of whether the company chooses the big-
bang approach (where full SCM functionality is implemented in one shot) or the
incremental approach, it is always better to have an SCMP. This is because, even
for the incremental approach, the broad outline of what the final system will be
like must be decided at the outset. There is no need to go into the finer details of
the portions that are not being implemented in the first phase, but a very high-level
outline of how these missing components will fit into the final system and the cho-
sen implementation strategy (the when and how of implementing those functions)
should be documented. This is important because, if the different functions of the
SCM system are implemented without considering the overall picture (that is, the
effect of each subsystem on the overall SCM system), then the integration of the
different subsystems will not be seamless.
So, even when the incremental approach is used, the full SCM system should
be designed and the SCMP prepared based on a full implementation. Otherwise,
as components are added and full SCM functionality finally is reached, the SCM
tools will not be well-integrated.

SCMPs and SCM Tools

Another question that is often asked about SCMPs by companies using SCM tools
is whether the SCMP is really necessary. Here also the answer is, “yes.” The SCMP

6518 Book.indb 168 12/30/14 1:24 PM

 SCMPs and Standards169

is the document that records how the different SCM functions will be performed.
Only after analyzing and deciding how the SCM system should function, what its
functions will be and which functions will be automated, and the peculiarities of
each organization or project can the company decide which tool to use.
The SCMP has a section on SCM resources in which details are given about the
software tools, techniques, equipment, personnel, and training necessary for the
implementation of the specified SCM activities. The SCMP, as discussed earlier, is
the basis for SCM training and auditing of the SCM system. So it is still very impor-
tant to have an SCMP. In fact, the author strongly advocates training employees in
the fundamentals and concepts of SCM and in how the SCM functions are carried
out before training them in the tools. This will give the users a better understand-
ing of what they are doing and how their actions will affect others in the project.
In practice, if one is using a tool he or she can perform the SCM functions without
knowing the SCM concepts; the tool’s user manual is enough. If, however, users
want to know why they are performing a function, they need to be aware of the
SCM concepts.
So even though it is possible to use SCM tools without knowing much about
the SCM concepts and functions, a person who knows the SCM concepts is a better
user of the SCM tool than a person who has been told just to perform certain activi-
ties. There is always a difference between doing something just because somebody
is told to do it that way and doing something after knowing why a task has to be
performed and what will be the effect of that action.

SCMPs and Standards

Almost all CM standards advocate some sort of a document or plan. Except for
some minor differences, the format specified by most of the standards for the SCMP
is similar. According to a study conducted by Bounds and Dart [1], in which they
compared three standards (by IEEE, NASA, and DOD) based on six criteria (ease
of use, completeness, tailorability, consistency, correctness, and life cycle connec-
tion), the IEEE standard—IEEE Std-828-1998—had the best rating. IEEE Std-828-
1998 defined only the contents of an SCMP. It has since been revised. The revised
standard—IEEE Std-828-2012—expands the previous version to explain CM,
including identifying and acquiring CIs, controlling changes, and reporting the
status of CIs, as well as software builds and release engineering. It also addresses
what CM activities are to be done, when they are to happen in the life cycle, and
what planning and resources are required. In the revised version there is only an
annex (Annex D) that deals with the CM plan (CMP) and what it should contain.
According to IEEE Std-828-2012 the CMP should have the following sections:

• Introduction: This section should cover such topics as the purpose, scope,
relationship to the organization and other projects, key terms, and references;
• Criteria for identification of the CIs to which CM will be applied;
• Limitations and assumptions affecting the plan;
• CM responsibilities and authorities;
• Project organization;

6518 Book.indb 169 12/30/14 1:25 PM