Configuration Management

Dibyesh Giri
Nepal
 Configuration Management
Configuration Management is the process which controls
the changes made to a system and manages the
different versions of the evolving software product.
Configuration management involves the development and
application of procedures and standards for managing an
evolving system and releasing them to customers.
Procedures should be developed for building systems and
releasing them to customers.
Standards should be developed for recording and
processing proposed system changes and identifying and
storing different versions of the system.
CM may be part of a more general software quality
management process.
In some organizations, the same manager may share
quality management and configuration management
responsibilities.
 Configuration Management
• Software may be released by the developers to a
quality assurance team who are responsible for
checking that the system is of acceptable quality.
• It is then passed to the configuration management
team who become responsible for controlling changes
to the software.
• Controlled systems are sometimes called baselines as
they are a starting point for controlled evolution.
• Reasons why systems exist in different configurations.
1. For different computers.
2. For different operating systems.
3. Incorporating client-specific functions, etc.
 Configuration Management
• Configuration managers are responsible for keeping
track of the differences between software versions and
for ensuring that new versions are derived in a controlled
way.
• Configuration managers are responsible for ensuring
that these new versions are released to the correct
customers at appropriate time.
• The configuration management process and associated
documentation should be based on a set of standards.
Within an organization, these standards should be
published in a configuration management handbook or
as part of a quality handbook. e.g. IEEE standard 828-
1983, which is a standard for configuration management
plans.
 Configuration Management

Mainframe
PC
Version
Version
VMS
DEC-Digital Electronic Configuration Version

Initial DEC Workstation

System Version Version
Unix
Version
Sun
Version
Configuration Management – CM Planning

• CM takes over control of systems after

they have been developed.
• Planning CM process must start during
system development.
• A CM plan should be developed as part of
the overall project planning process.
 Configuration Management – CM Planning

The CM plan should include at least the following information:

• The definition of what entities are to be managed and a formal

scheme for identifying these entities.
• A statement of who takes responsibility for the configuration
management procedures and for submitting controlled entities to
the configuration management team.
• The configuration management policies which are used for
change control and version management.
• A description of the records of the configuration management
process which should be maintained.
• A description of the tools to be used for configuration
management and the process to be applied when using these
tools.
• A definition of the configuration database which will be used to
record configuration information.
 Configuration Management – CM Planning

An important part of the CM plan is the definition of

responsibilities.
It should define who is responsible for the delivery of each
document or software component to quality assurance
and configuration management.
It may also define the reviewers of each document.
The person responsible for document delivery need not be
the same as the person responsible for producing the
document.
To simplify interfaces, it is often convenient to make project
managers or team leaders responsible for all of the
documents produced by their team.
 Configuration Management – CM Planning

Configuration Item identification

• In the course of developing a large software system, thousands of
documents are produced. Many of these are technical working
documents which present a snapshot of ideas for further
development
• These documents are subject to frequent and regular change.
• A key task of the configuration management planning process is to
decide exactly which items ( or classes of item) are to be controlled.
• Documents or groups of related documents under configuration
control are formal documents or configuration items
• Project plans, specifications, designs, programs and test data suits
are normally maintained as configuration items.
• However, all documents which may be necessary for future system
maintenance should be controlled.
 Configuration Management – CM Planning

Configuration Item identification

• The document naming scheme must assign a
unique name to all documents under
configuration control.
• There will be relationship between documents.
e.g. design documents will be associated with
programs.
• These relationships can be recorded implicitly by
organizing the naming scheme so that related
documents have a common root to their name.
• This leads to hierarchical naming scheme.
 Configuration Management – CM Planning

Configuration Item identification

Hierarchical naming Scheme:
PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
PCL-TOOLS/EDIT/HELP/QUERY/HELPEFRAMES/FR-1
• These names have a number of components. The initial part of the
name is the project name, PCL-TOOS.
• There are four separate tools.
PCL-TOOLS/COMPILE
PCL-TOOLS/BIND
PCL-TOOLS/EDIT
PCL-TOOLS/MAKE-GEN
• The problem with naming schemes of this sort is that they are
project-based.
• Components are identified as being associated with a particular
project.
 Configuration Management – CM Planning

The Configuration Database

• As part of the configuration management plan, a
database schema to record configuration information
should be defined.
• The configuration database is used to record all relevant
information relating to configurations.
• Its principal functions are to assist with assessing the
impact of system changes and to provide management
information about the CM process.
• As well as defining the database schema, procedures for
recording and retrieving project information must also be
defined as part of the Configuration Management
Planning Process.
 Configuration Management – CM Planning

The Configuration Database

A configuration database must be able to provide answers to a variety of queries about system configurations. Typical
queries might be:

3. Which customers have taken delivery of a particular

version of the system?
4. What hardware and operating system configuration is
required to run a given system version?
5. How many versions of a system have been created
and what were their creation dates?
6. What versions of a system might be affected if a
particular component is changed?
7. How many change requests are outstanding on a
particular version?
8. How many reported faults exist in a particular version?
 Configuration Management – Change
Management
• Change is a fact of life for large Software System.
• This requires corresponding changes to be made to the
software. There is therefore a need for a system to ensure
that changes are recorded and applied to the system in “a
cost-effective” way.
• Change management procedures should be designed to
ensure that the costs and benefits of change are properly
analyzed and that changes to a system are made in a
controlled way.
• Change management processes involve technical change
analysis, cost-benefit analysis and change tracking.
• The first stage in the change management process is to
complete a Change Request Form (CRF). This is a formal
document where the requester sets out the change
required to the system.
 Configuration Management – Change
Management
Change Request Form
Project: Proteus/PCL-Tools Number:23/94
Change requester: I. RGP Date: 1/08/2007
Request change: When a component is selected from the structure, display the name of the file
where it is stored.
Change analyser: BNB Analysis date: 10/08/2007
Component affected: Display-Icon-Select, Display-Icon-Display
Associated components: FileTable
Change assessment: Relatively simple to implement as a file name table is available. Requires the
design and implementation of a display field. No changes to associated components are
required.
Change priority: Low
Change implementation:
Estimated effort: 0.5 days
Date of CCB: 15/08/2007 CCB decision date:02/09/2007(Change Control
Board)
CCB decision: Accept change, Change to be implemented in Release 2.1
Change Implementer: Date of change:
Date submitted to QA: QA decision:
Date submitted to CM:
Comments
 Configuration Management – Change
Management
• The CM team, rather than the system developers, is
responsible for building a new version or release of the
software.
• Change requests are themselves configuration items.
They should be registered in the configuration database.
• As software components are changed, a record of the
changes made to each component should be
maintained. This is sometimes called the derivation
history of a component.
• The procedural nature of this process means that a
change process model can be designed and integrated
with a version management system. This model may
then be interpreted so that the right documents are
passed to the right people at the right time. e.g. Lifespan.
 Configuration Management – Version and
Release Management
Version and release management are the processes of
identifying and keeping track of different versions and
release of a system.
A system version is an instance of a system that differs, in
some way, from other instances. New versions of the
system may have different functionality, performance or
may repair system faults.
Some versions may be functionally equivalent but designed
for different hardware or software configurations. If there
are only small differences between versions, one of
these is sometimes called a variant of the other.
 Configuration Management – Version and
Release Management
A system release is a version that is
distributed to customers.
Each system release should either include
new functionality or should be intended for
a different hardware platform.
Normally, there are more versions of a
system than release. Some versions may
never be released to customers. e.g.
versions may be created within an
organization for internal development or
for testing.
 Configuration Management – Version and
Release Management
A release is not just an executable program or set
of programs. It usually also includes:
• Configuration files defining how the release
should be configured for particular
installations.
• Data files which are needed for successful
system operation.
• An installation program which is used to help
install the system on target hardware.
• Electronic and paper documentation describing
the system.
 Configuration Management – Version and
Release Management
All above information must be made available on some
medium which can be read by customers for that
software.
For large systems, this may be magnetic tape.
For smaller systems, floppy disks may be used.
Increasingly, however, releases are distributed on CD-ROM
disks because of their large storage capacity.
When a system release is produced, it is important to
record the versions of the operating system, libraries,
compilers and other tools used to build the software.
If it has to be rebuilt at some later date, it may be
necessary to reproduce the exact platform configuration.
 Configuration Management – Version and
Release Management

Version Identification
Identifying versions of a system appears to be
straightforward.
Linear Scheme – 1.0 subsequent 1.1,1.2,1.3,…
At some stage it is decided to create release 2.0
and process starts again 2.1,2.2,2.3,…
Version Management tools such as SCCS
(Rochkind, 1975) support this approach to
version identification.
 Configuration Management – Version and
Release Management
Version Management
Linear Scheme is simple but it has associated problems:
• When should a new release (i.e. a new branch in the derivation
graph) rather than a new version be created?

• If several versions are created from a single parent, how should

be they numbered? e.g. say a system is intended to run on a
number of different computer architectures. These are all derived
from a single base release numbered 1.0. Should the versions be
numbered 1.1, 1.2 and so on, implying sequential derivation?

• If many versions of a system are created and distributed to

different customers, should the version naming scheme include
some customer identifier? Each customer or system user may
have a unique version of the system.
These identification problems arise because the naming scheme
implies a linear derivation of versions whereas the actual logical
derivation structure is a network structure.
 Configuration Management – Version and
Release Management
Version Management
An alternative to a numeric naming structure is to
use a symbolic naming scheme. e.g. rather than
refer to Version 1.1.2, a particular instance of a
system might be referred to as
V1/VMS/DBserver. This implies that this is of
version of database server for a Digital computer
running the VMS operating system.

This has some advantages over the linear scheme

but, again, it does not truly represent the
derivation structure.
Configuration Management – Version and
Release Management
Version Management

V1.1b V1.1.1

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

V1.1a

Version derivation structure

 Configuration Management – Version and
Release Management
Version Management
• Customer
• Development language
• Development status
• Hardware platform
• Creation date
New system versions should always be created by
the CM team rather than the system developers.
System developers should not have write access
to this database.
 Configuration Management – Version and
Release Management
Release Management
• New versions of a system may be created to fix reported
faults or as part of the development process.
• Creating a new system version involves creating new
source code and building the system.
• Creating a release, however, is more complex and
expensive. As well as creating new source code and
system building, data and configuration files may have to
be prepared and new documentation written. The
release must be packaged and distributed to customers.
 Configuration Management – Version and
Release Management
Release Management
Over the lifetime of a system, changes are likely to be
proposed on a fairly regular basis.
• Corrective changes are intended to fix faults.
• Perfective changes are intended to implement new
requirements.
• Adaptive changes are intended to change the system to
make it operate in a new environment.
• The configuration manager must decide how often the
components affected by these changes should be rebuilt
into a new version or release of the system.
 Configuration Management – Version and
Release Management
Release Management
When a new release of a system is created, the
changes which have been made may introduce
new faults or bring other existing faults to light.
The more changes to system, the more new faults
will be introduced.
If a release incorporates a large number of
changes, it is likely that there will be a
correspondingly a large number of new faults.
These have to fixed in the next system release.
 Configuration Management – Version and
Release Management
Release Management
Lehman suggested that if a lot of new
functionality was introduced in one release
of a system, it would be necessary to
issue another release fairly quickly.
• This suggests that it is unwise to change
too much of a system’s functionality at
once. Otherwise an excessive number of
faults may be introduced.
 Configuration Management – Version and
Release Management
Release Management
• A good change strategy is to interleave fault
repair release immediately after the
Enhanced release.
• All serious faults (faults which cause system
corruption) should be repaired before
functional or behavioral changes are applied.
Enhanced Repair Repair Enhanced Repair
release release release release release

Figure – System Release Strategy

 Configuration Management – Version and
Release Management

Version Management Tools

Version management involves managing large amounts of
information and ensuring that system changes are
recorded and controlled.
• There are several CASE tools available to support
version management.
• For UNIX platforms, the most widely used version
management systems are SCCS (Rochkind, 1975) and
RCS (Tichy,1985).
• Version management system control a repository of
configuration items where the contents of that repository
are immutable (i.e. cannot be changed).
 Configuration Management – Version and
Release Management

Version management tools

All version management systems provide a
comparable basic set of capabilities although
some have more sophisticated facilities than
others. Examples of the capabilities which may
be included in a version management system
are:
3. Version and release identification
4. Controlled change
5. Storage management
6. Change history recording
Configuration Management – CM Tools

Configuration Management Tools

• VSS – Visual Source Safe for documents.
• VSTS - Visual Studio Team System
• VAJ - Visual Age for Java for source files.
• RCE – Revision Control Engine.
• Software Manager – Information from virtual sky.
• QVCS – Quma Version Control System.
• Source Code Manager.
• SCLM – Software Configuration Library Manager.
• CVS – Concurrent Version System.
Configuration Management – CM Tools
VSS
• VSS is used through out the life cycle. The purpose of
this tool is identifying the configurable items in the
project. Keep those in repository and maintain version
controlling.
• It is a Version control tool.
• VSS is a virtual library of computer files.
• VSS is a common repository
• In VSS store the information like FRS, SRS, TP, Test
cases documents
• In VSS documents read only but not modifying
• If we want to modify that first we need to check out
(download) the required file to our local system then
modify the file and then check in (upload) the modified
one.
Configuration Management – CM Tools
VSS
• Virtual Source Safe... Visual SourceSafe (VSS)
is a client/server application which acts as a
storage system for files.
• A file stored in a VSS server is not available via
the standard file system, instead, it must be
accessed through the VSS client tools Tool.
• Mainly useful to developer, for storing code and
maintains version copying a code from VSS By
developers is called CHECK-IN Upload the code
in to VSS is called CHECKOUT.
Configuration Management – CM Tools
VSS-VSTS
• Microsoft recently developed a team collaboration tool called "Visual
Studio Team System" (VSTS). This tool allows source control
management and several other software development management
tools.
• Microsoft will be promoting VSTS in future instead of VSS. However,
next few years, VSS will still be the most popular source control
system due to it's easy to use user interface, simple configurations
and availability of experienced users.
• Visual Source Safe is available as part of Visual Studio .NET
products.
• The following are the various versions currently in use by majority of
the development teams:
• Visual Source Safe 5.0
• Visual Source Safe 6.0
• Visual Source Safe 2005 Visual Source Safe 2005 is
available as part of the Visual Studio 2005 suite of products.