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

 170 SCM Plans (SCMPs)

• CM responsibilities;
• Applicable policies, directives, and procedures;
• Planned activities, schedules, and resources;
• CMP maintenance.

For developing a CMP, the combination of IEEE Std-828–1998 and IEEE

Std-1042–1987 is still a better option than depending on the annex of the IEEE
Std-828-2012.
As mentioned before, many standards exist for SCMPs. In the following sec-
tions, we will examine four, comprising a representative sample of the lot:

• IEEE Std-828–1998, IEEE Standard for Software Configuration Manage-

ment Plans, and IEEE Std-1042–1987, IEEE Guide to Software Configura-
tion Management;
• MIL-HDBK-61A(SE)-2001, Military Handbook: Configuration Manage-
ment Guidance;
• EIA-649-B: 2011, National Consensus Standard for Configuration
Management;
• ISO 10007: 2003, Quality Management-Guidelines for Configuration
Management.

ANSI/IEEE Std-828–1998 and ANSI/IEEE Std-1042–1987

ANSI/IEEE Std-828–1998 is the standard for CMPs. Complementing this standard
is a guide—IEEE Guide to Software Configuration Management (ANSI/IEEE Std-
1042–1987)—that contains an explanation of the standard and sample SCMPs for
different kinds of projects. These two standards together form the most compre-
hensive standards available on SCM and SCMPs.
The IEEE standard is a very comprehensive standard on SCM, and it can be
customized easily to suit one’s needs. This standard intentionally addresses all lev-
els of expertise, the entire life cycle, other organizations, and the relationships to
hardware and other activities on a project.
The ANSI/IEEE Std-828–1998 provides a format for creating the SCMP. Accord-
ing to the standard, the SCMP should consist of six sections as shown in Table 13.1.
ANSI/IEEE Std-1042–1987, the guide to SCMPs, explains how Std-828 should
be implemented. This guide has several appendixes for different types of SCMPs
(e.g., real-time, critical projects, and maintenance projects) that can be customized
very easily to suit individual needs and requirements.

MIL-HDBK-61A (SE)-2001
The purpose of MIL-HDBK-61A (SE) is to assist configuration managers in plan-
ning for and implementing effective DOD configuration management 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.

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

 SCMPs and Standards171

Table 13.1 Format of SCMP per IEEE Std-828–1998

No. Section Name Description

1 Introduction Purpose of the plan, scope, definition of key terms, and
references.
2 SCM Management Describes the allocation of responsibilities and authorities for
SCM activities to organizations and individuals within the
project structure.
3 SCM Activities Identifies all functions and tasks required for managing the
configuration of the software system as specified in the scope of
the SCMP. Both technical and managerial SCM activities must be
identified.
4 SCM Schedules Establishes the sequence and coordination for the identified SCM
activities and for all events affecting the SCMP’s implementation.
5 SCM Resources Identifies the software tools, techniques, equipment, personnel,
and training necessary for the implementation of the specified
SCM activities.
6 SCMP Maintenance Identifies the activities and responsibilities necessary to ensure
continued SCM planning during the life cycle of the project.

According to MIL-HDBK-61A (SE), CM planning is a vital part of the prepa-

ration for the next phases of a program life cycle. The CMP documents the results
of that planning to enable it to be communicated and used as a basis in managing
the program CM activities.
Appendix A of this handbook provides guidance in the content, use, and main-
tenance of government CMPs (GCMPs). It also provides guidance in evaluating
contractor CMPs (CCMPs). In addition, the appendix provides two activity guides
that give the contents and guidance for writing GCMPs and CCMPs.
The primary objective of the GCMP is to document the planning for the gov-
ernment CM activity to take place during the upcoming phase and to schedule
specific actions necessary to implement those activities. The second purpose is to
communicate and coordinate the government’s intentions with the contractor or
contractors involved in the program so that efficient and effective interfacing pro-
cesses and working relationships may be established. The GCMP communicates to
the contractor, the government’s CM objectives for a given phase and the associated
risks if those objectives are not met. It describes the expected deployment and use
of the system or CI and indicates the CM process, systems, and methodologies the
government plans to use and the interfaces that the contractor will be expected to
establish. According to the handbook, the content of the GCMP should include the
following six sections: (1) introduction, (2) reference documents, (3) government
CM concept of operations and acquisition strategy, (4) CM organization, (5) data
management, and (6) government CM process.
The CCMP describes the contractor’s CM objectives, the value-adding CM
activities that will be employed to achieve them, and the means of measuring and
assuring that they are effectively accomplished. The CCMP should have the fol-
lowing sections: (1) introduction, (2) reference documents, (3) CM organization, (4)
CM phasing and milestones, (5) data management, (6) configuration identification,
(7) interface management, (8) configuration control, (9) CSA, (10) CAs, and (11)

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

 172 SCM Plans (SCMPs)

subordinate performing activity and vendor control. The handbook gives detailed
descriptions and phase-by-phase guidance for each section.

EIA-649-B: 2011
According to EIA-649-B, the purpose and benefits of CM planning and manage-
ment include the following:

• Assurance that the appropriate CM processes and activities are applied;

• Establishment of organizational responsibilities for CM activities;
• Identification of—and making available—necessary resources and facilities;
• Formation of a basis for continuous improvement;
• Enhanced maturity of the enterprise’s process.

EIA-649-B discusses in detail the requirements of the plan and considerations

that should be taken into account in its development. A CMP should not be a one-
size-fits-all document. Rather, it must be tailored to meet the needs of the agency
responsible for CM. In particular, EIA-649-B points out that a well-developed plan
will aid in the training of personnel in CM and will help explain the process to
outside personnel, such as upper-level management and auditors. A comprehensive
CMP that reflects efficient application of CM principles and practices to the identi-
fied context and environment would normally include the following topics:

• General product definition and scope;

• Description of CM activities and procedures for each major CM function—
configuration planning and management, configuration identification, con-
figuration change management, CSA, configuration verification and audit,
and CM of digital data;
• CM;
• Organization, roles, responsibilities, and resources;
• Definitions of terms;
• Programmatic and organizational interfaces;
• Deliverables, milestones, and schedules;
• Subcontract flow-down clauses;
• Definitions of terms.

If these topics are covered in detail in the plan, the CM program will have a
sound blueprint to guide its effective implementation.

ISO 10007: 2003

This international standard gives guidance on the use of CM in industry and its
interface with other management systems and procedures. This standard defines a
CMP as a document that sets out the organization and procedures for the CM of a
specific product or project. The standard states that the CM plan provides the CM
procedures that are to be used for each project and states who will undertake these

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

 SCMPs and Standards173

and when. The standard also states that the plan should be subjected to document
control procedures.
This standard specifies a format for the CM plan (Annex A-Recommended
Structure and Content of a Configuration Management Plan). According to ISO
10007, a CMP should have the six chapters listed in Table 13.2.
The standard also specifies that whenever an existing procedure or standard is
used, it should be referenced rather than repeated so that duplication can be avoided
and simplicity can be maintained. This is a good practice to follow irrespective of
which standard you are using, because it will make the SCMP simple and short,
and it will eliminate data duplication. For example, according to the preceding
standard, the audit procedures that will be followed have to be mentioned in Chap-
ter 6, CA. If the audit is conducted as per the ISO guidelines for auditing quality
systems, instead of defining and describing the auditing process, the plan can just
say that the SCM auditing will be done in accordance with the ISO 10011–1:1990,
ISO 10011–2:1990, and ISO 10011–3:1990 (ISO guidelines for auditing quality
systems, Parts 1, 2, and 3).
In a study conducted by Bounds and Dart [1], users of the CMPs were asked
whether CM procedures should be part of the CMP or separate. The overwhelming
response was that the procedures should be kept separate from the plan but that the
plan should reference the procedures. Although many reasons were cited for this,
the most common reasons were that separating the procedures allows the users to
focus only on what applies to them and makes maintenance of the procedures and
plan much easier. Respondents also stated that procedures should focus on how to
do something, whereas a plan should focus on what is to be done.
The same study recommended the use of IEEE standards as the best standards
to use in developing SCMPs for these reasons:

Table 13.2 Format of SCMP per ISO 10007

No. Chapter Name Description

1 Introduction Description of the system or CIs to which the plan
applies, a schedule of the CM activities, the purpose and
scope of the plan, list of related documents, and so on.
2 Policies and Procedures CM policies, CM organization and structure of the CCB
and the other committees, selection criteria for the CIs,
frequency, distribution, and control of reports and agreed
terminology.
3 Configuration Identification Family tree of the CIs, numbering conventions, baselines
to be established, and so on.
4 Configuration Control Organization and composition of the CCB, change
management procedures, and so on.
5 CSA Procedures for collecting, recording, processing, and
maintaining the data for status accounting reports,
definition of all CM reports, and so on.
6 CA List of audits to be conducted, the audit procedures, the
authorities and disciplines involved, format of the audit
reports, and so on.

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

 174 SCM Plans (SCMPs)

• The IEEE standard was written explicitly for use by anyone within the indus-
try, whereas the NASA and DOD standards were written for their specific
segments of industry.
• The IEEE standard is, by far, more complete than the other two standards
and is the only standard that can be treated as a stand-alone document.
• The IEEE standard has greater potential for timely updates than the other
standards since it is used by general industry.

Audit of the SCMP

An SCMP is a controlled document as well as a CI. So all document control proce-

dures that are applicable to a controlled document and all the change management
procedures that are applicable to a CI are applicable to the SCMP also. This means
that the distribution of the SCMP should be controlled. There should be a distribu-
tion list that contains the names of persons having a copy of the plan. Also, access
to the plan should be controlled. The level of control is decided based on the nature
of the project. If the plan is hosted on the company intranet or bulletin board, then
access to that should be controlled.
Another aspect is that changes to the plan should be done in accordance with
the change management procedures mentioned in the plan. When a change is imple-
mented the new versions should be made available to all who are in the distribution
list. If the plan is hosted on the intranet then it should be updated.
The SCMP should be subject to auditing. Like any other CI, the plan should
undergo the functional and physical CAs. Auditing ensures that the plan is complete
and correct and satisfies the requirements as described in the standard or standards
on which it is based.

How to Write a Good SCMP

Writing the SCMP is not an easy task. Good SCMPs take time; thorough knowl-
edge of SCM functions, the peculiarities of the project, and the organization; and
knowledge of other procedures such as auditing and testing. It is also not a task
that should be taken lightly because the practice of SCM functions in a project or
organization is based on the procedures and tasks specified in the SCMP. It is not
too strong a statement to say that the SCMP can make or break a project. A bad
and improperly designed SCMP will create unnecessary and cumbersome proce-
dures, and instead of assisting the development process and improving productivity,
it will result in confusion and an increased workload for the project team and the
SCM team. In the following paragraphs, we look at some practices and tips that
will help in the creation of good SCMPs.
The most important decision that affects the quality of an SCMP is the capa-
bility and knowledge of the person or the team that writes the plan. Ideally, the
plan should be written by the people who have designed the SCM system for the
project or organization. Here we are talking about experienced people who have a
good understanding of the project or organization and the SCM system. Once the

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

 How to Write a Good SCMP175

plan is written, the technical documentation team can copyedit it so that typos and
grammatical mistakes are eliminated. This is a good practice to follow, because the
writing skills of the technical people may not be on par with their technical skills.
The copyeditors should be given clear instructions not to touch the structure of the
plan, just to check for grammatical and spelling errors. In fact, it could be beneficial
to have the editor sit with the technical team during the writing process, so if any
issues arise, they can be resolved immediately.
The second most important decision is selecting the standard on which the
SCMP is going to be based. As mentioned earlier, the IEEE standards emerge as
the best and most popular choice. However, it is good practice to see what other
standards have to offer, and it may not be a bad idea to borrow good ideas from
them. There is nothing wrong with formulating an SCMP based on more than one
standard, because all standards will have some weak areas, and adapting substitute
areas from other standards might improve them. Some of the standards that could
be referenced are listed as follows:
• IEEE Std-828–1998, IEEE Standard for Software Configuration Management
Plans, IEEE, 1998;
• IEEE Std-1042–1987, IEEE Guide to Software Configuration Management,
IEEE, 1987;
• ISO 10007, Quality Management-Guidelines for Configuration Management,
ISO, 2003;
• DOD MIL-STD-973, Military Standard for Configuration Management,
Department of Defense, 1995;
• MIL-HDBK-61A (SE)—Military Handbook: Configuration Management
Guidance, 2001.
One can get a feel for how to write the SCMP by studying some sample plans and
reading books on SCM. Today, getting sample SCMPs is not a difficult task. IEEE
Std-1042–1987 has four appendixes consisting of sample SCMPs for different types
of projects. Also, hundreds of SCMPs—of all types and sizes—are available on the
Web. A Google query for “sample SCMP” produced more than 2,050,000 results.
The next step in writing the SCMP is to identify the procedures that should be
followed in the practice of SCM. If the SCM system is using procedures that are
part of other standards, then as we have seen before, it is quite sufficient just to
give references to those standards. These standards can be industry standards, the
organization’s internal standards, or even the project’s own standards. However,
before giving reference to a standard, it is a good idea to ensure that all the stan-
dards are available and, if possible, to bring them under document control, so that
they are readily available for reference.
We have researched the standards and literature, discussed the sample plans,
and identified the procedures that will be followed and the documents that define
these procedures. The next step is to write the plan using any of the existing tem-
plates that are available. Many SCMP templates are available on the Web; the IEEE
standard provides a very customizable template, and the ISO has a reasonably good
template. The choice of template is a matter of taste and convenience. The contents
of both the IEEE and ISO templates are almost the same, but the IEEE template
is more comprehensive. For a company using ISO standards, however, the ISO

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

 176 SCM Plans (SCMPs)

10007 template can be used. You just have to choose a template that is suited to
your purpose (and similar to your project or organization) and customize it to your
specific needs. Once the template or the table of contents is ready, the next step is
to fill in the blanks or put the procedures and other details in place to complete the
plan. The resulting document is considered the initial draft of the SCMP. Copies
of this document—the initial draft—should be circulated to all groups that will
be involved in implementing the SCM system and performing the various SCM
functions. This process—involving everyone who matters in plan development—is
very important; SCM is a team effort. To implement and manage an SCM system
successfully, the SCM team will need cooperation from all quarters. One way to
ensure that cooperation is to get others involved by sending copies of the initial
draft and asking for feedback.
Once the feedback from the various groups is received, the SCMP’s authors can
review it, accept valid comments, and incorporate them into the plan. Once the final
draft is ready, it is a good idea to get it reviewed by an external agency—a person
or team of experts. This review can throw light on issues that the plan might have
failed to address or bring up inadequacies or even detect errors that the internal
reviews have missed. The external audit also provides a stamp of approval from a
body that is supposed to be an expert in this area, which will help to increase the
credibility and acceptance of the plan. Once the SCMP is reviewed and approved,
it can be baselined.

Contents of a Typical SCMP

The SCMP can be written in any format as long as it contains all necessary informa-
tion. The standards offer considerable latitude and freedom to the person who writes
the SCMP. All standards require one to address certain topics such as scope, purpose,
definitions, SCM organization, SCM functions, responsibilities, and resources. How
this material should be presented, however, is decided by the author of the plan.
Such decisions as the degree of detail or the amount of additional information to
include in the SCMP depend on the nature of the project.
A sample outline for an SCMP is given next. All items, sections, and subsec-
tions need not be present in all projects. Some will have additional information.
This structure relies heavily on the IEEE standards. Each section and subsection is
proceeded by an explanation of its contents.
i. Cover Page
• This page should have the title “SCMP” and details on the project such as
the organization, the authorities, the version number, and the release date.
ii. Copyright Page
• This page should list the copyright information of the SCMP.
iii. Distribution List
• This page should include the name and number of copies distributed and a
description of how the documentation control activities will apply to this
document.

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

 Contents of a Typical SCMP177

iv. About the Document

• A short description of the document and its sections.

1.0 INTRODUCTION
• An overview of the plan, the SCM activities, the audience for the plan, and
how to use the plan, so that the user will have a clearer understanding of
the plan. The introduction should contain at least the following four topics:
purpose, scope, definitions, and references.

1.1 Purpose
• Addresses the need for the plan and the intended audience.

1.2 Scope
• Covers the plan’s applicability, limitations, and assumptions. This section
provides an overview of the software development process in the project or
organization and how the SCM functions and activities fit into the project.

1.3 Definitions
• Defines the key terms used in the document.

1.4 References
• Identifies all documents, standards, and external and internal procedures to
be used in the plan. This section also identifies where the documents can be
found so that the readers of the plan can retrieve them.

2.0 SCM MANAGEMENT

• Gives information on the organization of the SCM team and the allocation
of responsibilities to teams and individuals, among other management topics.

2.1 SCM Organization

• Describes the organizational structure of the SCM team and how it fits into
the organizational structure with respect to other groups such as the project
team, the QA team, and top management. Also included in the structure are
clients (customers and vendors) and subcontractors, if any are involved in the
SCM activities. An organization chart depicting the structure is very useful
in this section. This section also describes the composition of the CCB and
other auditing and review teams that will be part of the SCM activities.

2.2 SCM Responsibilities

• Describes the duties and responsibilities of all those involved in carrying out
the SCM activities. This section identifies the responsibilities of the CCB and
other committees and boards necessary for CM, the structure of which is
defined in the previous section.

2.3 Relationship of SCM to the Software Process Life Cycle

• Relates the SCM activities to the different phases of the software development
life cycle. It spells out what SCM activities need to be performed during each
phase of the life cycle.

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

 178 SCM Plans (SCMPs)

2.4 Interfaces to Other Organizations on the Project

• Describes how the SCM team will interact with other organizations in the
project such as QA, test, project management, and requirements and includ-
ing vendors and subcontractors.
2.5 SCM Responsibilities of the Organizations
• Describes the responsibilities—or what is expected—of the vendors, sub-
contractors, and other organizations in relation to the carrying out of SCM
functions.
3.0 SCM ACTIVITIES
• Identifies the tasks and functions that are required to manage the configura-
tion of the system as specified in the scope of the plan. This section deals with
the core SCM activities and how they are performed in the project.
3.1 Configuration Identification
• Describes how to identify, name, and document the functional and physical
characteristics of the CIs. Once the items are identified, they are acquired and
moved into the controlled environment.
3.1.1 Identification of CIs
• Identifies the items to be selected as CIs that will be controlled by the SCM
activities. This section gives a list of CIs in the project. Inclusion of a tree
structure showing the various CIs and their interdependencies is ideal.
3.1.2 Naming CIs
• Specifies the identification system, naming conventions, version numbers, and
letters used to identify the CIs.
3.1.3 Acquiring CIs
• Describes how the CIs are to be stored, how access to them will be controlled,
the details of the configuration libraries, the procedures for check in and check
out of CIs from the library, and other related information.
3.2 Configuration Control
• Explains the change management processes such as change initiation, change
disposition, change implementation, reviews, approval, and baselining.
3.2.1 Change Initiation
• Describes how to initiate a change. A change can be the result of a fault or
problem or the result of an enhancement or new feature. This section describes
the procedures to be followed to initiate a CR or PR so that the change man-
agement activities are started.
3.2.2 Change Evaluation
• Describes how the evaluation of a CR is carried out, including details on han-
dling problem analysis and problem classification. The section details how to
classify the changes or problems and how to do an impact analysis, among
other relevant information. The section also specifies the qualifications of the
people who will be doing the change or problem evaluation.

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

 Contents of a Typical SCMP179

3.2.3 Change Management

• Describes how a CR is processed. It spells out clearly procedures such as
those for receiving CRs, assigning CRs for evaluation, CCB meetings, and
dispositioning the CRs carried out.
3.2.4 Change Implementation
• Once the CR is approved it has to be implemented. Selecting the change
implementation team or person, conducting verification and validation, and
promoting the item to the new baseline are described in this section.
3.2.5 CCBs
• This is the apex body that decides the fate of the change requests. This sec-
tion describes the functioning of the CCB. If multiple CCBs are present, the
authority of each CCB must be specified and if more than one CCB of the
same authority is present in the project, then conflict resolution mechanisms
also should be documented.
3.3 CSA
• Details the recording the status of the CIs and reporting them to people who
need to know about them.
3.3.1 Identification of Information Needs
• Describes the information requirements of the project, including what kind of
information is required, who requires it, the nature of the requirement (e.g.,
routine or ad hoc), and the frequency of the reports.
3.3.2 Information Gathering Mechanisms
• Explains how status accounting information is gathered. Ideally the informa-
tion should be entered into the CMDB by the initiators of the SCM activities
rather than by the SCM person chasing the activities and updating the sta-
tus accounting data. For example, when a CR is initiated, if the person who
initiates the CR creates a record of that in the database, the job of informa-
tion gathering is easy. However, to accomplish this, the necessary forms and
access privileges should be given to the different users of the system. This
section describes the exact mechanism of capturing the information for sta-
tus reporting.
3.3.3 Reports, Their Contents, and Frequency
• Describes the various reports that will be created, their contents, and the
frequency of each report.
3.3.4 Access to Status Accounting Data
• The status accounting function cannot anticipate all of the information require-
ments of users and produce reports to meet all requirements. Also, in many
cases, information requests will be for ad hoc reports, which may be generated
only once. If the status accounting system is computerized, then an interactive
query facility can be made available to users to get this information. If such
a facility is available, this section will describe the procedures for using that
facility. In the case of manual processing, this section will describe how the
manual records can be accessed for ad hoc information needs.

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

 180 SCM Plans (SCMPs)

3.3.5 Status Accounting Information Dissemination Methods

• Describes how and to whom the status accounting information will be
disseminated.

3.3.6 Release Details

• Details information such as what is contained in a release, to whom the release
is being provided and when, the media the release is on, known problems with
the release, known fixes in the release, and installation instructions.

3.4 Configuration Auditing

• Describes, for example, what types of audits are to be performed, the audit
procedure, frequency, and the auditing authority.

3.4.1 Audits To Be Performed

• Describes the different types of audits that will be performed and when they
will be performed. Typical audits include FCAs, PCAs, subcontractor audits,
and external audits.

3.4.2 CIs Under Audit

• Specifies the list of CIs that are to be audited.

3.4.3 Audit Procedures

• Describes the procedure to be followed for each audit, including the auditing
authority, the documents required, how the audit should be conducted, and
the format of the audit report.

3.4.4 Audit Follow-Up Activities

• Describes the activities that should be carried out after the audit such as
resolution of NCRs.

3.5 Interface Control

• Describes the coordination of the changes to the CIs with the changes to
the interfacing items outside the scope of the plan like the hardware system,
off-the-shelf packages, and support software. The plan must identify each of
these external items and should define the nature of the interface, the affected
groups, how the interface items will be controlled, and how the interface items
will be approved to be included as part of a baseline.

3.6 Subcontractor or Vendor Control

• Describes the activities necessary to incorporate the items developed outside the
project environment into the project environment, in particular, items that are
the responsibility of subcontractors and vendors. This section should describe
the SCM functions and activities that should be followed by the vendor or
subcontractor, mechanisms to ensure that they are followed, procedures to
audit the items that are submitted by the vendor or subcontractor, and the
items that must be supplied by the vendor or subcontractor. This section also
describes how the items will be received, tested, and placed under SCM and
how CRs to these items will be processed and implemented.

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

 Summary181

4.0 SCM SCHEDULES

• Describes the sequence of the SCM activities, their interdependencies and
relationship to the project life cycle, and project milestones. The schedule
will identify the life cycle phases or project milestones where the different
baselines (e.g., functional baseline, allocated baseline, and product baseline)
will be established. This section also establishes the schedule for the differ-
ent CAs. Graphical representation using PERT charts or Gantt charts help
to enhance the usefulness of this section.
5.0 SCM RESOURCES
• Identifies the software tools, techniques, equipment, personnel, budget, and
training necessary for the implementation of the specified SCM activities.
6.0 SCMP MAINTENANCE
• Describes the activities that are required to keep the plan current during the
life cycle of the project. The plan should be monitored and synchronized with
the activities of the project. This section describes the mechanism for syn-
chronization and identifies the person or team responsible for those activities.

Sample SCMPS

We have just looked at a generic structure for SCMPs that can be tailored to suit the
needs of individual projects. We have also discussed tips for writing good SCMPs.
As mentioned previously, it is a good idea to go through a few sample SCMPs of
similar projects before you start writing the SCMP.
Sample SCMPs can be obtained from a host of sources, but two of the easiest
sources are listed as follows:

• The Internet. Thousands of SCMPs covering a spectrum of projects—e.g.,

military, government, research, and commercial—of various sizes and com-
plexity are hosted on the Internet. You can use a search engine to locate
them. By spending a few hours on the Internet, you can browse through the
different types of SCMPs.
• ANSI/IEEE Std-1042–1987. This is the IEEE Guide to SCM. There are four
appendixes for this document, which are sample SCMPs for different types
of projects.

Also, anyone who is writing an SCMP will benefit tremendously from [1], which
is an excellent primer for SCMPs.

Summary

The SCMP is the document that defines the SCM system and how SCM is to be
practiced in a project. The SCMP documents what SCM activities are to be done,
how they are to be done, who is responsible for doing specific activities, when they
are to happen, and what resources are required.

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

 182 SCM Plans (SCMPs)

The SCMP should be prepared irrespective of whether the organization is using

an incremental approach or using SCM tools. Preparing a good SCMP requires
knowledge of the SCM concepts and functions, SCM tools, SCM standards, software
engineering and QA procedures, and standards and knowledge of the organization
or project for which the standard is being written. The SCMP can be based on a
single standard or can be based on more than one standard.
The SCMP is a CI and should be updated and reviewed whenever required. The
SCMP should be prepared with the cooperation of all those who will be involved in
the functioning of the SCM system and should be audited by external SCM experts.
It is a good idea to go through some SCMPs before starting to write the plan. Hun-
dreds of sample plans are available on the Internet. Also, anyone who is writing
an SCMP will benefit tremendously from the document by Bounds and Dart [1].

Reference

[1] Bounds, N. M., and S. Dart, “CM Plans: The Beginning to Your CM Solution,” Technical
Report, Software Engineering Institute, Carnegie Mellon University, 1998.

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.
Babich, W. A., Software Configuration Management: Coordination for Team Productivity,
Boston, MA: Addison Wesley, 1986.
Ben-Menachem, M., Software Configuration Management Guidebook, New York: McGraw-
Hill, 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.
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.
IEEE Software Engineering Standards Collection 2003 (CD-ROM Edition), Piscataway, NJ:
IEEE, 2003.
IEEE, IEEE Standard for Configuration Management in Systems and Software Engineering
(IEEE Std-828–2012), Piscataway, NJ: IEEE, 2012.
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, DC:
TechAmerica, 2011.
Whitgift, D., Methods and Tools for Software Configuration Management, Chichester, England:
John Wiley & Sons, 1991.

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

 Chapter 14

SCM Organization

Introduction

CM—like any other management function—needs people to perform the vari-

ous activities and to produce results. CM is a discipline that applies technical and
administrative direction and surveillance to (1) identify and document the functional
and physical characteristics of a CI, (2) control changes to those characteristics,
(3) record and report change processing and implementation status, and (4) verify
compliance with specified requirements [1]. As you can see, this definition states a
lot of tasks—configuration identification, change management, change disposition,
change implementation, configuration control, status accounting, and CAs, among
others—that have to be performed for the SCM system to function properly.
To perform all of these functions effectively and efficiently, one needs procedures
and resources. In examining the various SCM procedures in the last few chapters,
it becomes obvious that the most important resource is people. Accordingly, for
any SCM system to function properly, there should be enough qualified people to
do the various functions.
The number of people on an SCM team will vary depending on the nature,
size, and complexity of the project. In the case of large and complex projects with
hundreds of programmers and thousands of programs, the SCM team will be big
with lots of full-time members, whereas in the case of small projects the project
leader might do all the SCM functions independently. Also, there are people whose
services will be required on an as-needed basis. For example, for a CR evaluation,
an outside expert might be called, and once the evaluation is over and the report
is submitted he or she will leave. There might also be permanent personnel on the
SCM team who are in charge of receiving the various CRs and PRs, ensuring the
completeness of these forms, assigning them to the right people for evaluation, coor-
dinating the CCB activities, and whatever else is necessary. This chapter reviews the
structure of a typical SCM team based on the different functions.

SCM and the Organization

We know that SCM is a support function, so let’s take a look at where and how
SCM fits into the organizational structure. Different organizational structures in
different organizations will require the SCM team to be structured or positioned
differently. In many cases, there will be a central SCM team that will take care of

183

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

 184 SCM Organization

all the SCM activities of the different projects in the company. The SCM team here
will act as a support function and will use the members of the project team to get
the SCM activities done.
The main responsibilities of the SCM team in such an arrangement are to com-
plete the SCM activities of the different projects such as receive the CRs, assign the
implementation, and convene the CCB meetings. The advantage of this kind of setup
is that the central SCM team can have standardized procedures and policies enforced
for all projects and prioritize the SCM needs of the different projects based on the
overall company objectives. This kind of an arrangement is shown in Figure 14.1.
Some companies have a central SCM team along with individual teams for
each project. The central team creates the guidelines and policies and the general
organization-wide SCM plan and is responsible for the proper functioning of the
SCM system in the company as a whole. The individual teams associated with each
project customize the plans and procedures to suit the needs of the particular project
and are responsible for the SCM activities in the project. These SCM teams in the
different projects usually have a dual reporting arrangement in which they report
to the central SCM team leader and to the leader of the project with which they are
associated. This type of arrangement is shown in Figure 14.2.
In a third situation, there may be no central SCM team, but each project will
have its own SCM team. This is usually applicable to large projects, where the size
and complexity of the project warrants a full-fledged SCM team of its own. This
type of arrangement is shown in Figure 14.3.

Figure 14.1 Organizational structure in which a central SCM team deals with the different
projects.

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

 SCM and the Organization185

Figure 14.2 Organizational structure when a central SCM team and individual SCM teams are
used.

The SCM team needs strong support from management, because it does not
have the necessary muscle power to enforce its decisions like the line functions do.
However, if proper awareness is created about the importance of SCM and its benefits
and if the SCM system is designed in such a way that SCM approval is a prerequisite
for moving from one phase to another, the SCM team can get the necessary coop-
eration from the project team and other support functions to carry out its tasks.
Another important aspect that should be remembered is that the SCM team will
have to enlist the help of other professionals in the organization. The SCM team
will require help from the management team, the QA team, the project team, and
others to carry out the various functions. For example, the CCB’s permanent mem-
bers include management, QA, marketing, and project team representatives. Also,
for conducting CR evaluations or causal analysis, outside help might be required.
So a mechanism should be in place for determining how these human resources
will be made available to the SCM team. Ideally, the SCM team should make a
request to the concerned group and the group should cooperate. However, if the
cooperation is not forthcoming, the SCM team might need management support
to get the required personnel.

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

 186 SCM Organization

Figure 14.3 Organizational structure in which there are independent SCM teams for each
project.

SCM Organization

The CMO is the head of the SCM team. He or she is usually the person who was part
of the SCM system design team and has most probably written the SCM plan. This
person is responsible for all SCM activities in the project and reports to the CCB.
The main responsibilities of the CMO include setting up the SCM system, training
the SCM team, assigning duties and responsibilities, constituting the CCB(s) as the
case may be, coordinating between the project team and the CCB, managing the
change control activities, setting up the SCM libraries and other control mechanisms,
and coordinating between the audit team and the project team. He or she will be
part of the CCB and will ensure that the CCB meetings are convened according to
the schedule or whenever the need arises (emergency meetings).
Other members of the SCM team help the CMO in performing the SCM tasks.
These include both technical people and administrative personnel. The technical
people will be concerned with tasks like configuration identification, library man-
agement, change management, version control, release management, CAs, causal
analysis, and updating the configuration knowledge base. The administrative staff
will—among other things—ensure that meeting information is sent on time, the
minutes of the meetings are sent to the people on the distribution list, the decisions
made in the meetings are conveyed to the appropriate people, the status accounting
reports are delivered, and the skill inventory database is updated regularly.

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

 SCM Organization187

Then there will be people who work with the SCM team on an ad hoc basis.
These people include those who conduct the CR evaluation, problem analysis, causal
analysis, and CAs and those who serve as subject experts in the CCB meetings.
So in a typical SCM setup, different people will carry out the various SCM
functions. Some of the people in an SCM environment are listed next and a brief
description given about what they do.

• Developers. Developers are the project team members who develop the soft-
ware system or product. They do the analysis, design, and coding.
• Testers. Testers conduct the testing of the programs developed by the develop-
ers. In most cases, the developers do the unit testing and hand over their pro-
grams to the testers. The testers do the module testing, the integration testing,
and the system testing. These people are responsible for coordinating the alpha
and beta testing phases. The testers originate the defect or problem reports,
make enhancement suggestions, and collect and collate the feedback from the
alpha and beta testing programs. Then they initiate the problem tracking and
change management process for each of the defects or enhancements found.
The role of the testers varies slightly from project to project (for example, in
some projects, there will be separate teams for alpha and beta testing), but
their main responsibility is to find the bugs and report them.
• QA representatives. The goal of a good QA program is to prevent defects from
occurring or recurring. So the main responsibility of the QA personnel is to
develop standards and guidelines for the different activities in the project such
as design, coding, and testing. They must also make sure that these policies
and standards are followed by everybody on the team. To ensure this, they
conduct quality audits. QA personnel also form part of the CCB and play a
vital role in the change disposition. In many organizations, it is the QA team
members who perform the CR evaluation, problem analysis, casual analysis,
and the knowledge base and help desk maintenance.
• Assigners. An assigner is the SCM team member responsible for scheduling
the tasks that are to be performed based on their severity and impact and
assigning these tasks to the other people in the team. Assigning the CRs for
evaluation, giving the problem reports for analysis, giving the task of imple-
menting a change to somebody, and ensuring that all activities are performed
on schedule are all the assigner’s responsibility. The assigner’s function may
also be performed by a pre-CCB screening committee [sometimes called the
software review board (SRB)]. The SRB may also be given some measure of
authority, by the CCB, to act on minor CRs and problem reports; such as,
approvals, rejections, and requests for additional information.
• Build manager. This is another SCM role whose responsibility is to handle
the various builds and releases. He or she is the person who is responsible
for such tasks as ensuring that the CIs are given the correct version numbers,
proper baselines are established, build files are accurately kept, and branch-
ing and merging of the file or files is done properly. The primary goal of this
person is to take all the necessary steps to ensure that the SCM system is
capable of configuring and building the system or its components completely
and accurately at any time.

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

 188 SCM Organization

• Administrator. This is the person who does the database administration of

the various SCM databases and repositories, assigns access privileges to the
different team members, and makes backups, among other responsibilities.
This person works very closely with the build manager to ensure that the
build process proceeds without any problem.

We have already seen that many other people are involved in the SCM team.
The roles just mentioned are generally full-time jobs and are usually present in
every project that has SCM. The other personnel in the SCM team, possibly with
the exception of the CMO and a few administrative people, are called in as needed.
For example, the CCB members are called only in situations such as when a CR has
been submitted that needs to be resolved or when a decision has to be made about
the release of a product.

Automation and SCM Team Size

With CM tools automating every possible aspect of CM, the number of people
required to manage the SCM functions is decreasing. However, some areas—analy-
sis, evaluation, and audits—still require human intervention. Also, not all projects
will use totally automated SCM tools; some projects will use tools that automate
certain areas such as change management, version control, build management or
system building, and status accounting. So depending on the nature of the project
and level of automation, the organization of the SCM team will vary.
Another factor that should be considered is the additional capabilities, fea-
tures, and functionality offered by the new-generation SCM tools. These tools are
highly complex and sophisticated and hence require highly trained specialists like
system administrators, database administrators, and release and build managers
to manage them effectively and efficiently. So even though SCM tools automate
the repetitive and monotonous activities, with the added capabilities, the number
of people required to manage the SCM system has not decreased considerably. The
advantages of automation include that people do not have to perform the repetitive
and tedious tasks, that the chances of errors are less, and that accurate and up-to-
date information is available, but not a significant reduction in the SCM team size.

Skill Inventory Database

Since the SCM team relies heavily on professionals from other groups in the orga-
nization to carry out its various functions., the SCM team should know whether
the people (with the necessary qualifications) whom they want are available and if
available where are they located and so on. The author has worked on many proj-
ects where one of the main problems faced by the SCM team was tracking down
the right people to do particular functions, such as impact analysis, problem evalu-
ation, and causal analysis.
In one particular project where the author was the CMO, this problem—the
task of finding the right people—was very acute. The company had more than 1,500

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

 Skill Inventory Database189

employees in five or six different offices. The skills and availability of people was
difficult information to get. So we used the idea of a skill inventory database. The
concept was borrowed from industrial engineering, where creating a skill inven-
tory of the shop floor workers has been used for implementing modern production
systems like Toyota’s. It is also used in small group manufacturing where finding
the people with the right skills fast is a necessity.
Using a skill inventory database in the SCM system proved such a success that
I have since used it in many projects with equal results.
Accordingly, it is a good idea for SCM teams to create a skill inventory database
of the company’s personnel. The database can store the details of each and every
professional whose services will be required by the SCM team. This includes top
management, the QA team members, the project team members, the SCM team
members, the vendor and subcontractor team members, the members of the hard-
ware group, and other support functions. An example of such a database is shown
in Table 14.1.
A skill inventory database will come in handy in large organizations where the
SCM manager or team needs to know details about staff, such as who can conduct
an impact analysis, who has the necessary qualifications to be part of the CCBs,
and who can conduct reviews, FCAs, and PCAs. In big organizations, the SCM
team may not know all the employees and the skill set each person has. Employee
turnover adds to this problem. CCB members who have left the organization have
to be replaced, orphan CIs (CIs whose authors or owners have left the company or
have been promoted and have more responsibilities than doing an impact analysis,
for example) have to be replaced. So it is very helpful for the SCM team to have a
skill inventory database to help find the right people for different tasks.
The skill inventory database captures the skills of every person in the company.
The SCM team should decide which skills need to be captured. For example, knowl-
edge of SCM procedures; experience in conducting quality audits, causal analysis,
and change evaluation; and knowledge of programming languages and database
management systems are all skills that could be captured in such a database.
The numbers in the columns in Table 14.1 represent the experience in years
for each skill. The number of years of experience in a particular field is not always
a good guide, however, to a person’s knowledge level and expertise in that field.
Nevertheless, it is the most easily available yardstick. Other criteria such as a merit

Table 14.1 Sample Skill Inventory Database

Name Thomas Barbara Ishtar Bob

Location/project L1/P1 L2/P2 L2/P2 L1/P2
SCM activities 7 2 0 0
Quality audits 4 0 3 0
Causal analysis 3 4 3 0
COBOL 10 0 5 2
DB2 7 0 3 2
CICS 7 0 3 2
Oracle 0 4 0 0
Visual Basic 0 5 0 0

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

 190 SCM Organization

rating or point rating system can be used. If the company has a good personnel
evaluation system, then those ratings could be used instead of the number of years
of experience.
Although it is perfectly fine to store this information on an electronic spreadsheet,
it would be ideal if it were stored in a relational database, because this makes the
identification of the right people an easier task. For example, if you need a person
to do an evaluation of a CR that involves a program developed in the COBOL-DB2-
CICS environment, then you need a person who is familiar with the SCM activi-
ties and who has good knowledge of COBOL, DB2, and CICS. If you were using
a spreadsheet or a manual log, it would be a very time-consuming job to locate the
people you want. However, if the data were stored in a relational database, one
could get an answer by simply querying the database:

SELECT name, Location

FROM skill_inventory_table
WHERE SCM >= 2 AND COBOL >= 2 AND DB2 >=2 AND CICS >=2;

This query will bring up the names of all people who have two or more years
of experience in SCM, COBOL, DB2, and CICS. Then you merely choose from
the resulting list.
There are some overheads in maintaining the skill inventory database. Usually,
the skill inventory database is managed by the HR department. They need the list
of the skills possessed by each and every employee of the company. This is required
to identify the training needs of the employees, to forecast the skill requirements,
and to formulate the recruitment strategy, among other things. Accordingly, the
HR department usually asks employees to complete the skill inventory database
and update HR on a regular basis—as and when new skills are learned. The SCM
team can ask the HR department to include the list of the skills they want to be
included in the list. The responsibility for managing the skill inventory database is
ideal for the HR department, since this office is constantly in touch with employees
and knows which employees have left and which have joined the organization. The
SCM team can access the database whenever they want to get the necessary infor-
mation about the people they require to perform the various SCM functions. It is
important to remember that the skill inventory database is of little value if it is not
kept up-to-date. As mentioned previously, people leave the company, new people
join, and people learn new skills, all of which should be reflected in the database.

CCB Organization

The CCB is the apex body that decides on whether or not to carry out a change.
Depending on the size, complexity, and nature of the project, there will be a single
CCB, multiple CCBs, or even multilevel CCBs. In most projects, there will be only
one CCB. For small projects, there may not even be a CCB, in which case, the proj-
ect leader will decide whether to accept or reject a CR. For projects having a CCB,
the CCB will have both permanent and ad hoc members. The permanent members
include representatives of the management, project team, QA team, marketing team,

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

 CCB Organization191

Figure 14.4 Sample CCB organization.

and SCM team and, in many cases, client representatives. The ad hoc members are
people who are called (and whose expertise is required) in to resolve issues that the
CCB is not able to resolve—or not able to resolve without expert advice. Sometimes
the CCB may summon the change initiator or evaluator for clarifications. Figure
14.4 shows a sample structure for the CCB.
In some large and complex projects, more than one CCB will be required, with
each handling different modules of the project. This situation arises when the proj-
ect is very large and may be distributed geographically, so that a single CCB will
not be able to handle the disposition of all the CRs and problem reports. In cases
where multiple CCBs are present, there should be a “super CCB” (SCCB) or project
CCB (PCCB) to oversee the functioning of the CCBs and to resolve conflicts, if any,
between the CCBs. Figure 14.5 shows this type of setup.
In some cases, multilevel CCBs will be required, as shown in Figure 14.6. Here
the difference is that each level of CCB will handle a particular kind of CR or prob-
lem report. For example, a level-3 CCB will handle problems with low severity. Here
the CCBs are classified based on the types of CRs they handle, whereas in the case
of multiple CCBs they are classified based on the module or subsystem they handle.

Figure 14.5 Multiple CCBs.

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

 192 SCM Organization

Figure 14.6 Multilevel CCBs.

So in the case of a multiple CCB environment all the CRs from a particular
module will be handled by the same CCB, but in a multilevel CCB all the CRs with
the same severity level will be handled by a CCB. Multiple CCBs are useful when
the project is large and has many modules, and development takes place in differ-
ent locations. Multilevel CCBs are applicable to large projects that are complex in
nature, but the development occurs in one place. Here the multiple levels help to
resolve simple problems faster because the lower-level CCB would be comprised of
the module leader and an SCM representative, who can make decisions faster rather
than waiting for the full CCB meeting to happen. Thus, the load on higher-level
CCBs is reduced, and they can focus their attention on critical and severe problems
that will have huge impacts on costs and project schedules.

Summary

The place of the SCM team in the organizational structure depends very much on
the organization and varies from one organization to another. Irrespective of the
position in the organizational hierarchy, however, the SCM team performs the
same functions.
We have examined the organization of the SCM team and the different people
who play significant roles in the functioning of the SCM activities. We have also
considered the different types of CCBs and how they function.
Because SCM tools are automating more and more tasks, the role of the SCM
team and the tasks it has to perform are being reduced. As a result, in the future,
we may see reductions in the size of the SCM team, except in some areas such as
analysis, evaluation, and audits, where human intervention is still required.

Reference

[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.

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

 Summary193

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.
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.
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 193 12/30/14 1:25 PM