Managing work-process environments. After establishing an ^Activity SCM plan, an SCM environ-

Plan

ment is created by selecting and installing SCM tools. At Hospcom, Visual SourceSafe was used for SCM. Traceability matrices were created as Word documents. These practices were used independent of each other. Change requests and changes incorporated in source-code modules documented in Visual SourceSafe were not linked to rationale documented in traceability matrices.

Manage

For synergistic operation, ^{baseline and} release

traceability environments should be integrated with the SCM environment so developers can work in either when incorporating changes in the system. Although such integration can be achieved ^{Monitor and} report with some effort through the^{configuration} status interfaces provided by either the SCM or traceability system, the development of a common environment will be tremendously helpful. This integration can be achieved at different levels— ranging from just a simple tool invocation to interoperation with the ability to share data and metadata. Integration should be done in such a way that the SCM and traceability tools are aware of the changes in each other and rework is avoided while managing changes in either.

Managing change requests and making and delivering changes. During SCM, developers create workspaces, make changes, and deliver the changed system. Important tasks in SCM are to accept, review, control, and fulfill change requests. Hospcom created textual documents in the SCM tool that briefly explain the nature of changes incorporated. In several instances, these documents did not provide adequate or specific details on why certain changes were done and how they affect other artifacts.

In an integrated practice, traceability knowledge acquired during development can be used to analyze the impact of changes by tracing dependency links among artifacts and identifying the ripple effect of changes. Traceability knowledge can be used to ensure that changes are made in a consistent manner. Also, when changing software artifacts, developers need to document new traceability knowledge that includes

SCM Traceability SCM integrated with Traceability

Even if organizationwide SCM and traceability plans are developed SCM plans are developed, in conjunction with one another for detailed and fine-grain effective change management. This knowledge about approach provides guidance on the level dependency and rationale of detail at which knowledge about for changes are not changes is to be documented and linked managed within SCM to versions and configuration in SCM.

Manage work- SCM tools are typically Traceability tools are typically Integrated work process environments
process used to manage source code used to manage finer dependencies for SCM and traceability enables linking
environments modules at file level, but across various artifacts. of fine-grain knowledge about
not other artifacts like dependencies to specific versions and
requirements and design. configurations.

Manage change SCM is used in reviewing, Impact of changes can be identified Specific changes to software artifacts can
requests, make controlling, and approving through knowledge about be documented in detail in traceability
and deliver changes. Only brief textual dependencies and rationale behind tools and linked to specific versions of
changes comments are used to changes. But these are not linked to artifacts. Rationale behind decisions on
describe changes affected versions of artifacts. reviews, control, and approvals can be
incorporated in specific documented in traceability tools and
artifacts. linked to versions and configurations in
SCM.

The integration enables linking requirements in specifications to design elements in versions of design models and source-code modules. This enables checking completeness and consistency of baselines and releases.

Typically, no organization-wide traceability plans are developed. Knowledge about dependencies and rationale are managed in traceability tools or documents in isolation from SCM

Completeness and consistency checks are difficult by just using information from SCM tools. Artifacts managed in SCM tools are typically not linked to requirements specifications explicitly.

Status of configuration items can be determined using knowledge about changes to various versions documented in SCM tools. Since this is typically done using brief textual comments, this knowledge is usually not comprehensive.

Though traceability tools are used to establish links among requirements, design models, source code, etc., they are not specifically linked to various versions of these artifacts. As changes may affect various versions, it is difficult to use traceability in isolation from SCM to check completeness and consistency.

Though traceability tools can be used to check status of various software artifacts, they cannot be used to check status of specific configurations of artifacts.

Configuration status reports can be more complete as they can bring together knowledge about changes to specific versions of software artifacts and how various configurations were derived. Information on composition of configurations from SCM environments and rationale behind the creation of configuration from traceability environment aree integrated.

Comparing isolated SCM and traceability practices with an integrated approach.

links between the changed artifacts and related artifacts, and they must link this documentation to affected artifacts so the integrity and completeness of artifacts can be ensured.

Managing baseline and release. SCM helps create baselines of systems or subsystems for release or reuse. When creating or promoting a baseline, developers need to ensure that all the required artifacts are archived, and the quality and reliability of these artifacts can be guaranteed. At Hospcom, during the creation of baselines and releases, developers were unable to check the completeness and consistency of the system with specific versions of artifacts due to the lack of synergistic use of traceability and SCM. For example, while traceability matrices helped identify software artifacts that implemented specific requirements, they did not provide specific links to the exact versions and configurations that implemented them. Also, when changes were incorporated in specific artifacts to accommodate changes in requirements, the traceability matrices did not direct them to the specific versions of the artifacts that were subject to these changes. Part of this knowledge was documented in the SCM tool. Thus, the knowledge required for performing completeness and consistency checks was fragmented in traceability and SCM environments.