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:

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:

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]:

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:

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]:

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:

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 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:

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:

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:

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]:

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]:

The risks associated with people include [Burrows 1996]:

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

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: 630-691-0718, 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 .

Related

Категории