Level 2 - Software Configuration Management

Software Configuration Management

a key process area for level 2: Repeatable


The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle.

Software Configuration Management involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g., the software requirements document and the code) and the items that are identified with or required to create these software products (e.g., the compiler).

A software baseline library is established containing the software baselines as they are developed. Changes to baselines and the release of software products built from the software baseline library are systematically controlled via the change control and configuration auditing functions of software configuration management.

This key process area covers the practices for performing the software configuration mangement function. The practices identifying specific configuration items/units are contained in the key process areas that describe the development and maintenance of each configuration item/unit.

Goals

Goal 1

Software configuration management activities are planned.

Goal 2

Selected software work products are identified, controlled, and available.

Goal 3

Changes to identified software work products are controlled.

Goal 4

Affected groups and individuals are informed of the status and content of software baselines.

Commitment to perform

Commitment 1 -- The project follows a written organizational policy for implementing software configuration management (SCM).

This policy typically specifies that:
  1. Responsibility for SCM for each project is explicitly assigned.
  2. SCM is implemented throughout the project's life cycle.
  3. SCM is implemented for externally deliverable software products, designated internal software work products, and designated support tools used inside the project (e.g., compilers).
  4. The projects establish or have access to a repository for storing configuration items/units and the associated SCM records.
    The contents of this repository are referred to as the "software baseline library" in these practices.

    The tools and procedures for accessing this repository are referred to as the "configuration management library system" in these practices.



    Work products that are placed under configuration management and treated as a single entity are referred to as configuration items.

    Configuration items are typically decomposed into configuration components, and configuration components are typically decomposed into units. In a hardware/software system, all of the software may be considered as a single configuration item, or the software may be decomposed into multiple configuration items. In these practices the term "configuration items/units" is used to refer to the elements under configuration management.


  5. The software baselines and SCM activities are audited on a periodic basis.

Ability to perform

Ability 1 -- A board having the authority for managing the project's software baselines (i.e., a software configuration control board - SCCB) exists or is established.

The SCCB:
  1. Authorizes the establishment of software baselines and the identification of configuration items/units.
  2. Represents the interests of the project manager and all groups who may be affected by changes to the software baselines.
    Examples of affected groups include:
    • hardware quality assurance,
    • hardware configuration management,
    • hardware engineering,
    • manufacturing engineering,
    • software engineering (including all subgroups, such as software design),
    • system engineering,
    • system test,
    • software quality assurance,
    • software configuration management,
    • contract management, and
    • documentation support.

  3. Reviews and authorizes changes to the software baselines.
  4. Authorizes the creation of products from the software baseline library.

Ability 2 -- A group that is responsible for coordinating and implementing SCM for the project (i.e., the SCM group) exists.


A group is the collection of departments, managers, and individuals who have responsibility for a set of tasks or activities. A group could vary from a single individual assigned part time, to several part-time individuals assigned from different departments, to several individuals dedicated full time. Considerations when implementing a group include assigned tasks or activities, the size of the project, the organizational structure, and the organizational culture. Some groups, such as the software quality assurance group, are focused on project activities, and others, such as the software engineering process group, are focused on organization-wide activities.


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.
    A work product is any artifact from defining, maintaining, or using a software process.


  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.

Ability 3 -- Adequate resources and funding are provided for performing the SCM activities.

  1. A manager is assigned specific responsibilities for SCM.
  2. Tools to support the SCM activities are made available.
    Examples of support tools include:
    • workstations,
    • database programs, and
    • configuration management tools.

Ability 4 -- Members of the SCM group are trained in the objectives, procedures, and methods for performing their SCM activities.


Examples of training include:
  • SCM standards, procedures, and methods; and
  • SCM tools.

Ability 5 -- Members of the software engineering group and other software-related groups are trained to perform their SCM activities.


Examples of other software-related groups include:
  • software quality assurance, and
  • documentation support.


Examples of training include:
  • the standards, procedures, and methods to be followed for SCM activities performed inside the software engineering group and other software-related groups; and
  • the role, responsibilities, and authority of the SCM group.

Activities performed

Activity 1 -- A 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.
    "Managed and controlled" implies that the version of the work product in use at a given time (past or present) is be known (i.e., version control), and changes are incorporated in a controlled manner (i.e., change control).

    If a greater degree of control than is implied by "managed and controlled" is desired, the work product can be placed under the full discipline of configuration management, as is described in this key process area.


Activity 2 -- 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.

Activity 3 -- A configuration management library system is established as a repository for the software baselines

This library system:
  1. Supports multiple control levels of SCM.
    Examples of situations leading to multiple levels of control include:
    • differences in the levels of control needed at different times in the life cycle (e.g., tighter control as product matures),
    • differences in the levels of control needed for software-only systems vs. systems which include both hardware and software.

  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.
    Examples of library maintenance functions include:
    • backup/restoring of library files, and
    • recovery from library errors.

Activity 4 -- 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.

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

Activity 6 -- 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.
    Examples of check-in/out steps include:
    • verifying that the revisions are authorized,
    • creating a change log,
    • maintaining a copy of the changes,
    • updating the software baseline library, and
    • archiving the replaced software baseline.

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

Activity 8 -- 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.

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


Examples of reports include:
  • SCCB meeting minutes,
  • change request summary and status,
  • trouble report summary and status (including fixes),
  • summary of changes made to the software baselines,
  • revision history of configuration items/units,
  • software baseline status, and
  • results of software baseline audits.

Activity 10 -- 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

Measurement 1 -- 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

Verification 1 -- The SCM activities are reviewed with senior management on a periodic basis.


The primary purpose of periodic reviews by senior management is to provide awareness of and insight into software process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.



Refer to Verification 1 of the Software Project Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.


Verification 2 -- The SCM activities are reviewed with the project manager on both a periodic and event-driven basis.


Refer to Verification 2 of the Software Project Tracking and Oversight key process area for practices covering the typical content of project management oversight reviews.


Verification 3 -- The SCM group periodically audits software baselines to verify that they conform to the documentation that defines them.

Verification 4 -- 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.

[^^]Table of contents [->]Back one chapter

page d'accueil

contact

 

menu precedent
Acknowledgements
SEI CMM Key Practices - Overview
Introduction
CMM Overview
Using the Key Practice Pages
Interpreting the CMM
Level 2 - Requirements Management
Level 2 - Software Project Planning
Level 2 - Software Project Tracking and Oversight
Level 2 - Software Subcontract Management
Level 2 - Software Quality Assurance
Level 2 - Software Configuration Management
Level 3 - Organization Process Focus
Level 3 - Organization Process Definition
Level 3 - Training Program
Level 3 - Integrated Software Management
Level 3 - Software Product Engineering
Level 3 - Intergroup Coordination
Level 3 - Peer Reviews
Level 4 - Quantitative Process Management
Level 4 - Software Quality Management
Level 5 - Defect Prevention
Level 5 - Technology Change Management
Level 5 - Process Change Management
Appendix A: References
Appendix B: Glossary
Appendix C: Abridged Key Practices
Appendix D: Change History

 

 

contact

<-- precedent ] page d'accueil ] menu precedent ] suite --> ]

FREE, la liberté n'a pas de prix !  antoine@apple2.com 29-04-2000