Introduction to Software Configuration Management

OVERVIEW

Software configuration management (SCM, or just plain CM) is an organizational framework ” that is, a discipline ” for managing the evolution of computer systems throughout all stages of systems development. That a rigorous framework for producing quality computer systems is needed is undeniable according to the following statistics:

• More than half (53 percent) of IT projects overrun their schedules and budgets , 31 percent are cancelled, and only 16 percent are completed on time.
• Source: Standish Group
• Publication date: 2000
• Of those projects that failed in 2000, 87 percent went more than 50 percent over budget.
• Source: KPMG Information Technology
• Publication date: 2000
• 45 percent of failed projects in 2000 did not produce the expected benefits, and 88 to 92 percent went over schedule.
• Source: KPMG Information Technology
• Publication date: 2000
• Half of new software projects in the United States will go significantly over budget.
• Source: META Group
• Publication date: 2000
• The average cost of a development project for a large company is $2,322,000; for a medium company, it is $1,331,000; and for a small company, it is $434,000.
• Source: Standish Group
• Publication date: 2000
• $81 billion was the estimated cost for cancelled projects in 1995.
• Source: Standish Group
• Publication date: 1995
• More than half (52.7 percent) of projects were projected to cost over 189 percent of their original estimates.
• Source: Standish Group
• Publication date: 2000
• Projects completed by the largest American companies have only approximately 42 percent of the originally proposed features and functions.
• 88 percent of all U.S. projects are over schedule, over budget, or both.
• Source: Standish Group
• Publication date: 2000
• The average time overrun on projects is 222 percent of original estimates.
• Source: Standish Group
• Publication date: 2000

During the past decade , the capabilities and sheer innovativeness of software technology has far outpaced our ability to manage the complexity of problems that software development must address. Unfortunately , the ability to develop and deliver reliable, usable software within budget and schedule commitments continues to elude many software organizations.

Software configuration management (SCM) provides the means to manage software processes in a structured, orderly, and productive manner. SCM spans all areas of the software life cycle and impacts all data (see Chapter 10) and processes. Hence, maximum benefit is derived when SCM is viewed as an engineering discipline rather than an art form, which, unfortunately, many developers have a tendency to do.

As an engineering discipline, SCM provides a level of support, control, and service to the organization:

• Support. SCM is a support function in that it supports program engineers and developers, the program, the corporation, and, in a number of situations, the customer.
• Control. SCM is a control function in that it controls specifications, documents, drawings, requirements, tools, software, and other deliverables.
• Service. SCM is a service provider in that it supports people and controls data. The role of the SCM manager is to ensure that (1) SCM personnel are properly trained and have the necessary resources (budget and tools) to do an efficient and effective job; (2) a proper balance of control and support is tailor made to each program that is being supported; and, (3) the SCM function is flexible and can accommodate the changing needs and requirements of the developers, customers, the program, and the company.

The process of SCM has not really changed much during the past 20 to 30 years . However, the environment that SCM operates within has changed significantly and is likely to continue to change. Over the past few decades, we have migrated from centralized mainframes using just a few programming languages such as COBOL and FORTRAN to decentralized, networked, Web-based environments with thousands of devices using hundreds of software packages and dozens of programming languages.

The most significant impacts to SCM have centered on the automated tools and the library systems they operate upon. Up until the 1990s, the entire focus of SCM was on version control with very few vendors from which to choose. Today, there are literally hundreds of small to large SCM vendors promoting a variety of products from simple version control to sophisticated tools that purport to establish and monitor the entire software development and production environment.

Regardless of this amazing diversity, the process of CM is basically immutable ” that is, the process does not change, only what is being managed changes. What this means is that CM is as applicable to a mainframe shop as it is to a shop running all Web-based applications in a networked, secured environment. The key is in the process.

SCM AND PROCESS IMPROVEMENT

Improvement depends upon changing current processes along with the accompanying environment. SCM, then, provides the underlying structure for change and process improvement. We refer to this as process-based configuration management.

For example, the first step to improve the product is to know how the product is currently produced. The second step for improvement is to foster an atmosphere in which change can be readily accommodated. If change does not appear possible, then improvement is also unlikely . SCM measurements of current practices and their associated metrics can help identify where processes are working and where they need to be improved. Such change efforts should lead to increased productivity, integrity, conformance, and customer satisfaction.

The Institute of Configuration Management (ICM) defines configuration management (CM) as "the process of managing the full spectrum of an organization's products, facilities, and processes by managing all requirements, including changes, and assuring that the results conform to those requirements" [ICM 1998]. By this definition, CM can also be called process configuration management because it includes the process of managing an organization's processes and procedures.

Many organizations can be characterized as Level 1 organizations as defined in the Software Engineering Institute's Software Capability Maturity Model (SEI SW-CMM). These Level 1 organizations rely heavily on "heroes" to accomplish the work. The organization's processes are not documented, and few people know how the work is accomplished. "The software process is characterized as ad hoc, and occasionally even chaotic . Few processes are defined, and success depends on individual effort and heroics" [Paulk 1995].

An effective SCM program, when applied to organizational processes, identifies which processes need to be documented. Any changes to those processes are also tracked and documented. Adhering to these processes will reduce an organization's dependence on heroics for the work to be accomplished and the project to succeed. It also relieves the frustration and problems that arise if one of the "heroes" is not available to perform a task.

SCM is an essential discipline in the everyday activities of defining requirements, designing, writing, compiling, testing, and documenting the software. SCM is not simply version control or format control. It is not a clerical "after-the-fact" function. It is a technical field of expertise with formal practices.

The benefits derived from SCM are directly proportional to the extent that SCM is implemented. The primary objective is to deliver a quality product that meets the stated requirements, on schedule, and within budget. An effective SCM program supports this objective by tracking each requirement from concept through implementation to customer delivery.

MEASUREMENTS AND METRICS

The status accounting aspect of SCM provides management visibility into the state of software products. Status accounting data includes measurements (see Chapter 13) that can show the location of bottlenecks in the software development process, and can indicate the maturity of the software products.

Hermann [1998] describes the use of software changes to measure product maturity and readiness to deliver the software. He goes on to mention other metrics that may be useful, including average severity, severity level distribution, average closure time, charts for each severity level, and charts for each configuration item or sub-system .

A measure can be defined as "a standard of measurement, the extent, dimensions, capacity, etc., of anything, especially as determined by a standard, an act or process of measuring, a result of measurement" [Starrett 1998]. Examples of a measure include the number of defects found in a release or the number of source lines of code delivered. A metric can be defined as "a calculated or composite indicator based on two or more measures, or a quantified measure of the degree to which a system, component, or process possesses a given attribute. An example of a metric is defects per thousand source lines of code" [Starrett 1998].

A metric can also be "a composite of measures that yields systematic insight into the state of processes or products and drives appropriate actions" [Pitts 1997]. Measures (measurements) and metrics can be used to identify areas of the process that require attention. These areas are identified through compiling measurements into metrics. Measurements are compiled in an electronic spreadsheet, a database, or by hand. There are also several management tools that allow collection of measurements and derivation of metrics. The format is not the issue; the data is.

A metrics program should include the following fundamentals [Pitts 1997]:

• A motive that is compelling, not simply conformism
• Benchmarks that define nominal operation of the software development process
• Goals that define the purpose of the metrics program
• Strategy for achieving the goals
• An appropriate model (COCOMO, SLIM, etc.), whether it is a mathematical model or heuristic
• Collection of data that is unobtrusive
• Analysis of the data to find patterns: patterns imply consistency and consistency implies process
• Action on the analysis change in the process to achieve better results
• Implementation ethics, including trust, value, communication, and understanding

Metrics are used to measure the progress of a project, the quality of its product, the effort necessary to complete the project, etc. One desired outcome of compiling and using these metrics to improve processes is the improvement of the product's value-to-cost ratio. If a change in a process yields an increase in production during a specific timeframe, or yields the same production in a decreased timeframe, the value-to-cost ratio is improved.

Another desired outcome is increased customer satisfaction through meeting their requirements. For example, if defects in software can be traced back to incomplete or faulty requirements definition, the requirements definition process should be reviewed to increase the clarity and completeness of the requirements. The metrics may help show that the customer needs to be more actively involved in defining the requirements clearly and precisely.

BENEFITS OF SCM

There are many benefits to be gained by an organization that practices SCM. Software developers, testers, project managers, quality assurance (QA) personnel, and the customer may benefit from SCM. Benefits include:

1. Organizes tasks and activities that maintain the integrity of the software
2. Helps manage assets
3. Provides ability to track changes made during sequential or parallel development
4. Ensures correct configurations of software (i.e., compatible configurations)
5. Ensures that engineers are implementing changes into the correct "baseline" or version of the software
6. Provides the ability to trace the process from requirement to product
7. Limits legal liability by recording all data whether flattering to the company or not including memos, decisions, meeting minutes, changes to requirements/code/test procedures, etc., providing a "paper trail"
8. Helps reduce the life-cycle cost of maintaining software, which can easily exceed the initial cost of development
9. Allows responsibility to be traced to the source (i.e., a requirement problem, coding problem, etc.)
10. Provides for consistent conformance to customer requirements
11. Provides a stable environment for the software development process to be defined, repeated, and improved
12. Enhances compliance with standards being applied
13. Provides an environment in which meaningful measures can be gathered and used
14. Enhances current status accounting
15. Provides data for reports that can be easily generated
16. Allows quick and easy auditing
17. Provides the ability to reproduce circumstances/conditions under which the product was produced by retaining information relative to the production process (tracks changes made to baselines, hardware, compiler versions, etc.)
18. Provides communication channels between groups (system, subsystem, test, interface, etc.)
19. Fosters an ability to improve without being punitive in nature
20. Provides an understanding of when the product is ready for release (when all changes have been processed completely)
21. Helps produce higher quality software

SCM provides visibility into the status of the evolving software product. Software developers, testers, project managers, quality assurance (QA) personnel, and the customer benefit from SCM information.

SCM COMPONENTS

SCM encompasses the everyday tasks within an organization, whether software development or maintenance. Software changes are identified, controlled, and managed throughout project life cycle.

The ten key SCM activities for most common development environments are [Platinum 1998]:

1. Accessing and retrieving software
2. Retrofitting changes across the development life cycle
3. Migrating changes across the development life cycle
4. Managing the compile and build process
5. Managing the distribution of changes
6. Obtaining approvals and sign-offs
7. Managing software change requests
8. Coordinating communication between groups
9. Obtaining project status
10. Tracking bugs and fixes

SCM is divided into the following functional areas, as shown in Figure 1.1.

Figure 1.1: Functional Elements of SCM

CONFIGURATION IDENTIFICATION

Configuration identification (see Chapter 4) involves identifying the structure of the software system, uniquely identifying individual components, and making them accessible in some form. The goal of configuration identification is to have the ability to identify the components of a system throughout its life cycle and provide traceability between the software and related software products. Identification answers What is the configuration of my system? What version of the file is this? and What are the components of the system?

Configuration identification activities include:

• Selecting items to be placed under SCM control
• Developing the software hierarchy
• Creating an identification scheme that reflects the software hierarchy
• Identifying which version of a component can or cannot be included in a working release
• Uniquely identifying the various revisions of the software product
• Defining relationships and interfaces between the various software products
• Releasing configuration documentation
• Establishing configuration baselines

Figure 1.2 presents a typical breakdown of software into its distinct parts and presents a numbering scheme that uniquely identifies each component of a baseline release. The number to the left of the dot is the last baseline or major release. The number to the right of the dot is the version since the last baseline or minor release. Normally, after a new baseline, major release, the number to the right of the dot is zero. A hierarchical scheme is used.

Figure 1.2: Software Configuration Identification Hierarchy

Although key components to be managed are the requirements and source code, related documentation and data should be identified and placed under SCM control. It is important to store and track all environment information and support tools used throughout the software life cycle to ensure that the software can be reproduced.

Items typically put under SCM control include [Kasse 1997]:

• Source code modules
• System data files
• System build files and scripts
• Requirements specifications
• Interface specifications
• Design specifications
• Software architecture specifications
• Test plans
• Test procedures
• Test data sets
• Test results
• User documentation
• Software development plan
• Quality plans
• Configuration management plans
• Compilers
• Linkers and loaders
• Debuggers
• Operating systems
• Shell scripts
• Third-party tools
• Other related support tools
• Procedure language descriptions
• Development procedures and standards

Effective configuration identification is a prerequisite for the other configuration management activities (configuration control, status accounting, and audit), which all use the products of configuration identification. If configuration items and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items' configuration, to establish accurate records and reports , or to validate the configuration through audit. Inaccurate or incomplete identification of configured items and configuration documentation may result in defective products, schedule delays, and higher maintenance cost after delivery.

CONFIGURATION CHANGE CONTROL

Configuration change control involves controlling the release and changes to software products throughout the software life cycle (see Chapters 5 and 11). It is perhaps the most visible element of configuration management. It is the process to manage preparation, justification, evaluation, coordination, disposition, and implementation of proposed engineering changes and deviations to affected configuration items and baselined configuration documentation.

The goal of configuration change control is to establish mechanisms that will help ensure the production of quality software as well as ensure that each version of the software contains all necessary elements, and that all elements in a version will work correctly together. A generic change process is identified in Figure 1.3.

Figure 1.3: Generic Change Process [Berlack 1992]

Configuration change control answers What is controlled? How are the changes to the products controlled? Who controls the changes? When are the changes accepted, received, and verified ?

Configuration change control activities include:

• Defining the change process
• Establishing change control policies and procedures
• Maintaining baselines
• Processing changes
• Developing change report forms
• Controlling release of the product

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:

• Who can initiate the change requests
• What the criteria are for placing the software components under formal change control
• The "change impact" analysis expected for each requested change
• How revision history should be kept
• The check-in/ check-out procedures
• The process that the Software Configuration Control Board (SCCB) follows to approve changes
• How change requests will be linked to the Trouble Reporting System
• How change requests are tracked and resolved
• The reviews and regression tests that must be performed to ensure that changes have not caused unintended effects on the baseline
• The procedure that will be followed to update all affected software life-cycle components to reflect the approved changes

To control changes made to configuration items or the system, many organizations establish a Software Configuration Control Board (SCCB). This board reviews each proposed change; approves or disapproves it; and if approved, coordinates the change with the affected groups.

Another key concept of change control is the use of baselines. A baseline is "a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change procedures" [IEEE 1990]. When an item is baselined, it becomes frozen and can only be changed by creating a new version.

Historically, three different types of baselines were used: functional, allocated, and product. The functional baseline is the initially approved documentation describing the functional characteristics and the verification required to demonstrate the achievement of those specified functional characteristics. The allocated baseline is the initially approved documentation describing the interface requirements, additional design constraints, and the verification required to demonstrate the achievement of those specified functional and interface characteristics. The product baseline is the initially approved documentation describing the necessary functional and physical characteristics and those designated for production acceptance testing.

Several additional but informal baselines are usually established during the software development process. The number and type of baselines depend on which life-cycle model the project is implementing. Life-cycle models, such as the spiral, incremental development, and rapid prototyping, require more flexibility in the establishment of baselines.

CONFIGURATION STATUS ACCOUNTING

Configuration status accounting (see Chapters 6, 7, and 13) involves the recording and reporting of the change process. The goal of status accounting is to maintain "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" [Kasse 1997].

Configuration status accounting answers What changes have been made to the system? and How many files were affected by this problem report?

Configuration status accounting activities include:

• Determining type of logs and reports required
• Tracking the status of SCM items
• Tracking the status of changes to the system
• Generating status reports
• Recording and reporting the activities of SCM

Questions that SCM status accounting should be able to answer include [Kasse 1997]:

1. What is the status of an item? A developer may want to know whether a specification has been fully approved. A developer may want to know whether a sub-system has been tested so that the developer can test the modules that interface with that sub-system . A project leader may wish to track the progress of a project as items are developed, reviewed, tested , and integrated.
2. Which version of an item implements an approved change request? Once a requested enhancement of a library routine is implemented, the originator and other developers will want to know which version of the routine contains the enhancement.
3. What is different about a new version of a system? A new version of a software system should be accompanied by a document listing the changes from the previous version. The change list should include both enhancements and fixes to faults. Any faults that have not been fixed should also be named and described.
4. How many faults are detected each month, and how many are fixed? Faults are continuously detected during the operational use of the system. Comparing the number of detected and fixed faults helps to assess the stability of the latest release of the system. Tracking the number of faults also helps the program manager decide when to make a new release of the system.
5. What is the cause of the trouble report? Trouble reports can be categorized by their causes: violation of programming standards, inadequate user interface, or invalid, incorrect, or incomplete customer requirements. Sometimes, when it is discovered that many faults have a similar cause, action can be taken to improve the process and stop such faults from recurring.

Key information about the project and configuration items can be communicated to project members through status accounting. Software engineers can see what fixes or files were included in which baseline. Project managers can track completion of problem reports and various other maintenance activities. Minimal reports to be completed include transaction log, change log, and item "delta" report. Other typically common reports include resource usage, "stock status" (status of all configuration items), changes in process, and deviations agreed upon [Ben-Menachem 1994].

CONFIGURATION AUDITING

Configuration auditing (see Chapters 8 and 9) verifies that the software product is built according to the requirements, standards (see Chapter 12), or contractual agreement. Test reports and documentation are used to verify that the software meets the stated requirements. The goal of configuration audit is to verify that all software products have been produced, correctly identified and described, and that all change requests have been resolved according to established SCM processes and procedures. Informal audits are conducted at key phases of the software life cycle. There are two types of formal audits that are conducted before the software is delivered to the customer: functional configuration audit (FCA) and physical configuration audit (PCA).

FCA verifies that the software satisfies the software requirements stated in the System Requirements Specification and the Interface Requirements Specification. That is, the FCA allows one to validate the system against the requirements. The PCA determines whether the design and reference documents represent the software that was built. Configuration audit answers Does the system satisfy the requirements? and Are all changes incorporated in this version?

Configuration audit activities include:

• Defining audit schedule and procedures
• Identifying who will perform the audits
• Performing audits on the established baselines
• Generating audit reports

IMPLEMENTING SCM IN THE ORGANIZATION

One of the first steps in successfully implementing SCM is to obtain management sponsorship. This means public endorsement for SCM, and making sure the resources needed for success are allocated to the project. Management also needs to establish SCM as a priority and help facilitate implementation.

An organization can maintain management sponsorship by identifying and resolving risks, reporting progress, managing SCM implementation details, and communicating with all members of the organization.

The next step is to assess current SCM processes. Every organization that produces software is practicing some type of SCM. This may not be a formal process or even thought of as SCM. To assess current processes, one might ask the following questions: How are files identified? How are versions of software releases identified? How are baselines controlled? What files are included in each release? How are changes to the software identified and tracked?

After assessing your current processes, the next step is to analyze your requirements. What is it that your organization wants to accomplish? The requirement may be a specific level SW-CMM certification, ISO 9000 certification, some other standard or certification, or simply to improve your software process. Document the requirements for your organization, how you will implement them, and how you will measure success.

Depending on the requirements of your organization, the various roles and formality of the SCM team may differ . At a minimum there should be a point-of-contact for SCM. Other recommended roles and functions include:

• A control and review board should be in place to analyze and approve changes.
• Project managers and leaders also play a role in SCM in establishing or following an SCM plan (see Appendices A and T and Chapter 2) for their project, ensuring system requirements are properly allocated, ensuring adequate tools are available to support activities, and conducting regular reviews.
• A librarian is also necessary to track baselines and versions of files included in each release. An SCM tool can assist in those activities.
• Quality assurance (QA) can be used to verify that documented SCM processes and procedures are followed. QA is also necessary for SW-CMM Level 2 certification.

MANAGE THE RISKS OF SCM

With each new software project or process, there is some amount of associated risk. The same is true when implementing SCM. Whether an organization is implementing a whole new system or just updating a few processes, there will be risks that must be addressed. Note that having risk is not bad on the contrary, risk is a necessary part of SCM and the software development process.

Without risk, there is no opportunity for improvement. Risk-free SCM processes are typically of little use. The very nature of SCM requires risk-taking. Managing and controlling the risks associated with SCM is essential to the success of SCM processes in terms of cost, schedule, and quality.

It is always less expensive to be aware of and deal with risks than to respond to unexpected problems. A risk that has been analyzed and resolved ahead of time is much easier to deal with than one that surfaces unexpectedly [Guidelines 1996].

The Software Engineering Institute has developed a risk management program comprising six different activities, with communication being central to all of them. This program can be used when implementing SCM to effectively manage the associated risks. Risk management should be viewed as an important part of the SCM process. A brief summary of each activity follows [Paulk 1993]:

• Identify. Before risks can be managed, they must be identified. Identification surfaces risks before they become problems and adversely affect a project.
• Analyze. Analysis is the conversion of risk data into risk decision-making information.
• Plan. Planning turns risk information into decisions and actions (both present and future). Planning involves developing actions to address individual risk, prioritizing risk actions, and creating an integrated risk management plan.
• Track. Tracking consists of monitoring the status of risks and actions taken to ameliorate risks.
• Control. Risk control corrects for deviations from planned risk actions.
• Communicate. Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. Without effective communication, no risk management approach can be viable .

As part of an organization's risk management program, a plan should be developed that integrates the above outlined activities. An SCM risk management plan may focus on addressing risks in three areas: business, people, and technology [Burrows 1996]. The business risks include [Burrows 1996]:

• Cost. The expense to incorporate SCM encompasses far more than just the licensing fee for a tool. Management must be willing to make the necessary expenditures for people and resources.
• Culture shock . Each organization has its own culture, to which the success of the business can be attributed. The procedures and products implemented for SCM must match that culture. The person in charge of SCM needs a broad understanding of software engineering principles and the cultural aspects of the organization.
• Commitment. To establish a successful SCM process, there must first be a strong commitment from management. The benefits of SCM are not always immediately recognized. "Deploying CM can be a long, costly, and sometimes painful exercise. Counter this risk by building up steam in the project. Get momentum going quickly and keep feeding it."

The risks associated with people include [Burrows 1996]:

• Cheating. Software developers may try to incorporate their code into the final product without following procedures and resist any changes to the established procedures.
• Preferred tools. They may have a tool they want to use that is different from that of the organization. To mitigate these risks, try to get offenders to be part of the decision-making process. Let them have input into the procedures and tools that will be used.
• Resistance. The greatest barrier to overcome when SCM is introduced into an organization is to change how people view SCM. People generally react negatively toward it. In many organizations, SCM has a low status, and SCM personnel are not trained or qualified to perform their duties . Many software developers perceive SCM as intrusive and have little understanding of the longterm effects of not following SCM procedures. Communication, training, and developer input to SCM processes will help ensure SCM principles are adopted by an organization.

The last area is technology. The technology risks include [Burrows 1996]:

• Loss of control. At times, it may seem that the SCM procedures and tools are at the controls. There may also be reliance on tools where previously the needed data and information were obtained manually. Again, communication will help mitigate this risk. Management will have greater control over and information about their projects after successfully implementing SCM.
• Access. Controlling who can have access and make changes to various baselines, data repositories, software files, or documents is also a risk that must be managed. By thorough analysis and design, the procedures implemented may restrict access to approved individuals and give up-to-date information on many aspects of the project that is current and accurate.
• Scalability. A project has the potential to outgrow the implemented tool. Counter this risk by selecting a tool that will adapt to the changing size of your organization over time.

The secret to SCM risk management is to identify and resolve potential risks before they surface unexpectedly or become serious problems. Develop a program for identifying and managing risks. Incorporate an SCM risk management plan that addresses risks to business, people, and technology. Central to everything is communication. Communicate as much as possible to as many people and organizations as possible.

SUMMARY

Configuration management (CM) is the framework around which software engineering processes exist. It is interesting how there is almost a one-to-one relationship between the life-cycle activities of software engineering and those of configuration management.

CM is a carefully orchestrated set of activities that provides the organization and control required to manage an idea from its inception to its deployment. This chapter serves as an introduction to the remainder of the handbook. Now that the principles of CM are a bit more well- understood , we can delve into each of the component parts in more depth.

Note  

This chapter is based on the following governmental report: Software Technology Support Center, United States Air Force, Ogden Air Logistics Center, Software Configuration Management Technologies and Applications, April 1999, www.stsc.hill.af.mil.

REFERENCES

[ANSI/IEEE 1987] ANSI/IEEE Std 1042 “1987, American National Standard IEEE, Guide to Software Configuration Management , Institute of Electrical and Electronics Engineers, Inc., New York, 1988 .

[Ayer 1992] Ayer, Steve J. and Frank S. Patrinostro, Software Configuration Management: Identification, Accounting, Control, and Management , McGraw-Hill Software Engineering Series, McGraw-Hill, New York, 1992 .

[Babich 1986] Babich, Wayne A., Software Configuration Management: Coordination for Team Productivity , Addison-Wesley, Reading, MA, 1986 .

[Ben-Menachem 1994] Ben-Menachem, Mordechai, Software Configuration Management Guidebook , McGraw-Hill, New York, 1994 .

[Berlack 1992] Berlack, Ronald H., Software Configuration Management , John Wiley & Sons, New York, 1992 .

[Boehm 1981] Boehm, Barry, "Software Engineering Economics," Prentice-Hall, Englewood Cliffs, NJ, 1981 .

[Bounds 1996] Bounds, Nadine M. and Susan A. Dart, Configuration Management Plans: The Beginning to Your CM Solution , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, February 1996 .

[Bray 1995] Bray, Olin and Michael M. Hess, "Reengineering a Configuration Management System," IEEE Software , January 1995 .

[Buckley 1992] Buckley, Fletcher J., Implementing Configuration Management: Hardware, Software, and Firmware , IEEE Computer Society Press, Los Alamitos, CA, 1993 .

[Buckley 1994] Buckley, Fletcher J., "Implementing a Software Configuration Management Environment," IEEE Computer , 1994 .

[Butler 1995] Butler, Kelley L., "The Economic Benefits of Software Process Improvement," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, July 1995 .

[Burrows 96] Burrows, Clive, George W. George, and Susan Dart, Ovum Evaluates Configuration Management , Ovum Limited, London, U.K., 1996 .

[Burrows 1998] Burrows, Clive and Ian Wesley, Ovum Evaluates Configuration Management , Ovum Limited, London, U.K., 1998 .

[Carnegie 1998] Carnegie Mellon University and the Software Engineering Institute, "The '98 Software Engineering Symposium Preliminary Program," 1998 .

[Carr 1993] Carr, M., S. Kondra, I. Monarch, F. Ulrich, and C. Walker, Taxonomy-Based Risk Identification , Technical Report CMU/SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1996 .

[Conner 1982] Conner, Daryl R. and Robert W. Patterson, "Building Commitment to Organization Change," Training and Development Journal , 36 (4), 18 “30, April 1982 .

[Dart 1990a] Dart, Susan A., "Issues in Configuration Management Adoption," Proceedings of Conference on Caseware , Software Engineering Institute Overview, Carnegie Mellon University, Pittsburgh, PA, 1990 .

[Dart 1990b] Dart, Susan A., Spectrum of Functionality in Configuration Management Systems , Technical Report CMU/SEI-90-TR-11, ESD-90-TR-212, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990 .

[Dart 1992a] Dart, Susan A., "State-of-the-Art in Environment Support for Configuration Management," ICSE 14 Tutorial , Australia, Carnegie Mellon University, Pittsburgh, PA, May 1992 .

[Dart 1992b] Dart, Susan A., The Past, Present, and Future of Configuration Management , Technical Report CMU/SEI-92-TR-8, ESC-TR-92-8, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, July 1992 .

[Dart 1994] Dart, Susan A., "Adopting an Automated Configuration Management Solution," Proceedings of Software Technology Conference , April 1994 .

[Dart 1996] Dart, Susan, A., "Achieving the Best Possible Configuration Management Solution," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, September 1996 .

[DeGrace 1990] DeGrace, Peter and Leslie Hulet Stahl, "Wicked Problems, Righteous Solutions," A Catalogue of Modern Software Engineering Paradigms , Yourdon Press, Englewood Cliffs, NJ, 1990 .

[Evans 1997] Evans, Michael W. and Shawn T. O'Rourke, "CenterZone Management: he Relationship between Risk Management and Configuration Management in a Software Project," Proceedings of Software Technology Conference , April 1997 .

[Feiler 1991] Feiler, Peter H., Configuration Management Models in Commercial Environments , Technical Report CMU/SEI-91-TR-7, ESD-9-TR-7, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, March 1991 .

[Feiler 1990] Feiler, Peter H. and Grace Downey, Transaction-Oriented Configuration Management: A Case Study , Technical Report CMU/SEI-90-TR-23, ESD-90-TR-224, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, November 1990 .

[Firth 1987] Firth, Robert et al., A Guide to the Classification and Assessment of Software Engineering Tools , Technical Report CMU/SIE-87-TR-10, ESD-TR-87-111, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, August 1987 .

[Forte 1990] Forte, Gene, "Configuration Management Survey," CASE Outlook , 90 (2), 1990 .

[Fowler 88] Fowler, Pricilla and Stan Przybylinski, Transferring Software Engineering Tool Technology , IEEE Computer Society Press, Washington, D.C., 1988 .

[Guidelines 1996] Guidelines for Successful Acquisition and Management of Software-Intensive Systems: Weapon Systems, Command and Control Systems, Management Information Systems , Software Technology Support Center, Hill Air Force Base, UT, June 1996 .

[Haque 1997] Haque, Tani, "Process-Based Configuration Management: The Way to Go to Avoid Costly Product Recalls," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, April 1997 .

[Hermann 1998] Hermann, Brian and Jim Marshall, "Are You Ready to Deliver? To Ship? To Test?," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, August 1998 .

[Humphrey 1990] Humphrey, Watts S., Managing the Software Process , Addison-Wesley, Reading, MA, August 1990 .

[ICM 1998] Institute of Configuration Management, CMII Model, Course I, "CMII-Based Business Process Infrastructure," 1998 .

[IEEE 1990] IEEE Std 828 “1990, IEEE Standard for Software Configuration Management Plans, 1990 .

[Kasse 1997] Kasse, Tim, "Software Configuration Management for Project Leaders," Proceedings of Software Technology Conference , April 1997 .

[Kingsbury 1996] Kingsbury, Julie, "Adopting SCM Technology," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, March 1996 .

[Marshal 1995] Marshall, A.J., "Demystifying Software Configuration Management," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, May 1995 .

[Marshal 1995] Marshall, Alexa J., "Software Configuration Management: Function or Discipline?," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, October 1995 .

[MIL-HDBK-61 1997] MIL-HDBK-61, Military Handbook: Configuration Management Guidance , Department of Defense, Washington, D.C., Sept. 30, 1997 .

[Mosley 1995] Mosley, Vicky, "Improving Your Process for the Evaluation and Selection of Tools and Environments," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, September 1995 .

[Myers 1995] Myers, Robin J., "Configuration Management: A Prerequisite for BPR Success," Enterprise Reengineering, August 1995 .

[Olson 1993] Olson, Timothy G. et al., A Software Process Framework for the SEI Capability Maturity Model: Repeatable Level , Technical Report CMU/SEI-93-TR-7, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993 .

[Paulk 1993] Paulk, Mark C. et al., Key Practices of the Capability Maturity Model for Software, Version 1.1 , Technical Report CMU/SEI-93-TR-25, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993 .

[Paulk 1995] Paulk, Mark C., Charles V. Weber, Bill Curtis, and Mary Beth Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, October 1995 .

[Pence 1993] Pence, J.L. Pete and Samuel E. Hon, III, "Building Software Quality into Telecommunications Network Systems," Quality Progress , Bellcore, Piscataway, NJ, 95 “97, October 1993 .

[Pitts 1997] Pitts, David R., "Metrics: Problem Solved?," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, Dec. 1997

[ Platinum 1998] 1995 , 1998 PLATINUM Technology, Inc. All rights reserved. 1-800-442-6861, 630-620-5000, Fax: [phone], www.platinum.com .

[Rader 1993] Rader, Jack, Ed. J. Morris, and Alan W. Brown, An Investigation into the State-of-the-Practice of CASE Tool Integration , Technical Report CMU/SEI-93, Software Engineering Institute, Carnegie Mellon University, Pittsburg, PA, 1993 .

[Schamp 1995] Schamp, Alan, "CM-Tool Evaluation and Selection," IEEE Software , 1995 .

[Semiatin 1994] Semiatin, William J., "Evolution of Configuration Management," Program Manager: Journal of the Defense Systems Management College , November/December 1994 .

[Slomer 1992] Slomer, Howard M. and Alan M. Christie, Analysis of a Software Maintenance System: A Case Study , Technical Report CMU/SEI-92-TR-3, ESC-TR-92-031, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, November 1992 .

[Smith 1993] Smith, Dennis et al., Software Engineering Environment Evaluation Issues , Technical Report CMU/SEI-93, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, March 1993 .

[Softool 1992] Softool Corporation, Successful Software Strategies Seminar Series: Improving Your Configuration Management Implementation Strategy, Washington, D.C., 1992 .

[Starbuck 1997] Starbuck, Ronald A., "Software Configuration Management: Don't Buy a Tool First," CrossTalk, The DefenseJournal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, November 1997 .

[Starrett 1998] Starrett, Elizabeth C.L., "Measurement 101," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, August 1998 .

[STSC 1994] Software Technology Support Center, Software Configuration Management Technology Report , Software Technology Support Center, Hill Air Force Base, UT, September 1994 .

[Ventimiglia 1997] Ventimiglia, Bob, Advanced Effective Software Configuration Management , Technology Training Corporation, 1997 .

[Ventimiglia 1998] Ventimiglia, Bob, "Effective Software Configuration Management," CrossTalk, The Defense Journal of Software Engineering , Software Technology Support Center, Hill Air Force Base, UT, February 1998 .

[Wallnau 92] Wallnau, Kurt C., Issues and Techniques of CASE Integration with Configuration Management , Technical Report CMU/SEI-92-TR-5, ESD-TR-92-5, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, March 1992 .

[Whitgift 1991] Whitgift, David, Methods and Tools for Software or Software Configuration , John Wiley & Sons, New York, 1991 .

[Wreden 1994] Wreden, Nick, "Configuration Management: Getting with the Program," Beyond Computing , November/December 1994 .