Report On Software Configuration Management

A Tutorial on Software
Configuration Management
by Vivek Kaushal
Abstract:
Software configuration management (SCM) is the discipline of controlling the
evolution of complex software systems. This tutorial gives the historical
background and surveys methods and tools that support or automate
aspects of SCM. It proposes a standard terminology describes the areas that
are amenable to automation, discusses a representative set of existing SCM
tools, and identifies directions for future research and development.
Appendix 1 is Glossary and Appendix 2 is an annotated of relevant web sites,
technical papers and other reference materials.
1.Introduction
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.
General CM in a broad way is good for managing large systems but its
actual application for small systems or software is not viable.
SCM differs from general CM in the following two ways. First, software is
easier to change than hardware, and it therefore changes faster. Even a
small software made by a small time can experience change at very fast
rate. And second, SCM is potentially more automatable. Because all
components of a software system are easily stored on-line.
Dealing with software configuration management (SCM) has many
problems involved in it. Many developers work on the same software
which keeps on changing, support for more than one version needs to be
given and the same software will run on different machines and operating
systems maintaining the same user experience due to which there is
many times problem of coordination between the developers. These are
few problems that are handled by Software Configuration Management
which manages the changes and cost involved in those changes
effectively.
1 Tutorial on Software Configuration Management
Opinions still vary greatly as to what tools and methods are best for
software configuration management. This tutorial explains several of the
most widely accepted approaches and also reviews a number of tools
designed to assist with selection.
2.History
The history of software configuration management (SCM) in computing
can be traced back as early as the 1950s, when CM (for Configuration
Management), originally for hardware development and production
control, was being applied to software development. Early software had a
physical footprint, such as cards, tapes, and other media. The first
software configuration management was a manual operation. With the
advances in language and complexity, software engineering, involving
configuration management and other methods, became a major concern
due to issues like schedule, budget, and quality. Practical lessons, over the
years, had led to the definition, and establishment, of procedures and
tools.
The first SCM systems of early 80s were developed in house and their
primary focus was on file control. Most of them were built as a set of UNIX
scripts over RCS (a simple version control tool).
In early 90s, the first real SCM tools emerged. These tools were much
better than the previous generation tools and often used relational
database but still heavily relied on file control. This generation included
Clear Case (DSEE successor) which introduced the virtual file system and
Continues which introduced, with Adele, explicit process support.
Continues and Clear Case are currently the market leaders.
In late 90s, web programming grew big and this gave rise to remote
programming which in turn increased the demand of SCM in the market.
During this period process support came to SCM and all the previous SCM
projects matured. SCM market grew as big as $1 billion in 1998 and SCM
was considered as one of the very important aspects in software
development.
The 21st century, brought further optimizations and innovations in the
working of SCM systems and also brought new SCM solutions like
Subversion with improved memory utilization etc. Big players of the
industry like Microsoft, IBM etc. also found this technology quite useful
and implemented it in their flagship tools like Visual Studio. Another
innovative and effective technology GIT emerged recently for SCM making
remote project management more easy job.
3.Software Configuration Management Activities

According to the IEEE's (IEEE Std. 828-1990) traditional definition of
SCM, the following four activities are included:
1. Configuration Identification
2. Configuration Control
3. Configuration Status Accounting
4. Configuration Audit
The Basic Activities of SCM
3.1 Configuration Identification

The first step in configuration management is to define the
configuration items (CIs) and the conventions for their
identification. The configuration item list physically defines the
components to be developed and the baselines to be integrated.
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.
3.1.1 What to identify as configuration items?

Too much identification can be hard to maintain whereas too
little causes confusion and productivity problems so
identification of CI has to be just right. Several factors may
be relevant in deciding what to identify as the lowest level CI,
such as the:
Defined software design.
Capabilities of the software development tools.
Bottom-level work package
Based on the above factors the CIs are then defined which may
include:
Requirement Analysis Document

System Design Document
Object Design Document
Source Code
Unit Tests
Test Data
Support Software
Once the CIs are listed they are then organized in a tree.
3.1.1.1 Baseline:
A baseline is a type of CI that has been formally reviewed
and approved and declared as the basis of further
development. Software development proceeds from
baseline to baseline, accumulating new or revised CIs in
the process. Early baselines contain only documents
specifying the software to be built; later baselines contain
the code as well.
3.1.1.2 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).
The need to develop and maintain several variants can

greatly complicate configuration management, so the
number of variants should be minimized. One way to do
this is to include conditional code in modules, so that one
module can handle every variation.
Each CI should possess a unique name or identifier. Unique
and easy names help developers to quickly determine the
item and make appropriate changes according to the
requirement. Mainly CI can be grouped in following types:
Source CIs are created by software engineers.

Corrections and modifications to CIs should always
be done at source level. For example, documents,
source code etc.
Derived CIs are created by processing source CIs in
tools like compilers and linkers. There should be a
distinct identifier to identify the Derived CI and tool
used for deriving it. For example, object files,
executable files etc.
Version numbers allow changes to CIs to be

distinguished. Whenever a CI is changed, the version
number changes. In most configuration management
systems, the version number is an integer.
3.1.1.3 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.
Large projects may have more levels. As a CI passes
through the stages of verification (formal review meeting in
the case of documents, unit, integration, system and
acceptance tests in the case of code), so the control

authority changes to match the higher verification status of
the CI.
3.1.1.3.1Software 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.
3.1.1.3.2Software 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.
3.1.1.3.3Review board
The review board approves baselines and changes to
them. During the TR and OM phases, baselines are
controlled by the Software Review Board (SRB).
The review board is the control authority for all
baselines that have been approved or are under
review. The review board may decide that a baseline
should be changed, and authorizes the development
or maintenance team to implement the change.
Control authority rights are not returned. Those
responsible for implementing changes must resist
the temptation to make any changes that have not
been authorized.
3.2 Configuration Control

Software can change very quickly and easily, and uncontrolled
changes can lead to chaos. Therefore, after the configuration items
of the system have been identified, the next step is to control the
changes to the software.
The change management process for conventional software (Asklund &

Bendix 2002)
Controlling changes during software development has been defined as
a task for SCM (Pressman 1997). According to (IEEE Std. 610.12-1990),
baselines can be changed only through formal change control
procedures including the following steps: evaluation, coordination,
approval or disapproval and implementation of changes to
configuration items.
A change request can result from many things. For example, new
features, enhancements of existing features or defects can lead to
change requests. Figure above presents a traditional change control
process. The 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. 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.
Change is intrinsic in software and must be accepted as a fact of life.
Making changes to software is easy, but if it is done at will, chaos will
result. However, the level and formality of control required varies
considerably; large teams need strict and formal change control, but
small teams can rely on much less formal control.
Changes must be verified before the next changes are implemented. If
changes are done in a group, each change must be separately
verifiable. For documents, this just means that the Document Change
Record (DCR) at the beginning of a document should describe each
change precisely, or that a revised document is issued with change
bars. For code, groups of changes must be carefully analyzed to
eliminate any confusion about the source of a fault during regression
testing. If time permits, changes are best done one at a time, testing
each change before implementing the next. This one-at-a-time'
principle applies at all levels: code modification and unit testing;
integration and integration testing, and system testing.
3.3 Configuration Status Accounting

Software configuration status accounting is 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 the proposed changes'. The status
of all configuration items must be recorded (SCM31). Configuration
status accounting continues throughout the life cycle. The software
librarian is normally responsible for maintaining the configuration
status accounts, and for checking that the as-built' configuration
status complies with the as-designed' status defined in the SCMP.
Configuration status accounts are composed of:
Records that describe the contents, dates and version/issue of

each baseline;
Records that describe the status of problem reports and their

solutions.
Example of Baseline Records
Above table is an example of a table of baseline records. Each column

of the table lists CIs in a baseline. The table shows the issue and
revision number of each document, and the version number of the
code in seven baselines. Six of the baselines are associated with the
six major milestones of the software project. An extra interim baseline
is created during integration. The table assumes that revisions to each
document are required between each baseline to show how the version
numbers change. This is an extreme case.
Configuration status accounts are important instruments of project
control, and should be made available to all project members for up-todate information on baseline status. When a program works one day
and not the next, the first question is what has changed?'. The
configuration status accounts should answer such questions quickly
and accurately. It should be possible to reproduce the original baseline,
verify correct operation, and individually reintroduce the changes until
the problem recurs.
Values of quality metrics (e.g. reliability) might be derived by means of
data in the configuration status accounts, and these metrics might be
used to decide the acceptability of the software. Sometimes quite
simple pieces of information can be highly significant. A module that
requires frequent bug fixes' may have more serious structural
problems, and redesign may be necessary.
3.4 Configuration Audit

The purpose of configuration audits is to ensure that the software
product has been built according to specified requirements
(Functional Configuration Audit, FCA), to determine whether all the
items identified as a part of CI are present in the product baseline
(Physical Configuration Audit, PCA), and whether defined SCM
activities are being properly applied and controlled (SCM system
audit or in-process audit). 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.
Auditing can be of two types:
3.4.1 Functional Configuration Audit

Verifies that the software does what it is supposed to do
Meets its requirements,
Passes its tests,
Is properly designed, etc.
3.4.2 Physical Configuration Audit

Verifies that all the parts are there and that they are the
correct parts. For example, if you compile the source using the
right compiler, do you get the right version of the object
code?
4. SCM Planning
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 (Buckley
1996). Thus, the SCM plan serves as a guideline for the people working
with software configuration management. According to Buckley (1996),
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.
According to Software Engineering: Principles and Practice by Hans Van
Vliet it can be divided in following parts:
1. Introduction
2. SCM Management
3. SCM Activities
4. SCM Schedules
5. SCM Resources
6. SCM Plan Maintenance
Following table gives the common contents of an SCM plan according
to IEEE standards (IEEE Std. 828-1998):
4.1 Introduction to SCM Plan:

Introduction phase of a Software Configuration Plan gives the
following things:
Overview description of the software project

Identification of the software CI(s) to which SCM will be
applied
Identification of other software to be included as part of the
Plan (e.g., support or test software)
Relationship of SCM to the hardware or system configuration
management activities for the project
The degree of formality, depth of control, and portion of the
software life cycle for applying SCM on this project
Limitations, such as time constraints, that apply to the Plan
Assumptions that might have an impact on the cost,
schedule, or ability to perform defined SCM activities (e.g.,
assumptions of the degree of customer participation in SCM

activities or the availability of automated aids).
4.2 SCM Management:

This involves following:
4.2.1 Organization
Organizational context (technical and managerial) within
which the configuration management activities are
implemented.
4.2.2 Responsibilities
List name or job title of people how perform activities
For each board, list
o Purpose and objectives
o Membership and affiliations
o Period of effectivity.
o Scope of authority
o Operational procedures
4.2.3 Applicable policies, directives and procedures:
External constraints placed on the SCMP.
4.3 SCM Activities:

SCM Activities involve the following:
Configuration identification
o Identify configuration items (events, items,
procedures).
o Name configuration items (unique identifiers).
o Acquiring configuration items (physical
procedures).
Configuration control
o Requesting changes.
o Evaluating changes.
o Approving or disapproving changes.
o Implementing changes.
Configuration status accounting
o Metrics to be tracked and reported and type of
report.
o Storage and access control of status data.

Configuration evaluation and reviews
At minimum an audit on a CI prior to its release.
Defines objective, schedule, procedures, participants,
approval criteria etc.
Interface control
Coordination of changes to CIs with changes to
interfacing items outside of the scope of the Plan.
Subcontractor/vendor control
Incorporation of items developed outside the project
environment into the project CIs.
Release Management and Delivery
Description of the formal control of build, release and
delivery of software products.
4.4 SCM Schedules:
4.5
Sequence and coordination of SCM activities.

Relationship of key SCM activities to project milestones
or events, such as
Establishment of configuration baseline.
Implementation of change control procedures.
Start and completion dates for a configuration audit.
Schedule either as absolute dates, relative to SCM or
project milestones or as sequence of events.
Graphical representations can be used here.
SCM Resources:
Identifies environment, infrastructure, software tools,

techniques, equipment, personnel, and training.
Key factors for infrastructure: functionality, performance,
safety, security, availability, space requirements, equipment,
costs, and time constraints.
Identify which tools etc. are used in which activity.
4.6 SCM Plan Maintenance:
This section answers the following questions

o Who is responsible for monitoring the Plan
o How frequently updates are to be performed
o How changes to the Plan are to be evaluated and
approved
o How changes to the Plan are to be made and

communicated.
Also includes history of changes made to the plan
Example of a SCM Plan:
5. People involved in SCM:

There are Three Generally Acknowledged Configuration Management
Roles:
Configuration Manager or Librarian

Module Owner
Change Control Authority
For ideal case these three should work together for effective CM. But
normally these jobs are performed in different organizations which
sometimes result in problems.
5.1 Configuration Manager or Librarian:

The configuration manager is the central control point for all changes
in the software configuration management. Responsibilities of the
Configuration Manager or Librarian include:
Defines/communicates/enforces procedures.
Establishes baselines and backups.
Forbids unauthorized changes.
Records all changes.
Assures that changes are properly tested.
Resolves all exceptions.
Configures and operates CM tools.
5.2 Module Owner

The module owner has following technical responsibilities:
Responsible for technical integrity.

Knows and understands the design.
Knows and understands the interfaces to/from the module.
Technical control point for changes, fixes, enhancements.
May do periodic regression tests.
Reviews all changes.
5.3 Change Control Authority

Responsibilities of the change control authority includes control,
evaluation, authorization and coordination of changes from:
Includes representatives from all affected functions, such as

development, documentation, quality assurance,
maintenance, test, etc.
Makes sure all ramifications of any proposed change are
understood.
Authorizes work to make changes.
These are the responsibility of Configuration Control Board.

Configuration control board has two groups:
Typical Members:
Typical members include the following:

Software Manager
Configuration Manager
Quality Assurance Manager
Representatives of All Parts of the Software
o Sometimes, only those affected by a change will
participate in a meeting of this board
Representatives of Other Parts of the System that Might Be
Effected by a Change
o For example, a systems engineer
These members are not always required to be technical.

Typical Meeting Participants:
All members of the Board (or all who might be affected by the
changes under consideration)
Module owner(s) for all modules that may need to be changed
Anyone else who has related expertise or concerns
o Sometimes you have a separate, technical committee
to evaluate proposed changes and advise the CCB as to
the technical issues involved
6. Tools Used in Configuration Management:

The basic SCM activities introduced in the previous subsection are
assisted by SCM tools. The role of an SCM tool is to automate SCM
activities and to improve development productivity. Automating
manual SCM tasks provides more time to do the actual development
work, leading to improved speed and productivity. From a developer
point of view, SCM offers a stable development environment, maintains
configuration items, stores their history, supports product building and
coordinates simultaneous changes. In other words, it helps software
developers in their daily work. A typical modern software configuration
management tool provides primary services in the following areas:
Management of the repository of components.
Version control.
Support for engineers.
Workspace management.
Concurrency control.
System building.
Process control and support.
6.1 Common Features of SCM Tools:

Today there are a number of SCM tools available, while their
features vary greatly. Each tool has its own strengths and
weaknesses. For example, some are better at change management,
whereas others have excellent build management and versioning
capabilities.
6.1.1Version Control:
The main purpose of version control is to manage different
versions of configuration objects that are created during the
software engineering process (Pressman 1997). The term
object is used by some authors to describe CI. A
component repository is a place where all the versions of
CIs are kept. The terms version, revision and variant are
basic SCM concepts. Therefore, their differences are explained
next. The meaning of branching and merging is also
explained.
Variants are versions that are organized in parallel
development lines called branches. However, branches are
only one way to implement variants, because they can be
done also with conditional compilation, with installation
description, or with a run-time check. There are two types of
variants: permanent and temporary (Whitgift 1991).
Permanent variants are created, for example, when the
product is adjusted for different environments. There can be a
variant for Linux and another for Windows. The difference
between a permanent and a temporary variant is that a
temporary variant will later be integrated with another variant
(Zeller 1996). This kind of integration is also called merge.
According to Whitgift (1991), an instance of an item, each of
its variants and revisions, is called an item version.
Following figure depicts development of a software done in

various branches where version control is needed the most.
6.1.2Workspace Management:
SCM tools can also help developers to work in peace by
providing them with private workspaces. The purpose of
provided workspace is to prevent users from interfering with
one another's work (Dart 1994). Developers can check out
desired files or configuration from the repository in their own
workspaces. The check out operation creates copies of the
items in the developer's workspace; after that, the developer
can modify the items as needed and finally execute check
in. The check in operation copies items back into the
repository: the version control system then creates new
versions as needed. Figure below represents the check out/in
process. A get operation equals to a check out operation,
except that the files copied into the workspace are read-only
and therefore cannot be modified. The terminology in use for
these operations can vary between different SCM tools.
6.1.3Concurrency Control:
The implementation of concurrency control depends on the
SCM tool in use. Some of these tools use so-called optimistic
concurrency control (Asklund &Bendix 2002), which means
that files are not locked when checking them out, and there
may be simultaneous modifications to the same files by
multiple users. Others prevent simultaneous access by using a
locking mechanism. Microsoft's Visual SourceSafe (VSS) is a
one example of an SCM tool in which both of these
mechanisms are implemented and locking is used as a
standard setting.
The advantages of concurrent development are remarkable.
Development teams can work with the same files, while the
SCM tool controls development. The difference between
concurrent and parallel development is that in concurrent
development, branches are finally merged into a single item,
whereas in parallel development merging is not performed
and branches go ahead separately. The same alternatives can
exist at the project level. For example, if there is a project that
reaches the testing stage, the project can be branched so that
testing and bug fixing can be performed separately.
Development continues in the main branch, and later on the
modified files on these two branches can be merged.
6.1.4System building
In system building (a.k.a. build management), the purpose is
to combine needed file versions and then compile them to
create an application. Building can be done for a subsystem, a
module, or a whole system (Leon 2000) and the building
strategy can be either incremental or from scratch. In
incremental building, only files that been changed will be
built; correspondingly, all files will be built when building from
scratch. According to Whitgift (1991), building from scratch
can be a very expensive process in terms of machine
resources, because a large system may contain thousands of
files of source code. SCM tools can facilitate building work by
capturing necessary information and making the building
process repeatable. To be repeatable, details of used
components, components' versions, the operating system and
its version, compiler and linker options etc., are required
(Leon 2000). An SCM tool usually includes a Make tool to
generate an executable software system reliably and
efficiently (Conradi & Westfechtel 1998).
6.1.5Process control and support

According to Estublier (2000), process support means both the
"formal" definition of what is to be performed on what (a
process model) and the mechanisms to help reality conform to
the model. In practice, a State Transition Diagram (STD) and
activity-centred modelling are offered as a solution. As an
example Estublier (2000) states that change control is
traditionally an integral part of SCM tools.
6.2 Examples of Software Configuration Management

Tools:
Software configuration management is normally supported by tools
with different functionality.
6.2.1Local Data Model:

In the local-only approach, all developers must use the same file
system.
Open Source Systems:
Revision Control System (RCS):

o Very old but still in use; only version control system
o Stores the latest version and backward deltas for
fastest access to the trunk tip compared to SCCS and
an improved user interface, at the cost of slow
branch tip access and missing support for
included/excluded deltas.
Source Code Control System (SCCS):
o Part of UNIX
o Based on interleaved deltas, can construct versions
as arbitrary sets of revisions. Extracting an arbitrary
version takes essentially the same speed and is thus
more useful in environments that rely heavily
on branching and merging with multiple "current"
and identical versions.
Out of the above discussed systems we will now discuss about the
RCS model in detail.
The Revision Control System (RCS) is a software

implementation of revision control that automates the
storing, retrieval, logging, identification, and merging of
revisions. RCS is useful for text that is revised frequently,
for example programs, documentation, procedural
graphics, papers, and form letters. RCS is also capable of
handling binary files, though with reduced efficiency.
Revisions are stored with the aid of the diff utility.
RCS was first released in 1982 by Walter F. Tichy while he
was at Purdue University. RCS was an alternative to the
then-popular Source Code Control System (SCCS). It is

currently maintained by the GNU Project.
The RCS Model
RCS is file-based and controls concurrency through locks.

Users first have to acquire a lock on a file before they can
modify it and check in a new version. Directories, file
renaming, and file copying are not tracked.
RCS operates only on single files; it has no way of working
with an entire project. Although it provides branching for
individual files, the version syntax is cumbersome. Instead
of using branches, many teams just use the built-in locking
mechanism and work on a single head branch.
RCS Numbering Model
Advantage:
o In single-user scenarios, such as server configuration
files or automation scripts, RCS may still be the
preferred revision control tool as it is simple and no
central repository needs to be accessible for it to
save revisions. This makes it a more reliable tool
when the system is in dire maintenance conditions.
Additionally, the saved backup files are easily visible
to the administration so the operation is
straightforward. However, there are no built-in
tamper protection mechanisms (that is, users who
can use the RCS tools to version a file also, by
design, are able to directly manipulate the
corresponding version control file) and this is leading
some security conscious administrators to consider
client/server version control systems that restrict
users' ability to alter the version control files.
Application:
o Some wiki engines, including TWiki and Foswiki, use
RCS for storing page revisions.
6.2.2Client-server model
In the client-server model, developers use a shared single
repository.
Open source
Concurrent Versions System (CVS) originally built on
RCS, licensed under the GPL.
CVSNT cross-platform port of CVS that allows case
insensitive file names among other changes.
OpenCVS CVS clone under the BSD license, with
emphasis put on security and source code correctness.
Subversion (SVN) versioning control system inspired
by CVS.
Vesta build system with a versioning file system and
support for distributed repositories.
Proprietary
AccuRev source configuration management tool with

integrated issue tracking based on "Streams" that
efficiently manages parallel and global development;
replication server is also available.
CA Software Change Manager (originally Harvest/CCC)
change and configuration management tool by Computer
Associates.
Autodesk Vault Version control tool specifically designed
for Autodesk applications managing the complex
relationships between design files such
as AutoCAD and Autodesk Inventor.
CADES - Designer productivity and version control system
by International Computers Limited.
IBM Rational ClearCase SCC compliant configuration
management system by IBM Rational Software
IBM Configuration Management Version Control (CMVC)
version control system, no longer available.
IBM Rational Team Concert Collaboration and application
lifecycle management platform by IBM Rational Software
IC Manage Global Design Platform (GDP) design data
management for IC design and Perforce infrastructure
support.
MKS Integrity.
Perforce Free for use in open source projects.
PVCS originally Polytron Version Control System,

developed by Don Kinzer at Polytron, first released in 1985.
Now owned by Serena.
Quma Version Control System
Razor (configuration management), integrated suite from
Visible Systems
SolidWorks Enterprise PDM - version and revision control
system also including notifications and workflows for
managing SolidWorks files as well as any other file types.
SourceAnywhere version control tool by Dynamsoft.
StarTeam coordinates and manages software delivery
process by Micro Focus, formerly Borland; centralized
control of digital assets and activities.
Surround SCM version control tool by Seapine Software.
Team Foundation Server (TFS) - Development software
by Microsoft which includes revision control.
Telelogic Synergy SCC compliant integrated change
management and task-based configuration management
system, proprietary of IBM.
Vault version control tool by SourceGear (First installation
can be used for free).
Visual SourceSafe version control tool by Microsoft;
oriented toward small teams.
From all the above systems let us discuss a few in detail.
6.2.2.1 CVS concepts
The Concurrent Versions System (CVS), also known as

the Concurrent Versioning System, is a client-server
free software revision control system in the field
of software development. A version control system keeps
track of all work and all changes in a set of files, and allows
several developers (potentially widely separated in space
and time) to collaborate. Dick Grune developed CVS as a
series of shell scripts in July 1986.
In addition to commercial software developers, CVS
became popular with the open source software world and
was released under the GNU General Public License. While
there was regular development to add features and fix
bugs in the past, including regular builds and test
results, there have been no new releases since 2008. The
product is mature: new releases are not produced until
there are requests for new features or bug reports.
CVS addresses two short comings of RCS:
o Directories are also controlled items
o Concurrency is dealt with optimistically, with a
copy/modify/merge approach (as opposed to
locking).
Matching of SCM Pattern to CVS concepts.
CVS uses a clientserver architecture: a server stores the

current version(s) of a project and its history, and clients
connect to the server in order to "check out" a complete
copy of the project, work on this copy and then later
"check in" their changes. Typically, the client and server
connect over a LAN or over the Internet, but client and
server may both run on the same machine if CVS has the
task of keeping track of the version history of a project with
only local developers. The server software normally runs
on Unix, while CVS clients may run on any major operatingsystem platform.
Several developers may work on the same project
concurrently, each one editing files within their own
"working copy" of the project, and sending (or checking in)
their modifications to the server. To avoid the possibility of
people stepping on each other's toes, the server only
accepts changes made to the most recent version of a file.
Developers are therefore expected to keep their working
copy up-to-date by incorporating other people's changes
on a regular basis. This task is mostly handled
automatically by the CVS client, requiring manual
intervention only when an edit conflict arises between a
checked-in modification and the yet-unchecked local
version of a file.
If the check in operation succeeds, then the version
numbers of all files involved automatically increment, and
the CVS-server writes a user-supplied description line, the
date and the author's name to its log files. CVS can also
run external, user-specified log processing scripts following
each commit. These scripts are installed by an entry in
CVS's login of file, which can trigger email notification or
convert the log data into a Web-based format.
Clients can also compare versions, request a complete
history of changes, or check out a historical snapshot of
the project as of a given date or as of a revision number.
The CVS Model
The CVS Copy/Modify/merge Model
6.2.2.2 Subversion concepts
Apache Subversion (often abbreviated SVN, after the

command name SVN) is a software versioning and revision
control system distributed as free software under
the Apache License. Developers use Subversion to
maintain current and historical versions of files such
as source code, web pages, and documentation. Its goal is
to be a mostly compatible successor to the widely used
Concurrent Versions System (CVS).
The free software community has used Subversion widely:
for example in projects such as Apache Software
Foundation, Free
Pascal, FreeBSD, GCC, Mono and SourceForge. Google
Developers also provides Subversion hosting for their free
software projects. CodePlex offers access to Subversion as
well as to other types of clients.
The corporate world has also started to adopt Subversion.

A 2007 report by Forrester Research recognized Subversion
as the sole leader in the Standalone Software Configuration
Management (SCM) category and as a strong performer in
the Software Configuration and Change Management
(SCCM) category.
Subversion was created by CollabNet Inc. in 2000, and is
now a top-level Apache project being built and used by a
global community of contributors.
Features:
o Commits as true atomic operations (interrupted
commit operations in CVS would cause repository
inconsistency or corruption).
o Renamed/copied/moved/removed files retain full
revision history.
o The system maintains versioning for directories,
renames, and file metadata (but not for timestamps).
Users can move and/or copy entire directory-trees
very quickly, while retaining full revision history.
o Versioning of symbolic links.
o Native support for binary files, with space-efficient
binary-diff storage.
o Apache HTTP Server as network
server, WebDAV/Delta-V for protocol. There is also an
independent server process called SVN serve that
uses a custom protocol over TCP/IP.
o Branching is a cheap operation, independent of file
size (though Subversion itself does not distinguish
between a branch and a directory)
o Natively clientserver, layered library design.
o Client/server protocol sends diffs in both directions.
o Costs proportional to change size, not to data size.
o Parsable output, including XML log output.
o Free software licensed Apache License since the 1.7
release; prior versions use a derivative of the Apache
Software License 1.1.
o Internationalized program messages.
o File locking for unmerge able files ("reserved

checkouts").
o Path-based authorization.
o Language bindings for C#, PHP, Python, Perl, Ruby,
and Java.
o Full MIME support users can view or change the
MIME type of each file, with the software knowing
which MIME types can have their differences from
previous versions shown.
o Merge tracking Merges between branches will be
tracked, this allows automatically merging between
branches without telling Subversion what (doesn't)
need to be merged.
o Change lists to organize commits into commit
groups.
The Subversion Model
Limitations of Subversion Model:

o A known problem in Subversion affects the
implementation of the file and
directory rename operation. As of 2014, Subversion
implements the renaming of files and directories as a
"copy" to the new name followed by a "delete" of the

old name. Only the names change, all data relating to
the edit history remains the same, and Subversion will
still use the old name in older revisions of the "tree".
However, Subversion may become confused when a
move conflicts with edits made elsewhere, both for
regular commits and when merging branches. The
Subversion 1.5 release addressed some of these
scenarios while others remained problematic. The
Subversion 1.8 release addressed some of these
problems by making moves a first-class operation on
the client, but it is still treated as copy + delete in the
repository.
o As of 2013, Subversion lacks some repositoryadministration and management features. For instance,
someone may wish to edit the repository to
permanently remove all historical records of certain
data. Subversion does not have built-in support to
achieve this simply.
o Subversion stores additional copies of data on the local
machine, which can become an issue with very large
projects or files, or if developers work on multiple
branches simultaneously. In versions prior to 1.7
these .SVN directories on the client side could become
corrupted by ill-advised user activity like global
search/replace operations. Starting with version 1.7
Subversion uses a single centralized. SCV folder per
working area.
o Subversion does not store the modification times of
files. As such, a file checked out of a Subversion
repository will have the 'current' date (instead of the
modification time in the repository), and a file checked
into the repository will have the date of the check-in
(instead of the modification time of the file being
checked in). This might not always be what is
wanted. To mitigate this third-party tools exist that allow
for preserving modification time and other file system
meta-data. However, giving checked out files a current

date is important as well.
o Subversion uses a centralized revision control model.
Ben Collins-Sussman, one of the designers of
Subversion, believes a centralized model would help
prevent "insecure programmers" from hiding their work
from other team members. Some users of version
control systems see the centralized model as
detrimental; famously, Linus Torvaldsattacked
Subversion's model and its developers.
o While Subversion stores filenames as Unicode, it does
not specify if pre composition or decomposition is used
for certain accented characters (such as ). Thus, files
added in SVN clients running on some operating
systems (such as Mac OS X)
use decomposition encoding, while clients running on
other operating systems (such as GNU/Linux) use pre
composition encoding, with the consequence that those
accented characters do not display correctly if the local
SVN client is not using the same encoding as the client
used to add the files.
6.2.2.3 Visual SourceSafe:

VSS is one of the more commonly used VC tools among
those using a Microsoft-based IDE such as Visual C++. VSS
has a very nice GUI and seamless integration with
programming language environment. It has limited support
for branching and parallel development. It is not intended
for projects that regularly require multiple codelines.
A repository in VSS corresponds to a database that holds
one or more master projects. It supports project-oriented
operations that operate on all selected files or all the files
defined to be in a specified project. A master project holds
the master copies of a set of files and their latest versions
(it also serves as the mainline).
Matching of SCM Pattern to VSS concepts.

Above table maps the SCM concepts and terms with the
terms used for them by VSS. The development workspace
is created by linking a project to working directory.
The working directory is initially made by performing a
project-wide GET operation to get all the tasks of the
project. The working directory can be updated anytime

using the GET operation to fetch the latest files in the
project.
Changes from the working directory are committed to the
master project or the codeline by performing a check-in
operation for all the modified tasks and the latest version
will be stored in the master project.
A new codeline is created for a project by sharing and

branching the files in that project to create a new copy of
that project.
The share operation links and copies the selected file

versions from the master project into a new project for
the new codeline.
The branch operation makes sure the selected files are

copies and may have their contents revised and evolved
independently of the project from which they were
initially shared.
The label operation creates a new label for the selected set
of tasks from the working directory.
The VSS has the following disadvantages:
o The get operation works properly for a workspace
update only when you check out the files you want to
change before making your local changes to them. If
you modify your local copies but don't invoke the get
operation until just before you are ready to check them
in, VSS won't know that your locally modified files were
checked out before other versions that were checked in
after you made your changes.
o VSS doesn't effectively support a branching depth of
more than two levels. If branching is performed for more
than two-levels it will not perform complete merge
operation for the entire hierarchy.
6.2.3Distributed Model
In the distributed approach, each developer works directly
with his or her own local repository, and changes are shared
between repositories as a separate step.
Open source
Aegis written by Peter Miller, mature software,

filesystem-oriented, limited network support. It has
support for distributed revision control. It has built-in
support for a disciplined process, including peer review
and regression testing.
ArX written by Walter Landry, started as a fork of GNU

arch, but has been completely rewritten
Bazaar written in Python, originally by Martin Pool and

sponsored by Canonical; decentralised, and aims to be
fast and easy to use; can losslessly import Arch
archives.
Codeville written in Python originally by Ross Cohen;

uses an innovative merging algorithm
Darcs written in Haskell and originally developed by

David Roundy; can keep track of inter-patch
dependencies and automatically rearrange and "cherrypick" them using a "theory of patches"
DCVS decentralized and CVS-based
Fossil written by D. Richard Hipp for SQLite; distributed

revision control, wiki, and bug-tracking
Git written in a collection of Perl, C, and various shell

scripts, designed by Linus Torvalds based on the needs
of the Linux kernel project; decentralized, and aims to
be fast, flexible, and robust
GNU arch
LibreSource configuration management
Mercurial written in Python as an Open Source

replacement to BitKeeper; decentralized and aims to be
fast, lightweight, portable, and easy to use
Monotone developed by the Monotone Team;

decentralized in a peer-to-peer way
SVK written in Perl by Kao Chia-liang; built on top of

Subversion to allow distributed commits
Veracity - Is another distributed version control system

which includes bug tracking and Agile software
development tools integrated with the version control
features.
Proprietary
BitKeeper was used in Linux kernel development

(2002 April 2005)
Code Co-op peer-to-peer version control system (can

use e-mail for synchronization)
Sun WorkShop TeamWare designed by Larry McVoy,

creator of BitKeeper
Plastic SCM by Codice Software, Inc.
From all the above systems let us discuss a few in detail.

6.2.3.1 GIT
GIT was developed by Linux development community
(and in particular Linus Torvalds, the creator of Linux) in
2005 when their partnership with BitKeeper for version
controlling broke down. It was developed keeping the
following things in mind:
Speed
Simple Design
Strong Support for non-linear development
Fully distributed
Ability to handle large projects like the Linux Kernel
efficiently.
Branching is one of the features which makes GIT unique

from other tools present in the market. Following are
some branching features that GIT offers:
We can perform context based switching to switch

between experiment branch and main production
branch while keeping each separate and merging
only when we want.
Create branch for each feature and commit as
many times as one wants and keep on merging
them by applying patches and deleting the feature
branches as they get merged in the final code.
Deleting a branch which is not working as desired
and not affecting anyone else using the directory.
GIT is pretty exciting open-source Distributed version

control tool which is fast and consumes very less space. It
is secure too as it converts all the commits into hash codes
so getting anything out requires exact bits to be same. But
this also turns out to be one of the drawbacks many people
complain about as hashes are not easy to read and
remember.
6.2.3.2 BitKeeper
BitKeeper is one of the very famous and widely ised
proprietary Distributed SCM system. Its history goes back
to 1992 when Linux development team was closely linked
with BitKeeper developing company to build it and from
1992-2002 there was various updates and changes to
make BitKeeper the system it is today. But due to end of
the partnership between the BitKeeper parent firm and
Linux systems it went paid and Linux developed GIT as
discussed in the previous section.
In the BitKeeper system every workspace is a repository.
Also the changes made are in the form of change-sets on
the workspace and the developers can propagate
change-sets back and forth between workspaces using
push and pull operations.
Matching of SCM Pattern to BitKeeper concepts.

The workspaces here work like an unnamed branch. A
developer can plan the codelines and create a hierarchy.
Branches need not be created when the change-set gets
pulled from another repository as the receiving repo
knows about the concurrent changes and creates
branches for those files on its own.
One of the important aspects of BitKeeper is that the

change-set is repository wide. It captures both the
change and the context of the change. This makes
BitKeeper time-safe as it makes o it easy to track the
evolution of a project based on the hierarchy of
workspaces.
BitKeeper is pretty easy to use and gives developer
option to use it either as a GUI or from the command-line.
One noticeable drawback of this system is that it is not
free and open for all as the other systems present like
GIT.
7. Conclusion
SCM is a method of bringing control to the software development
process and is known as an inseparable part of quality-oriented
product development regardless of development method. On the other
hand, software configuration management is often considered
bureaucratic method, an approach that causes additional work and
more documentation. However, the value of SCM should not be
underestimated in the case of agile software development methods.
Currently, there are very few studies of software configuration
management in agile methods.
The aim of this report was to systematically review the existing
literature on agile software development methodologies from an SCM
point of view.
Therefore, analytical SCM lenses based on existing literature were
constructed, including the following five perspectives:
7.1
SCM approach:
This perspective analyzed how software configuration management

is addressed in a method and explored each methods SCM-related
practices. It was found that only two of the methods take SCM
explicitly into account. However, most of the methods address SCM
at some level via SCM tools.
7.2
SCM planning:
The purpose of this perspective was to find out what the agile
methods define as SCM planning. The results show that agile
methods literature does not mention SCM planning at all. In
software configuration management literature, SCM planning has
been described as a basis for successful SCM implementation.
Therefore, agile methods should also place emphasis on SCM
planning.
7.3 Configuration identification:
In this perspective, it was analyzed what the agile methods

defined as item identification and base lining. The results of the
study show that only three of the existing agile methods
stipulate every development artefact should be under version
control. However, modern SCM tools can handle any number of

configuration items without any problems and, therefore,
"controlling everything" should be the tendency in the other agile
methods as well. Only DSDM has addressed base lining by
suggesting that it should be possible to carry out base lining
daily.
7.4 Change management:
The purpose of this perspective was to clarify what agile

methods define as change management. It was found that
different agile methods take quite different approaches. For
example, ASD suggests adapting to changes rather than
controlling them. Respectively, in FDD and DSDM, the change
controlling process is part of the required SCM implementation.
Thus, change management processes should be defined and
taken into account as part of a project's SCM implementation
7.5 SCM tools:
This perspective analyzed the role of software configuration

management tools in agile methods. The results show that most
of the methods emphasize the importance of SCM tools, and the
ability to revert earlier versions of items is seen as the most
important feature. However, while tools are an important part of
software configuration management, agile methods should stress
more comprehensive SCM solutions.
In conclusion, the results of this study showed that there are lacks in
the SCM approaches in the different agile methods. The positive result
was that software configuration management had not been completely
forgotten. However, it is clear that SCM should be a key ingredient in
fast-paced agile development.
Appendix I- GLOSSARY
This section defines the software configuration management terms used in
this guide.
Archive library
A software library used for storing CIs in releases or retired baselines.
Backup
A copy of a software item for use in the event of the loss of the original.
Baseline
A configuration item that has been formally reviewed and agreed upon, that
thereafter serves as a basis for further development, and that can be
changed only through formal change control procedures.
Change control
An element of configuration management, consisting of the evaluation,
coordination, approval or disapproval, and implementation of changes to
configuration items after formal establishment of their configuration
identification.
Configuration identification
An element of configuration management, consisting of selecting the

configuration items for a system and recording their functional and physical
characteristics in technical documentation.
Configuration item
An aggregation of hardware, software, or both, that is designated for
configuration management and treated as a single entity in the configuration
management process.
Configuration item identifier

A data structure that describes the name, type and version number of a
configuration item.
Configuration item list

A catalogue of configuration items in a baseline or release.
Configuration item storage

The process of storing configuration items in software libraries and on
hardware media.
Configuration status accounting

An element of configuration management, consisting of the recording and
reporting of information needed to manage a configuration effectively.
Control authority
The individual or group who decides upon the changes to a configuration
item; a configuration item cannot be changed without the control authority's
consent.
Controlled configuration item

A configuration item that has been accepted by the project for integration
into a baseline. Controlled configuration items are stored in master libraries.
Controlled configuration items are subject to formal change control.
Derivation record
A record of one event in the life of the configuration item (e.g. source code
change, compilation, testing etc.).
Release
A baseline made available for use.
Review board
The authority responsible for evaluating proposed changes, and ensuring
implementation of the approved changes.
Revision
A version of a document with minor changes from the previous version.
Simultaneous update
The phenomenon of two updates being made by different people on different
copies of the same configuration item; one of the updates is always lost.
Software change request

A description of the changes required to documentation and code, the
responsible staff, schedule and effort.
Software configuration management

A discipline of applying technical and administrative direction and
surveillance to identify and document the functional and physical
characteristics of a configuration item, control changes to those
characteristics, record and report change processing and implementation
status, and verify compliance with specified requirements
Software librarian
A person responsible for establishing, controlling, and maintaining a software
library.
Software library
A controlled collection of software and related documentation designed to
aid in software development, use, or maintenance.
Variant
A configuration item that meets special requirements.
Appendix II Discussion with Dmitri Sarytchev

Dmitri Sarytchev is Principal Domain Specialist at SAS Institute, Inc. in
Boston, MA. I got an opportunity to have one-on-one interaction with him
during summer and discussed with him about the report on Software
Configuration Management. He gave me insights about the version control
techniques used by companies these days. His research shows that the
companies like SAS are moving towards cloud based deployment tools for
version controls because they are very easy to handle and are not needed to
be installed on local machines.
Few examples which he cited were, doker.io, and bosh.io. Both of these web
applications offer services required to build and run the team projects.
Docker.io is a closed source platform for version controlling and building
team projects. They have partnered with various cloud based servers like
Amazon Web Services, Microsoft Azure etc. to help their users deploy, build
and ship their server based web applications directly without much hassle.
Various web-based applications like ebay, paypal, uber etc. take advantage
of this service. Their pricing varies according to the number of team
members that are building the project. It starts from $150 for a small team
and POCs.
Bosh.io on the other hand is open source tool for cloud based deployment
and version controlling of application. It was initially developed to deploy
PaaS applications of Cloud Foundry but it can be used to deploy and
collaborate on application of any platforms like Hadoop etc. It also supports
IaaS applications from servers like VMware, Amazon Web Services etc. It
solves the problem of version control as well as deployment and testing of
applications which are simple and small to the complex ones.
Appendix III Annotated Bibliography

1. Stephen P. Berczuk; Brad Appleton, Software Configuration
Management Patterns: Effective Teamwork, Practical Integration,
Published November 04, 2002.
This book is very effective in giving the broader perspective of
the Software Configuration Patterns. As a good SCM proves to be
very useful for development of a software system and makes the
system healthier.
The book also provides various types of instructions on how to
address the problems in the current system while building new
features, building an environment for optimal team work,
collaborating on a product efficiently etc.
The book also covers basics of various SCM tools available in the
market to give the reader introduction to each tool from where
she/he can build on.
2. ESA Board for Software Standardization and Control, "Guide to
software configuration management", Revision 1, 1995
This book was intended to describe the software engineering
standards to be applied for all deliverable software implemented
for the European Space Agency (ESA).
This book defines and explains what software configuration
management is, provides guidelines on how to do it, and defines
in detail what a Software Configuration Management Plan should
contain.
This book also discusses the principles of software configuration
management, gives an overview of tools for software
configuration management.
Few parts of the book also give details on how to write the SCMP.
Target readers are people who are directly or indirectly linked
with the software development process. Few sections also help
end-users to understand about versions and fixes.
3. James N. Menendez, "Guide to Understanding Configuration
Management in Trusted Systems,"
This publication, is issued by the National Computer Security
Center (NCSC) to provide guidelines that provide a set of good
practices related to configuration management in Automated

Data Processing (ADP) systems employed for processing
classified and other sensitive information.
It gives the core idea of how to implement Configuration
Management techniques in Automated Data Processing systems.
The experiments in the book are still on-going and they may
launch revised version of the book.
4. Anne Mette, Jonassen Hass, Configuration Management Principles
and Practices. Published on December 30, 2002.
The book explains the elements and benefits of a sound CM
strategy and shows how to put that strategy into action. Through
configuration examples and recommendations drawn from the
author's considerable experience, this practical guide lays
foundation to better manage and deliver projects.
It gives basic idea about incorporating CM techniques on various
development phases, tracing the product changes etc.
5. Juha Koskela, VTT Publications 514 Software configuration
management in agile methods
This publication closely analyzes all the SCM techniques and
tools present in the industry right now and points out the
benefits and the flaws of each system. The author takes into
account the theoretically defined SCM principles and based on
them analyses the current systems and concludes that none of
the current systems implement SCM principles properly and all of
them need to be refined.
6. Aleksandar Seovic, Visual SourceSafe 2005 Software Configuration
Management in Practice. Published on February 16, 2007
This book gives best practice management and development of
Visual Studio .NET 2005 applications with this easy-to-use SCM
tool from Microsoft. It clearly explains SCM fundamentals and
strategies.
It gives real world case study of a hotel reservation system to
explain how to use Visual SourceSafe 2005, (Microsofts SCM tool
before integrating it as Team Foundation Server), in the realworld projects.
It also provides a best-practices reference on using SourceSafe
2005 to manage the software development lifecycle.
7. Scott Chacon; Ben Straub, Pro Git, Second Edition. Published on
November 19, 2014.
Git has come a long way since it was first developed by Linus
Torvalds for Linux kernel development. It has taken the open
source world by storm since its inception in 2005, and this book
describes how to use it like a pro.
This book describes the principles and techniques of Distributed
SCM model and how GIT implement its features.
It describes how GIT is used from small-scale to large projects
and how various companies are taking advantage of one of the
most efficient Distributed SCM.
8. http://git-scm.com/
This website is the best source of information we can find about
the theoretical concepts of GIT over the web. It describes all the
features of GIT in detail and also provides comparison of
benchmarks of GIT with the Subversion system.
For new developers who are using GIT for the first time this site
can provide great documentation which can help them get
started and implement GIT in their projects.
Appendix IV Other Important Sources

[1] ESA Board for Software Standardisation and Control, "Guide to software
configuration management", Revision 1, 1995
[2] IEEE 1042-1987. IEEE Guide to Software Configuration Management. IEEE
Standards Collection Software Engineering, Institute of Electrical and
Electronics Engineers, Piscataway, New Jersey.
[3] IEEE 610.12-1990. IEEE Standard Glossary of Software Engineering
Terminology. IEEE Standards Collection Software Engineering, Institute
of
Electrical and Electronics Engineers, Piscataway, New Jersey.
[4] IEEE 828-1990. IEEE Standard for Software Configuration Management
Plans.
IEEE Standards Collection Software Engineering, Institute of Electrical
and
[5] IEEE 828-1998. IEEE Standard for Software Configuration Management
Plans.
IEEE Standards Collection Software Engineering, Institute of Electrical
and
[6] Rahikkala, T. 2000. Towards Virtual Software Configuration Management.
A
Case Study. Espoo, VTT Electronics, 110 p. + app. 57 p. VTT Publications
409.
http://www.vtt.fi/inf/pdf/publications/2000/P409.pdf.
[7] Tichy, W. 1988. Software Configuration Management Overview.
[8] University of Zurich, Presentation on "Software Configuration

Management"
[9] Wikipedia, Apache Subversion
[10 Wikipedia, Concurrent Versions System
]
[11 Wikipedia, List of Revision Control Softwares
]
[12 Wikipedia, Revision Control System
]
[13 Wikipedia, Software Configuration Management
]

Report On Software Configuration Management

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Report On Software Configuration Management

Încărcat de

Drepturi de autor:

Formate disponibile

A Tutorial on Software

3.Software Configuration Management Activities

The Basic Activities of SCM

3.1 Configuration Identification

3 Tutorial on Software Configuration Management

Describe the history of a CI.

3.1.1 What to identify as configuration items?

Requirement Analysis Document

4 Tutorial on Software Configuration Management

The need to develop and maintain several variants can

Source CIs are created by software engineers.

Version numbers allow changes to CIs to be

acceptance tests in the case of code), so the control

6 Tutorial on Software Configuration Management

3.2 Configuration Control

7 Tutorial on Software Configuration Management

The change management process for conventional software (Asklund &

assigned to developers to be implemented. After implementation, the

9 Tutorial on Software Configuration Management

3.3 Configuration Status Accounting

Records that describe the contents, dates and version/issue of

Records that describe the status of problem reports and their

Example of Baseline Records

10 Tutorial on Software Configuration Management

Above table is an example of a table of baseline records. Each column

3.4 Configuration Audit

3.4.1 Functional Configuration Audit

3.4.2 Physical Configuration Audit

12 Tutorial on Software Configuration Management

4.1 Introduction to SCM Plan:

Overview description of the software project

13 Tutorial on Software Configuration Management

assumptions of the degree of customer participation in SCM

4.2 SCM Management:

4.3 SCM Activities:

o Storage and access control of status data.

4.4 SCM Schedules:

Sequence and coordination of SCM activities.

Identifies environment, infrastructure, software tools,

4.6 SCM Plan Maintenance:

This section answers the following questions

15 Tutorial on Software Configuration Management

o How changes to the Plan are to be made and

Example of a SCM Plan:

5. People involved in SCM:

Configuration Manager or Librarian

16 Tutorial on Software Configuration Management

5.1 Configuration Manager or Librarian:

5.2 Module Owner

Responsible for technical integrity.

5.3 Change Control Authority

Includes representatives from all affected functions, such as

These are the responsibility of Configuration Control Board.

Typical members include the following:

These members are not always required to be technical.

6. Tools Used in Configuration Management:

Management of the repository of components.

18 Tutorial on Software Configuration Management

6.1 Common Features of SCM Tools:

Following figure depicts development of a software done in

20 Tutorial on Software Configuration Management

6.1.5Process control and support

22 Tutorial on Software Configuration Management