Software configuration management plan

Before you go into the details, you might want to add a front page and some revision history.

Remember, the following is an example template for the layout of an SCM plan. Use it as an aid in creating your SCM plan and as you see fit. You decide the level of detail that you want to put into the plan.

Template

1. Introduction

The introduction of the Software Configuration Management Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Software Configuration Management Plan.

1.1. Purpose

Here you specify the purpose of this Software Configuration Management Plan.

1.2. Scope

This subsection provides a brief description of the scope of this Software Configuration Management Plan; what model it is associated with, and anything else that is affected by or influenced by this document.

1.3. Definitions, Acronyms, and Abbreviations

This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Configuration Management Plan. This information may be provided by reference to the project’s Glossary.

1.4. References

This subsection provides a complete list of all documents referenced elsewhere in the Software Configuration Management Plan. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.

1.5. Overview

This subsection describes what the rest of the Software Configuration Management Plan contains and explains how the document is organized.

2. The SCM framework

2.1. Organization, Responsibilities, and Interfaces

Describe who is going to be responsible for performing the various Software Configuration Management (SCM) activities described in the SCM Process Workflow.

2.2. Tools, Environment, and Infrastructure

Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle.

Describe the tools and procedures required used to version control configuration items generated throughout the project or 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.

2.3. Administration and maintenance

Describe the backup and recovery strategies for the SCM implementation.

Describe miscellaneous tasks and procedures to be used for the administration and maintenance of your SCM installation, including license management and installation/upgrade processes.

3. The SCM process

3.1. Configuration Identification

3.1.1. Identification Methods and Naming Convention

Describe how project or product artifacts are to be named, marked, and numbered. The identification scheme needs to cover hardware, system software, Commercial-Off-The-Shelf (COTS) products, and all application development artifacts listed in the product directory structure; for example, plans, models, components, test software, results and data, executables, and so on.

3.1.2. Workspace Management

The workspace is where developers edit source files, build the software components they are working on, and test and debug what they have built. We can say that the workspace is a development area associated with a change.

Describe view and/or work area policies, types, naming conventions, and storage locations.

3.1.3. Project Baselines And Branching Strategies

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 or 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 the end of iterations within the various phases or even more frequently.

Describe who authorizes a baseline and what goes into it.

3.1.4. Promotion Model

The promotion model provides guidelines for when development work should be promoted into release or integration branches once development is completed. It also provides guidelines for when and how developers should synchronize their work with the recommended baseline.

3.2. Configuration and Change Control

3.2.1. Change Request Processing and Approval

Describe the process by which problems and changes are submitted, reviewed, and dispositioned. This should include the workflow diagrams for the different workflows used for the different development phases.

3.2.2. Change Control Board (CCB)

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

3.3. Configuration Status Accounting

3.3.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—online, offline, media type, and format.

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

3.3.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 or product lifecycle.

Reporting on defects based on change requests may provide some useful quality indicators and, thereby, alert management and developers to 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 they are fixed?

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

Trend (Time-related and Count-related Reports): What is the cumulative number of defects 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?

4. Milestones

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

5. Training and Resources

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

6. Subcontractor and Vendor Software Control

Describe how software developed outside of the project environment will be incorporated.