Document Information

Version:
V2.1

Date:
03-07-2002

File Identification:
Introduction_to_[SCM]

Department:
Professional Services
Introduction to
Authors: Container Based
E.J.Reek, H. Thelosen

Audience:
Software
World
Configuration
Revision History
Management
Abstract
Version: V1 Date: 09-02-2000 This document contains an introduction of Container
Release after review Based Software Configuration Management [SCM].
Version: V2 Date: 04-10-2001
Release after corrections
Version: V2.1 Date: 03-07-2002
Corrections and update used tools

Distribution List
World

Authorisation
Release: Hans Thelosen Date: 03-07-2002

____________________________ ______________
E.J.Reek, H. Thelosen Introduction to Container Based SCM

Table of Contents
1 CONTAINER BASED SCM........................................................................................................................2
1.1 Introduction ..........................................................................................................................................2
1.2 [SCM] basic concepts.........................................................................................................................2
1.3 The SCM actors ..................................................................................................................................5
1.4 The [SCM] process .............................................................................................................................6
1.5 The [SCM] structures .........................................................................................................................7
1.6 SCM tools.............................................................................................................................................7
1.7 Summary of highlights........................................................................................................................8
1.8 References...........................................................................................................................................8
E.J.Reek, H. Thelosen Introduction to Container Based SCM

1 CONTAINER BASED SCM

1.1 Introduction
A new methodology called “Container Based Software Configuration
Management” (acronym: [SCM]) has been developed. This
methodology reflects current best practises for Software Configuration
Management (SCM) in (re)use and parallel development
environments and replaces the traditional Baselining approach. The
methodology is new in a sense that a coherent set of terminology,
concepts, methods and specification techniques has not been
published before. [SCM] is not new in a sense that some leading
edge development sites already work according to its principles.
After a development and trial period of two years in various software
development environments, [SCM] has matured and implementations
show good results.

Three pillars constitute [SCM]. A set of basic concepts (one of them

being the concept: Container CI), a (tool independent) method for
implementation and performance of SCM, and specification
techniques for the SCM library structures, CI hierarchies and CI life
cycles.

1.2 [SCM] basic concepts

The SCM facilities needed to apply (re)use and parallel development
have led to a new conceptual foundation for SCM. The traditional
method of “Baselining”, where baselines of the software configuration
are created at certain points (milestones) in the development project,
is based on the concept of having one configuration that consists of a
grouping of configuration items, all going through the same stages of
development. Holding on to this concept in situations of (re)use and
parallel development leads to parallelism. That is, multiple
configurations (parallel baselines) containing multiple instances of
configuration items, each leading its own life of change. Working with
these types of parallel baselines is ineffective, inflexible and error
prone.
The concepts of [SCM] are designed to overcome these problems
and make (re)use and parallel development easier to perform. The
basic concepts of [SCM] will be explained below.

Version: V2.1 Date: 03-07-2002 2

E.J.Reek, H. Thelosen Introduction to Container Based SCM

Container CI
The (software) Configuration Item (CI) is the brick-stone of SCM.
Within [SCM] there are two types of Configuration Items, the Atomic
CI and the

[Label]
Label [Label]

=
Atomic CI
Container CI

! A CI can exist in multiple containers simultaneously

Container CI. Both types of CI’s have equal CI properties, they can be
labelled, stored in an SCM library and versioning mechanisms as
checkpointing, branching and merging can be used. The Atomic CI is
singular and indivisible. A file is a good example of an Atomic CI. The
Container CI is a grouping of CI’s. The Container CI is a smart object
and “knows” which CI’s are contained. The version of a Container CI
is determined by the versions of CI’s that are in it. Hence the
Container CI, for every version, knows the CI’s that are contained and
the version of each contained CI.
The term sub-configuration [1] can be compared with the Container
CI, as it also is a grouping of CI’s and can have multiple versions.
They are not equal because the Container CI carries its own
administration and has recursive properties (see Container
Hierarchy).
A CI is an individual and independent object that can be contained by
multiple Container CI’s. A CI does not know in which Container CI’s it
is used. As a result the CI is never labelled with a group (status)
identifier. The labelling function of SCM tools therefor, that can
recursively label individual CI’s of a configuration is not used for this
purpose.
The Container CI construct allows flexible (re)use. As a result of its
properties, a Container CI hides details and assures that the right
versions and right CI’s are kept together and are available for “Use”.

Container hierarchy
Both Atomic CI’s and Container CI’s can be placed in a Container CI.
This allows hierarchic Container CI structures. A hierarchical
Container CI structure is used to store and control the items of the
software product that is under configuration control. The contents as
well as the technical structure of the software product is (recursively)

Version: V2.1 Date: 03-07-2002 3

E.J.Reek, H. Thelosen Introduction to Container Based SCM

contained in the Container CI hierarchy. This property allows

multilevel (re)use.
The Container CI is related to the <<Configuration Item>> as
introduced by Jacobson and Griss [2]. Major difference is the
allowance of recursion. The Jacobson and Griss approach towards
reuse is very well supported by [SCM]. The <<Configuration Item>>,
<<Façade>>, <<Component System>> and <<Application System>>
constructs can be controlled by a Container CI hierarchy.

Multiple and independent CI life cycles

Each CI leads its own life independent of the other CI’s. A CI Life
Cycle specifies a formal promotion model, from creation to release.
One cycle leads to a new released version of the CI. A CI goes
through a series of creation and validation phases before it is
released for use. Multiple CI Life Cycles are specified in an [SCM]
domain (typically 4 – 6). Each type of CI (e.g. SW product, document,
reuse component) has its own specific CI Life Cycle.

The use/change dilemma

There is a strict distinction between the “open” version of a CI and
“stable” versions. There is always an open version of a CI available
for “Change” (add to- and/or delete its contents) and there is always a
shielded (e.g. released) version of a CI available for “Use”. Only
stable versions are (re)used. Each (re)usable CI has a separated
work area.

Design of SCM structures

The Container CI is a design object that allows the design of SCM
structures on a higher level of abstraction and independent from its
technical implementation.

Version: V2.1 Date: 03-07-2002 4

E.J.Reek, H. Thelosen Introduction to Container Based SCM

1.3 The SCM actors

There are three actors that contribute to successful implementation of
[SCM]: the [SCM] process, the [SCM] structures and the SCM tool.
Within [SCM] the actors are treated as individual areas of expertise
each having their concepts, methods, techniques, related
documentation and training facilities, etc.

The SCM-process The SCM-tool

SCM

The SCM-structures

The [SCM] process is the over-all SCM work method and is defined
by its tasks, activities, roles, responsibilities, authorities and
associated work products such as documentation.

The Configuration Identification” function of SCM defines: the types of

CI’s, CI labelling conventions, naming conventions and the SCM
library structure. Traditionally tree type of (directory) structures are
used as a specification method. The [SCM] structures extend the just
mentioned identification items with: CI life cycles, the CI (product)
hierarchy and the developer work area structures.

The SCM tool is the software program, or suite of programs that

automates key SCM activities such as SCM library control,
versioning, labelling, promotion etc.

Version: V2.1 Date: 03-07-2002 5

E.J.Reek, H. Thelosen Introduction to Container Based SCM

1.4 The [SCM] process

The [SCM] process is specified in a generic procedure, which is
based on current best practices and the CMM and SPICE quality
models. The [SCM] process is split-up in main tasks and each of the
tasks is specified in further detail using an activity flow diagram. More
detailed information on activities is available by reference. The latter
is used to tailor the procedure at the time of SCM implementation.
The [SCM] procedure is generic and can be used in any software
development environment. Much effort is spent on finding the right
balance between abstraction and detail. The traditional setting of
“Configuration Control”, “Configuration Status Accounting” and
“Configuration Auditing” is left. They origin from paper based
hardware CM systems. Modern SCM tools automates many of the
tasks that used to be performed manually. The [SCM] procedure has
a focus on the human tasks that remain.

Project Plan

SCM
SCMPlanning
Planning

CM

Problem Report (PR) SCM

SCM
Change Request (CR) Initiation
Initiationand
and
Set-up
Set-up
CM TA

SCM
SCM SCM
SCM SCM
SCM SCM
SCM
SCM
SCM SCM
SCM Version
Version Build
Build Status
Status Environment
Environment
Audit
Audit Change
Change Control
Control Management
Management Reporting
Reporting Management
Management, ,
Control
Control CM SD Backup
Backup/ /Archive
Archive
and
andSecurity
Security
SCM
SCM
Release
Release
Management
Management

CM SQAG CHM CCB SD CM TA BM SD CM CM TA

SCM
SCM
Transfer
Transfer/ /Phase
Close
Out
Out
CM TA

The [SCM] process is set up independent of the SCM structures. It

can be applied using [SCM] structures as well as traditional tree type
of structures. Compared to other SCM generic processes [3], [4], [5]
the [SCM] process is different (and more advanced) in the way that it
facilitates (re)use and parallel development.
The following roles are defined to perform the SCM tasks:
Configuration Manager (CM), Change Manager (CHM), Change
Control Board (CCB), Build Manager (BM) and Tool administrator
(TA). The Configuration Manager writes the “SCM Plan”, the “SCM
Status Report” and the “SCM Domain Description”, which are the key
[SCM] documents.

Version: V2.1 Date: 03-07-2002 6

E.J.Reek, H. Thelosen Introduction to Container Based SCM

1.5 The [SCM] structures

The Container CI object is used to design the [SCM] structures. The
shape of these structures determines the flexibility, (re)use and
parallel development features of the [SCM] environment. This design
is based on the architecture of the software product(s), the (re)use
and parallel development requirements, the required and anticipated
robustness for change and the development strategy (e.g.
evolutionary development). Designing [SCM] structures is a creative
process performed by the Configuration Manager. It requires
expertise and experience and can’t be automated. Two [SCM] models
support this process: the “Configuration Identification Matrix” and the
“Version Relation Diagram”. The CId-Matrix is the “city map” of the
[SCM] library and shows the Container CI’s categorised in two
independent ways: the “CI categories” (based on type, source or
function) and the “CId Tiers” (based on the assigned architectural
level). The “Version Relation Diagram” shows the Container CI
hierarchy. For the latter a notation technique is used, introduced by
Jacobson, Griss and Jonsson [2]. The two models replace the
traditional “Tree Model”. The Tree Model is not suited for modelling
(re)use. A (re)usable CI in a Tree Model is either separated from the
tree or on the wrong branch level. The models are specified in a
document titled “SCM Domain Description” together with the CI Life
Cycles and the SCM Tool configuration.
1.6 SCM tools
SCM tools that implement all concepts of [SCM] are not available.
There is a wide range of SCM tools that can be used for SCM, and
(few) tools that severely limit the implementation of [SCM]. The lack
of [SCM] facilities is handled by introduction of manual procedures
performed by the Configuration Manager.

SCM tools can automate parts of the SCM process. Tool vendors and
universities have developed various approaches for automation,
which can be characterised by 4 conceptual models. The following
models do exist [6]:
• the Checkout/Checkin model; being the most fundamental,
• the Composition model,
• the Long Transition model,
• the Change Set models.

The [SCM] conceptual model uses the Checkout/Checkin model but

resembles none of the latter three. There are three conceptual
differences. First of all the Container CI, being a joint set of CI’s, has
full CI properties. Groups and individuals are equally treated and
controlled. This is in contrast to the models mentioned above, where
the control of groups (configurations) differs from the control of CI’s.

Version: V2.1 Date: 03-07-2002 7

E.J.Reek, H. Thelosen Introduction to Container Based SCM

Secondly, the data on contents is coupled to the Container CI object.

It is a distributed data set that becomes available through recursion.
Thirdly, the coherence between parts of the software product is
embedded in the Container hierarchy. More commonly a central data
dictionary or database containing semantic information is used to hold
data on contents and product structure.

The differences in conceptual foundation will not hinder the use of

these tools for [SCM]. An SCM tool guideline is required, which
contains a method for configuration of the [SCM] structures, a method
for version control of the Container CI’s and a method for the
separation of change and use Container CI versions. [SCM] has been
successfully implemented with: Continuus/CM (CM Synergy), PVCS,
MKS, Visual Source Safe, QVCS and StarTeam. For small projects
the file system can be used and an SCM tool is not needed.

1.7 Summary of highlights

Advantages of the [SCM] approach are:
• [SCM] facilitates (re)use and parallel development.
• A set of generic concepts is defined that, in contrast to existing
concepts, fully facilitate (re)use and parallel development.
• The SCM structures are considered to be an important aspect of
SCM and a method and techniques are presented to design and
specify them.
• The process and the structures are defined at a non-technical
level and independent of the SCM tool.
• [SCM] can be used in any software development environment.

1.8 References
[1] Bersoff, E., Henderson, V. and Siegel, S.: “Software
Configuration Management: An Investment in Product
Integrity”, Prentice-Hall, 1980
[2] Jacobson I, Griss M, Jonsson P, “Software Reuse: Architecture
Process and Organization for Business Success”, ACM Press,
Addison-Wesley, 1997.
[3] Bach et al., Software Configuration Management Process
Definition, DOD, AIR-4.5, 1998.
[4] SPICE ISO/IEC 15504, 1995
[5] The Rational Unified Process
[6] Configuration Management Models in Commercial
Environments”, Peter H. Feiler:
www.sei.cmu.edu/legacy/scm/abstracts/abscm_models_TR07_91.html

Version: V2.1 Date: 03-07-2002 8