Software Configuration Management

Jessica Keyes

• Publisher: Auerbach Publications
• Year: 2004
• eBook ISBN: 9781135492953
• Topic: Computer Science
• Subtopic: Information Technology
• Index: Computer Science

An effective systems development and design process is far easier to explain than it is to implement. A framework is needed that organizes the life cycle activities that form the process. This framework is Configuration Management (CM). Software Configuration Management discusses the framework from a standards viewpoint, using the original

1
INTRODUCTION TO SOFTWARE CONFIGURATION MANAGEMENT

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 an...

Table of contents

• COVER PAGE
• TITLE PAGE
• COPYRIGHT PAGE
• DEDICATION
• FOREWORD
• PREFACE
• 1. INTRODUCTION TO SOFTWARE CONFIGURATION MANAGEMENT
• 2. PROJECT MANAGEMENT IN A CM ENVIRONMENT
• 3. THE DoD CM PROCESS MODEL
• 4. CONFIGURATION IDENTIFICATION
• 5. CONFIGURATION CONTROL
• 6. CONFIGURATION STATUS ACCOUNTING
• 7. A PRACTICAL APPROACH TO DOCUMENTATION AND CONFIGURATION STATUS ACCOUNTING
• 8. CONFIGURATION VERIFICATION AND AUDIT
• 9. A PRACTICAL APPROACH TO CONFIGURATION VERIFICATION AND AUDIT
• 10. CONFIGURATION MANAGEMENT AND DATA MANAGEMENT
• 11. CONFIGURATION CHANGE MANAGEMENT
• 12. CONFIGURATION MANAGEMENT AND SOFTWARE ENGINEERING STANDARDS REFERENCE
• 13. METRICS AND CONFIGURATION MANAGEMENT REFERENCE
• 14. CM AUTOMATION
• APPENDIX A: PROJECT PLAN: ORSS SOFTWARE PROJECT PLAN
• APPENDIX B: DOD ENGINEERING CHANGE PROPOSAL
• APPENDIX C: SAMPLE DATA DICTIONARY
• APPENDIX D: PROBLEM CHANGE REPORT
• APPENDIX E: TEST PLAN
• APPENDIX F: PROGRAM CODE INSPECTION FORM
• APPENDIX G: SAMPLE INSPECTION PLAN
• APPENDIX H: QA HANDOVER DOCUMENT
• APPENDIX I: SYSTEM SERVICE REQUEST
• APPENDIX J: DOCUMENT CHANGE REQUEST (DCR)
• APPENDIX K: PROBLEM/CHANGE REPORT
• APPENDIX L: SOFTWARE REQUIREMENTS CHANGES
• APPENDIX M: PROBLEM REPORT (PR)
• APPENDIX N: CORRECTIVE ACTION PROCESSING (CAP)
• APPENDIX O: SPECIFICATION CHANGE NOTICE
• APPENDIX P: PROJECT STATEMENT OF WORK
• APPENDIX Q: PROBLEM TROUBLE REPORT (PTR)
• APPENDIX R: LIBRARY/BASELINE CHANGE FORM
• APPENDIX S: SAMPLE MAINTENANCE PLAN
• APPENDIX T: SOFTWARE CONFIGURATION MANAGEMENT PLAN (SCMP)
• APPENDIX U: ACRONYMS AND GLOSSARY: ACRONYMS
• APPENDIX V: FUNCTIONAL CONFIGURATION AUDIT (FCA) CHECKLIST
• APPENDIX W: PHYSICAL CONFIGURATION AUDIT (PCA) CHECKLIST
• APPENDIX X: SCM GUIDANCE FOR ACHIEVING THE “REPEATABLE” LEVEL ON THE SOFTWARE
• APPENDIX Y: SUPPLIER CM MARKET ANALYSIS QUESTIONNAIRE