<D PREFIX>-<Proj/Ver>-CMP-001

<D_PREFIX>-<Proj/Ver>-CMP-001

<Month Day, Year>

This document was produced by <Company_Name> for internal use only; this document may not be reproduced or used, in whole or in part, outside <Company_Name>without permission from the company.

Document History

Customization Information

Delete this section and table when you are done. Don't delete the section break after the table.

<D_PREFIX>-<Proj/Ver>-CMP-001Configuration Management Plan for <Project> v<Version<Month Day, Year>

Table of Contents

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Updates to This Plan

2. Related Documents

2.1. Customer Documents

2.2. <Company_Name> Documents

2.3. <Acronym> v<Version>–Developed Documents

2.4. Resources and Templates

3. Stakeholder Responsibilities

3.1. Program Manager

3.2. Project Manager

3.3. CM Group

3.4. Quality Assurance Group

3.5. Engineering Group

3.6. Developmental Configuration and Control Board

3.7. Customer Configuration Management Group

4. Configuration Management

4.1. CM Activity Planning

4.1.1. CM Tools

4.2. Establishing a Project Library System

4.2.1. Project Configuration

4.2.2. Change Management Data

4.3. Identifying Configuration Items

4.3.1. Accepting Configuration Items

4.3.2. Configuration Baselines

4.3.3. Creating and Releasing Baselines

4.4. Controlling Changes to the Project Baseline

4.4.1. Software Change Requests

4.4.2. Bug Reports

4.4.3. Related Document Changes

4.4.4. Emergency Updates and Patches

4.4.5. Changes Based on Peer Review Results

4.5. Maintaining Baseline Integrity

4.5.1. History and Status of Configuration Items

4.5.2. Configuration Audits

4.5.3. Disaster Recovery and Backups

4.6. Reporting CM Status

Appendix A. Acronyms and Abbreviations

List of Figures

Figure 41. Change request process

Figure 42. Bug report process

List of Tables

Table 41. Project CM tools

Table 42. Methods for introducing CIs into a baseline

Table 43. Major configuration baselines

Table of Contents1

<D_PREFIX>-<Proj/Ver>-CMP-001Configuration Management Plan for <Project> v<Version<Month Day, Year>

1.Introduction

1.1.Purpose

This document describes the configuration management (CM) roles, responsibilities, and activities to be performed during the <Project> (<Acronym>) v<Version> lifecycle. It has been developed in accordance with <Company_Name> standard processes and policies written for the implementation, throughout the organization, of sound CMpractices.

1.2.Scope

This document encompasses the CM activities in each phase of the project. This is the primary planning document for CM activities.

1.3.Updates to This Plan

Revision to the document will be made on an annual basis or as neededto reflect significant changes in project scope or process improvement recommendations from the Software Engineering Process Group (SEPG). The document history page will be updated to reflect changes to this plan.

The project manager, in coordination with the customer if appropriate, will be the approval authority for any changes to this document. The project manager will coordinate all document changes and reviews with technical writers and the Quality Assurance (QA) group to ensure that updates are managed in accordance with <Company_Name> engineering policies. Baseline versions of this document will be maintained in the project library as described in this plan.

4. Configuration Management1

<D_PREFIX>-<Proj/Ver>-CMP-001Configuration Management Plan for <Project> v<Version<Month Day, Year>

2.Related Documents

The following documents are related to the <Acronym> v<Version> project and to this document.

2.1.Customer Documents

<!>

2.2.<Company_Name> Documents

• Configuration Management Policy
• Configuration Management Process. This process includes the Change Management Process.

2.3.<Acronym> v<Version>–Developed Documents

• Project Practices and Procedures for <Project> (<D_PREFIX>-<Acronym>-PPP)
• Project Management Plan for <Project> v<Version> (<D_PREFIX>-<Proj/Ver>-PMP)
• Software Development Plan for <Project> v<Version> (<D_PREFIX>-<Proj/Ver>-SDP)
• Quality Assurance Plan for <Project> v<Version>(<D_PREFIX>-<Proj/Ver>-QAP)
• Measurement and Analysis Plan for <Project> v<Version>(<D_PREFIX>-<Proj/Ver>-MAP)

2.4.Resources and Templates

The following items are available in the <Company_Name>Business Process System and will form the basis for some of the work products described in this plan.

• Build Reporter template
• CM Baseline Audit template

4. Configuration Management1

<D_PREFIX>-<Proj/Ver>-CMP-001Configuration Management Plan for <Project> v<Version<Month Day, Year>

3.Stakeholder Responsibilities

The <Acronym> v<Version> project comprises personnel from different <Company_Name> management, engineering, and support groups. A project organizational chart is available in the Project Management Plan. The members of each group, including the CM group, are appointed by the project manager.

3.1.Program Manager

The program manager, along with other senior managers, has the following CM responsibilities:

• Adherence to <Company_Name> policy
• Allocation of staff and tools to perform CM activities

3.2.Project Manager

The project manager is responsible for directing the implementation of CM policies and processes throughout the project lifecycle. This includes:

• Implementing the <Company_Name> software engineering and management policies and procedures
• Appointing and managing the CM group
• Appointing and managing the Developmental Configuration and Control Board (DCCB)
• Directing the creation of this configuration management plan
• Identifying configuration items
• Coordinating adequate and standardized CM methods and tools training for each member of the CM and Engineering groups
• Managing change requests and problem reports pertaining to configuration items
• Ensuring that measurements are used to determine and monitor the status of CM activities
• Reviewing CM activities according to the project schedule and as warranted by project events

3.3.CM Group

The CM group is responsible for executing CM activities throughout the project's lifecycle. This includes:

• Drafting this plan for the project manager's review and approval
• Establishing a CM library
• Controlling changes to baselines
• Creating and controlling product releases and deliveries
• Recording the status of configuration items
• Developing reports on CM activities
• Auditing software baselines and ensuring that they conform to product documentation
• Making measurements to determine the status of CM activities

3.4.Quality Assurance Group

The QA group will periodically audit CM activities against the Project Practices and Procedures and convey the results to the project team and the SEPG.

3.5.Engineering Group

The Engineering group is responsible for performing some CM activities in accordance with this plan and the Software Development Plan. They include:

• Providing work products that have been designated as configuration items to the CM group
• Assisting as needed in the development of this plan

3.6.Developmental Configuration and Control Board

The DCCB is established by the project manager to oversee an organized process for managing changes to the project's baseline. The DCCB meets as necessary to discuss the impact of change requests and problem reports. Within the DCCB, the project manager is the final approval authority for whether a change will be implemented. The DCCB ensures that the impacts of proposed changes are analyzed, considered, and documented.

3.7.Customer Configuration Management Group

The project CM group, under the oversight of the project manager, will coordinate delivery of software and related work products with the CM group for the project's customer, namely <Customer> (<Cust_Abbrev>).

4. Configuration Management1

<D_PREFIX>-<Proj/Ver>-CMP-001Configuration Management Plan for <Project> v<Version<Month Day, Year>

4.Configuration Management

The project manager will appoint a CM group, which is responsible for performing or assigning the activities described in this plan except where otherwise noted. CM work is done in accordance with the Project Practices and Procedures.

4.1.CM Activity Planning

The project manager will review this document with the CM group and the QA group and will ultimately approve it. The activities described here will be included in project estimates, schedule, budget, Project Management Plan, and Software Development Plan. Additionally, the project manager will ensure that the members of the CM group have been trained in <Company_Name> and project CM procedures and tools.

4.1.1.CM Tools

The project manager will ensure that CM tools required for the project are available for use. These tools are listed in Table 41.

Table 41. Project CM tools

4.2.Establishing a Project Library System

The CM group is responsible for maintaining a project configuration and change management data.

4.2.1.Project Configuration

Project data management directories will be set up by the CM group.

• Documentation developed by this project will be maintained in <Doc_Control_Tool(<DCT_Abbrev>) using the directory structure and access controls described the Project Management Plan.
• Code developed by this project will be maintained in <Source_Control_Tool(<SCT_Abbrev>)using the directory structure described in the Software Development Planand the access controls described in the Project Management Plan. System builds, when the development is sufficiently mature, will be done from these directories in order to create testable system versions.

4.2.2.Change Management Data

The project change management system will track change requests and problem reports (bugs).

• Change requests will be entered and tracked in <Cr_Tracking_Tool>. The CM group will set up the tool by adding the necessary project and version information.
• Bugs will be entered and tracked in <Bug_Tracking_Tool>. Again, the CM group will set up the tool with project-specific parameters.

4.3.Identifying Configuration Items

The CM group will consider the following classes of items to be configuration items (CI) that will be maintained in the configuration management systems described in Section 4.2.

• Code written by or used by the project and necessary for a full system build. Specific files will be identified by the Engineering group during product integration.
• Deliverable documents. A list of deliverable documents is in the P1 document.
• Specifications describing the <Acronym> v<Version> application. This includes requirements, design, and architecture descriptions.
• Background documents or other information necessary to support the project. This includes customer communications, reports, schedule, metrics, and other information.

An item designated as a CI and placed under CM control becomes part of a baseline, as described in subsection 4.3.2. No two CIs in the same baseline may have the same name.

4.3.1.Accepting Configuration Items

CIs entering configuration control may be new or may be updates to existing CIs. (The types of changes are discussed in Section 4.4.)

In the case of an updated CI, the change may be minor or major. The CM group is responsible for determining the first case—whether the CI is new. The project manager will determine whether a change is major or minor. If the change is based on peer review results, the peer review record will classify changes as major or minor. If the change is based on a <Cr_Tracking_Tool> ticket, that ticket must be completed.

CIs also fall into two primary types: software files, including data files and build scripts; and documentation.

Table 42 describes the way CIs enter the project baseline under these various conditions.When ticket completion or comments are required, the primary purpose is to pair the reason for the submission or change (e.g., requirement implementation, change request, bug report) with the affected CIs.

Table 42. Methods for introducing CIs into a baseline

4.3.2.Configuration Baselines

A baseline is a set of formally reviewed work products that serves as the basis for further development or delivery and that can only be changed via change control procedures.

Table 43 lists the major baselines planned for this project; however, there may be any number of intermediate baselines between major baselines. By definition, each baseline serves as the input or starting baseline for the next phase of development. The initial Planning Baseline uses the project statement of work as its input.

Table 43. Major configuration baselines

• Project plans
• Estimates, schedule

• Allocated requirements
• Interface specifications

• System design documentation
• Allocated requirements

• Source code files

• Build procedures
• Modified source code
• System test cases
• Test results
• User documentation

• Test results, bugs
• Software change requests

4.3.3.Creating and Releasing Baselines

The project manager will ask the CM group to build the software at certain points during development. The configuration library at that point will be labeled with version/baseline identification.

The CM group is responsible for testing the build procedures and scripts for completeness and validity in builds generated from the configuration library. Only builds based on the configuration library will be considered valid for testing or delivery.

The project manager will coordinate product delivery to the customer with the CM group.

4.4.Controlling Changes to the Project Baseline

Changes to the project baseline must be authorized. The means of change authorization, tracking, and implementation and are described in this section. Note that these processes apply only to baselined work products except where noted.

4.4.1.Software Change Requests

Software change requests are requests by the customer or a project team member for an enhancement or other alteration to the current application or design. They are not bug reports in that they do not describe something contrary to or in error versus current requirements.

The program or project manager will enter customer change requests in <Cr_Tracking_Tool>. A project team member may also enter a change request in <Cr_Tracking_Tool>.

The project manager will assign a team member to review the change request and analyze its impact. This analysis will be recorded in the change request in <Cr_Tracking_Tool>. The analysis should include a list of documentation that would be affected if the change is implemented.

Prior to the establishment of the test baseline (see Table 43), the project manager may approve the change request without the involvement of the DCCB. After the test baseline is established, however, DCCB review and approval is required before a change request is implemented. The CM group acts as recording secretary to the DCCB and updates change requests with the DCCB's actions.

If a change request is approved for implementation, a software developer is assigned to make the change. Assignment indicates an authorization for the developer to perform the required work. Once the software files have been updated, the developer will perform informal testing of the change. The updated files will be submitted to the configuration library. Following the next formal build, the Test group will verify that the change has been correctly and properly implemented, and will close the change request.

The developer assigned to implement the change request is also responsible for updating associated design documentation. The project manager will ensure that other affected documentation, including requirements, test cases, and user documents, are also updated by project team members.New and updated work products are submitted to the baseline as described in subsection 4.3.1.

The change request tracking and implementation process is shown in Figure 41.<!<This Visio diagram is included with your download. Update it to reflect your CR tool's phases and flow.>

Figure 41. Change request process

4.4.2.Bug Reports

Bug reports describe a problem in the software that is counter to approved requirements or design. Bug reports are tracked and handled separately from change requests.

The program or project manager will enter problem reports from the customer in <Bug_Tracking_Tool>. A project team member may also enter a bug in <Bug_Tracking_Tool>.