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