Concepts in Configuration Management Systems

Susan Dart
Software Engineering Institute
Carnegie-Mellon University
Pittsburgh, PA. 15123-3890
USA
dart@sei.cmu.edu
Sponsored by the U.S. Department of Defense

Abstract: There has been considerable progress con- 1.1 Definition of Configuration Management
cerning support for software configuration management Software CM is a discipline for controlling the evolution
(CM) in environments and tools. This paper’s intent is to of software systems. Classic discussions about CM are
highlight the user concepts provided by existing CM sys- given in texts such as [3] and [4]. A standard definition
tems. These are shown as a spectrum. In the spectrum, taken from IEEE standard 729-1983 [16] highlights the fol-
concepts are seen as extensions to, or generalizations of, lowing operational aspects of CM:
other concepts. There is difficulty associated with extract-
ing concepts from CM systems since there is no common- • Identification: an identification scheme
reflects the structure of the product, identifies
ality in terminology concerning CM functionality through- components and their type, making them
out the software engineering community and many CM unique and accessible in some form.
systems implement variations on concepts. As a result, each
• Control: controlling the release of a product
concept presented is described as it exists in one particular and changes to it throughout the lifecycle by
CM system. A part of highlighting the concepts involves having controls in place that ensure consistent
discussing the scope of issues important to users of CM software via the creation of a baseline product.
systems. No single CM system provides all the function- • Status Accounting: recording and reporting
ality required by the different kinds of users of CM sys- the status of components and change requests,
tems. Rather, each CM system addresses some part of the and gathering vital statistics about components
in the product.
spectrum of concepts. To complete the report, the CM ca-
pabilities of the systems used as examples are briefly de- • Audit and review: validating the complete-
ness of a product and maintaining consistency
scribed.
among the components by ensuring that the
product is a well-defined collection of compo-
nents.
1 Introduction
It becomes evident upon surveying existing configura- The definition includes terminology such as configura-
tion management (CM) systems that there has been tion item, baseline, release and version. Most CM systems
progress concerning support for software CM in environ- incorporate functionality of varying degrees to support
ments and tools. This is evident from the spectrum of con- these aspects. And some CM systems provide functionality
cepts provided by CM systems. The intention of this paper that goes beyond the above definition. This is due (amongst
is to highlight that spectrum. To begin, a broadened defini- other reasons) to the recognition of different user roles
tion of CM and a CM system are given along with a typical (discussed further in sections 1.3 and 2.1), disparate operat-
CM scenario. ing environments such as heterogeneous platforms, and
programming-in-the-large support such as enabling teams
of software engineers to work on large projects in a har-
monious manner. To capture this extra functionality, it is
 worthwhile to broaden the definition of CM to include: who is in charge of a software group, a configuration man-
ager who is in charge of the CM procedures and policies,
• Manufacture: managing the construction and the software engineers who are responsible for developing
building of the product in an optimal manner.
and maintaining the software product, the tester who
• Process management: ensuring the carrying validates the correctness of the product, the quality as-
out of the organization’s procedures, policies
surance (QA) manager who ensures the high quality of the
and lifecycle model.
product, and the customer who uses the product.
• Team work: controlling the work and inter-
actions between multiple users on a product. Each role comes with its own goals and tasks. For the
In sum, the CM capabilities provided by existing systems project manager, the goal is to ensure that the product is
encompass identification, control, status accounting, audit developed within a certain time frame. Hence, the manager
and review, manufacture, process management and team monitors the progress of development and recognizes and
work. reacts to problems. This is done by generating and analyz-
ing reports about the status of the software system and by
performing reviews on the system.
1.2 The Definition of a CM System
As to what constitutes a CM system, there is no univer- The goals of the configuration manager are to ensure that
sally accepted definition. That is, there is no unified notion procedures and policies for creating, changing, and testing
of a CM system. For instance, if a system has version of code are followed, as well as to make information about
control, is it a CM system? Ideally speaking, a CM system the project accessible. To implement techniques for main-
is one that provides all functionality based on the definition taining control over code changes, this manager introduces
given above. But practically speaking, any system that pro- mechanisms for making official requests for changes, for
vides some form of version control, configuration identifi- evaluating changes (via a Change Control Board (CCB)
cation, system structuring, system modelling, and has the that is responsible for approving changes to the software
intent of providing CM (to some degree) is considered by system), and for authorizing changes. The manager creates
the software engineering (and sales) community to be a CM and disseminates task lists for the engineers and basically
system. It should be noted that existing CM systems pro- creates the project context. Also, the manager collects sta-
vide their own combination of functionality rather than a tistics about components in the software system, such as
standard set. This report mentions 15 CM systems, yet information determining which components in the system
there are at least 40 CM systems that can be acquired for are problematic.
use today.
For the software engineers, the goal is to work effec-
It is worthwhile clarifying one minor notion for this tively in creating the product. This means engineers do not
paper, the notion of a CM system and a CM tool. A CM unnecessarily interfere with each other in the creation and
system can be considered part of an environment where the testing of code and in the production of supporting docu-
CM support is an integral part of the environment and the ments. But, at the same time, they communicate and coor-
CM system is sold in that manner as part of a package. For dinate efficiently. They use tools that help build a consis-
instance, the Rational [14] environment has CM function- tent software product and they communicate and coordinate
ality that is an integral part of it. A CM tool can be consid- by notifying one another about tasks required and tasks
ered a stand-alone tool. For instance, the Revision Control completed. Changes are propagated across each other’s
System(RCS) [15]) is a CM tool since it is intended to be work by merging them and resolving and conflicts. A his-
installed into an existing environment. But because the tory is kept of the evolution of all components in the prod-
distinction is not important to this paper, the term CM uct along with a log with reasons for changes and a record
system will be used to represent both notions. of what actually changed. The engineers have their own
work area for creating, changing, testing, and integrating
code. At a certain point, the code is made into a baseline
1.3 A Typical CM User Scenario from which further development continues and from which
Before discussing CM systems, a simple, typical, CM parallel development for variants of other target machines
user scenario of an organization is described in order to emerges.
present a frame of reference. The scenario involves various
people with different responsibilities: a project manager
 The tester’s goal is to make sure all the product is tested • User roles: there are different kinds of users
and found satisfactory. This involves testing a particular of CM systems and, consequently, different
version of the product and keeping a record of which tests functionality requirements for CM systems.
apply to which version of the product along with the results • Integration: the various kinds of integration
of the tests. Any errors are reported back to the appropriate affect the usability (or "power") of the CM sys-
tem.
people and fixes are put through regression testing.
• When to start using CM: the point at which a
The QA manager’s goal is to ensure the high quality of project group may start using a CM system de-
the product. This means that certain procedures and pends on the capabilities of the CM system.
policies must be fulfilled with the appropriate approval. • Control Level: a CM system can impose dif-
Bugs must be fixed and fixes propagated to the appropriate ferent levels of control over the product and its
management.
variants of the product with the correct amount of testing
applied to each variant. Customer complaints about the • Process and product: an ideal CM system
provides for the CM process as well as for the
product must be followed up.
product and its artifacts.
The customers use the product — most likely, different • Automation level: fulfilling CM functions is
customers use different versions and variants of it. Cus- generally a combination of using both manual
and automated procedures.
tomers follow certain procedures for requesting changes
and for indicating bugs and improvements for the product. • Functionality: CM systems have features that
implement a spectrum of CM functionality.
Ideally, a CM system suited to this scenario should sup-
These are discussed below in further detail.
port all these goals, roles and tasks. That implies, these
roles, tasks and goals determine the functionality required
of a CM system. This paper presents some concepts that 2.1 User Roles
attempt to address these. As indicated by the scenario of Section 1.3, there are
different kinds of users of CM systems.1 Each of these
users has a specific role and can have a different view of
1.4 Organization of This Paper
CM and, hence, different requirements for a CM system.
The introduction has given a definition of CM and a CM
These requirements are distinct and generally complemen-
system and an example of a typical CM scenario, thereby
tary. Figure 1 highlights a set of functionality that project
hinting at requirements for CM systems. Section 2 de-
managers, configuration managers, software engineers,
scribes the scope of CM issues important for users of a CM
testers, QA managers and customers expect of a CM sys-
system. These issues affect users’ expectations for a CM
tem. Each box in Figure 1 represents a major functionality
system. Section 3 illustrates the spectrum of CM concepts.
area. The topology of Figure 1 is intended to indicate that
Section 4 makes some observations about the future of CM
the outside boxes (auditing, accounting, controlling, com-
systems, and Section 5 gives a conclusion. The appendix
ponents, structure and construction) are functionality areas
presents an overview of the CM systems referenced in this
that could exist by themselves in any CM system, but when
paper.
combined with team and process functionality, a holistic
(or comprehensive) CM system results.
2 Issues for Users of CM Systems
Many issues related to CM affect the user of a CM sys-
tem. Existing CM systems address these issues in a variety
of ways. Although the intent of this paper is to discuss
some of the features in existing CM systems, it is worth-
while presenting the issues because all affect the user’s
expectations for a CM system. The issues are:

1
There are other kinds of roles pertinent to CM systems: the
environment/tool builder and the environment/tool integrator. These roles
are not strictly user roles in the sense that this paper presents. They are
really related to developing a CM system for the above kinds of users.
 CONSTRUCTION STRUCTURE

Building TEAM System model

Snapshots Interfaces
Optimization Relationships
Change impact analysis Selection
Regeneration Consistency

Workspaces
Conflict resolution
AUDITING Families

Versions
History Configurations
Traceability Versions of configurations
Logging Baselines
Project contexts
Repository
Lifecycle Support Kinds of components
Task Management
Communication
Documentation COMPONENTS

Access control
Statistics Change requests
Status Bug tracking
Reports Change propagation
Partitioning
PROCESS

ACCOUNTING CONTROLLING

Figure 1: CM Functionality Requirements

The functionality areas are: For components’ requirements, users need to: record
versions of components, their differences, and reasons for
• Components: identifies, classifies, stores and those differences; identify a group of components that
accesses the components that make up the
product. make up a configuration and versions of those; denote
baselines for a product and extensions to those; identify
• Structure: represents the architecture of the
project contexts that represent the collection of components
product.
and artifacts related to a particular project. Furthermore,
• Construction: supports the construction of the users need repositories or libraries to store and capture
product and its artifacts.
components and CM information as well as the different
• Auditing: keeps an audit trail of the product kinds of components such as source and object code, ex-
and its process.
ecutables, diagrams, documentation and baselines.
• Accounting: gathers statistics about the prod-
uct and the process. For structure requirements, users need to: model the
• Controlling: controls how and when changes structure of the product via a system model that represents
are made. the inventory of components for that product; specify inter-
• Process: supports the management of how the faces among components, versions, and configurations,
product evolves. thereby making them reusable; identify and maintain
• Team: enables a project team to develop and relationships between components; and select compatible
maintain a family of products. components to be made into a valid and consistent version
of the product.
The requirements for these areas are discussed in further
detail. For construction requirements, users need: means to eas-
ily construct or build the product; the ability to take a snap- 2.2 Integration of a CM System
shot or freeze the status of the product at any time; Any CM system has some notion of integration level
mechanisms for optimizing efforts at constructing systems with its environment. A CM system can co-exist with other
by reducing the need to recompile components and saving tools or be fully integrated. Integration pertains to various
space; facilities for doing change impact analysis that aspects of the environment: process, toolset, and database.
predict all ramifications of making a change; and easy Process integration means incorporating the usage pattern
regeneration of any phase or part of the product at any of the CM system (which makes up the CM process) with
point in time. the usage pattern of the environment (which pertains to the
software lifecycle process). Toolset integration means in-
For auditing requirements, users require: a history of all stalling the CM system into the environment so that it can
changes; traceability between all related components in the at least co-exist with all the other tools in that environment.
product and their evolution; and a log of all the details of For instance, the user would like to invoke CM functions to
work done. create a new version every time the "save" command is
issued while in the editor. Database integration concerns
For accounting requirements, users need: a mechanism to
the (logical) positioning of the CM database — whether it
record statistics, to examine the status of a product, and to
is combined in some way with the extant environment’s
easily generate reports about all aspects of the product and
database, or whether its database is a separate entity, and
process.
whether it makes use of information in other databases. All
these kinds of integration are general tool integration and
For controlling requirements, users need: cautious ac-
technology transition issues. But since CM is intended to
cess to components in the system to avoid any unwarranted
affect most objects in an environment and throughout all
changes or change conflicts; on-line support for change re-
phases of the lifecycle of an object, integration of a CM
quest forms and problem reports; means for tracking bugs
system is bound to have significant impacts on many of the
and how, when, and by whom they are dealt with; propaga-
tools in the environment. Most CM systems co-exist with
tion of changes, in a controlled manner, across different,
the other tools, and some environments have CM as an
but related, versions of the product; and a way of partition-
inherent part of themselves.
ing the product for limiting the effects of changes to it.

For process requirements, users need: support for their

2.3 When to Start Using a CM System
lifecycle model and their organization’s policies; the ability
It varies as to when project teams start using a CM sys-
to identify tasks to be done and how and when they are
tem on the products they are developing and maintaining.
completed; the ability to communicate information to ap-
Some teams choose to do so when the product has been
propriate people about relevant events; and the facilities for
through its development lifecycle and is ready for shipment
documenting knowledge about the product.
to the customer site. On the other hand, others choose to
For team requirements, users need: individual and group put everything under CM from the initiation of a project.
workspaces; the resolution of conflicts when merging Both choices have their own overheads. For instance, a
changes; and facilities for supporting the creation and team may make the choice based on the overheads associ-
maintenance of a family of products. ated with asking for a change. That is, if there are a num-
ber of manual procedures (such as filing a change request
Note that the process box and team box are presented as form, seeking CCB approval and getting acknowledgment),
being the significant areas of functionality. This is because a team opts for placing the software under CM control once
they affect, and are affected by, all the other areas. For a the major part of development is complete. But if the
user, an ideal CM system would support all the areas of change request procedure can be done on-line with little
functionality with team and process support fully inte- time and effort expended by the team, CM will be used at
grated. No single, existing system provides all the func- an earlier part of the lifecycle. In theory, CM is applicable
tionality for the areas. throughout the product’s lifetime—from creation, develop-
ment, product release, customer delivery, customer use,
through maintenance. Ideally, CM systems should support
this with minimum overhead possible, thereby allowing
CM to be applied as early as possible on a project. Existing
CM systems, however, tend to focus mostly on a particular organization and its software development lifecycle model.
phase of the lifecycle, so users are limited by that function- The CM product is the result of the process that is an engi-
ality. neering task. A CM system needs to provide functionality
for both aspects. Existing systems provide some product
and process support, but generally not comprehensive sup-
2.4 Levels of CM Control port for both in the same CM system.
A number of procedures, policies and tools combine to
assist in carrying out CM. They will provide varying de-
grees of control over the users and evolution of the product. 2.6 Amount of CM Automation
For instance, they may require an engineer to submit a At present, CM is generally a combination of manual and
formal, written change request. This is followed by a CCB automated procedures. It is possible to perform CM with-
evaluation and authorization of a change. The configu- out any kind of on-line assistance. But that is recognized as
ration manager then sets up a workplace for the software being inefficient. The goal is to automate as many as pos-
engineer. Particular files are extracted by the configuration sible of the non-creative parts of CM. For instance, written
manager from a guarded repository and placed in that change request forms and the protocol of responding to
workspace solely for that engineer. On the other hand, them are generally documented in an organization’s policy
different procedures, policies and tools may actually allow folder rather than captured and enforced on-line. Yet there
the engineers to electronically mail their request for are systems that can provide for completely automated
changes to the configuration manager and other members change requests. Each CM system automates some func-
of the CCB. The members mail their responses immedi- tion of CM to a different degree. And users need to supple-
ately. Upon approval, the change request is assigned to an ment automated procedures with manual ones when proce-
engineer who extracts the pertinent files directly from a dures are not supported on-line.
repository and makes the changes. All this is done without
any manual intervention. And since the CM system would
automatically log all accesses, an official record of the
2.7 CM System Functionality
Existing CM systems provide some of the required func-
change process is created.
tionality for CM, but no single system provides all the
The first scenario can be considered to have tight, active functionality required by all the kinds of users. This is
control over any action, but the latter scenario has loose, likely to improve though, with time, as the needs of users
passive control over actions. Frequent changes are dis- and the capabilities of environment architectures are better
couraged in the first scenario because of all the manual understood. The next section highlights the spectrum of
overhead, whereas in the latter scenario frequent change is concepts in existing CM systems.
encouraged since it is easy to do. These different levels of
control may be more appropriate at certain phases of the
3 Spectrum of Concepts in CM Systems
product’s lifecycle, for example, the first one is suitable for
The previous section explained the breadth of issues con-
maintenance but the second for development. Whatever
cerning requirements for CM systems. This section gives
CM system is used, it will have a certain level of control
details about specific functionality in CM systems. In par-
over the user and the timeliness of the product’s evolution.
ticular, it examines concepts that support some of the func-
It will either drive the user’s process, enforce it, or a bit of
tionality areas identified in the previous section. The con-
both. Existing CM systems provide their own level of con-
cepts are organized as a spectrum to represent an evolution
trol which is either loose or tight and few are flexible
of CM support. Each concept is described as it exists in a
enough to allow the user to pick the kind of control.
particular CM system. The functionality areas of interest
for the CM system concepts to be discussed are: compo-
2.5 Distinguishing Between Process and Product nent, process, a combination of structure and construction
CM involves a process and a product. A CM process features, and team concepts. Figure 2 shows the entire
represents the sequence of tasks needed to carry out CM. spectrum of concepts along with their representative CM
Essentially, the process is a plan that defines what needs to systems. The following gives a simplified description of
be done, who does it and how it is be carried out. Support- each concept and highlights the advantages of the concept.
ing the process is a management function. The process This section ends with a summary of, and an analysis of,
model takes into account policies and procedures of the the strengths and limitations of the spectrum and the con-
cepts.
 Legend: Concept
Direction of evolutiion

Example system

Context
Context
management
management Transaction

Lifecycle NSE*
Lifecycle PowerFrame*
model
model
CCC* Distributed Transparent
component view
SMS*
Sherpa DMS*
Change
Change
request
request Workspace
LIFESPAN*
LIFESPAN*
shape*

Repository System Object

Repository pool
modelling DSEE*
RCS*
RCS* Jasmine*
Attribution
Adele*

Consistency
Contract
Contract Change set Subsystem maintenance
ISTAR*
ISTAR* ADC*
ADC* Rational* CMA*

* This system exemplifies the concept shown in the node

Figure 2: Spectrum of Configuration Management Concepts

3.1 Caveats 3.2 Component Concepts

It should be noted that the concepts and systems dis- Component concepts deal with identifying and accessing
cussed are meant to be representative of what exists, rather components of a software product. They are the repository
than a complete summary or evaluation of what exists. For and distributed component and are described below.
each concept, one CM system is used to discuss that con-
cept. It should be noted though, that some of the CM sys- 3.2.1 Repository
tems actually provide many of the concepts shown in the The notion of a repository is fundamental to a CM sys-
spectrum. Concepts are taken directly from specific CM tem. The Revision Control System (RCS) [15] provides the
systems since there is no common terminology when deal- notion of a repository for ASCII files. In effect, the repos-
ing with automated CM functionality — each CM system itory is a centralized library of files and provides version
has its own concepts and semantics. The description of con- control for the files in the repository. Any file, while in the
cepts is simplified in order to focus on a certain aspect. As repository, is considered to be under a form of CM. The
a result, it is realized that this may not highlight the full files in the repository are immutable — they cannot be
capabilities of concepts (nor of their systems). But, for the changed. Making a change means creating a new version of
sake of presenting a spectrum and in order to hone in on a a file. All the CM information about files and the content of
basic set of CM concepts, simplification is required. Brief the files are kept in the repository. Hence, any CM controls
overviews of each CM system referenced in this paper are pertain to files in the repository. To work on a file, users
presented in the appendix. The overviews give a more com- check out a particular version of it into their working di-
prehensive listing of the full CM capabilities of each sys- rectory, perform any work on it, and, at the their discretion,
tem.
check it back into the repository. This creates a new version 3.3 Process Concepts
of that file. So that users cannot simultaneously check out Concepts that deal with process related functionality are
the same file and change it, the file checked out is automat- context management, contract, change request and lifecycle
ically locked (from the repository’s perspective) until model and are described below.
checked back in. A version number is automatically asso-
ciated with a new version; consequently, users can check 3.3.1 Context Management
out any file with a particular version number at any time PowerFrame [13] is a system designed for the computer-
although the default is the most recent version. Changes to aided engineering/design field and essentially shields its
the most recent version result in a new, sequential version users from low-level details of the file system and configu-
whereas changes to older versions result in a variant ver- ration management. Users see only their domain-specific
sion. Together, the version numbering scheme and usage world of circuit design and PowerFrame manages the work
pattern result in a version history tree for the file, indicating context for the user. Project data is represented graphically
predecessor/successor versions. The repository stores file rather than as being hidden in directories. PowerFrame
history information that includes the different versions of provides workflow management to guide team members
the files, the reason for a change, who replaced that version through their work processes. For example, a tool-run may
of the file and when. Note that the complete code for the involve creation of a circuit, validating it, then simulating it
different versions is not stored. Rather, only the actual for determining its performance characteristics. During
difference between each version is stored; this is known as these actions, PowerFrame automatically derives the cur-
the delta. This assists in space savings and access time to rent context related to the tool run such as the data sets,
the most recent version of a file. Files can be tagged with a command files and options used for invoking tools. The
state and checked out based on that state’s value. They can next time, the user needs only to select the circuit design
also be checked out based on a revision number, date and and the tool function to return to the work. The user sees:
author. The repository is generally associated with the di- the appropriate tools for a particular task; certain forms of
rectory in which the files exist. In sum, a repository cap- data presentation such as a logic-schema or a layout design;
tures CM information and stores versions of files as im- data that are pertinent to a particular task; and the forms of
mutable objects. commands that are pertinent to that domain. The user can
perform actions on different granularities such as a single
3.2.2 Distributed Component data item or a configuration, of the context’s data. The user
The Sherpa Design Management System (DMS) [7] pro- does not have to worry about such tasks as version control
vides a repository for files distributed on different hardware or relationships between files, since the system, knowing
platforms. The repository is logically centralized, but the about the derived data from various versions of circuits,
data from the repository can be physically distributed. handles those tasks behind the scenes. In effect, the CM
Sherpa DMS is aware of the distribution and carries out its system captures, in a domain-specific way, the working
CM taking that into account, for example, by providing context for the user thereby eliminating the need for users
some fault tolerance facilities along with the necessary to remember how they got to a particular working status
translations of file formats. So, to the users, the distri- and what all the data items and their relationships are in
bution is transparent — users carry out their work on the that context.
repository as though all the files were located on their own
workstations. A team of users geographically dispersed can 3.3.2 Contract
be working on the same configuration of files. Multiple The ISTAR [9] environment provides for modelling
copies of files can exist on different workstations. Sherpa some parts of a software development process in terms of a
DMS is aware of the location of the most recent version of formal agreement — a contract — to perform tasks with
a file. Any changes to files in the repository can result in specified input and deliverables. Artifacts of the contract
the local copy on the distributed workstations being up- are recorded and are configuration items. A contract
dated since the system knows where all the local copies are. models information flow, the start and completion of tasks,
Updates can occur interactively or be done in batch mode. the passing of results from the tasks and components of the
In effect, distributed users have access to a centralized re- product, and are "exchanged". A contract is fulfilled by the
pository, and to them the CM facilities seem to span the "passing" of the deliverables subject to specified accep-
network of heterogeneous workstations. tance criteria. The deliverables are passed to certain ele-
ments of the process model such as to a different phase of
the lifecycle or to a person. Movement of these artifacts is out the phases into developing, testing, approving and
subsequently tracked. The work in progress on the contract releasing of a product. This separation allows different
can be monitored, since various artifacts (such as kinds of users such as software engineers and testers to
communications) are recorded. In effect, the contract independently perform their work on the same code simul-
represents a formal plan for, and a record of, a unit of work taneously. The separation of, and transition between,
on a configuration item. phases and independent work are achieved by passing the
code through to separate configurations that represent each
3.3.3 Change Request phase. That is, the product is developed as a sequence of
In LIFESPAN [11], a change request represents a docu- baselines. Each baseline exists as four configurations: de-
mented request for a change and an associated process velopment, test, approved and production. The configura-
model for change. LIFESPAN models the change request tion is a hierarchy of components. Each baseline evolves in
via a series of "forms" and the process of change via a a particular way. Code development occurs in the devel-
series of states, tasks and roles. A customer may submit an opment configuration, passes to the test configuration for
on-line Software Performance Report (SPR) which identi- review, then to the approved configuration, and to the pro-
fies a fault or a request for an enhancement for versions of duction configuration for use by the customer. In order to
components. This allows the report to be investigated by be passed onto the next phase, a protocol of interactions
circulating it to the original designers and implementors required by various users (such as the Project Manager and
who can diagnose the problem. In response to the SPR and Test Manager) must authorize the transition. At any time,
change impact analysis, an on-line Design Change (DC) is the level of approval for a component is seen from the
proposed. This details exactly what components are to be configuration to which it belongs. In effect, a lifecycle
changed and how. LIFESPAN analyses who would be af- model is achieved via different states of a configuration.
fected by the change. Those people are then automatically
chosen to be the Change Control Board. They are notified
3.4 Structure and Construction Concepts
by electronic mail about the DC and must vote within a
Concepts that deal with: selecting components of a struc-
certain time frame on whether to approve the change. Once
ture; capturing changes to a component and its structure;
the DC is agreed to, a new development version of the code
describing the structure of a product; accessing parts of that
to be changed is made, the DC’s state becomes "active" and
structure; constructing the product; and, characterizing and
the code to be changed is locked. Upon completion of the
keeping the components of a structure consistent are the
changes the new version is frozen and submitted for check-
change set, system modelling, subsystem, object pool,
ing and approval to a person with QA privilege. Upon ap-
attribution and consistency maintenance. These are de-
proval the code changes acquire an "approved" status, the
scribed below.
status of the DC becomes "approved" and affected users are
notified by electronic mail that the new version is available.
3.4.1 Change Set
The users are notified via a Software Status Report (SSR)
Aide-De-Camp (ADC) [1] abstracts a fundamental no-
which closes off the original SPR. Thus, the SPR, DC and
tion captured in a repository — differences between ver-
SSR not only provide a means for users and maintainers to
sions of components— into a difference relationship and
communicate but they also represent: a history of changes
makes it accessible to the user. The difference relationship,
related to a particular change request; status reports for
along with the files to which they apply and other details
changes in progress; audit trails of changes completed; a
about changes, make up the change set. ADC captures
supporting mechanism for change impact analysis and en-
change to a configuration in a change set and that change
suring that the appropriate people carry out their tasks at
set can be used to construct a customized version of a con-
the right time. In effect, change requests assist in driving
figuration. This change set has a name which means it can
the process of change.
be used in operations. The user specifies a formula to
create a particular instance of a configuration. The formula
3.3.4 Lifecycle Model
designates a baseline to which selected change sets are ap-
Change and Configuration Control (CCC) [5] provides
plied. A change set can be treated as dependent (meaning a
notions for supporting a particular lifecycle model in the
version history is followed), or independently of (meaning
sense of supporting the transition between phases and
selective parts of the history are applied), previous change
people in a lifecycle, and the tasks and data management to
sets. Thus, the user either works from the most recent ver-
be performed during those phases. It does this by separating
sion or works with a customized version of a configuration. product, such as the sources and binary modules must agree
The change set captures all changes to all files in the con- (meaning all the binary modules were compiled from those
figuration along with the reason for changes and details of source modules). For selecting a version of a component, a
who made the changes and when. The user determines the selection expression using families is evaluated against a
scope of the change and ADC automatically records all the context that represents a search path for the modules. The
details of the changes. For instance, the user wants to make resultant modules selected are bound to the template into a
major changes to a configuration because of one bug. The data object known as an image. Tools such as browsers,
user designates a change set and makes changes to the files. module retrievers, debuggers, and inter-module analyzers
In the change set is captured: the reason (the bug) for can reference and manipulate the system models. In effect,
making changes to all files in the configuration; all the system modelling is an abstraction of a product from an
actual code changes (which will be different for each file in instance of it, and by fully describing the product, it assists
the configuration); all related file changes; and, details of tools in maintaining the integrity of the product.
who made the changes and when. Much of this information
is seen when the user browses each file or change set. In 3.4.3 Subsystem
sum, the change set represents a logical change to a product The Rational [14] environment provides for partitioning
and a means of creating any version of a configuration that a large Ada product into parts, allowing for confining the
is not necessarily dependent on the latest version of that scope of the effects of changes. The parts are called
configuration. subsystems. Subsystems have interface specifications as
well as implementation bodies, and represent configuration
3.4.2 System Modelling items; therefore, they can be treated as wholes and accessed
System modelling describes a software product— its via their names. Components within a subsystem are not
structure, its components and how to build it. The Jasmine visible to components in other subsystems unless they are
[10] system model is a textual description that the user can designated, via the interface specification, to be exported.
alter and that tools can access to carry out their tasks. Jas- The Rational environment checks at runtime that the imple-
mine system modelling is described by sets and functions mentation bodies exactly match the interface specification.
that represent four kinds of information: (1) relations be- As a result, work can progress on the implementation
tween product components, (2) version binding informa- bodies independent of the interface specification, which can
tion, (3) construction rules, and (4) verification rules. The be changed when the user desires. Recompilations will
relations describe: the modular decomposition of a product happen only to components within that subsystem until the
such as the hierarchy of subcomponents, the dependency interface is changed; at that time, any parts of the product
between components such as the build order of modules, using that interface will need to be recompiled. Changes to
and the grouping of components based on related properties an interface specification could possibly require the whole
such as grouping all source or object modules. A descrip- product to be recompiled. Subsystems have version control
tion of a product via these relations is called a template and on their components, and subsystems themselves can be of
captures its structure. Using functional operators and the a particular version. Users can mix-and-match versions of
relations, the user can define more complex relations from subsystems to make up a particular version of the product.
the simpler ones. This enables the Jasmine tools to answer In summary, subsystems represent a way for users to limit
user-defined queries such as which components are af- the effect of their changes and recompilation, and for the
fected by changing a particular component. System modell- environment to check the validity of combining parts of a
ing includes the notion of a family to capture the history of product.
the product. A family describes the succession of versions
of the components. Various user-specified versions of the 3.4.4 Object Pool
product make up a family. Associated with each version Using its notions for system modelling, the Domain Soft-
are attributes such as creation date and author. Queries, ware Engineering Environment (DSEE) [8] has all the nec-
version selection, and rules are based upon the attributes. essary information to recognize what is required to generate
Construction rules record how existing components were a particular version of a derived object. Derived objects are
generated and how future components should be con- placed in an object pool to be shared amongst users. DSEE
structed, such as recording the compiler, its version and the enables the sharing once the user has indicated the desired
compiling options needed. Verification rules specify and derivation properties of the objects. The derived object
record the structural and organizational constraints on the pool contains a collection of binaries and other objects pro-
duced by translation tools. Each derived object has associ- butes and relationships. The user can define any structure
ated with it all information pertaining to its system modell- (rather than just a hierarchical structure) to a product in
ing including versions of sources and translator tools used terms of desired characteristics. Thus, the user can de-
along with translator options, user comments about the scribe a product at a higher level of abstraction via its char-
derivation, date, time, person involved and location of the acteristics rather than in terms of a composition of lengthy
derivation. This information is known as a bound configu- file lists.
ration thread (BCT). When DSEE performs a system build,
it computes the desired BCT for each component in the 3.4.6 Consistency Maintenance
system model. DSEE looks into the pool to see if a derived The Configuration Management Assistant (CMA)
object matching the desired one exists. If it does, it is used; [6] provides configuration construction and validation
if not, it is built. Thus, whenever a user needs a particular based on an abstract description of the product as well as
derived object (or a compatible one), DSEE can reuse one on information about the successful or unsuccessful usage
from the pool thereby obviating the need for generating the of components forming the configuration. The data modell-
object. The user need not know that that derived object ing facilities include predefined attributes and relationships
exists; DSEE does all the checking. Once objects in the with which the user describes configurations. Based on the
pool become defunct (based on a period of non-use) DSEE semantics of those attributes and relationships, CMA can
can delete them, thereby freeing up space. This saves on determine whether a configuration (which is a set of in-
the amount of compilation time and space required, and stances of components) is usable. To be usable, a configu-
reuses work already done. DSEE also provides different ration must be complete, unambiguous, consistent and lack
kinds of object pools such as for objects derived from version skews. This means a configuration must consist of
source files that are still checked-out of the repository to a all instances of components required and must not contain
particular user. In effect, the CM system optimizes the multiple instances of a component. The classes of attri-
need for regenerating components and maximizes the butes represent user-defined characteristics such as con-
amount of sharing derived objects. straints, types, and versions. Classes of relationships repre-
sent kinds of dependencies, such as logical, compatible,
3.4.5 Attribution component, instance, and inheritable dependencies. Every
The Adele [2] system generalizes upon the repository time a new configuration is constructed, CMA utilizes the
and system modelling by using an entity relationship data- information that accumulated in the database via the previ-
base with data modelling capabilities. A product is de- ous use of the components forming the configuration. In
scribed in terms of a data model, and Adele performs its this way, CMA predicts whether the configuration is us-
operations based on that model. Components of a product able. This new configuration is added to the database for
are represented as database objects with attributes and future analyses of usability. Thus, the user can rely on the
relationships. Attributes are associated with each object and system to identify any inconsistencies and to preserve con-
characterize that object. At attribute has a name and a sistencies in creating and re-using configurations.
value. An example is the attribute name "delta" which
represents whether the object exists in ASCII form and so
can be compressed; it can have a value of "true" or "false".
3.5 Team Concepts
Concepts that deal with the isolation, co-ordination and
Two kinds of attributes are distinguished: predefined and
synchronization of software engineering teams working on
user-defined. The former are managed by Adele and the
a product are workspace, transparent view and transaction
latter are declared and managed by the user. One
and are described below.
predefined, special kind of attribute is "type". This "type"
attribute is mandatory and immutable for each object. It
represents the main CM entities in Adele (such as the com- 3.5.1 Workspace
posed object, the document, the revision and the element). The notion of a workspace in "shape" [17] is designed to
Relationships define dependencies between objects, for ex- prevent users from interfering with one another’s work. It
ample, object B is derived from object A. The user can provides the notion that work can proceed on mutable ob-
describe a configuration in terms of characteristics of ob- jects that are under CM. The workspace is achieved via a
jects, rather than in terms of a list of specific versions of version status model. This means that an attribute "state" is
objects. Adele instantiates and builds a configuration using associated with a version of a component. Depending on
selection rules and constraints centered around the attri- that state (such as state "busy" or "frozen"), the component
is considered to be in either a private workspace or in the rations. The user can update the repository with a new
public repository. A "busy" component is mutable and not version of the configuration. NSE assists in merging the
usable by others, whereas a "frozen" one is immutable and changes into the repository. But it checks that what exists
available for public use. Components are promoted to the currently in the repository (which could have been placed
public repository making them available for public use after there by some other user) does not conflict with the new
being approved by appropriate people. In effect, the changes coming. If there is a conflict, NSE notifies the
workspace provides isolation of work and suggests a dis- user about the merging problems and provides assistance in
tinction between a global, long-term repository for im- eliminating the conflicts. Users can request that any
mutable objects and a private, shorter-term repository for changes made to the repository be incorporated into their
mutable objects. own workspaces. In sum, the transaction synchronizes and
co-ordinates teams changing the same or different parts of
3.5.2 Transparent View the product.
The Software Management System (SMS) [18] enhances
the notion of a workspace by making it an explicit object
3.6 Summary and Analysis of the Spectrum
and providing a transparent view of the repository in that
Figure 2 represents a spectrum of CM concepts provided
workspace. This means that only the versions of the files in
by various CM systems. The concepts and their purposes
which the user is interested will be seen in the workspace;
are: a repository for capturing the history of immutable
all other versions are hidden from view (although they
files; the distributed component for distribution of data un-
physically exist). For example, any changes made to the
der CM; the contract that represents a plan for a unit of
latest public version need not be seen in the workspace.
work; a change set that captures changes to a configuration
The user is isolated from public changes and the workspace
and allows selection of configurations independent of the
gives the appearance of a specialized repository for the
latest version; the lifecycle model that enforces an
user. Version control with workspace-relative version num-
organization’s process of software evolution; system
bering is provided in the workspace. New versions are
modelling for fully describing and recording the structure
private and not publicly visible until released from the
and building of a product; the object pool for enabling the
workspace. A configuration is checked out from the public
re-use of derived objects thereby optimizing product build-
repository to the workspace, and users are assigned access
ing; attribution that allows the selection of a configuration
to that workspace. Components in the workspace effec-
based on characteristics other than a long list of files; con-
tively belong to that workspace rather than to a user. Only
sistency maintenance for automated checking and predic-
the user registered with that workspace can change the con-
tion of inconsistencies between components of a configu-
figuration and only components in that workspace can be
ration; the workspace for isolating private changes to
accessed. In sum, the transparent view provides a viewing
mutable configurations; a transparent view for viewing
mechanism with protection against unauthorized access to a
configurations and protecting against un-authorized access
configuration.
to mutable configurations; and a transaction for co-
ordinating changes to configurations by a team. These con-
3.5.3 Transaction
cepts represent advances in CM system functionality.
The transaction notion of the Network Software Environ-
ment (NSE) [12] represents a co-ordinated unit of work. It The topology of the spectrum is intended to show an
reflects the structure of a product and supports the isolation evolution of concepts. For instance, from left to right of
of work, interactions between users, and the merging of Figure 2, generally speaking, there have been advances in
changes. A transaction involves of an environment and a set modelling various processes, capturing components, de-
of commands. The environment provides notions similar to scribing components of a product, optimizing product con-
a workspace and a transparent view. It shows the directory struction. characterizing component dependencies and co-
structure used to store source and derived objects. Com- ordinating team work. The "arms" of the spectrum indicate
mands such as "acquire", "reconcile", "resynch" and related progress. For example, the change request and
"resolve" provide the interactions across environments. lifecycle model as described in this paper are related: the
They represent a protocol used to coordinate and synchro- lifecycle model subsumes a certain change request model
nize the actions between users and represent the communi- and the change request operates with a repository.
cation of the actual changes. Users work independently in
their environments, changing the same or different configu-
 There are concepts that the spectrum does not show. point for developing, or at least extracting, a CM model —
What cannot be shown are concepts such as: the evolution a set of fundamental CM services — from existing CM
in granularity of components (such as from version identifi- systems. Further work is needed to determine: the useful-
cation, to configuration identification, through to versions ness of the spectrum, whether there are other concepts, how
of configurations); progress in system modelling (such as to define, name and present the concepts and their alternate
the evolution from command files, to make files, through to semantics, and how to combine concepts into a useful CM
system models as versionable objects); recognition of system.
"roles" and different kinds of changes (such as bugs versus
enhancements versus emergency patches); and, current re-
search work. 4 The Future of CM Systems
The spectrum of concepts in Figure 2 represents typical
Regarding the extraction of concepts from CM systems, concepts in commercially-used CM systems. It is envi-
the descriptions presented in this paper are simplified, com- sioned that as research continues, and experience in using
pared to what is implemented, in order to find some com- and combining the concepts is gained, the many "arms" of
mon concepts. There really is no common vocabulary the spectrum will join. This means that there is probably a
when talking about concepts. The distinction between con- set of fundamental CM services that each CM system will
cepts and their implementation is not always clear. For in- eventually attain to better suit user requirements. But
stance, implementations of workspaces vary across CM regardless of whether every CM system designer is trying
systems and hence provide different functionality to the to implement the same features, there are political and tech-
user. Thus, should the concept of the workspace be the nical issues that affect the future of CM systems. (Political
lowest common denominator of all implementations, or the issues relate to marketing and standardization; technical is-
opposite? Are workspace, transparent view and transaction sues concern the feasibility of implementing certain
really one notion since a transaction subsumes notions of a mechanisms.)
workspace and transparent view? Or are they really three
concepts, as shown in the spectrum? A major political issue concerns the evolution of Com-
puter Aided Software Engineering (CASE) tools. For in-
Another difficulty in extracting concepts is that most CM stance, should CASE tool vendors bypass implementing
systems overload concepts. That is, there are many pur- CM within their tools and assume that environment vendors
poses for a concept (and the purposes are generally not will provide the CM support in their frameworks? Or
uniform across CM systems). For instance, the Rational should CASE tools builders provide CM support in their
subsystem concept is shown in the spectrum as providing tools? If CASE vendors incorporate their own CM support,
support for limiting the scope of changes, yet subsystems users will have to solve the problem of integrating different
provide more functionality than that. They can: provide a CM systems when they install their different CASE tools.
name scope boundary, support partitioning of a system, Also, from the vendors’ viewpoint, will they essentially be
represent a baseline, be workspaces, represent a means for duplicating much of the work that has already been at-
working on variant configurations or the same configura- tempted for environment frameworks?
tion by a team, provide the granularity for interface check-
ing, or represent an immutable and executable component On the other hand, if CASE vendors do not incorporate
(a "load view" in Rational terminology). So, in order to CM into their tools, can they rely on environment architects
discuss subsystems, it is necessary to hone in on a certain to provide a suitable framework to integrate CASE tools
aspect of it. Thus, overloading makes it difficult to extract and simultaneously provide some sort of global CM capa-
the basic concept. Similarly, combining parts of concepts, bility? The answers to these questions are not known. In
or the side-effects of a particular implementation of a con- any case, there is the implication that some kind of stan-
cept, make concept extraction tricky. For instance, when dardization would probably be needed for CM systems in
considering a change request, are roles (such as configu- relation to environments, or vice versa.
ration manager and test manager) and phases of the
Many technical, research issues affect the capabilities of
lifecycle (such as development and testing) crucial to that
CM systems. Questions such as the following arise. What
concept, or are they independent?
is the appropriate technology on which to base a CM sys-
At any rate, the spectrum of concepts provides a starting tem? Is an object-oriented database with persistency no-
tions for objects the most suitable? In what layer of an
environment’s architecture does CM fit? Should it be at the Acknowledgments
base level in the database, making it an integral part of an
environment framework? Or is it all a matter of specifying Many thanks to the reviewers of this paper, in particular,
CM as a process at a higher level in the architecture? Can Peter Feiler, Grace Downey, Kurt Wallnau, Ed Morris, Bob
the mechanisms for CM be separated from all the CM func- Ellison, Chuck Weinstock, Mario Barbacci, Rick Green,
tionality, that is, are there "standard" CM primitives that Jim Tomayko, technical writer Marie Elm, and the SCM3
could be used in any environment to support all the CM reviewers.
functionality? Is there a unified CM model? Is it possible
to provide distributed CM support? Can geographically References
dispersed software teams use the same CM system for local
CM and for system integration? This is a major problem in 1. Software Maintenance & Development Systems, Inc.
industry, particularly for Department of Defense contrac- Aide-De-Camp Software Management System, Product
Overview. Concord, MA, 1989.
tors. Is it possible to support cross-development of soft-
ware? Can engineers developing a product on a host ma- 2. Estublier, J. A Configuration Manager: The Adele Data
chine easily move it to the target machine while still main- Base of Programs. Proceedings of the Workshop on Soft-
ware Engineering Environments for Programming-in-the-
taining CM control over the product? Is scale a limiting Large, June 1985, pp. 140-147.
factor for CM systems? Is the CM support for a million
3. Babich, W.. Software Configuration Management.
line product the same as that for a 100 million line product?
Addison-Wesley, 1986.
Is it possible to model all aspects of the CM process, in-
cluding the people-intensive parts, and implement those in 4. Bersoff, E. H., Henderson, V.D., and Siegel, S. G..
Software Configuration Management. Prentice-Hall, 1980.
a CM system?
5. Softool. CCC: Change and Configuration Control Envi-
Answers to the above questions are not yet obvious. It is ronment. A Functional Overview. 1987.
likely that progress will come from various sources—from 6. Ploedereder, E. and Fergany, A. A Configuration Man-
CM system vendors, environment architects and resear- agement Assistant. Proceedings of the Second Internation-
chers, tool integrators, the software process modelling al Workshop on Software Version and Configuration Con-
trol, ACM, USA, October 1989, pp. 5-14.
forum, and from the computer-aided design/engineering,
computer-integrated manufacturing worlds. 7. Deitz. D. "Pulling the Data Together". Mechanical
Engineering , (February 1990).
8. Leblang, D. and McLean, G. Configuration Manage-
5 Conclusions ment for Large-Scale Software Development Efforts. GTE
CM is management of the evolution of a software prod- Workshop on Software Engineering Environments for Pro-
uct. At the operational level for CM systems, CM is identi- gramming in the Large, June 1985, pp. 122-127.
fication, control, status accounting, audit, review, manufac- 9. Graham, M. and Miller, D. ISTAR Evaluation. Tech.
ture, process management and team work. It is an area in Rept. CMU/SEI-88-TR-3, Software Engineering Institute,
Carnegie-Mellon University, July 1988.
software engineering environments where progress has
been made. That is evident from the spectrum of concepts, 10. Marzullo, K. and Wiebe, D. Jasmine: A Software Sys-
as well as from the number of existing CM systems and tem Modelling Facility. Proceedings of the ACM
SIGSOFT/SIGPLAN Software Engineering Symposium on
their capabilities. The spectrum presented in this paper Practical Software Development Environments, December
represents a snapshot of many concepts implemented by 1986, pp. 121-130.
various CM systems. Each system addresses differently, the
11. Whitgift, D.. Software Configuration Management:
user issues — roles, integration, control, automation level, Methods and Tools. John Wiley and Sons, England, To be
process versus product support, when is the best time to published June 1991.
start using CM and what functionality is provided by the 12. Feiler, P. and Downey, G. Transaction-Oriented Con-
system. It is hoped that presenting the spectrum may aid in figuration Management. Tech. Rept. CMU/SEI-90-TR-23,
understanding the capabilities of CM systems and in pro- Software Engineering Institute, Carnegie-Mellon Universi-
viding a common framework for discussing CM tool sup- ty, November 1990.
port. 13. Johnson, W. Bringing Design Management to the
Open Environment. High Performance Systems, June
1989, pp. 66-70.
14. Feiler, P., Dart, S. and Downey, G. Evaluation of the I.2 Aide-De-Camp (ADC)
Rational Environment. Tech. Rept. CMU/SEI-88-TR-15, ADC, from Software Maintenance and Development
Software Engineering Institute, Carnegie-Mellon Universi-
ty, July 1988. Systems, Inc., consists of the basic ADC system and a
turnkey system. The basic ADC provides a database for
15. Tichy, W. Design, Implementation and Evaluation of a
capturing CM information. The user defines attributes and
Revision Control System. 6th International Conference on
Software Engineering Tokyo, September 1982, pp. 58-67. relationships on files. The database can store source and
binary code and it stores mutable ("plastic") and immutable
16. IEEE Guide to Software Configuration Management.
1987. IEEE/ANSI Standard 1042-1987. ("installed") information. ADC’s list processing language
effectively allows the user to work on one file or a group of
17. Mahler, A. and Lampen, A. shape—A Software Con- files. ADC performs conflict resolution at the moment of
figuration Management Tool. Proceedings of the Interna-
tional Workshop on Software Version and Configuration check-in and flags any conflicts. Change sets captures
Control, Siemens Germany, January 1988, pp. 228-243. changes to configurations and allow users to designate any
version of a configuration via a list of change sets thereby
18. Cohen, E., Soni, D., Gleucker, R. Haslin,
W. Schwanke, R. and Wagner, M. Version Management in creating their own version tree. Reports can be generated
Gypsy. Proceedings of the ACM SIGSOFT/SIGPLAN based on database contents. Program builds are supported,
Symposium on Practical Software Development Environ- with structural relationships being automatically derived.
ments, November 1988, pp. 210-215.
Some non-ADC CM information can be imported to the
ADC database. The turnkey system supports configura-
tions directly, integrates problem reports, change requests
I. Appendix: Overview of CM Systems and the recognition of user roles with the assigning of work
This appendix gives a snapshot of the capabilities of the orders and setting up of a local workspace ("cleanroom").
various CM systems mentioned in the earlier sections of This means that when a change request is sent to the CM
this paper. Neither an evaluation nor a complete description manager and approved, the manager assigns a work item to
is given of the systems. Rather, the intent is to give the a software engineer. When the engineer activates that work
reader some information about the scope of CM capabilities item, the workspace which is a local copy of directories and
of the following systems that are representative of the files, is created. As soon as the engineer is finished with
various kinds of CM systems existing today. They are: that work item, the workspace is automatically deleted and
Adele, ADC, CCC, CMA, DMS, DSEE, ISTAR, Jasmine, changes are added back to the database.
LIFESPAN, NSE, PowerFrame, Rational, RCS, "shape",
and SMS. These systems are described below.
I.3 Change and Configuration Control (CCC)
Softool’s CCC is sold as a turnkey system (called
I.1 Adele CCC/Development and Maintenance) or as a native prod-
Adele is a configuration management system from the uct. CCC provides a change control methodology, configu-
University of Grenoble. Its basic features are data modell- ration identification and status accounting, and the building
ing, interface checking, representing families of products, of derived items. All of these are provided assuming the
configuration building and workspace control. Adele is waterfall lifecycle model. Components under CCC pass
intended to be the kernel of a software engineering environ- through various phases of the lifecycle after appropriate
ment. The Adele database is an Entity Relationship one approvals. CCC supports some documentation standards.
that provides for the defining of objects such as interfaces Five classes of users form a hierarchy of access rights to
and their realizations (instances of bodies), configurations information in the database. They are the database admin-
and families. Objects have attributes that describe their istrator, the CM manager, the project manager, the devel-
characteristics and the dep relation that describes their de- oper, and the test manager. Several levels of access con-
pendencies which Adele uses to assist in composing a con- trols exist such as access based on passwords, user classes
figuration. The user can designate a configuration based and specific data item or change request assignments. The
upon desirable attributes. Attributes can be user-defined CCC database hierarchy, which represents the product’s
and system-defined. The user can designate selection rules structure, comprises multiple levels of data structures in-
based on attribute values, constraints and preferences. cluding the database, a system, a configuration, a module,
Adele can detect incomplete and inconsistent configuration and text. Parallel versions of code can be used for simulta-
descriptions. neous development via virtual copies. These can be
merged or selected and changes can be applied across con- provals and checks are required for sign-off and promotion.
figurations. Conflicts will be detected during a merge. The DMS access control is based on class of user and promo-
change requests of CCC, known as projects, can deal with tion level of file, and file names can be encrypted. Virtual
one small change to one component or it can deal with all teams can be defined (these are users that are geographi-
changes required for the next release of a product. Elec- cally dispersed but share a common database). Automatic
tronic mail notification of events relating to change re- update synchronization or batch updates can be requested.
quests provided. Emergency changes which bypass most of Changes can be communicated to team members. The
the change controls are allowed. latest version of a file can be located regardless of where it
resides in the network. DMS uses that structure for carry-
ing out checks. Report generation and audit trails are pro-
I.4 Configuration Management Assistant vided. Change requests (with associated documentation)
(CMA) are automated along with approval.
CMA from Tartan Laboratories provides mechanisms
(without policies) for creating CM systems. The
mechanisms use an Entity-Relationship-Attribute database. I.6 Domain Software Engineering
Classes of attributes and relationships define the character- Environment (DSEE)
istics of components, the decomposition of a product and Apollo’s DSEE provides version control, system modell-
interdependencies between components. The classes of at- ing, releases of configurations, distributed system building,
tributes are partition, rendition, and version; the classes of object pools, task lists for tracking tasks to be done and
relationships are logical dependency, consistency, compati- those completed, and alerts for notifying users of certain
bility, component, instance, and inheritable dependency. events. Version control is on a source file repository. A
CMA provides for recording and retrieving descriptions of DSEE system model represents a description of a product
configurations and the set of components that comprise, (or part thereof). It is a declarative description defining
record, and retrieve information about known static and structural properties and includes a description of
(in)consistencies and dependencies between components in source file, derived object and tool dependencies, the hier-
a configuration. It predicts the completeness, ambiguity and archy of components, the build rules (shell scripts), the
consistency of newly formed configurations. Any change build order, identification of the library and paths, options
to the database occurs via the commitment of a simple for translator tools, and some conditional processing rules.
"transaction." Each configuration can have its own access The configuration thread represents a language for version
control mechanisms. Name clashes between configurations selection of components to be used in the building of the
are avoided through use of name spaces. product. Versions can be selected based on certain charac-
teristics, equivalences, or compatibilities. A bound config-
uration thread represents all the instances of components
I.5 Design Management System (DMS) that were used to build the product, and has a unique identi-
DMS from the Sherpa Corporation is geared for the fication. Each derived object has a bound configuration
computer-aided design/engineering market and is part of a thread associated with it. A distributed build shares the
hardware, design engineering environment. DMS provides compile-time load across machines.
a logically centralized repository with transparent, distri-
buted data handling for files. Files can contain any kind of
information such as ASCII, graphics, and design data. Ver- I.7 ISTAR
sions of files are maintained via resident operating system’s ISTAR from Imperial Software Technology Ltd. is an
versioning mechanism. All information (product structure, environment designed to especially support project man-
release procedures, alerts on events, user-defined attributes agement. Relationships between individuals on a software
and relationships) is centralized into a kernel database facil- project are modeled as contracts. A contract is theoretically
ity. The notion of a "release" is achieved via promotion a description of expected products and is implemented as a
levels (promotion levels represent stages through which a database. A configuration item is the unit of transfer be-
project passes). These represent company policy for re- tween contracts and is considered "frozen" when trans-
view, approval or sign-off on files. The user can specify ferred. The transferring of contracts indicates certain tasks
who has access to what kind of data, the grouping of data, or phases are complete. CM exists for items in the contract
who should be notified of status changes, and what ap- databases and deliverables between contracts. Successor
and variant control are provided for components in the Once changes are agreed upon, it is a management decision
databases. The user can define relationships between CM to authorize changes and assign resources. Items are then
components and can assign components to a problem re- taken out of the store, modified, and then re-submitted at a
port. There is support for system building. development status level and the quality cycle then repeats.

I.8 Jasmine I.10 Network Software Environment (NSE)

Jasmine is a programming-in-the-large system developed NSE from Sun Microsystems is an environment with a
at Xerox Information Systems Division for in-house CM. database that manages the operating system’s directory
System modelling is the key part of Jasmine. It describes a structure and derived files in addition to the source code.
software system using a simple algebra based on sets and NSE provides for team support in developing code via its
functions. The user can define complex queries and easy environment which represents a workspace. Workspaces
version selection using the algebra. Software structure is support nested/recursive transactions with a protocol for
defined in a template. Version binding is supported in an merging and updating files between a child and a parent
image and the successive versions of a component are workspace. The files in workspaces represent a configu-
recorded in a family. Families can represent parallel devel- ration and can represent multiple versions of the configu-
opment. Specific versions of the component can be grouped ration. All but the last configuration are immutable. Multi-
to make up a particular history (such as a project specific ple users of the same workspace must check out and check
history). Version selection is provided by contexts and in files while working in that workspace. Merging of work
families. Construction and consistency rules can be de- across workspaces requires conflict resolution for which
fined. Jasmine tools make use of the system modelling NSE provides interactive support. The workspace effec-
information for copying and archiving files, compiling tively captures the directory structure used to store the
sources, generating releases and browsing. source and derived objects of the product, the build struc-
ture, and the logical structure of the product. The structure
of a product is made visible via the browser.
I.9 LIFESPAN
LIFESPAN comes from Yard Software Systems and
rigorously supports change control. It is geared for the I.11 PowerFrame
project manager in monitoring changes. Only authorized PowerFrame from EDA Systems, Inc. provides configu-
users have access to the repository. LIFESPAN uses a rela- ration management for computer-aided design work. It
tional database and query language. It stores text, binary shields the user from the operating system and file systems
code and diagrams, and provides version control on those through a uniform, graphical/iconical interface. Operation-
items. Collections of objects belong to packages around ally, users pull down an appropriate tool menu and
which most of the change control centers. A package is PowerFrame automatically finds all relevant data, runs the
assigned to a manager who is responsible for approving any tool, and saves all the changes after the user is finished.
changes to that package. LIFESPAN uses the "drawing PowerFrame incorporates several ways of organizing data
office" model based on hardware design methodology. in a product in order to allow the user to focus on only the
States, transitions, transition triggers, prompts, and user data required for a particular task—a project, a vista, a view
roles are recognized. Electronic mail provides automatic and a datapack. The project is a collection of data that is
notification. Reports based on items in the repository and the subject of the work of a cooperating team (i.e., the
changes can be generated. For security, passwords can be product that includes all versions of the files for every
supplied for configuration items, along with encrypted phase of the circuit design). A vista is a working set of file
filenames. Problem reporting, tracking and formal change versions in use by a particular engineer at any time. A
control in accordance with various national standards are view allows users to concentrate attention on a particular
supported. Testing information may be held as a configu- aspect of a design (i.e., information relevant only to a logic-
ration item with relationships/dependencies to other items. schematic view or a layout view is displayed). A datapack
LIFESPAN monitors the agreement process for changes. It is a logical unit (such as an Arithmetic Logic Unit) that is
determines what systems use the modules under review, an abstraction of some component being designed; it allows
flags all developers who might need to be included in any detailed data—such as that produced by various tools—to
review and issues the necessary control documentation. be hidden, yet accessed when needed; in effect,
PowerFrame groups together all related information regard- I.14 shape
ing that abstraction. Some objects are under version control The "shape" System is from the University of Berlin.
whereas others are versioned by checkpointing. "shape" provides a repository with an attributed file system,
version control, workspaces via version states, configura-
tion identification. It integrates system modelling facilities
I.12 Rational and derived binary pools. Configurations can be described
The Rational Environment from Rational provides sup-
and selected via an attribute pattern where attributes are
port for teams of programmers working on large Ada prod-
user-defined and/or system-defined. Linear and parallel
ucts. Rational’s CM facilities are based on its subsystem
versions (variants) of configurations support team devel-
concept. Ada program libraries are integrated with their
opment. Workspaces are emulated via "states" of a version
CM. A subsystem represents a portion of the Ada product.
which also determine the mutability of the file. Files in the
Subsystems can be developed independently of other parts
workspace transition between states "busy", "saved" and
of the product by a single software engineer or by a team in
"proposed" and, for the official public database, states
a coordinated manner. A subsystem has a version identifier;
"published", "accessed" and "frozen".
a subsystem can be released. Different versions can be
worked on simultaneously and changes merged; and sub-
systems can be combined with other subsystems. An I.15 Software Management System (SMS)
activity table specifies which versions of which subsystems SMS from BiiN provides version control, workspace
are to be combined. Rational provides mechanisms that management, system modelling, derived object manage-
minimize the need for recompilation of Ada units. Within ment, change detection in the repository, tool interface
the subsystem, Ada units can be placed under version con- specification, and attribute-based version selection. The
trol; the user can turn version control on and off as desired. workspace is a protected environment for working on task-
related versions and supports authorization and logging on
a per-task basis. Changes to objects are monitored and
I.13 Revision Control System (RCS) actions triggered when a particular event occurs. A derived
RCS, developed by W. Tichy, provides version control
object has a consistency state ("valid", "blessed",
on source files in a repository. The repository is a version
"obsolete" and "invalid") to represent its relationship to
tree of each file. A branch in the tree represents a variant
system building, and a quality state ("ok", "warning",
of the file. RCS uses its own numbering scheme to number
"error", and "fatal-error") to indicate version consistency.
versions and branches. Only the differences between ver-
sions of the files (reverse deltas) are stored in the repos-
itory to save space and allow the latest version in the tree to
be accessed most quickly. The normal usage pattern for
accessing the repository of files involves the user checking
out a particular version of the file from the repository (with
a lock), making changes to the files, and eventually check-
ing it back in when the user has completed the changes. At
this time, RCS logs details of the change such as the author,
date, time, and reason for change. RCS can automatically
incorporate a unique stamp into the actual file if needed.
RCS can compare different versions of files, freeze a con-
figuration, and assist in merging branches by recognition of
differences in source lines. Tags (e.g., configuration or state
tags) on files in the repository can be used for indicating
relationships between files.
 Table of Contents
1 Introduction 1
1.1 Definition of Configuration Management 1
1.2 The Definition of a CM System 2
1.3 A Typical CM User Scenario 2
1.4 Organization of This Paper 3
2 Issues for Users of CM Systems 3
2.1 User Roles 3
2.2 Integration of a CM System 5
2.3 When to Start Using a CM System 5
2.4 Levels of CM Control 6
2.5 Distinguishing Between Process and Product 6
2.6 Amount of CM Automation 6
2.7 CM System Functionality 6
3 Spectrum of Concepts in CM Systems 6
3.1 Caveats 7
3.2 Component Concepts 7
3.2.1 Repository 7
3.2.2 Distributed Component 8
3.3 Process Concepts 8
3.3.1 Context Management 8
3.3.2 Contract 8
3.3.3 Change Request 9
3.3.4 Lifecycle Model 9
3.4 Structure and Construction Concepts 9
3.4.1 Change Set 9
3.4.2 System Modelling 10
3.4.3 Subsystem 10
3.4.4 Object Pool 10
3.4.5 Attribution 11
3.4.6 Consistency Maintenance 11
3.5 Team Concepts 11
3.5.1 Workspace 11
3.5.2 Transparent View 12
3.5.3 Transaction 12
3.6 Summary and Analysis of the Spectrum 12
4 The Future of CM Systems 13
5 Conclusions 14
I. Appendix: Overview of CM Systems 15
I.1 Adele 15
I.2 Aide-De-Camp (ADC) 15
I.3 Change and Configuration Control (CCC) 15
I.4 Configuration Management Assistant (CMA) 16
I.5 Design Management System (DMS) 16
I.6 Domain Software Engineering Environment (DSEE) 16
I.7 ISTAR 16
I.8 Jasmine 17
I.9 LIFESPAN 17
I.10 Network Software Environment (NSE) 17
I.11 PowerFrame 17
I.12 Rational 18
I.13 Revision Control System (RCS) 18
I.14 shape 18
I.15 Software Management System (SMS) 18
 List of Figures
Figure 1: CM Functionality Requirements 4
Figure 2: Spectrum of Configuration Management Concepts 7