Volume 2 • Number 4
Software Configuration Management for Project Leaders
As the systems being built today increase in software content, the need for software configuration management continues to rise. Prime contractors are integrating millions of lines of code from multiple subcontractors. Companies are required to produce and maintain variants of their main product to reach out to a diversified market. Project leaders are aware of the need to better manage and control their projects.
Change is a fact of life in software development: Customers want to modify requirements, developers want to modify the technical approach, and management wants to modify the project approach. Modification is necessary, because, as time passes, all parties know more about what they need, which approach would be best, and how to get it done and still make money. The additional knowledge becomes the driving force behind most changes. But, these changes must be carefully controlled.
This article brings together most of the software configuration management concepts to be analyzed from the project leader point of view. Configuration management will be shown as a project management support function that indeed helps project leaders manage and control their projects better.
Key words: baselines, Capability Maturity Model, change control, CMM, configuration control, process improvement, project leader, software configuration audits, software quality assurance
by Tim Kasse and Patricia A. McQuaid,
Kasse Initatives, LLC, and California Polytechnic State University
PURPOSE OF SOFTWARE CONFIGURATION MANAGEMENT
According to the Software Engineering Institutes (SEIs) Key Process Areas definition of software configuration management (SCM) (Paulk et al. 1993a; Paulk et al. 1993b), the purpose of SCM is to establish and maintain the integrity of the products produced throughout the projects software life cycle. Knowing the state of the product that a project is developing and knowing that it satisfies the customers requirements are of utmost importance for any project leader. SCM then can be viewed as a support function that helps a project leader better manage and control the project (IEEE 1997).
The Need for SCM
In many software companies, software support functions such as software quality assurance and SCM are not perceived as value-added by project leaders and software developers alike. SCM is frequently viewed by developers as a hindrance to product improvements because of the overhead associated with the change control function of SCM. But on closer examination, one can see that the most frustrating software problems are often caused by poor configuration management. Some examples of poor practices are (Babich 1986):
Most of these problems were revealed during software process assessments conducted by the authors (Kasse 1995). Projects, under great pressure to meet difficult deadlines, found their scarce time resource constantly under attack because of the rework caused by these reasons. One developer stated that he had fixed a problem three times, and three months after each delivery the problem recurred. Project leaders cannot afford to have their software developers redoing what was already done.
The cost of rework adds greatly to the cost of developing software and can be reduced by implementing an effective SCM program. The principles behind the modern cost-of-quality concept were derived for manufacturing applications and can be found in the works of J. M. Juran (Juran and Gryna 1988). In 1988 Raytheon Electronic Systems began using a cost of software quality model derived from Philip Crosby (1984) and process improvement methods to increase efficiency. According to Herb Krasner (1997), one of the leading researchers in the field of the cost of quality, by 1991, Raytheon moved from CMM level 1 to level 3; by 1994 it decreased rework costs from 41 percent to 20 percent of project costs. In 1995 it reached level 4. Between 1988 and 1994, Raytheons cost of rework from both internal and external nonconformances was reduced to less than 10 percent of development cost, and the productivity of the development staff increased by a factor of 170 percent. Additional material on this topic can be found at (Krasner 1998; Dion 1993; Haley 1996).
Another example of how a strong SCM program can reduce the cost of rework is that of Gunter Air Force Base in Montgomery, Ala. Gunters first assessment was conducted in 1987 by Watts Humphrey. The base was supplying MIS software support for the entire Air Force. They had about 500 outstanding Trouble Reports and so much pressure to get the defects fixed that they were sending out a release per month and patches in between. Based on the statistic that for every four defects one detects and fixes a new defect is introduced, one can imagine the chaos. While they did not keep statistics, they were probably introducing two to three errors for every four that they fixed. After the assessment, they focused on configuration management. When one of the authors conducted the follow-up assessment in 1989 while working at the SEI, the Air Force base was still not at CMM level 2, but they had made such a distinct business difference in configuration management they told the whole world how well they had done. It was not surprising that the number of trouble reports went from 500 to 50 and product releases went from once per month to once every six months. The results were impressive for any organization.
A key role of SCM is to control changes actively in order to answer the following questions (Babich 1986): What is the current software configuration? What is the status of the modules? What changes have been made to the software? Do anyone elses changes affect the software? SCM provides visibility into the status of the evolving software product. SCM answers who, what, when, and why. Who made the changes? What changes were made to the software? When were the changes made? Why were the changes made? Project leaders must be able to obtain answers to these questions in order to manage the projects technical activities and determine actual product evolution.
SCM VS. CHANGE CONTROL
SCM is often equated to change control. Indeed change control is a critical component of SCM, but it is only one of many. Following is a brief look at the components of SCM and how they connect to supporting a project leaders ability to manage and control the project.
Configuration identification supports the identifying of the structure of the software system and identifying the related life-cycle work products. It provides a unique identifier for each work product, and it supports traceability between the requirements and all other related software products.
Two structures that SCM is concerned with directly affect a project:
Figure 1 shows a V-Software life cycle (McDermid 1994) out of which comes a number of predefined work products. Examples of work products that should be considered for placement under configuration control include:
Source code modules
|System data files||Configuration management plans|
|System build files/scripts||Compilers|
|Design specifications||Operating systems|
|Software architecture specification||Shell scripts|
|Test plans||Third-party tools (STSC 1994)|
|Test procedures||Other related support tools|
|User documentation||Procedure language descriptions|
|Software development plan||Development procedures & standards|
Figure 2 is a simple example of a software product system composed of subsystems and modules (Walker 1996). Each system or subsystem component may have associated with it an include file for code or data and a make file for creating compiled and linked systems or subsystems. A discussion between the project and the SCM representative can help the project leader look critically at the software architecture and plan for evolutionary builds that can be controlled and tested at the developmental and system level.
Change is a fact of life in software development: Customers want to modify requirements, developers want to modify the technical approach, and management wants to modify the project approach. Modification is necessary, because, as time passes, all parties know more about what they need, which approach would be best, and how to get it done and still make money. The additional knowledge becomes the driving force behind most changes.
The fundamental success of any development effort depends on well-defined reference points against which to specify requirements, formulate a design, and specify changes to these requirements and the resultant designs. The term baseline is normally used to denote such a reference point. A baseline is an approved snapshot of the system at appropriate points in the development life cycle. A baseline establishes a formal base for defining subsequent change. Without this line or reference point, the notion of change is meaningless. A baseline could be:
A baseline is a record of a contract and serves as the basis for further development. It should be changed only through an agreed-upon change procedure. A baseline helps a project to control change without seriously impeding justifiable change. It will help a project to control the identified configuration items but not constrain early development excessively from the aspects of time, money, or resources. Before a baseline is established, change may be made quickly and informally. Once a baseline is established, change can be made but a specific, formal procedure must be applied to evaluate and verify each change. The items in the baseline are the basis for the work in the next phase of the software development cycle. The items of the next baseline are measured and verified against previous baselines before they become baselines themselves.
Figure 3 illustrates both the types of baselines that are typical and the quality functions that may be used to ensure that the work products are of the highest quality before they are baselined (Bersoff, Henderson, and Siegel 1980; Bryan and Siegel 1988; Humphrey 1990). The functional baseline, allocated baseline, and product baseline are most often thought of as organizational or system baselines. The requirements baseline, design baselines, module baselines, integration baseline (component and system), and operational baseline are often thought of as project or developmental baselines. System baselines are the records of contract made with the external customer. Developmental baselines are agreements to assure the project leader that the product integrity remains as it moves from phase to phase.
In the ideal world, once a configuration item is fully approved there would be no need to change. In the real world, new versions of a configuration item are needed for a variety of reasons:
In each case, a new version of a configuration item is needed that supersedes the earlier version. Without change control, a software engineer could make an important change to a configuration item or its interfaces without a lot of extra work and red tape. No record would be kept of what the change was, however, why the change was requested, who approved the change, who made the change, and who verified the change (IEEE 1997; Whitgift 1991). In addition, it would be hard to find answers to the following questions:
All changes made to the configuration management baselines or baselined software configuration items should be done according to a documented change control process. The change control process should specify:
To control the organizational or system baselines or contracts with the external customers, many organizations establish one or more SCCBs. The purpose of the SCCB is to ensure that every change is properly considered and coordinated. This SCCB may include members from program management, systems engineering, software engineering, software quality assurance, SCM, independent test, documentation, hardware engineering, and may even include a customer representative. The SCCB is responsible for receiving and initially evaluating the change requests that come from all sources (that is, customer, engineering, marketing, trouble reports, program management) and performing triage to get the most critical or significant change requests to the right people for impact analysis. Following the impact analysis, the SCCB ensures that all affected groups are able to recommit to the new requirements. The SCCB can make the decision to implement the change request, defer it to the next release, or discard it altogether. It is also possible that the SCCB will have to seek additional information before a decision can be made.
Project Leader Approval of Baseline Changes
Once the allocated baseline is created and the customer has accepted the software requirements specification and interface specification, the control of the work products and system components comes under developmental configuration control. Normally this means that decisions to make changes are decided by the project leader. If a change to a software module results in a required change to an interface module to a hardware device, the project leader may share the approval responsibility with the appropriate hardware manager. When the software passes to the integration and test stage, the project leader may share approval authority to make changes with the integration and test manager. When the product is ready to be shipped to the customer and a product baseline is established, the SCCB again becomes the approval authority. What baselines, when they are created during the software life cycle, and who the approval authorities are become part of each projects SCM plan.
Configuration Management Status Accounting
Configuration management status accounting involves maintaining a continuous record of the status and history of all baselined items and proposed changes to them. It includes reports of the traceability of all changes to the baseline throughout the software life cycle, and it should identify what changes have been made to the system and what changes remain to be implemented.
Configuration management status accounting provides visibility into the system evolution by recording and reporting the status of all items and the status of all requests for change. Questions that configuration management status accounting should be able to answer include (IEEE 1997; Whitgift 1991):
Configuration management status accounting is the means by which key project or system information can be communicated to everyone. Project members can easily determine which configuration item should be used, whether it is subject to a change request, and what a build consists of. Project leaders can easily determine what configuration items passed review, which changes have been completed, which changes are still in progress, how many changes have been accepted, which modules are the most volatile, what a build consists of, and what has been delayed to the next release.
Configuration Management and the Use of Peer Reviews
Configuration management status accounting can help the project leader make decisions on what degree of formality peer reviews should follow. For example: The product the project is building consists of 50 modules or units. Status accounting information reveals that 45 of the modules have changed once in six months, but five of the modules have changed 10 times per month for the past two months. With this configuration status information, the project leader can choose to conduct formal software inspections on the five modules that are experiencing rapid change and use less formal walkthroughs to ensure the integrity of the 45 modules that change infrequently.
The definition of interfaces is one of the most important SCM planning and tracking activities (IEEE 1997). There must be agreement of each group or organizations responsibility. Any proposed changes to the product or baselined configuration items can be considered and evaluated by all affected groups.
There are two basic types of interfaces that must be considered: organizational interfaces and technical interfaces. Organizational interfaces are those in which configuration management controls the transfer of configuration items from vendor to customer, project to project, and co-developer to co-developer. SCM ensures that the correct configuration items are sent to the correct people. Organizational interfaces also include life-cycle phase interfaces. Phase interfaces become critical when control of the product is being transitioned between different groups (for example, software development group to independent test group for formal testing). Technical interfaces are descriptions that should be placed under configuration management control like any other configuration item. Technical interfaces include system, user, software, hardware, and communication interfaces.
If a portion of a software development project is to be subcontracted to another organization, the responsibility for the SCM generally belongs to the contracting organization and specifically the project leader of the project that requires this outside support. The subcontractor is normally only responsible for the portion of the work that his or her organization is tasked to perform. The integration of the subcontracted work is normally the responsibility of the organization that subcontracted portions of the work.
An effective SCM system greatly increases the opportunity to have portions of the product subcontracted out and then integrated back into a whole that satisfies the customers technical and quality requirements. SCM must be applied to a subcontractor to ensure that the subcontractor is able to maintain the integrity of the subsystem for which it has contracted (Paulk et al. 1993a; Paulk et al. 1993b). This includes placing necessary life-cycle products under configuration control to ensure consistency with the main development effort and maintaining a subcontractors software library that will release the agreed-upon configuration items or subsystems to the contracting organization.
Software Configuration Audits
Configuration auditing verifies that the software product is built according to the requirements, standards, or contractual agreement. Auditing also verifies that all software products have been produced, correctly identified and described, and that all change requests have been resolved (IEEE 1997; Kasse 1995).
A software configuration audit should be performed periodically to ensure that the SCM practices and procedures are rigorously followed. The integrity of the software baselines must be assessed and the completeness and correctness of the software baseline library contents must be verified. The accuracy of the implementation of the changes to the baselines must be verified to ensure that the changes were implemented as intended. It is recommended that a software configuration audit be performed before every major baseline change.
Software configuration auditing should be continuous, with increased frequency and depth throughout the life cycle. Types of configuration audits include functional configuration audits, physical configuration audits, in-process audits, and traceability audits (see Figure 4).
Functional configuration audits The objective of the functional configuration audit (FCA) is to provide an independent evaluation of the software products, verifying that each configuration items actual functionality and performance is consistent with the software requirements specification. An FCA audit must be concerned not only with functionality but also with performance. An FCA includes:
Physical configuration audits The objective of the physical configuration audit (PCA) is to provide an independent evaluation of the system configuration items to confirm that each item that makes up the as built system maps to its specifications. The audit is held to verify that the software and its documentation are internally consistent and ready for delivery to the customer or end user. Appropriate customer deliverable documentation includes installation manuals, operating manuals, maintenance manuals, and release notes or version description documents. A PCA includes:
In-process audits In-process audits are held during the design and development phases prior to the FCA and PCA to verify the consistency of the design as it evolves through the development process. In-process audits are performed to determine:
Traceability audits Traceability auditing is necessary to be able to verify throughout the software development process:
Traceability audits are also necessary to be able to answer the following questions:
Software configuration audits check that the configuration management system and practices are effective and efficient for the project and the organization.
The software library should contain the items that are important to a software project, including source code, user documentation, system documentation, test data, support software, specifications, and project plans. The SCM library typically stores the configuration items and prevents unauthorized changes to the baselined items. The library system (Whitgift 1991):
A software library provides safe and secure storage for configuration items (key project components) so they cannot be changed without authorization. Acceptance of items (new or revised) into the library is strictly controlled to ensure that everyone accessing items in the library can have complete confidence in their integrity. A number of different libraries may be established to hold different types of items or provide different levels of control.
The SCM plan is the document that describes how a project will manage configurations (Paulk et al. 1993b; Whitgift 1991). The SCM plan should cover:
SCM is one of the most important process improvement tools that project leaders can use to evolve and deliver their product in a controlled manner. Knowing the state of the product that a project is developing and knowing that it satisfies the customers requirements is of utmost importance for any project leader. Since many of the most frustrating software problems are often caused by poor configuration management, proper configuration management is critical.
Even if an organization has little or no configuration management in place and is just getting started with a configuration management program, five simple steps will add a great deal of control and project tracking information: 1) Formalize the use of reviews before a configuration item is baselined; 2) Uniquely identify system components; 3) Establish simple change control; 4) Build up a repository of configuration items, change requests, and problem reports; and 5) Restrict access to the project library.
A good place to start is with simple status reports, which may include only the versions one has. When developing a change history, one can expand to a status accounting system, which includes who changed it, when, why, how, and what was affected, as described earlier in the article. Then, a configuration audit can be performed to make sure the approved change requests have been implemented completely and correctly. Once established, FCAs would be the next step to ensure that the system matches what was approved, and nothing more. Then, a physical audit can be added to ensure that the documentation matches the changes.
It is important to implement requirements traceability from the beginning through systems testing, implementing life-cycle work-product consistency checks. This means that if a requirements change request has been accepted, one must go through life-cycle phases to determine if it is necessary to make a corresponding change. Without the ability to trace through the life-cycle process, it cannot be done. Once one has the design document, he or she needs the ability to go backward and forward to look at the other life-cycle work products.
After expanding to multisite, multicountry, and multicultural projects, one may be looking at implementing at multiple levels of control boards and need to ensure that all parts are being managed and controlled with consistency and integrity. Otherwise, it cannot all be brought together and integrated into a working and maintainable system. Ultimately, some project leader is responsible for the entire integrated product!
Babich, W. 1986. Software configuration management. Reading, Mass. Addison-Wesley.
Bersoff, E. H., V. D. Henderson, and S. G. Siegel. 1980. Software configuration management. Upper Saddle River, N. J.: Prentice-Hall.
Bryan, W. L., and S. G. Siegel. 1988. Software product assurance. New York: Elsevier Science Publishing Co.
Crosby, P. 1984. Quality without tears. New York: McGraw-Hill.
Dion, R. 1993. Process improvement and the corporate balance sheet. IEEE Software (July): 28-35.
Haley, T. J. 1996. Software process improvement at Raytheon. IEEE Software (November): 33-41.
Humphrey, W. 1990. Managing the software process. Reading, Mass.: Addison-Wesley.
IEEE. 1997. IEEE Software engineering standards collection. Washington, D. C.: IEEE Press.
Juran, J. M., and F. M. Gryna. 1988. Jurans quality control handbook. 4th ed. New York: McGraw-Hill.
Kasse, T. 1995. Project Leader Exploratory Question Database, Antwerp, Belgium. Institute for Software Process Improvement, internal document.
Kasse, T., and P. McQuaid. 1998. Entry strategies into the process improvement initiative. Software Process Improvement and Practice Journal 4, no. 2: 73-88.
Krasner, H. 1997. Accumulating the body of evidence for the payoff of software process improvement. URL document www.utexas.edu/coe/sqi/archive.
Krasner, H. 1998. Using the cost of quality approach for software. Crosstalk, The Journal of Defense Software Engineering (November) (or see URL www.stsc.hill.af.mil/crosstalk/frames.asp?uri=1998/11/krasner.asp).
Paulk, M. C., B. Curtis, M. B. Chrissis, and C. V. Weber. 1993. Capability Maturity Model for Software, version 1.1. (CMU/SEI-93-TR-24). Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
Paulk, M. C., C. V. Weber, S. M. Garcia, M. B. Chrissis, and M. Bush. 1993. Key Practices of the Capability Maturity Model, version 1.1. (CMU/SEI-93-TR-25). Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
STSC. 1994. Software configuration management technology report, Software Technology Support Center. (This document provided by the STSC is a checklist of criteria to help organizations develop their requirements for selecting configuration management tools.)
Walker, G. 1996. What is configuration management? Alcatel Alsthom internal presentation, Paris, France.
Whitgift, D. 1991. Methods and tools for software configuration management New York: John Wiley & Sons.
Buckley, F. J. 1996. Implementing configuration management. Computer Society Press.
International Organization for Standardization (ISO). 1994. ISO 9000 Quality Management, ISO Standards Compendium. Geneva, Switzerland: International Organization for Standardization.
McDermid, J. 1994. Software engineers reference book. Florida: CRC Press.
Pressman, R. S. 1987. Software engineering. New York: McGraw Hill.
Schulmeyer, G. G., and J. I. McManus, eds. 1987. Handbook of software quality assurance. New York: Van Nostrand Reinhold.
Tim Kasse is manager and principal consultant of Kasse Initiatives LLC, founded in 1999. Previously he served as the chief executive officer and principal consultant for the Institute for Software Process Improvement (ISPI), which he co-founded with Jeff Perdue in 1991. His focus is on innovative solutions for process improvement of business, systems, software, people, and lifestyles. He is the architect of the Action Focused Assessment, which has been applied in major organizations throughout Europe and has been commercialized in the Netherlands.
Kasse is the primary or co-developer of many of Kasse Initiatives workshops. He is a recognized speaker at major conferences around the world, including the SEIs SEPG conference, the European SEPG conference, the European Software Process Improvement Conference, the Software Technology Conference, and the World Congress of Software Quality. Prior to starting ISPI, Kasse spent four years at the Software Engineering Institute. He was a major contributor to the development of the Capability Maturity Model, which provides the framework for the SEIs assessments and evaluations. Kasse has a masters degree from Southern Methodist University and a bachelors degree in systems engineering from the University of Arizona. He is a member of IEEE and has participated in the development of the IEEE standard on reviews and audits. Kasse can be reached at Kasse Initiatives, LLC., 30 W. Sheffield Ave., Gilbert, AZ 85233, or by e-mail at firstname.lastname@example.org.
Patricia McQuaid is an associate professor of management information systems at California Polytechnic State University. She has taught a wide range of courses in both the college of business and college of engineering. She has industry experience in information systems auditing in both the banking and manufacturing industries, and is a certified information systems auditor (CISA). Her research interests include software quality, in particular, the areas of software process improvement, software testing, and complexity metrics. McQuaid is serving as the chair for the Americas for the Second World Congress for Software Quality, to be held in Japan in September 2000.
McQuaid has a doctorate and a masters degree in computer science and engineering from Auburn University, an MBA from Eastern Michigan University, and an undergraduate degree in accounting from Case-Western Reserve University. She is a Senior member of ASQ, and a member of the Association for Computing Machinery, IEEE, IEEE Computer Society, the International Function Point Users Group, the Information Systems Audit and Control Association, and the Decision Sciences Institute. She can be reached at California Polytechnic State University-MIS, College of Business, San Luis Obispo, CA 93407, or by e-mail at email@example.com.
(0) Member Reviews