Chapter 4

Software Configuration
Management (SCM)

1
 Topic Covered

 Introduction
 SCM terminologies
 Configuration management
 Configuration management tools
 SCM Processes
 Related Research

2
What is Software Configuration?
 The output of a software process is information that
may be divided into three broad categories:
◦ Computer programs (both source level and
executable)
◦ Work products that describe the computer programs
(targeted at both technical and end users)
◦ Data (contained within the program or external to it)
 The items that comprise all the information produced
as part of software process are collectively called as
software configuration.
Configuration Management
Definition:
The set of activities that have been
developed to manage change throughout
the software life cycle.
Purpose:
Systematically control changes to the
configuration and maintain the integrity
and traceability of the configuration
throughout the system’s life cycle.
What is SCM?
 It is an umbrella activity that is applied
throughout the software process.
 Because change can occur anytime, SCM
activities are developed to:
◦ Identify change
◦ Control change
◦ Ensure that change is being properly
implemented
◦ Report changed to others who have interest.
Difference between Software
Support and SCM
 Support is a set of software engineering
activities that occur after the software has
been delivered to the customer and put into
operation.
 Software Configuration Management is a set
of Tracking and Control activities that are
initiated when a software engineering
project begins.
 SCM is a set of activities that have been
developed to manage change throughout the
life cycle of computer software.
What is the Origin of these
Changes?
 New business or market conditions bring
changes in product requirements.
 New customer needs demand modification
of functionality delivered by the products or
services delivered by the computer based
system.
 Reorganization or business growth causes
changes in project priorities or s/w
engineering team structure.
 Budgetary constraints cause a change in the
definition of the system.
Why Change Happens?
 Change is a fact of life in software development.
◦ Customers want to modify requirements.
◦ Developers want to modify the technical approach.
◦ Managers want to modify the project strategy

 Why all these modifications???

◦ As time passes while building the software, all the
people involved in it come to know more about what
they need, which approach will be the best, how to
get it done within time constraints, etc.
◦ This additional knowledge is the driving force behind
most changes in software development.
Motivations
 Developer A wants to see latest version of foo.c
and its change history since last week

 B needs to revert foo-design.doc to its version

two days ago

 B makes a release of the project and he needs

to know what items to include and which
version
Motivations (cont.)
 A lives in New Dehli, India and B lives in Boston, US,
they want to work on HelloWorld.java together

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

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

 C wants to get reports about current project progress

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

11
SCM TERMINOLOGIES
 Configuration Item (CI)
 Version, Variant, and Revision
 Configuration
 Baseline
Software Configuration Items (SCIs)
 Definition: Information that is created as
part of the software engineering process.
 Examples:
◦ Software Project Plan
◦ Software Requirements Specification
 Models, Prototypes, Requirements
◦ Design document
 Protocols, Hierarchy Graphs
◦ Source code
 Modules
◦ Test suite
◦ Software tools (e.g., compilers)
 Version,Variant, and Revision

 Version: a CI at one point in its

development, includes revision
and variant

 Revision: a CI linked to 1.2 1.3 1.4

another via revision-of
relationship, and ordered in
time

 Variant: functionally equivalent Win32 on x86

versions, but designed for 1.3.1.1 1.3.1.2
different settings, e.g.
hardware and software Solaris on
SPARC
 Branch: a sequence of 1.2 1.3 1.4
versions in the time line
How to create version
 <MAJOR>. <MINOR>. <REVISION>.<BUILD>
 Example: 2.4.7.1333
◦ The version above is referenced as version 2.4.7
◦ Where: Major release is 2, Minor release is 4, Rev
release is 7 and Build is not used except for internal
tracking/deployments, e.g. SQA validation
 Any child version levels will be reset when their
parent level is incremented or reset.
 Child levels will always be reset to 0.
 In cases where a version level is incremented the
value will be considered to be an integer and
incremented by 1.

15
…..example
Reported Original CASE 1: CASE 2: CASE 3: CASE 4:
version version Next major Next Next Rev Next Build
version minor version
version
Internal 2.4.7.3214 3.0.0.5 2.5.0.111 2.4.8.1234 2.4.7.4321

External 2.4.7 3.0.0 2.5.0 2.4.8 2.4.7

Assuming that the current version is 2.4.7, the table above

describes the outcome of creating the next major, minor,
Rev, and Build versions.

16
Explanation of the preceding
example:
 Case 1 - Describes the creation of a new Major version where the
Major number is incremented by 1, from major level 2 to a value of
3. The effect of this change is that the minor level is reset to 0, the
Rev level is reset to 0, and the Build is reset to 0, because they are
all children of the major level.
 Case 2 - Describes the creation of a new minor version where the
Minor version number is incremented from 4 to 5. Both the Rev
and Build numbers are reset because the Minor level was
incremented, the Rev level is reset to 0, and the Build is reset to 0.
 Case 3 - Describes a new Revision that may potentially be released
to manufacturing. When the Rev number is incremented from 7 to
8, the Build number is reset to 0, because the Rev level was
incremented
 Case 4 - Describes the next Build. Here no levels are reset
because the Build level has no child levels.

17
How Versions are Stored

 Full copy of each version

 Delta (differences between two versions)
 Forward delta

1.1 1.2 1.3 1.4

 Reverse delta

1.1 1.2 1.3 1.4

 Mixed delta
Configuration

 An arrangement of functional CIs according to their

nature, version and other characteristics

 Guaranteed to recreate configurations with quality

and functional assurance

 Sometimes, configuration needs to record

environment details, e.g. compiler version, library
version, hardware platform, etc.

 Simple examples
 Ant buildfile, Makefile
Baseline

 A collection of item versions that have been

formally reviewed and agreed on, a version of
configuration

 Marks milestones and serves as basis for further

development

 Can only be changed via formal change

management process

 Baseline + change sets to create new baselines

Configuration
management

21
SCM
 User roles and operating environments
introduce extra SCM functionality.
 Manufacture
◦ Managing the construction and building of the
product in an effective and optimal way
 Process management
◦ Ensuring the carrying out of the organization’s
procedures, policies, and lifecycle model
 Team work
◦ Controlling the work and interactions
between multiple users on a product

22
User Roles and Views
 Project manager
◦ Developing within a certain time frame and
meeting requirements
◦ Status reporting and reviews
 Configuration manager
◦ Defining and following procedures for creating
and changing items
◦ Software Change Request (SCR), Configuration
Control Board (CCB), task lists
 Developer
◦ Working efficiently (sharing, changing, building)

23
SCM Requirements

24
SCM Concepts

25
Repository
 Library of configuration items (e.g. files),
providing version control.
 Objects are immutable while in
repository. Need to be “checked-out” to
change.
 Changes automatically create a new
version (and number)
 Versions may not be saved completely but
as “delta”
 Multi-user management may exist to
some degree
26
Distributed Components
 Repository may be logically centralized
but physically distributed in different
platforms (e.g. Sherpa Design
Management System, DMS)
 Fault tolerance and format translation for
user transparency.

27
Change Set
 Change set is the set of logically related
changes to configuration items.
 Change set relates low level configuration
changes to higher level change requests,
in Rational UCM terminology, artifacts to
activities.
 All related file changes (e.g. for a bug-fix)
are put in one set linking modified files,
the reason, people involved, and
additional information.
28
Workspace
 The notion of a workspace is designed to
prevent users from interfering with one
another’s work.
 Workspace is a private area where users
can “change” a configuration item, e.g. a
local directory.
 It is this service that really convinced
practitioners that SCM was thee to help.
 Needs:
◦ Resynchronization (e.g merging)
◦ Concurrency control

29
System/Product Model
 System modeling describes a software
product, its structure and components, and
how to build it.
◦ Usually and historically only file-based
◦ Build with makefiles. Not adequate enough !
 System modeling includes the notion of
family to capture the history of the product,
i.e. succession of versions of the
components.
 Version selection rules determine which
versions of components have to be used for
each version of the product.
30
Change Request
 Software Change Request (SCR) is a
documented request for any modification
in software (correcting a defect, adding a
feature, …) according to a certain
procedure
 Change tracking part of SCM traces any
SCR to all modified configuration items.
 Common SCR attributes are status (e.g.
assigned and completed), people, dates,
and comments.
31
CM PARADIGMS
 No single CM system supports all CM
concepts and requirements.
 Certain pattern of CM concepts can be
seen in existing systems, resulting in four
(sometimes combined) paradigms:
◦ Checkin/checkout
◦ Composition
◦ Long transaction
◦ Change set

32
Checkin/Checkout
 Repository support for versioning of components
◦ Branching and merging
◦ Concurrency control through locking
 Users “check out” before accessing an existing
version and “check in” to create a new one.
◦ Local file system is the working area for checked out
items
◦ Mutually exclusive modification within a version
branch
 Checkin/checkout paradigm results in a version
history in form of a graph (version graph)

33
Checkin/Checkout

34
 Composition
 Creating configurations and managing their
history/family.
 Configuration consists of
◦ a system model (aggregation of components)
◦ version selection rules (appropriate version of each
component)
A 1.0 1.1 1.2

B 1.0 1.1

C 1.0 1.1 1.2

35
Long Transaction
 Evolution of the whole software system as a
series of atomic changes.
◦ Start with a versioned configuration
◦ End up with creation of a new version of
configuration
◦ Development path is the sequence of transactions.
◦ Multiple transactions coordinated through
concurrency control
 Different from traditional DB transaction
◦ Creating a new version rather than updating existing
one
◦ Persistence, i.e. long duration more than a login
session
 Paths can create branches.

36
 Change Set
 Management of logical changes to configurations
◦ Change-oriented vs. version-oriented SCM
◦ Logical change is a set of physical changes
◦ Link between change requests and actual modifications
in configuration items
 No concurrency control, so combined with
checkin/checkout

A B + +
Fix 1 Feature 4

C D

37
VERSIONING
 Product space
◦ Software objects
◦ Relationships
◦ Representations
 Version space
◦ Versions
◦ Deltas
◦ Version graphs
◦ Interplay with product space
 Merge tools
38
Product Space
 Software objects are the results of a
development or maintenance activity.
◦ Coarse or fine-grained
◦ Composite objects (configurations)
 Relationships connect software objects
◦ Composition
 Composite vs. atomic
 Product is the root of composition hierarchy
◦ Dependency
 Master and dependent objects

39
 One-Level Version Graphs
 One level organization
◦ Each version connected by one single type of
relationship called “successor”
◦ Different shapes based on multiple sibling and
successor

40
 Multi-Level Version Graphs
 Two-level organizations
◦ Graph is composed of branches each with a sequence of revisions
◦ At least two relationships
 Successor (within a branch)
 Offspring (between branches)
◦ ClearCase introduces merging
 Multidimensional variation
◦ So many variants may explode the graph
◦ Clusters of related versions can be used
◦ Grids (n-dimensional coordinate system) are another solution.
◦ Revisions can be represented in grids by adding a time dimension

41
Two-level Version Graph

42
Multidimensional Variants

43
 Interplay of Version/Product Spaces
 Multiple configuration items with multiple versions
 AND/OR graphs provide a general model for
integrating product and version space.
◦ AND/OR edges come from AND/OR nodes,
respectively.
◦ Product can be represented by only AND nodes/edges.
◦ Versioning is introduced to product space by adding OR
nodes/edges.
 Selection order
◦ Product first
◦ Version first
◦ Intertwined

44
Merge Tools
 Raw merging applies a change in a new context
◦ Supported by SCCS
 Two-way merging compares two alternative versions
and combine them into a new one.
◦ Displays differences to the user and allow the choice of appropriate
one
◦ No automatic resolution of differences
 Three-way merge tool consults a common baseline
when difference is detected
◦ Conflicts can be resolved manually or automatically
◦ Aide-de-Camp provides this method.

45
Semantic Level of Merging
 Textual merging
◦ Only for text files
◦ Supported by almost all SCM systems
◦ Only physical conflicts are detected (no valid C
file !)
 Syntactic merging
◦ Needs knowledge of file structure
◦ Can guarantee a syntactically correct output
◦ Research prototypes
 Semantic merging
◦ Can find semantic conflicts and fix if possible
◦ Not fully implemented yet
46
Configuration
management tools
47
CM TOOLS

 Version control
 RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase

 Bug tracking
 Bugzilla, Mantis Bugtracker, Rational ClearQuest

 Build
 GNU Make and many variants, Ant

 Project management
 Sourceforge.net, freshmeat.net, GForge, DForge
Tools for Version Control
 The core mission of a version control system is to
enable collaborative editing and sharing of data.
 File sharing is the most common problem faced by
all version control systems, so most of the
systems use Version Control with Subversion.
 For this the solutions can be:
◦ Lock-Modify-Unlock Solution
◦ Copy-Modify-Merge Solution
The Problem of File Sharing
Lock-Modify-Unlock Solution
Copy-Modify-Merge Solution
Copy-Modify-Merge Solution
(Cont...)
SCM Processes

54
SCM PROCESS
 Planning and Setting up SCM
◦ Configuration items and procedures
 Performing SCM
◦ Managing the state transition of configuration
items
 Controlled and uncontrolled environments
 Checkin/checkout
 Release
◦ Change control
 Monitoring and Audits

55
SCM Planning Steps
 Identify configuration items
 Choose the tools and environments
 Define naming and numbering scheme,
and director structure
 Define change control procedure (and
people)
 Set up configuration control board (CCB)
 Define status tracking methods
 Define procedures for backup, release,
archival, and audits

56
Software Change Control
 Tools for creating and tracking software
change request (SCR), examples:
◦ ClearQuest
◦ Bugzilla
 SCR General Procedure
◦ Accept
◦ Assign
◦ Check out
◦ Perform
◦ Check in

57
Change Control Integration
 Change control needs to be integrated with
repository and other SCM tools to trace all
changes to the SCRs.
 Rational Unified Change Management
combines ClearQuest (activity-based) with
the version control tool, ClearCase
(artefact-based).
 More intelligent tools can/should show and
track the changes in higher levels of
abstraction than files, e.g. functionality
modules.
58
Monitoring and Audits
 Projects must perform regular status
checking (e.g. “under development”,
“ready for release”) for all configuration
items.
 SCRs must also be checked regularly.
 Projects can also perform CM audits o
make sure procedures are being followed.
◦ Audit report should generate a task list
assigned to specific people.

59
State of Practice
 Most useful features
◦ Change control
◦ Activity control
◦ Workspace support
◦ Global view
◦ traceability
 Most missing features
◦ Process support
◦ Concurrent and distributed engineering support
◦ Scalability
◦ Cross platform operation
60
Related Research

61
RELATED RESEARCH
 Versioning
◦ Why are two objects versions of each other?
 Data/product model
◦ Use of more advanced data models rather than
file systems
◦ Relation with version model (on top, below, part
of)
 Composition
◦ Configuration description languages
 Building
◦ Unified makefiles
◦ Language dependent systems (smart build)
62
RELATED RESEARCH
 Workspace
◦ Complex objects available at a given location in a
given format (e.g. editor file or DBMS schema)
 Cooperative and remote work
◦ Define, at high level, the cooperation strategies,
organization and procedures
◦ Merging objects (more than text files)
◦ Web support
 Process support
◦ Integration of activity-based and item-based
approaches
◦ High level procedures and models

63
Summary
 Configuration management is an
important activity for controlling and
effectively manage maintenance or
evolution process.
 Techniques available for configuration
management have been designed to make
the activity understandable and applicable
 Practicing configuration management will
assure well-arranged maintenance and
evolution operations.
64
 References:
Ali Arya, Software Project Management, Configuration
Management, Carleton School of Information
Technology & Department of Systems and Computer
Engineering, 2003.

65