Configuration Management Plan
Project name:
 Example
Owner:
 Sum Body Else
Modification date: yyyy/mm/dd
   
Checkpoint documents: Other documents:
 
 

 
Description:

The document is the configuration management plan. It should be possible to use without additional effort or modification unless the configuration management issues and needs are more challenging.  This document describes the overall configuration management goals, artifacts, processes and tools for the project. 
 
Configuration Management Introduction:

The intent for configuration management within the organization is to serve as part of the basic software engineering practices that ensure our smooth and effective operation.  This really involves a few key goals (drawn from HP Corporate Engineering's SEI/CMM documents):

Goals

  1. Configuration management activities are planned.
  2. Selected work products are identified, controlled, and available.
  3. Changes to identified work products are controlled.
  4. Affected groups are informed of the status and content of base lines. 
Interpretation
  • There is a plan.  (This document)
  • Individuals are given responsibility.
  • We track and record changes between release versions.
  • Version control includes the key artifacts: code, test cases, documentation, etc.
  • We make sure that our source code base stays consistent.
  • We can recreate and/or restore any version.
Artifacts:

The key artifacts of a project should be under configuration management:
 
area
artifacts
daily / 
ongoing
check-
points
version release
Development 
artifacts
  • Source code (.c  .cpp)
  • Header files (.h)
  • Images, bitmaps (.bmp)
  • Icons (.ico)
  • Installation package definition
suggested required required
Generated 
artifacts
  • Executable code (.exe .dll)
  • Generated object code (.o)
  • Installation package
suggested required
Planning 
documents
  • Project data sheet
  • Project plan
  • Quality plan
  • Requirements
  • Checkpoint slides and documentation
required required
Custom 
development 
tools
  • Build and Make scripts
  • Project files
  • Custom development tools
  • Custom tool configuration 
  • Commercial tool configuration 
suggested required
Testing
  • Test files & scripts
  • Test harness (tool) sources
  • Test harness (tool) executable 
  • Release test results
  • Active defect lists
optional required
Documentation
  • Help files
  • Frequently asked questions (FAQs)
  • Reference documentation
  • Other user documentation
required
Commercial development 
tools
  • Development tools
  • Tool configuration info & files
optional

The assumption is that commercial development tools will have the original software media and don't require versioning.  This also assumes that the organization system administrator or an identified team member will be the official keeper of the commercial tools media and related patches and update media.  If the tools are acquired without media (i.e. the web), then a CD-ROM or other physical archive of the tools will be created.
 
Processes:

 
Project start
  • A team member will be identified as the official SCM coordinator.
  • An SCM tool will be identified for the project.
  • An SCM structure will be defined for the project.
  • The coordinator will define the appropriate level of privileges for the team.  (Things like file/directory deletion, creation of new directories and users.)
  • The team members will receive adequate instruction on the selected tool.
On-going / daily
  • The team will do normal check-out's and check-ins of the files under configuration management. 
  • If a file is kept open for more than a day, the file should be checked in at least once a day, unless it would break the build.
  • All file check-in's will include a meaningful comment.
System build
  • All files will be checked in and unlocked.
  • The files used in the build will be tagged with an appropriate intermediate label.
Checkpoint
  • The SCM coordinator will check (audit) the SCM system status.
  • The SCM coordinator will check (audit) that all the appropriate artifacts are under configuration management.
  • The organization system administrator will archive the complete project information (including the SCM information).
Version release
  • The SCM coordinator will include an SCM status report as part of the formal release documentation.
  • The files used in the release will be tagged with an appropriate final release label.

 
SCM Tools:

The project will use commercial off-the-shelf SCM tools.
 
Other:

Subcontractors: 

When dealing with subcontractors, the SCM coordinator will ensure that they are using adequate SCM techniques, tools and processes.
 
  Template Modified: 19990716            Template Author: Tim Mikkelsen