Communications of the ACM
Improving the Change-Management Process
A common reason for the failure of a significant number of software development projects is the continuous evolution of software caused by volatility in customer requirements. Sources of volatility are diverse, ranging from changes in technology, evolving end-user needs, and dynamic market pressures. The evolution of software systems consumes significant resources, especially when change-management practices do not adequately support the process. Software configuration management (SCM) practices help in the management, control, and execution of change and evolution of systems [1]. Specifically, SCM helps in identifying the structure of the software product, controlling changes incorporated in software artifacts, maintaining the status of these artifacts, and generating reports for auditing and status reporting [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 of SCM and traceability as a means to address these problems.
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 organizations internally develop and use similar SCM processes. At the outset, the project team establishes SCM policies, writes an SCM plan, and establishes a change control process. An SCM tool 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 procedures 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 behind design decisions and the impact of changes caused by dependencies), developers usually implement changes based on their own (often incomplete) understanding of this knowledge. They rely on their past experience to understand design decisions made during development. This leads to poor maintenance performance, increased effort in identifying and modifying artifacts affected by the changes, low quality of changes incorporated in the system, and incomplete or inconsistent changes. Our study suggests that these problems can be addressed by the integration of traceability and SCM.
How Does Traceability Add Value?
Traceability is the ability to describe and follow the life of software artifacts, such as requirements, designs, and implementation of the system [5]. It is used to maintain links or relationships between software artifacts to ensure that the design and implementation satisfy the requirements. Traceability also helps represent design rationale [6]. Since traceability can be used to document complex dependencies across software artifacts, it can help explain how making changes to artifacts affects other artifacts.
While the benefits of traceability are typically delivered downstream, the costs are incurred upstream in the development life cycle.
Typical traceability practice involves the use of traceability matrices or networks. Traceability matrices identify the correspondence among requirements, design, source code, and test cases, in a tabular format. Traceability networks are semantic networks that identify different types of links among these artifacts. They are often used in large-scale, complex, and mission-critical projects that require a comprehensive understanding of the relationships among artifacts [7]. Given the important role of traceability in managing dependencies, it is a natural complement to SCM in managing system evolution.
While process frameworks like RUP provide guidelines on many key process areas, they do not provide adequate guidelines for traceability practice. Since the overarching objective of SCM and traceability is change management, we suggest the synergistic integration of these practices. For effective change management, clear traceability processes should be defined and associated with appropriate SCM processes. Based on our case study, we have charted the activities involved in a traceability process. We illustrate how they can be integrated with the SCM process described in RUP in the figure. The box on the right side of the figure outlines the activities in SCM as specified in RUP. The box on the left side of of the figure outlines the traceability workflow. The figure also shows how different activities in traceability practice are associated with those in SCM.
Here, we provide examples of problems faced in each activity by stakeholders in our case study and illustrate how SCM integrated with traceability can address a variety of problems.
Planning. SCM plans define how to identify and monitor the evolution of configuration items (software artifacts managed within an SCM system). Hospcom developed an SCM plan and followed it in its standardized SCM practice. However, each development team developed its own traceability practice, as no organizationwide traceability plan was developed. Typically, traceability matrices that link requirements to other artifacts were created.
An integrated approach requires the establishment of a traceability plan that is tightly intertwined with the SCM plan. A traceability plan defines the traceability practice for the organization. It identifies the various traceability items (like requirements, design elements, and source-code modules) and the links among them, as well as project-specific artifacts that need to be tracked. A traceability plan may also specify the level of detail with which traceability knowledge is maintained, possible variations in traceability practice based on project characteristics like size and complexity, and potential applications of documented traceability knowledge. For example, traceability can be established at a coarse level (such as links among related files) or at a more fine-grain level (such as links between a requirement and a class in a design model). The integration of such a traceability plan with the SCM plan is essential for effective change management. Traceability items should be consistent with configuration items managed in the SCM system. The change-management process should define the correspondence between items used in these environments. For example, the correspondence between the file-level items managed by SCM tools and fine-grain traceability items that are managed by traceability networks should be clearly established. This is essential in maintaining dependencies between items at different levels of detail within SCM and traceability tools.
Managing work-process environments. After establishing an SCM plan, an SCM environment 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.
For synergistic operation, 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 with some effort through the 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 levelsranging 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 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.
Checking completeness of a baseline or a release can be done more effectively when knowledge from traceability environments is integrated with that documented in SCM tools. For example, dependency knowledge available in traceability environments must be linked to knowledge about changes to specific versions so developers can easily navigate and examine if all applicable requirements and changes are implemented appropriately.
Monitoring and reporting configuration status. SCM systems help monitor and generate report projects to check the integrity of configuration items, determine whether they meet requirements, and evaluate the status of configurations. At Hospcom, the developers were unable to create reports on integrity and completeness of configuration items as the knowledge required for this was fragmented across traceability and SCM environments.
Traceability knowledge can be used to complement SCM systems in performing these activities. Traceability knowledge also needs to be audited and monitored to ensure its completeness and correctness. Given the critical role of traceability knowledge in acceptance testing (to examine whether a software system meets customer requirements and if so, how), traceability audit should be part of configuration audits. Traceability knowledge complements information stored in SCM tools while conducting audits by showing the origins of each product and process of development.
Conclusion
Our framework for integrating traceability and SCM offers several benefits. The key implications we draw from our study involve aspects of SCM-traceability integration and adapting traceability and SCM processes.
SCM-traceability integration. The guidelines we have provided here include two types of integration of SCM and traceability that project managers should understand and implement: process integration and tool integration. Project managers should recognize the extent to which SCM and traceability processes are intertwined. This should be reflected in the organizationwide quality-guideline documents prepared by quality-assurance groups. When the development processes are tailored, tight coupling between SCM and traceability practices should be maintained. Regarding tool integration, software development organizations should consider the development of homegrown applications that can act as middleware between SCM and traceability systems. Such in-house augmentation is necessary due to the limited ability of traceability and SCM tools to interoperate.
Adapting traceability and SCM processes. Though we suggest the inclusion of a traceability framework as part of comprehensive process frameworks like RUP, it should be adapted to suit the needs of the organization and the project. Using a generic traceability process in all projects may be counterproductive if it is implemented without consideration of project characteristics like complexity, size, and regulatory guidelines. While mission-critical projects may adopt sophisticated traceability processes, agile software development situations may find that these may constrain their development agility. Therefore, organizations involved in agile development need to create lightweight versions of the general process framework to maintain speed of development without significantly sacrificing product quality. The accompanying table summarizes how an integrated approach provides a synergistic change-management practice when compared to SCM and traceability.
Although we have emphasized the importance of integrating SCM and traceability, we recognize significant challenges in achieving this integration. For example, it imposes a considerable amount of overhead. Also, while the benefits of traceability are typically delivered downstream, the costs involved are incurred upstream in the development life cycle. Therefore, incentive schemes that recognize this issue should be developed to motivate the contributors and consumers of traceability knowledge. Further, the adoption of an integrated practice that deviates significantly from current practices is likely to encounter resistance unless appropriate incentives, tool, and process support are provided.
References
1. ANSI/IEEE-828-2005 IEEE Standard for Software Configuration Management Plans. IEEE Standards Association, 2005.
2. Chu-Carroll, M.C., Wright, J., and Shields, D. Supporting aggregation in fine-grained software configuration management. In Proceedings of the 10th ACM SIGSOFT Symposium on Foundations of Software Engineering (Charleston, SC, 2002), ACM Press, NY, 99108.
3. Conradi, R. and Westfechtel, B. Version models for software configuration management. ACM Computing Surveys 30, 2 (1998), 232282.
4. Hass, A.M.J. Configuration Management Principles and Practice. Addison-Wesley, 2002.
5. Palmer, J.D. Traceability. In Thayer, R.H. and Dorfman, M. eds. Software Requirements Engineering. IEEE Computer Society Press, Los Alamitos, CA, 1997, 364374.
6. Ramesh, B. and Dhar, V. Representing and maintaining process knowledge for large-scale systems development. IEEE Expert 9, 2 (1994), 5459.
7. Ramesh, B. and Jarke, M. Towards reference models for requirements traceability. IEEE Transactions on Software Engineering 27, 1 (2001), 5893.
8. Rational Unified Process. IBM, June 15, 2005; www-306.ibm.com/software/awdtools/rup/.
©2008 ACM 0001-0782/08/0500 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.