of SCM and traceability as a means to address
these problems.
Plan Traceability Management
Identify traceability Identify traceability links -
items - Definition of the Definition of links between
Framework elements in the framework
Establish traceability
practice guidelines -
Defining when and what
to capture
depends on
Tailor traceability practices -
Project-specific customization
of the framework
Manage
change
request
Create CM
Environments (setup of
VSS)
Create Traceability Environments
Identify traceability Tools
- Selection of Tracer
depends on
Setup traceability
environments - Setup of
tracer
Identify level of integration
needed - Configuration of
Tracer’s integration
capabilities
depends on
Change and deliver
configuration items
Create Make
development changes
workspaces
followed by
Establish Traceability
Deliver
Changes
Capture traceability knowledge -
Instantiate framework for
the context at hand
Link traceability
knowledge to artifacts -
Links across dependent
subsystems
Manage baselines and releases
Create Promote
baselines baselines
Impact Analysis
Generate impact analysis reports - Update traceability -
showing dependencies depending on changes to
across subsystems dependent subsystems
Audit traceability - Check if all
dependencies are captured to ensure
completeness and consistency
Plan CM HOW IS SCM USED?
Process frameworks like the Rational
Unified Process (RUP) provide detailed
guidelines on how to plan and execute
SCM [ 8]. The box on the right side of
the accompanying figure depicts the
RUP process for configuration and
change management. Many organiza-
tions internally develop and use similar
SCM processes. At the outset, the proj-
ect team establishes SCM policies,
writes an SCM plan, and establishes a
change control process. An SCM tool
Update
workspace like Microsoft’s Visual SourceSafe is
used to support these processes.
Development workspaces are created,
and change requests are logged,
reviewed, verified, and approved.
Changes incorporated in the system are
logged in the SCM tool. When needed,
audit and status reports are generated.
Now let us consider an example from
Hospcom to illustrate the problems even
with mature SCM practices. Clear pro-
cedures for documenting and fulfilling
change requests were developed based on RUP. Visual
SourceSafe was used to manage versions of various
source code modules. Following common industry
practices, these dependencies were managed at file
level (rather than at the level of individual objects).
Reasoning behind changes was documented with
minimal details and not linked to requirement specifications, design models, or source code. As a result,
when a change request was processed, developers did
not fully understand its repercussions on various software artifacts and their versions.
For example, when it was necessary to support a
new telephone system, Hospcom incorporated
changes in the television control module. The development team documented the changes in the SCM
tool using textual descriptions. Later, when incorporating a new feature in the patient billing system, the
developers found it very difficult to understand the
rationale behind the changes incorporated in the television control module. Traceability matrices that documented the rationale were not linked to specific
versions and configurations of various software artifacts. This resulted in erroneous and inconsistent
changes to the television control module.
In the absence of well-documented process knowledge (which refers to knowledge about the reasons
Monitor and Report
Configuration status
Report on Perform
configuration configuration
status audit
uses
Traceability and SCM as part of
a process framework.
[ 4]. Current SCM practices and tools do not adequately support change management [ 3]. First,
SCM often focuses on managing source code files,
leaving changes to other artifacts like requirements
and design documents unmanaged [ 2]. Second, the
management of dependencies among many artifacts
created during the development life cycle, which is
essential for ensuring the integrity of the system [ 7], is
typically done outside SCM tools. Traceability tools,
which help link conceptual and physical artifacts created during software development are commonly used
for this purpose [ 5]. Thus, though both SCM and
traceability have a common objective of facilitating
change management, they are often used independent
of each other.
This leads us to the question: How can we integrate
traceability practice with SCM practice and thereby
improve change management processes in software development? We investigate this question by conducting a case
study in an organization (hereafter referred to as Hospcom)
that develops embedded software systems (see sidebar for
details on how the study was conducted). We identify
problems in SCM practice and recommend the integration