You are on page 1of 52

Configuration

management

What is CM?
Configuration management (CM) is the discipline of
controlling the evolution of complex systems; software
configuration management (SCM) is its specialization
for computer programs and associated documents.
IEEE standard 729-1983 definition
Identification: an identification scheme reflects the
structure of the product, identifies components and their
type, making them unique and accessible in some form
"This program worked yesterday. What happened?
"I cant reproduce the error in this configuration.
"I fixed this problem long ago. Why did it reappear?
"The online documentation doesnt match the
program.
"Do we have the latest version?"

Control: controlling the release of a product and changes to it throughout


the lifecycle by having controls in place that ensure consistent software
via the creation of a baseline product
"How do I configure a test system that contains my temporary fixes to
the last baseline, and the released fixes of all other components?
"Given a list of fixes and enhancements, how do I configure a system
that incorporates them?
"This enhancement wont be ready until the next release. How do I
configure it out of the current baseline?
"How exactly does this version differ from the Baseline?"
Status Accounting: recording and reporting the status of components
and change requests, and gathering vital statistics about components in
the product.
"Has this problem been fixed?
"Which bug fixes went into this copy?
"This seems like an obvious change. Was it tried before?
"Who is responsible for this modification?
"Were these independent changes merged?"
Audit and review: validating the completeness of a product and
maintaining consistency among the components by ensuring that the
product is a well-defined collection of components

CM in a hardware-development environment
A computer has a processor, a mainboard, some
memory, a hard drive, a monitor, and a keyboard.
Each of these hardware items has an interface
that connects it to other hardware items.
Your mouse has a plug, and your computer has a
port into which you plug your mouse, and makes
everything works.
If the plug on the mouse was not compatible with
the port on the computer, there would be no way
to connect the two pieces of hardware into a
working system.

Throughout the computer, there are many other similar


interfaces.
The processor and memory plug into the mainboard, the
hard drive plugs into the computer, and the printer,
monitor, and keyboard all have interfaces.
When the hardware is manufactured, the interfaces that
are essential for the operation of the final system are
easily seen. Therefore, they are well known and are
carefully examined whenever changes are made to the
hardware design.
For a hardware system, configuration management has
the following aspects.
Each system is numbered or identified and also has a
version number. Each version number identifies different
designs of the same part.
When the design of a hardware system is changed, the
system gets a new version number.

A hardware system can be made up of hundreds,


thousands, or tens of thousands of parts.
The next thing that must be recorded is which
versions of these parts go together.
version of the mouse, hard drive, processor, and
monitor go together to make a complete system.
Each of these parts, such as a hard drive, is made
of many, many subparts, all of which must go
together to have a working unit.

Software development and


maintenance phases and CM

Configurati
on
manageme
nt

Documenta
tion CM

Code CM

WHY CM?
Software configuration management must ensure
that:
software components can be identified;
software is built from a consistent set of components;
software components are available and accessible;
software components never get lost (e.g. after media failure
or operator error);
every change to the software is approved and documented;
changes do not get lost (e.g. through simultaneous updates);
it is always possible to go back to a previous version;
a history of changes is kept, so that is always possible to
discover who did what and when.

Software develops from baseline to baseline until


it can be released.
Changes to baselines must be controlled
throughout the life cycle by documenting the:
problems, so that they can be understood;
changes that are proposed to solve the problem;
modifications that result.
ESA PSS-05-0 identifies five primary configuration
management activities:

configuration
configuration
configuration
configuration
release.

identification;
item storage;
change control;
status accounting;

Software Configuration
Management Activities
(Software configuration management plan)

SPMP Software project management plan

Important concepts and terms


in CM
Component Item (CI)
A CI is an aggregation of hardware, software or both that is
designated as a unit for configuration management, and treated
as a single entity in the configuration management process
A CI can be an aggregation of other CIs, organised in a hierarchy.
Any member of this hierarchy can exist in several versions, each
being a separate CI.

Examples of configuration items(CI) are:


software component, such as a version of a source module, object
module, executable program or data file;
support software item, such as a version of a compiler or a linker;
baseline, such as a software system under development;
release, such as a software system in operational use;
document, such as an ADD.

Types of CI
The type field of a CI identifier should identify the
processing the CI is intended for. There are three
main types of CI:
source CIs;
derived CIs;
tools to generate derived CIs from source CIs.

Configuration identification
Configuration identification conventions should state how
to:
name a CI;
decide who is the control authority of a CI;
describe the history of a CI.

At the top level, the whole system is a CI.


Several factors may be relevant in deciding what to
identify as the lowest level CI, such as the:
software design defined in the ADD and DDD (the lowest level of
the software design sets the lowest possible level of configuration
management);
capabilities of the software development tools (e.g. the units that
the compiler or linkers input and output);
bottom-level work packages defined in the SPMP.

Baselines
A baseline' is a CI that has been formally reviewed and
agreed upon (i.e. approved), and declared a basis for further
development.
Although any approved CI in a system can be referred to as
a baseline, the term is normally used for the complete
system.
Early baselines contain only documents specifying the
software to be built; later baselines contain the code as well.
The CIs in a baseline must be consistent with each other.
Examples of consistency are:
code CIs are compatible with the design document CIs;
design document CIs are compatible with the requirements document
CIs;
user manual CIs describe the operation of the code CIs.

Variants
The term variant' is often used to identify CIs
that, although offering almost identical
functionality, differ in aspects such as:
hardware environment;
communications protocol;
user language (e.g. English, French).

Variants may also be made to help diagnose


software problems.
The usefulness of such variants is often
temporary, and they should be withdrawn when
the problem has been solved.

Configuration item control


authority
Every CI should have a unique control authority
that decides what changes will be made to a CI.
The control authority may be an individual or a
group of people.
Three levels of control authority are normally
distinguished in a software project:
software author;
software project manager;
review board.

Software author
Software authors create low-level CIs, such as
documents and code.
Document writers are usually the control authority
for draft documents.
Programmers are normally the control authority
for code until unit testing is complete.

Software project manager


Software project managers are responsible for the
assembly of high-level CIs (i.e. baselines and
releases) from the low-level CIs provided by
software authors.
Software project managers are the control
authorities for all these CIs.
Low-level CIs are maintained in software libraries.
On most projects the software project manager is
supported by a software librarian.

Configuration item history


The development history of each CI must be recorded from
the moment it is first submitted for review or integration.
For documents, this history is stored in Document Change
Records (DCRs) and Document Status Sheets (DSS).
Change records in module headers should reference the
Software Change Request (SCR) that actioned them.
For derived code, the development history is stored in the
librarian's database.
The development history should include records of the
tests that have been performed.
The Software Modification Report (SMR) should summarise
the changes to CIs that have been revised in response to
an SCR.

Configuration item storage


All CIs must be stored securely so that they never
get lost.
Software projects can accumulate thousands of lowlevel CIs, and just as books are stored in libraries, it
is necessary to store low-level CIs in software
libraries.
The software libraries are themselves CIs.
Software CIs reside on hardware media (e.g. paper,
magnetic disk).
Storage media must be maintained securely and
safely so that software is never lost or its integrity
compromised.

Software libraries
A software library is a controlled collection of configuration
items (e.g. source module, object module and document).
Low-level CIs are developed and stored in libraries (e.g.
source and object libraries), and then extracted to build
high-level CIs (e.g. executable images).
As a minimum, every project must use the following
software libraries to store CIs:
development (or dynamic) libraries
master (or controlled) libraries
archive (or static) libraries

Master libraries store CIs in the current baselines.


Archive libraries store CIs in releases or retired baselines.
CIs in archive libraries must not be modified

Access control to libraries


Access to software libraries should be controlled so that it is
impossible:
to access CIs without the correct authorisation;
for two people to simultaneously update the same CI.

Read access allows a CI to be examined or copied.


Insert access right allows a new CI to be added to a
software library.
Delete access right allows a CI to be removed from a library.
Replace right allows a CI to be removed from a library and
another version inserted.

Development staff access rights

Software librarian access rights

Table 1 does not mean that a development library should


be accessible to all developers
Apart from the software librarian, only the person directly
responsible for developing or maintaining the CIs in a
development library should have access to them. For
sharing software, master libraries should be used, not
development libraries.
Simultaneous update occurs when two or more
developers take a copy of a CI and make changes to it.
When a developer returns a modified CI to the master
library, modifications made by developers who have
returned their CI earlier are lost.
A charge-in/charge-out or locking mechanism is required
to prevent simultaneous update.

Table 1: Development staff

Media control
All CIs should be stored on controlled media (e.g. tapes, disks).
Media should be labelled, both visibly (e.g. sticky label) and
electronically (e.g. tape header).
The label should have a standard format, and must contain the:

project name
configuration item identifier (name, type, version)
date of storage
content description

Procedures for the regular backup of development libraries


must be established.
Up-to-date security copies of master and archive libraries must
always be available .
An aim of good media control is to be able to recover from
media loss quickly.

VERSION CONTROL

Version control
Management of multiple revisions of the same unit of
information.
Changes identified by incrementing an associated number
or letter code - revision number, or revision level.
Revision numbers (levels) are associated historically with
the person making the change

Repository
A server where the files are stored.

Check-Out
copies a working copy from the repository
(the opposite of an import).

Change
A specific modification to a document under version control.
The granularity of the modification considered a change
varies between version control systems.

Change List

The set of changes made in a single commit.


A sequential view of the source code.

Commit or Check-in

Copy the changes on the local files to the directory.


(the VC software takes care of changes since the last synchronization).

Update

copies the changes that were made to the repository into your working
directory.
(opposite of a commit).

Merge / Integration
brings together (merges) concurrent changes into a unified revision.

Revision or version
one version in a chain of changes.

Conflict
Occurs when two changes are made by different parties to the
same document or place within a document.

Resolve
The act of user intervention to address a conflict between
different changes to the same document.

Example
CM Clients

Trunk

CM Server
Version A
Branch

Machine A

Version A.1
Branch

Check Out
Check In
C

Machine B
B
Check Out
D
Merg
e

Check In

Version B
Branch

History
CM systems save the files history.
Old versions can be viewed, compared, and
downloaded.
New versions can be (irreversibly) replaced with
old versions and wiped off the map.

Central repositories
Files are saved in a central file server.
Developers can view the files in the repository,
through the use of filters.

Labels
Several files can be labeled together.
Allows :
Access to the label as a whole set of files.
Changes to the labeled files as a unit.

Useful for marking product releases.

Check-in
Copies a file into the database.
The version you see is (usually) the latest version
that was checked in.
The old version is kept and can be accessed later.

Checkout
Copies the database file to your personal folder,
and raises a flag on the database copy.
Need to check out before checking in.

Undo check out (uncheck-out)


The undo checkout command does just that
the file returns to the status it had before it was
checked out.
This can be done even if changes have been
made to the local copy of course, these do not
go into the database!

Problems with file sharing


All version control systems have to solve the same
fundamental problem: how will the system allow
users to share information, but prevent them from
accidentally stepping on each other's feet?

Scenario
Suppose we have two co-workers, Harry and Sally.
They each decide to edit the same repository file
at the same time. If Harry saves his changes to
the repository first, then it's possible that (a few
moments later) Sally could accidentally overwrite
them with her own new version of the file. While
Harry's version of the file won't be lost forever
(because the system remembers every change),
any changes Harry madewon'tbe present in
Sally's newer version of the file, because she
never saw Harry's changes to begin with. Harry's
work is still effectively lostor at least missing
from the latest version of the fileand probably
by accident.

Versioning Models
Lock-Modify-Unlock Solution:

Only one person can change a file at a


time.
Example: VSS.
Copy-Modify-Merge Solution:

Users modify private copies only - in


parallel
Private copies are merged together into a
new, final version.
Example: CVS, Subversion.

The Lock-Modify-Unlock Solution

Problems With Locking


Administrative problems:
A user can lock a file and forget about it.
Time is wasted while others wait to edit the file.

Unnecessary serialization:
Different parts of a file dont necessarily overlap.
E.g.: Alice works on the beginning of a file, Bob wants to
edit the end of the same file.

False sense of security:


Lets say Alice locks and edits file A, while Bob
simultaneously locks and edits file B.
Lets say A and B depend on one another, and the changes
made to each are semantically incompatible.
Suddenly, A and B don't work together anymore.

The Copy-Modify-Merge
Solution
Aviva and Arik
both check out
file A.
Here, checkout
has no locking
effect its just a Read
local copy.
A

Repository
A

Read

The Copy-Modify-Merge
Solution
Both edit their local
files.

Repository
A

Aviva
Arik

The Copy-Modify-Merge
Solution
Aviva checks in
her file to the
repository first.

Repository
Aviva

Write

Aviva

Arik

The Copy-Modify-Merge
Solution
Now, Arik tries to
check-in his file.
He gets an upto-date check
error
Write

Arik

Repository
Aviva

Aviva

The Copy-Modify-Merge
Solution
Arik updates his local
copy to contain the
changes made by
Aviva. Changes are
added to the local file.
During this merge,
conflicts may occur.

Read

A
(=Aviva+Arik
)

Repository
Aviva

Aviva

The Copy-Modify-Merge
Solution
A new merged
file is created on
Ariks machine.

Repository
Aviva

Aviva

The Copy-Modify-Merge
Solution
Arik commits his
file to the
repository.

Repository
B

Write

Aviva

The Copy-Modify-Merge
Solution
Aviva updates her file
from the repository.

Repository
B

Read

THE SOFTWARE CONFIGURATION


MANAGEMENT PLAN

Introduction
All software configuration management activities shall
be documented in the Software Configuration
Management Plan
Each SCMP section must document all software
configuration management activities, specifically the:

organisation of configuration management;


procedures for configuration identification;
procedures for change control;
procedures for configuration status accounting;
tools, techniques and methods for software configuration
management;
procedures for supplier control;
procedures for the collection and retention of records.

IEEE Guide to Software Configuration Management


contains examples of plans for:
a complex, critical computer system;
a small software development project;
maintaining programs developed by other activities or
organisations;
developing and maintaining embedded software.

Configuration management procedures must be in


place before software production (code and
documentation) starts
Software configuration management procedures
should be easy to follow and efficient.
Wherever possible, procedures should be reusable in
later phases.
Instability in software configuration management
procedures can impede progress in a software project.

About SCMP
STYLE
The SCMP should be plain and concise.
The document should be clear, consistent and modifiable.
The author of the SCMP should assume familiarity with the
purpose of the software, and not repeat information that
is explained in other documents.

RESPONSIBILITY
The developer is responsible for the production of the
SCMP.

MEDIUM
It is usually assumed that the SCMP is a paper document.
There is no reason why the SCMP should not be
distributed electronically to participants with the
necessary equipment.

SCMP
content

Reference:
Guide to software configuration
management by ESA Board for
Software Standardisation and
Control (BSSC), ESA PSS-05-09
Issue 1 Revision 1, March 1995
Software Configuration
Management Overview by Walter
Tichy
http://svnbook.redbean.com/en/1.0/ch02s02.html

Thank
you

You might also like