Artifact: CM Plan

CM Plan	The CM Plan describes all CM related activities to be performed during the course of the product/project lifecycle.   It details the schedule of activities, the assigned responsibilities, and the required resources (including staff, tools and computer facilities).
Worker:	Configuration Manager
Template:	Word template
Purpose Brief Outline Timing Responsibility

Purpose

The purpose of the CM Plan is to define, or reference, the steps and activities that describe how Configuration and Change Control Management (CM) is to be performed in the development of a software product.

Brief Outline

1. Objectives

A brief description of the purpose of the Configuration Management Plan

2. Scope

A brief description of what the Configuration Management Plan applies to; what is affected or influenced by this document.

3. References

A list of related or referenced documents.

1. Organization, Responsibilities and Interfaces

Describe who is going to be responsible for performing the various CM activities described in the CM Process Workflow.

2. Tools, Environment and Infrastructure

Describe the computing environment and software tools to be utilized in fulfilling the CM functions throughout the project/product life cycle.

Describe the tools and procedures required used to version control configuration items generated throughout the project/product lifecycle.

Issues involved in setting up the CM environment include:

• Anticipated size of product data
• Distribution of the product team
• Physical location of servers and client machines

1. Identification Methods

Describe how project/product artifacts are to be named, marked and numbered. The identification scheme needs to cover hardware, system software, COTS products and all application development artifacts listed in the product directory structure (e.g. plans, models, components, test software, results and data, executables, etc.).

2. Project Baselines

Baselines provide an official standard on which subsequent work is based, and to which only authorized changes are made.

Describe at what points during the project/product lifecycle baselines are to be established. The most common baselines would be at the end of each of the Inception, Elaboration, Construction and Transition phases. Baselines could also be generated at ends of iterations within the various phases or even more frequently.

Describe who is to authorize a baseline, and what is to go into it.

2. Configuration and Change Control

1. Change Request Processing and Approval

Describe the process by which problems and changes are submitted, reviewed and dispositioned.

2. Change Control Board (CCB)

Describe the membership and procedures for processing change requests and approvals to be followed by the CCB.

3. Configuration Status Accounting

1. Project Media Storage and Release Process

Describe retention policies, and the back-up, disaster and recovery plans. Also describe how the media is to be retained (on-line, off-line, media type and format).

The release process should describe what is in the release, who it is for, whether there are any known problems, and what are the installation instructions.

2. Reports and Audits

Describe the content, format and purpose of the requested reports and configuration audits.

Reports are used to assess the ‘quality of the product’ at any given time of the project/product lifecycle. Reporting on ‘defects’ based on change requests can provide some useful quality indicators and thereby alert management and developers on particularly critical areas of development. Defects are often classified by criticality (high, medium and low) and could be reported on the following basis:

Aging (Time Based Reports): How long have defects of the various kinds been open? What is the ‘lag time’’ of when in the lifecycle defects are found, versus when are they being fixed?

Distribution (Count Based Reports): How many defects are there in the various categories by owner, priority or state of fix?

Trend (Time and Count Related Reports): What is the cumulative number of defects being found and fixed over time? What is the rate of defect discovery and fix? What is the ‘quality gap’ in terms of open versus closed defects? What is the average defect resolution time?

6. Milestones

Identify the internal and customer milestones related to the project/product CM effort. This section should include details on when the CM Plan itself is to be updated.

7. Training and Resources

Describe the software tools, personnel and training required to implement the specified CM activities.

8. Subcontractor and Vendor Software Control

Describe how software developed outside the project environment is to be incorporated.

Timing

The CM Plan is written early on in the project/product lifecycle once funding has been approved for the project to proceed. It should be re-visited at the end of each phase and updated accordingly. The CM Plan needs to be archived such that it is available for post-deployment maintenance activities for guidance on where certain software assets might be stored.

Responsibility

The Worker: Project Manager is responsible for the integrity of the CM Plan, ensuring that it:

• covers the activities to be performed,
• the schedule of activities,
• the assigned responsibilities, and
• the required resources (staff, tools, environment and infrastructure)