Configuration Management

What is Software Configuration?

The software configuration is an instantaneous snapshot of the physical representation of the software and the software process at some point in time. This representation can take two forms:

• Non-executable material generated to document the software process or complement the program. (e.g. design document, test data/results, and review problems/suggestions).
• Executable material processed directly by a computer. (i.e. system codes).

What Does Software Configuration Management Mean?

Configuration management consists of three tasks:

• Establishment of a document identification scheme.

  Before any document can be controlled, a document identification scheme must be established in order to minimize the efforts required to keep track of the documents. The SCM identification task has the following objectives:

  • Define an organized documentation structure in an understandable, predictable manner.
    
  • Provide methods to accommodate revisions and aid in tracking those changes as they occur.
    
  • Correlate changes with "who, what, when, why, and how" to facilitate control
    

  The identification task begin with the list of deliverables required in the development process. The format, content, and control mechanisms (i.e. tools) for all documentation are defined to trace the project. Appropriate identifiers are assigned to all products, documents, and media, using a numbering scheme that is defined and understandable by all members of the project team. The numbering scheme must accommodate additions and modifications.

• Establishing Baseline

  Baslines are defined as points during the software life cycle at which configuration control is applied to a specific deliverable. As each baseline is reached, the appropriate numbering scheme is applied to the document and stored in the SCM library.

• Change Control - Evaluation and recording of all changes to the software configuration.

  When modifications to a baselined document is needed, change control is applied to preserve the integrity of the document. Once a document has been baselined, the document is added to the software library. A designated software librarian maintains all copies of documents under control. In order to make changes to a controlled document, the changes must be approved by the designated reviewer (often the project manager) before the document can be modified. If the changes have been approved, a new version of the document (with the changes in place) is created and put under control.

• Accurate tracking and controlled access to completed documents.

  The designated software librarian is reponsible for the accurate tracking and controlled access to documents under control. All change suggestions must be recorded and controlled, whether or not it is approved or not. Access to the completed documents are allowed only with the approval of the project manager. A check-out and check-in process must be in place in order to track accesses to the document.

Goals

• To establish a plan for managing the project artifacts.
• To establish a scheme for naming and identifying all configuration items.
• To establish procedures for controlling access and change of configuration items.
• To implement practices that inform all needed parties of changes in configuration items.
• To coordinate the baseline configuration.

Commitment to perform

Organizational Policy

An individual team member, the SCM manager, is assigned the responsibility for establishing the configuration management activities for the team.

Ability to Perform

The SCM group coordinates or implements:

1. Creation and management of the project's software baseline library.
2. Development, maintenance, and distribution of the SCM plans, standards, and procedures.
3. The identification of the set of work products to be placed under SCM.
4. Management of the access to the software baseline library.
5. Updates of the software baselines.
6. Creation of products from the software baseline library.
7. Recording of SCM actions.
8. Production and distribution of SCM reports.

Activities Performed

SCM plan is prepared for each software project according to a documented procedure. This procedure typically specifies that:

1. The SCM plan is developed in the early stages of, and in parallel with, the overall project planning.
2. The SCM plan is reviewed by the affected groups.
3. The SCM plan is managed and controlled.

A documented and approved SCM plan is used as the basis for performing the SCM activities. The plan covers:

1. The SCM activities to be performed, the schedule of activities, the assigned responsibilities, and the resources required (including staff, tools, and computer facilities).
2. The SCM requirements and activities to be performed by the software engineering group and other software-related groups.

This library system:

1. Supports multiple control levels of SCM.
2. Provides for the storage and retrieval of configuration items/units.
3. Provides for the sharing and transfer of configuration items/units between the affected groups and between control levels within the library.
4. Helps in the use of product standards for configuration items/units.
5. Provides for the storage and recovery of archive versions of configuration items/units.
6. Helps to ensure correct creation of products from the software baseline library.
7. Provides for the storage, update, and retrieval of SCM records.
8. Supports production of SCM reports.
9. Provides for the maintenance of the library structure and contents.

The software work products to be placed under configuration management are identified

1. The configuration items/units are selected based on documented criteria.

   Examples of software work products that may be identified as configuration items/units include:

   • process-related documentation (e.g., plans, standards, or procedures)
   • software requirements,
   • software design,
   • software code units,
   • software test procedures,
   • software system build for the software test activity,
   • software system build for delivery to the customer or end users,
   • compilers, and
   • other support tools.
2. The configuration items/units are assigned unique identifiers.
3. The characteristics of each configuration item/unit are specified.
4. The software baselines to which each configuration item/unit belongs are specified.
5. The point in its development that each configuration item/unit is placed under configuration management is specified.
6. The person responsible for each configuration item/unit (i.e., the owner, from a configuration management point of view) is identified.

Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved, and tracked according to a documented procedure.

Changes to baselines are controlled according to a documented procedure.

This procedure typically specifies that:

1. Reviews and/or regression tests are performed to ensure that changes have not caused unintended effects on the baseline.
2. Only configuration items/units that are approved by the SCCB are entered into the software baseline library.
3. Configuration items/units are checked in and out in a manner that maintains the correctness and integrity of the software baseline library.

Products from the software baseline library are created and their release is controlled according to a documented procedure.

This procedure typically specifies that:

1. The SCCB authorizes the creation of products from the software baseline library.
2. Products from the software baseline library, for both internal and external use, are built only from configuration items/units in the software baseline library.

The status of configuration items/units is recorded according to a documented procedure. This procedure typically specifies that:

1. The configuration management actions are recorded in sufficient detail so that the content and status of each configuration item/unit are known and previous versions can be recovered.
2. The current status and history (i.e., changes and other actions) of each configuration item/unit are maintained.

Standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected groups and individuals.

Software baseline audits are conducted according to a documented procedure. This procedure typically specifies that:

1. There is adequate preparation for the audit.
2. The integrity of software baselines is assessed.
3. The structure and facilities of the configuration management library system are reviewed.
4. The completeness and correctness of the software baseline library contents are verified.
5. Compliance with applicable SCM standards and procedures is verified.
6. The results of the audit are reported to the project software manager.
7. Action items from the audit are tracked to closure.

Measurement and analysis

Measurements are made and used to determine the status of the SCM activities.

Examples of measurements include:

• number of change requests processed per unit time;
• completions of milestones for the SCM activities compared to the plan; and
• work completed, effort expended, and funds expended in the SCM activities.

Verifying implementation

The SCM activities are reviewed with the instructor on a periodic basis.

The SCM manager periodically audits software baselines to verify that they conform to the documentation that defines them.

The software quality assurance group reviews and/or audits the activities and work products for SCM and reports the results.

Refer to the Software Quality Assurance key process area.

At a minimum, the reviews and/or audits verify:

1. Compliance with the SCM standards and procedures by:
   • the SCM group,
   • the SCCB,
   • the software engineering group, and
   • other software-related groups.
2. Occurrence of periodic software baseline audits.