Software Project Management

1
 Chapter Eight

Software Configuration Management

2
 Definition

Configuration Management is the process of identifying

and defining the items in the system, controlling the
changes to these items throughout their life cycle,
recording and reporting the status of items and change
requests, and verifying the completeness and correctness
of items.
(Definition by IEEE - 1983)

3
 Cont’d
Configuration Management (CM) is a discipline that applies
technical and administrative direction and surveillance over
the lifecycle of items to:
» Identify (and document) configuration items
» Control changes to configuration items
» Record and report information needed to manage configuration
items (status)
» Audit configuration items to verify conformance to specifications
(Definition by DoD)

4
 Important Terms
Configuration Items:
» “An aggregation of hardware, software, or both, that is designated
for configuration management and treated as a single entity in the
configuration management process.”

» Software configuration items are not only program code segments but
all type of documents according to development, e.g
– all type of code files
– drivers for tests
– analysis or design documents
– user or developer manuals
– system configurations (e.g. version of compiler used)

» In some systems, not only software but also hardware configuration

items (CPUs, bus speed frequencies) exist!
» Selecting the right configuration items is a skill that takes practice.

5
 Cont’d
Version:
» The initial release or re-release of a configuration item associated
with a complete compilation or recompilation of the item.
» Different versions have different functionality.
Revision:
» Change to a version that corrects only errors in the design/code, but
does not affect the documented functionality.
Release:
» The formal distribution of an approved version.

6
 Cont’d

Baseline:
» “A specification or product that has been formally reviewed and agreed to
by responsible management, that thereafter serves as the basis for further
development, and can be changed only through formal change control
procedures.”
Examples:
» Baseline A: The API has completely been defined; the bodies of the methods
are empty.
» Baseline B: All data access methods are implemented and tested.
» Baseline C: The GUI is implemented.
A 3 digit scheme is quite common
7.5.5

Major, Minor, Small Revision

External Release Internal Release (Developer)
(Customer) (Developer)
7
Why Software Configuration Management?
Software changes are inevitable.
» System requirements are likely to change while the system is being
developed because their environment is changing.
» Systems are tightly coupled to their environment.
One goal of software engineering is to improve how easy it
is to change software.
Configuration management is all about change control.
Every software engineer has to be concerned with how
changes made to work products are tracked and propagated
throughout a project.
To ensure quality is maintained the change process must be
audited.
8
 Cont’d

“No matter where you are in the system life cycle, the
system will change, and the desire to change it will
persist throughout the life cycle.”
First Law of System Engineering [BER80]

9
 Cont’d
New versions of software systems are created as they
change:
» For different machines/OS
» Offering different functionality
» Tailored for particular user requirements
Configuration management is concerned with managing
evolving software systems.
» System change is a team activity
» CM aims to control the costs and effort involved in making changes to
a system
Involves the development and application of procedures and
standards to manage an evolving software product.
May be seen as part of a more general quality
management process. 10
 Some Simple CM Scenarios
Developer A wants to see latest version of foo.c
and its change history since last week.

Developer B needs to revert foo-design.doc to its

version two days ago.

Developer B makes a release of the project and he

needs to know what items to include and which
version.

11
 Cont’d
A lives in Silcon Valley, USA and B lives in Pretoria, South
Africa, they want to work on HelloWorld.java together.

In the latest release, a serious bug is found and manager C

wants to track what changes caused the bug, who made
those changes and when.

C wants to get reports about current project progress to

decide if she needs to hire more programmers and delay the
alpha release.

12
 Configuration Management Roles
Configuration Manager
» Responsible for identifying configuration items. The configuration
manager can also be responsible for defining the procedures for
creating promotions and releases.
Change control board (CCB) member
» Responsible for approving or rejecting change requests.
Developer
» Creates promotions triggered by change requests or the normal
activities of development. The developer checks in changes and
resolves conflicts.
Auditor
» Responsible for the selection and evaluation of promotions for release
and for ensuring the consistency and completeness of this release
13
 Software Configuration Management
Activities
Software Configuration Management Tasks/Activities can be
generally classified as (Leon, 2000):
» Configuration Identification
» Configuration Control
» Configuration Status Accounting
» Configuration Audit

14
 Configuration Identification
Configuration identification is a process where a system is
divided into uniquely identifiable components for the purpose
of software configuration management.
These components are called computer software
configuration items (CSCIs) or shorter and more generally
just configuration items (CIs).
Each CI must be named and versioned uniquely to
distinguish it from the other CIs and from other versions of
Cis.
Examples of CIs are: project plan, specifications, design
documents, source codes, test plans and test data,
executables, make files, tools, and SCM plan.
15
 Cont’d
Every source item should have a status attribute which
defines the level of approval that the item has achieved.
» An example of the range of status values for an element code is:
untested, module tested and integration tested.
» A document also can have such values as draft, proposed and
approved.
In the configuration identification phase, a project's baselines
and their contents are also identified.
A baseline is a software configuration management concept
that helps us to control change.
» It can also be an assembly of CIs, an accepted configuration.

16
 Configuration Control
Software can change very quickly and easily, and
uncontrolled changes can lead to chaos.
A change request can result from many things.
» For example, new features, enhancements of existing features or
defects can lead to change requests.
The change control process starts, when a need for change
is noticed.
A properly completed change request form is sent to the
configuration control board (CCB), whose main function is to
evaluate and to approve or disapprove change requests.
Change requests can also be deferred when they and their
associated documentation are filed for later resolution.
17
 Cont’d
If a change request is approved, proposed changes are
assigned to developers to be implemented.
After implementation, the changes are verified in various
testing procedures to ensure that they have been
implemented as agreed.
Effective projects control changes, whereas ineffective
projects allow changes to control them (McConnell,1998).

18
 Configuration Status Accounting
Consists of the recording and reporting of information needed
to manage a configuration effectively, including:
» a listing of the approved configuration identification,
» the status of proposed changes to the configuration and
» the implementation status of approved changes.
Status accounting reports include change logs, progress
reports, CI status reports and transaction logs.
Answers the questions:
» What happened?
» Who did it?
» When did it happen?
» What else will be affected?

19
 Configuration Audits
The purpose of configuration audits is to ensure that
» Functional Configuration Audit (FCA) - the software product has
been built according to specified requirements,
» Physical Configuration Audit (PCA) - to determine whether all the
items identified as a part of CI are present in the product baseline, and
» SCM system audit or in-process audit - whether defined SCM
activities are being properly applied and controlled.
A representative from management, the QA department, or
the customer usually performs such audits.
The auditor should have competent knowledge both of SCM
activities and of the project.

20
 SCM Plan
A successful SCM implementation requires careful planning
and management.
All of the SCM activities introduced above are described in
the SCM plan.
The main purpose of the SCM plan is to answer such
questions as: who is going to do what, when, where, and
how.
Thus, the SCM plan serves as a guideline for the people
working with software configuration management.
A configuration management plan is written for each project.
However, an organization may use a generic SCM plan
template that can be tailored to each particular project.
21
 Outline of a Software Configuration
Management Plan (SCMP, IEEE 828-1990)
1. Introduction 4. Schedule (WHEN?)
» Describes purpose, scope of » Establishes the sequence and
application, key terms and coordination of the SCM
references activities with project mile stones.
2. Management (WHO?) 5. Resources (HOW?)
» Identifies the responsibilities and » Identifies tools and techniques
authorities for accomplishing the required for the implementation
planned configuration of the SCMP
management activities 6. Maintenance
3. Activities (WHAT?) » Identifies activities and
» Identifies the activities to be responsibilities on how the
performed in applying to the SCMP will be kept current during
project. the life-cycle of the project.

22
 Configuration Management Tools
Revision Control System (RCS ):
» To change a configuration item, the developer has to lock that item first,
preventing other developers from changing the item at the same time.
» The developer specifies a label for each configuration item. Using this
label, developers can check out consistent set of versions by using this
label [Herbert 1999].

23
 Cont’d
Concurrent Versions System (CVS):
» CVS System lets the groups of people work simultaneously on group
of files.
» This tool is similar to RCS. In addition it also supports the concept of
branch.
» This system does not support locking of files.
» In CVS, the user would check out the latest version of a file or any of
the earlier versions from the repository .

24
 Cont’d
Perforce:
» Perforce is a commercial replacement for CVS.
» It also controls a central repository like CVS and RCS.
» Perforce includes version control, workspace management, atomic
change transactions and a powerful branching model to develop and
maintain multiple code lines.
» Files or elements are stored in the central repository called Versioned
Object Base (VOB).
» Different available versions of an element are stored in the VOB.

25
 Cont’d
Clearcase:
» ClearCase is designed to help developers track the files and
directories used to create software.
» The files stored in the repository are called elements.
» ClearCase supports parallel development which includes isolating
the work of a single developer from a small team, creating and
developing multiple releases in parallel using different teams, and
sharing of code among different teams located at different locations.

26
 Cont’d
ClearQuest:
» This tool is a change request management application that allows a
developer to track and monitor the change requests for a configuration
item [Rational 2002].
» ClearQuest maintains its own database which stores all the change
requests in the form of records.
» There are various categories of changes that can be done on a
product. These changes can be due to addition of new features,
detection of faults, activities etc.

27
 Cont’d

Reading Assignments
» Version Management
» Branch Management
» Variant Management

28