Software Configuration

Management
(SCM)
Dr. Aprna Tripathi
Objectives

To explain the importance of Software

Configuration Management (SCM)
To describe key SCM activities namely
SCM planning, change management,
and version management.
To discuss the use of CASE tools to
support configuration management
processes
Topics covered

Configuration management planning

Change management
Version and release management
CASE tools for configuration
management
 Need for SCM
“What is the correct version of the software
module that I have to continue its coding?”
“What version of the design document matches
the software version we are adapting to a new
customer?”
“What version of the software system is installed
at ABC Industries?”
“What changes have been introduced in the new
version of the software?”
“Where can I find the full list of customers that
use version 6.8 of our software?”

4 7/23/22
First Law of System Engineering

No matter where you are in the system

life cycle, the system will change, and
the desire to change it will persist
throughout the lifecycle.
What is Configuration Management

“SCM is the control of the evolution of

complex systems,…, for the purpose to
contribute to satisfying quality and delay
constraints.”
– Jacky Estublier

“SCM provides the capabilities of identification,

control, status accounting, audit and review,
manufacture, process management, and
teamwork.”
– Susan Dart
 What Are These Changes?

changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents

software models
Project
Plan
data
Test
code

7
 The Software Configuration

programs documents

The pieces
data

8
Software Configuration
Management
• Involves the development and application of
procedures and standards to manage an evolving
software product.
• New versions of software systems are created as
they change:
– For different machines/OS;
– Offering different functionality;
– Tailored for particular user requirements.
Software Configuration
Management
• 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.

10 7/23/22
Software Configuration Management

SCM may be seen as part of a more general

quality management process.
When released to SCM, software systems are
sometimes called baselines as they are a
starting point for further development.
What is CM not

Not just version control

Not just for source code management

Not only for development phase

Selecting and using tools are important, but

design and management of CM process are
more crucial for project success
Some Simple CM Scenarios

Developer A wants to see latest version

of foo.c and its change history since last
week

B needs to revert foo-design.doc to its

version two days ago

B makes a release of the project and he

needs to know what items to include
and which version
Some Simple CM Scenarios
(cont.)

A lives in New Dehli, India and B lives in

Boston, US, 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
Configuration Management

Definition:
The set of activities that have been
developed to manage change
throughout the software life cycle.
Purpose:
Systematically control changes to the
configuration and maintain the integrity
and traceability of the configuration
throughout the system’s life cycle.
Baseline
Definition: Specification or product that
– has been formally reviewed and agreed
upon,
– serves as the basis for further development,
and
– can be changed only through formal change
control procedures.
Signals a point of departure from one activity
to the start of another activity.
Helps control change without impeding
justifiable change.
Baselines in SCM

Baseline A (developmental)

Baseline B (functional, first prototype

Baseline C (functional, beta test)

Official Release

How do we manage changes in the

baselines?
Time
 Baselines
modified
SCIs
Project database
approved
Software Formal
engineering SCIs technical SCIs
tasks reviews

stored

SCIs

extracted
SCM SCIs
controls

BASELINES:
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System
18
Project Baseline

Central repository of reviewed and approved

artifacts that represent a given stable point in
overall system development.
Shared DB for project and kept in consistent
state.
Policies allow the team to achieve consistent
state and manage the project.
Software Configuration Item
(SCI)
Definition: Information that is created as part
of the software engineering process.
Examples:
– Software Project Plan
– Software Requirements Specification
 Models, Prototypes, Requirements
– Design document
 Protocols, Hierarchy Graphs
– Source code
 Modules
– Test suite
– Software tools (e.g., compilers)
 The SCM Process
Addresses the following questions …

How does a software team identify the discrete

elements of a software configuration?
How does an organization manage the many existing
versions of a program (and its documentation) in a
manner that will enable change to be accommodated
efficiently?
How does an organization control changes before and
after software is released to a customer?
Who has responsibility for approving and ranking
changes?
How can we ensure that changes have been made
properly?
What mechanism is used to appraise others of
changes that are made?

21
The SCM Process
Software
Vm.n

reporting

configuration auditing

version control

change control

identification

SCIs

22
SCM Processes / Elements of
SCM
There are Five elements of SCM:
1. Software Configuration Identification
2. Software Version Control
3. Software Change Control
3. Software Configuration Auditing
4. Software Configuration Status Accounting /
Reporting
 Configuration Management
Tasks
Identification
– tracking changes to multiple SCI versions
Version control
– controlling changes before and after customer
release
Change control
– authority to approve and prioritize changes
Configuration auditing
– ensure changes are made properly
Reporting
– tell others about changes made
24
Software Configuration
Identification
Provides labels for the baselines and their
updates.
Evolution graph: depicts versions/variants.

1.3 1.4

1.0 1.1 1.2

2.0
1.1.1 1.1.2

An object may be represented by variant,

versions, and components.
Configuration item identification

Large projects typically produce thousands of

documents which must be uniquely identified.
Some of these documents must be maintained
for the lifetime of the software.
Document naming scheme should be defined
so that related documents have related
names.
A hierarchical scheme with multi-level names
is probably the most flexible approach.
– PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
Family of Products

Member 1 A1 B E

A1
D A2 A3
B

C1 C1 C2

The component data base.

Member 2

A2
Member 3
B
A3
C2
D

A family of products using a component database

 Software Configuration Control
Three basic ingredients to SCC
1. Documentation for formally precipitating and
defining a proposed change to a software
system.
2. An organizational body (Configuration Control
Board) for formally evaluating and approving
or disapproving a proposed change to a
software system.
3. Procedures for controlling changes to a
software system.
Software Configuration Control

Why needed?
- Not all possible changes are beneficial.
- Need a mechanism to control access to
different items of the configuration (who
can access what).
 Access and Synchronization
Control
Configuration Object
(Modified Version) Check-In Configuration Object
Audit Info (Baseline Version)

Unlock
Software Project
Engineer Ownership Info
Access Database
Control
Lock
Configuration Object
(Baseline Version)
Configuration Object Check-Out
Request
 Access and Synchronization
Control
Configuration Object
(Modified Version) Check-In Configuration Object
Audit Info (Baseline Version)

Unlock
Software Project
Engineer Ownership Info
Access Database
Control
Lock
Configuration Object
Configuration Object (Baseline Version)
(Extracted Version) Check-Out
 Access and Synchronization
Control
Configuration Object
(Modified Version) Check-In Configuration Object
Audit Info (Baseline Version)

Unlock
Software Project
Engineer Ownership Info
Access Database
Control
Lock
Configuration Object
Configuration Object (Baseline Version)
(Extracted Version) Check-Out
 Access and Synchronization
Control
Configuration Object
(Modified Version) Check-In Configuration Object
Audit Info (Baseline Version)

Unlock
Software Project
Engineer Ownership Info
Access Database
Control
Lock
Configuration Object
Configuration Object (Baseline Version)
(Extracted Version) Check-Out
 Version Control Terms

Entity
– composed of objects at the same revision
level
Variant
– a different set of objects at the same
revision level and coexists with other
variants
New version
– defined when major changes have been
made to one or more objects
34
Version and release management

Invent an identification scheme for

system versions.
Plan when a new system version is to
be produced.
Ensure that version management
procedures and tools are properly
applied.
Plan and distribute new system
releases.
Versions/variants/releases

• Version An instance of a system which is

functionally distinct in some way from
other system instances.
• Variant An instance of a system which is
functionally identical but non-functionally
distinct from other instances of a system.
• Release An instance of a system which is
distributed to users outside of the
development team.
Version identification

Procedures for version identification

should define an unambiguous way of
identifying component versions.
There are three basic techniques for
component identification
– Version numbering;
– Attribute-based identification;
– Change-oriented identification.
Version numbering

Simple naming scheme uses a linear

derivation
– V1, V1.1, V1.2, V2.1, V2.2 etc.
The actual derivation structure is a tree
or a network rather than a sequence.
Names are not meaningful.
A hierarchical naming scheme leads to
fewer errors in version identification.
Version derivation structure

V1.1b V1.1.1

V1.0 V1.1 V1.2 V2.0 V2.1 V2.2

V1.1a
Attribute-based identification

Attributes can be associated with a version

with the combination of attributes identifying
that version
– Examples of attributes are Date, Creator,
Programming Language, Customer, Status etc.
This is more flexible than an explicit naming
scheme for version retrieval; However, it can
cause problems with uniqueness - the set of
attributes have to be chosen so that all
versions can be uniquely identified.
In practice, a version also needs an associated
name for easy reference.
Attribute-based queries

An important advantage of attribute-

based identification is that it can
support queries so that you can find
‘the most recent version in Java’ etc.
The query selects a version depending
on attribute values
– AC3D (language =Java, platform = XP,
date = Jan 2003).
Change-oriented identification

Integrates versions and the changes made to

create these versions.
Used for systems rather than components.
Each proposed change has a change set that
describes changes made to implement that
change.
Change sets are applied in sequence so that,
in principle, a version of the system that
incorporates an arbitrary set of changes may
be created.
Delta-based versioning

Version Version Version Version

1.0 1.1 1.2 1.3

D1 D2 D3

Creation da te
Version management tools
Version and release identification
– Systems assign identifiers automatically when a new
version is submitted to the system.
Storage management.
– System stores the differences between versions rather
than all the version code.
Change history recording
– Record reasons for version creation.
Independent development
– Only one version at a time may be checked out for change.
Parallel working on different versions.
Project support
– Can manage groups of files associated with a project
rather than just single files.
 Change Control

STOP

45
 Change Control Process—I
need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority decides

request is queued for action

change request is denied
user is informed
change control process—II
46
 Change Control Process-II

assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a “baseline” for testing

change control process—III

47
 Change Control Process-III
perform SQA and testing activities

check-in the changed SCIs

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

48
 Change Control Process - 1
Change request is submitted and evaluated to
assess its technical merit and impact on the
other configuration objects and budget
Change report containing the results of the
evaluation is generated
Change control authority (CCA) makes the
final decision on the status and priority of the
change based on the change report

49
 Change Control Process - 2

Engineering change order (ECO) is generated

for each change approved
– ECO describes the change, lists the
constraints, and criteria for review and
audit
Object to be changed is checked-out of the
project database subject to access control
parameters for the object
Modified object is subjected to appropriate
SQA and testing procedures

50
 Change Control Process - 3
Modified object is checked-in to the project
database and version control mechanisms are
used to create the next version of the software
Synchronization control is used to ensure that
parallel changes made by different people
don’t overwrite one another

51
 Auditing

Change
Requests SQA
Plan
SCIs

SCM Audit

52
Software Configuration Auditing

Provides mechanism for determining the

degree to which the current configuration of
the software system mirrors the software
system pictured in the baseline and the
requirements documentation.
Software Configuration Auditing
Asks the following questions:
1. Has the specified change been made?
2. Has a formal technical review been
conducted to assess technical correctness?
3. Has the software process been followed
and standards been applied?
4. Have the SCM procedures for noting the
change, recording it, and reporting it been
followed?
5. Have all related SCIs been properly
updated?
 Software Configuration Status
Accounting / Reporting

It is a task that answers the following

– What happened
– Who did it
– When did it happen
– What else will be effected

55 7/23/22
Software Configuration Status
Accounting / Reporting
Provides a mechanism for maintaining a record
of where the system is at any point with
respect to what appears in published baseline
documentation.
When a change proposal is approved it may
take some time before the change is initiated
or completed.
Software Configuration Status
Accounting

Why needed?
- Ensure that there is progress within the
development of the project.
- Track updates to baselines.
Requirements for CM

Repository: shared DB for artifacts with

controlled access to prevent overwrites.
Version management: Maintain history of
changes made to each artifact; provide ability
to see how version was created.
Work-space control: Private work space with
ability to check out from repository and check
in with new version number.
Product modeling and building: Procedure to
build the product from artifacts in repository.
CM Tools

Concurrent Version System (CVS)

Subversion
Visual Source Safe
CASE tools for configuration
management

CM processes are standardised and involve

applying pre-defined procedures.
Large amounts of data must be managed.
CASE tool support for CM is therefore
essential.
Mature CASE tools to support configuration
management are available ranging from
stand-alone tools to integrated CM
workbenches.
CM workbenches
Open workbenches
– Tools for each stage in the CM process are
integrated through organizational
procedures and scripts. Gives flexibility in
tool selection.
Integrated workbenches
– Provide whole-process, integrated support
for configuration management. More tightly
integrated tools so easier to use. However,
the cost is less flexibility in the tools used.
Change management tools

Change management is a procedural process

so it can be modelled and integrated with a
version management system.
Change management tools
– Form editor to support processing the change
request forms;
– Workflow system to define who does what and to
automate information transfer;
– Change database that manages change proposals
and is linked to a VM system;
– Change reporting system that generates
management reports on the status of change
requests.
SCM standards

SCM should always be based on a set of

standards which are applied within an
organisation.
Standards should define how items are
identified, how changes are controlled and
how new versions are managed.
 Cont’d…

Standards may be based on external SCM

standards (e.g. IEEE standard for SCM).
Some existing standards are based on a
waterfall process model - new SCM standards
are needed for evolutionary development.

64 7/23/22
Key points

Configuration management is the

management of system change to software
products.
A formal document naming scheme should be
established and documents should be
managed in a database.
The configuration data base should record
information about changes and change
requests.
A consistent scheme of version identification
should be established using version numbers,
attributes or change sets.
Key points

System releases include executable code,

data, configuration files and documentation.
System building involves assembling
components into a system..
CASE tools are available to support all CM
activities
CASE tools may be stand-alone tools or may
be integrated systems which integrate support
for version management, system building and
change management.