General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
engineering graphic
white space
engineering
Engineering
CERT Coordination Center
COTS-Based Systems
Integration of Software-Intensive Systems
Performance-Critical Systems
Predictable Assembly from
Certifiable Components (PACC)
Information Repositories
Team & Personal Software Process
Product Line Practice
Software Architecture Technology
Software Engineering Measurement
& Analysis (SEMA)
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
pixel
Rollover Popup Hints for Topic Navigation Buttons above
pixel
CM Plans Appendix B: Outline of a Model CM Plan



from Configuration Management Plans: The Beginning to your CM Solution
1.0 INTRODUCTION
    1.1 Purpose
    1.2 Scope
    1.3 Definitions
    1.4 References
    1.5 Tailoring
2.0 SOFTWARE CONFIGURATION MANAGEMENT

    2.1 SCM organization

    2.2 SCM responsibilities

    2.3 Relationship of CM to the software process life cycle

      2.3.1 Interfaces to other organizations on the project

      2.3.2 Other project organizations CM responsibilities

3.0 SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES

    3.1 Configuration Identification

      3.1.1 Specification Identification

      • Labeling and numbering scheme for documents and files
      • How identification between documents and files relate
      • Description of identification tracking scheme
      • When a document/file identification number enters controlled status
      • How the identification scheme addresses versions and releases
      • How the identification scheme addresses hardware, application software system software, COTS products, support software (e.g., test data and files), etc.
      3.1.2 Change Control Form Identification

      • Numbering scheme for each of the forms used
      3.1.3 Project Baselines

      • Identify various baselines for the project
      • For each baseline created provide the following information:
        • How and when it is created
        • Who authorizes and who verifies it
        • The purpose
        • What goes into it (software and documentation)
      3.1.4 Library

      • Identification and control mechanisms used
      • Number of libraries and the types
      • Backup and disaster plans and procedures
      • Recovery process for any type of loss
      • Retention policies and procedures
        • What needs to be retained, for who, and for how long
        • How is the information retained (on-line, off-line, media type and format)
    3.2 Configuration Control

      3.2.1 Procedures for changing baselines (procedures may vary with each baseline)

      3.2.2 Procedures for processing change requests and approvals-change classification scheme

      • Change reporting documentation
      • Change control flow diagram
      3.2.3 Organizations assigned responsibilities for change control

      3.2.4 Change Control Boards (CCBs) - describe and provide the following information for each:

      • Charter
      • Members
      • Role
      • Procedures
      • Approval mechanisms
      3.2.5 Interfaces, overall hierarchy, and the responsibility for communication between multiple CCBs, when applicable

      3.2.6 Level of control - identify how it will change throughout the life cycle, when applicable

      3.2.7 Document revisions - how they will be handled

      3.2.8 Automated tools used to perform change control

    3.3 Configuration Status Accounting

      3.3.1 Storage, handling and release of project media

      3.3.2 Types of information needed to be reported and the control over this information that is needed

      3.3.3 Reports to be produced (e.g., management reports, QA reports, CCB reports) and who the audience is for each and the information needed to produce each report

      3.3.4 Release process, to include the following information:

      • What is in the release
      • Who the release is being provided to and when
      • The media the release is on
      • Any known problems in the release
      • Any known fixes in the release
      • Installation instructions
      3.3.5 Document status accounting and change management status accounting that needs to occur

    3.4 Configuration Auditing

      3.4.1 Number of audits to be done and when they will be done (internal audits as well as configuration audits); for each audit provide the following:

      • Which baseline it is tied to, if applicable
      • Who performs the audit
      • What is audited
      • What is the CM role in the audit, and what are the roles of other organizations in the audit
      • How formal is the audit
      3.4.2 All reviews that CM supports; for each provide the following:

      • The materials to be reviewed
      • CM responsibility in the review and the responsibilities of other organizations

4.0 CM MILESTONES

  • Define all CM project milestones (e.g., baselines, reviews, audits)
  • Describe how the CM milestones tie into the software development process
  • Identify what the criteria are for reaching each milestone

5.0 TRAINING

  • Identify the kinds and amounts of training (e.g., orientation, tools)

6.0 SUBCONTRACTOR/VENDOR SUPPORT

  • Describe any subcontractor and/or vendor support and interfacing, if applicable



forward back [Table of Contents] scm home


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2007 by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/legacy/scm/papers/CM_Plans/CMPlans.AppendixB.html
Last Modified: 11 January 2007