Operation and maintenance:Configuration management

Configuration management

80.1 Purpose

The purpose of configuration management is to define, manage, control, and audit the changes made to the original system. This chapter considers configuration management personnel and planning, configuration control, and configuration auditing, and reporting.

80.2 Strengths, weaknesses, and limitations

As appropriate, the strengths and weaknesses associated with specific tools or techniques will be discussed in context.

80.3 Inputs and related ideas

System control tools and techniques are covered in Chapter 77. Performance analysis is discussed in Chapter 78, and maintenance is discussed in Chapter 81. Queuing theory (Chapter 79) can be used to perform bottleneck analysis. Virtually all the documentation created during the systems analysis (Part IV), design (Part VI), testing, and implementation (Part VII) stages of the system development life cycle might be relevant to configuration management.

80.4 Concepts

The purpose of configuration management is to define, manage, control, and audit the changes made to the original system. Typical enhancements might include adding new features, adjusting operation procedures, changing execution priorities, fixing bugs, and modifying the original system to accommodate new hardware or software.

80.4.1 Personnel

Many organizations assign change authorization responsibility to a configuration approval board chaired by the chief information officer (or a similar high-level information system manager) and composed of representatives from the user, the developers, the maintainers, and other systems professionals. The board reviews change requests and proposed adaptive and perfective maintenance tasks, authorizes work to begin, and schedules the work. Depending on the project, individual managers, supervisors, or project leaders assign the necessary resources, delegate responsibilities, and monitor progress. The developers and maintainers are responsible for actually performing the work. On some smaller projects, the developers and maintainers perform the management functions.

80.4.2 Planning

The first step in the process is to establish a configuration management plan. The responsible developers and maintainers must be identified and a budget defined. Additionally, steps must be taken to ensure that the appropriate tools and documentation are available.

The configuration items, a set of resources to support configuration management, are collected during this phase. There is no universally accepted standard list; the configuration items are a function of the maintenance project and are subject to time and budget constraints. Typically, system specifications (both generic and detailed), design specifications (logical and physical), manuals (user, operation, command, and system), program code listings, and testing, operation, and execution plans, standards, and procedures are all included. Additionally, such post-release materials as problem and error reports, maintenance requests, change requests, and maintenance standards and procedures might be considered configuration items.

The configuration items are used to define configuration objects, concrete tools that can be used to support the change process. Examples include documents and reports, test cases, input data sets, tools used to build the system, and source code. Also, such parameters as exploded objects, meta-objects, derived objects, imported objects, exported objects, source objects, and detailed processing requirements help to define the relationships between the various configuration entities.

Configuration management standards help to enforce quality, increase productivity, facilitate the management process, and reduce misinterpretation. Three well-known U.S. Government Department of Defense guidelines are MIL-STD-483, DOD-STD-480A, and MIL-STD-1521A. Additionally, software quality assurance standards are applied to configuration management.

80.4.3 Configuration control

A key responsibility of configuration management is to keep track of changes (e.g., new features, upgrades, bug fixes, etc.). A system is composed of numerous interrelated subsystems and/or programs. Each time a subsystem or program is changed, a new version of the system is created. Because the subsystems are interrelated, it is essential that the active version be carefully controlled. For example, a change intended for version 2 may not work or may introduce serious ripple effects if it is incorporated directly into version 3.

80.4.3.1 Establishing a baseline

The term baseline comes from surveying. It refers to an initial line that serves as a reference point for all other measurements. In configuration management, the baseline is typically defined as an outcome or milestone of system development; for example, the version of the system on which the final system test is performed might serve as the initial baseline. All changes are made relative to the baseline.

80.4.3.2 Version control

The objective of version control is to track and manage multiple versions of the system and its components. As a minimum, version control should maintain for each system, subsystem, and/or program a production version, the most recently changed version, and a test version. Additionally, many organizations maintain a repository library of historical versions. The most recently changed version (which presumably worked) serves as back-up in the event of problems with the production version. Changes are made only to the test version. After a change (or set of changes) has been thoroughly tested, the test version becomes the production version and a new test version is initiated.

Often, multiple non-emergency changes are accumulated over time, incorporated in the test version, and released at regular intervals. For example, a university might accumulate changes throughout the first semester, freeze the new version (Section 80.4.3.3) on the day the semester ends, test the new version over the semester break, and release the new version to production at the start of the next semester. Note that once the system is released, no additional changes are permitted to the production version until the next release cycle. The result is a stable, dependable production system. Also, grouping changes makes it easier to identify ripple effects and helps to ensure that the documentation is updated to reflect the changes. Limiting changes to a scheduled release cycle can cause the system to lag behind technological breakthroughs, however.

80.4.3.3 Freezing the system

Before the changes are implemented, the test system is frozen. The freezing process involves archiving the entire system, including the executable programs, data files, source code, and related documentation. The usual practice is to store the archived file on a back-up medium, such as magnetic tape. Should the system fail or become unstable when the changes are made, the archive can be used to reestablish the pre-change version.

80.4.3.4 Benchmarks

At the time the system is frozen, benchmark measurements (execution time, response time, and the like) should be taken for the system. The idea is to establish concrete parameters for measuring baseline performance. Unless the system’s pre-change performance is known, there is no way to measure the effect of the change.

80.4.3.5 Regression testing

Once the changes are made, the system must be tested. Unit test all affected programs or components. Then system test the application. Finally, perform regression tests to measure how the change affected response time and other standard performance metrics. The benchmark measurements taken on the baseline is the key to regression testing. The idea is to prove that the old and new versions of the system are functionally equivalent.

80.4.3.6 Establishing a new baseline

After the changes have been implemented and thoroughly tested, the new version is submitted to the configuration approval board. After approval is granted, the production system is frozen, the new version of the test system becomes the production system, and a new baseline (the old production system or the new production system, depending on the configuration management standards in use) is established.

80.4.4 Configuration auditing and reporting

The purpose of configuration auditing is to ensure that the approved changes (and only the approved changes) have been implemented. The auditing process reviews all the changes, investigates any conflicts or ripple effects, and looks for omissions or violations of configuration management standards. An audit can be performed after all changes are implemented, but intermediate audits following important changes are a good idea. The purpose of configuration reporting is to ensure that the changes are broadcast so that everyone involved with the system is aware of the new version.

80.5 Key terms

Adaptive maintenance —

Maintenance activities intended to enhance the system by adding features, capabilities, and functions in response to new technology, upgrades, new requirements, or new problems.

Baseline —

An initial line that serves as a reference point for all other measurements; an established version of the system that serves as a reference point for future changes.

Benchmark —

A set of performance measurements for the baseline.

Configuration approval board —

A committee that reviews change requests and proposed adaptive and perfective maintenance tasks, authorizes work to begin, and schedules the work.

Configuration audit —

An audit intended to ensure that the approved changes (and only the approved changes) have been implemented.

Configuration item —

A resource that supports configuration management.

Configuration management —

The process of defining, managing, controlling, and auditing the changes made to the original system.

Configuration object —

A concrete tool that can be used to support the change process.

Configuration reporting —

The process of broadcasting (or reporting) the changes so that everyone involved with the system is aware of the new version.

Freeze —

To archive the entire system, including the executable programs, data files, source code, and related documentation, prior to making a change.

Perfective maintenance —

Maintenance activities intended to enhance the system by improving efficiency, reliability, functionality, or maintainability, often in response to user or system personnel requests.

Regression test —

A test designed to measure how a change to a system affects response time and other standard performance metrics.

Version control —

A set of tools and procedures used to track and manage multiple versions of the system and its components.

80.6 Software

Numerous configuration management and version control software packages are commercially available. Examples include CMVC (Configuration Management Version Control) from IBM, PVCS from Intersolv, SPARCworks/TeamWare from Sun Microsystems, STS/CM (Configuration Management) from Neuma Technology Corporation, VCS-UX Version Control System from Diamond Optimum Systems, Inc., and Visual SourceSafe from Microsoft. QVCS (Quma Version Control System) is a shareware product. This list is by no means complete, nor does it constitute an endorsement.

80.7 References

1.  Arthur, L. J., Software Evolution: The Software Maintenance Challenge, John Wiley & Sons, New York, 1988.

2.  Burch, J. G., Systems Analysis, Design, and Implementation, Boyd & Fraser, Boston, MA, 1992.

3.  Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.

4.  Dewitz, S. D., Systems Analysis and Design and the Transition to Objects, McGraw-Hill, New York, 1996.

5.  Fournier, R., Practical Guide to Structured System Development and Maintenance, Prentice-Hall, Englewood Cliffs, NJ, 1991.

6.  Hoffer, J. A., George, J. F., and Valacich, J. S., Modern Systems Analysis and Design,Benjamin/Cummings, Reading, MA, 1996.

7.  Lamb, D. A., Software Engineering: Planning for Change, Prentice Hall, Englewood Cliffs, NJ, 1988.

8.  Norman, R. J., Object-Oriented Systems Analysis and Design, Prentice-Hall, Upper Saddle River, NJ, 1996.

9.  Power, M. J., Cheney, P. H., and Crow, G., Structured Systems Development: Analysis, Design, Implementation, 2nd ed., Boyd & Fraser, Boston, MA, 1990.

10.  Pressman, R. S., Software Engineering: A Practitioner’s Approach, 2nd ed., McGraw-Hill, New York, 1987.