State of Michigan

(Insert System or Project Name Here)

Software Configuration Management Plan
General Information
System or Project
ID/Acronym:

Creation Date:

Client Agency:

Modification Date:

Author(s):

DTMB Authorized
by:

Privacy Information
This document may contain information of a sensitive nature. This information
should not be given to persons other than those who are involved with this
system/project or who will become involved during its lifecycle.

Change Control
Revision
Date

Author

Section(s)

Software Configuration Management Plan 1 of 18

Summary

SEM-0302 (Rev. 07/2012)

1. Introduction
This Software Configuration Management (SCM) Plan specifically addresses
configuration management for software. Configuration management for hardware,
telecom, operating systems, and other components managed by Infrastructure
Services are addressed by the DTMB Information Technology Infrastructure Library
(ITIL) Process and Procedures.

1.1 Purpose
The purpose of Software Configuration Management (SCM), in general, is to
establish and maintain the integrity of work products using:

Configuration
Configuration
Configuration
Configuration

Identification
Control
Status Accounting
Audit

A Configuration Item (CI) is an entity designated for configuration management,

which may consist of multiple related work products that form a baseline. This
logical grouping provides ease of identification and controlled access. The selection
of work products for configuration management should be based on criteria
established during planning. Section 3 of this SCM Plan contains detailed
information about CIs.
Configuration Identification
The purpose of Configuration Identification is to define the functional and physical
characteristics of a CI in sufficient detail so that it may be developed, tested,
evaluated, produced, competitively procured, accepted, operated, maintained, and
supported. Configuration Identification is established by baselines plus approved
changes. For purposes of this SCM Plan, Configuration Identification includes the
selection, creation, and specification of the following:

Products that are delivered to the client

SEM documents requiring Structured Walkthroughs (SWT)

Configuration Control
The process of evaluating, approving or disapproving, and managing changes to
controlled items. This includes tracking the configuration of each of the CIs,
approving a new configuration if necessary, and updating the baseline.
Configuration Status Accounting
The process of creating and organizing the information necessary for the

Software Configuration Management Plan 2 of 18

SEM-0302 (Rev. 07/2012)

performance of configuration management. An element of configuration

management consisting of the recording and reporting of information needed to
manage a configuration effectively. This information includes a listing of the
approved configuration identification, the status of proposed changes to the
configuration, and the implementation status of approved changes.
Configuration Audit
Audits are conducted to verify that a CI, or a collection of CIs that make up a
baseline, conforms to a specified standard or requirement. This includes functional
and physical configuration audits.

1.2 Objectives
This SCM Plan defines the configuration management policies and procedures
required for this project. This plan has been developed early in the lifecycle to
ensure the control of changes as soon as the project requirements are approved.
This plan addresses activities that are platform independent, such as identifying the
items that will be placed under configuration management. As the project
progresses through the lifecycle stages, the plan is expanded to reflect platform
specific activities.
Changes in this system affecting other SCM plans are identified and explained in
Section 2 (Software Configuration Management Resources) and Section 3 (Software
Configuration Management Tasks) of this plan.

1.3 References
Listed here are policies, procedures and standards used in preparing and setting up
this SCM Plan.

State of Michigans System Engineering Methodology (SEM)

2. Software Configuration Management Resources

This section identifies the roles of individuals and groups that participate in the SCM
process. It describes the relationships between individuals and groups.

2.1 Roles and Responsibilities

Only the responsibilities related to SCM are listed here.

Software Configuration Management Plan 3 of 18

SEM-0302 (Rev. 07/2012)

2.1.1 Project Manager (PM)

Establish the overall project schedule for SCM activities with Configuration
Management Manager (CMM)
Make sure team members are knowledgeable of SCM concepts and
techniques and that they are applied to project activities
Ensure compliance with the SCM standards and procedures set by the CMM,
the Configuration Control Board (CCB), and any other affected groups as
outlined in this plan

2.1.2 Configuration Management Manager (CMM)

The project CMM will prepare the SCM Plan with assistance from the Project
Manager. The CMM is responsible for creating and/or updating the SCM Plan, as well
as communicating the contents of the plan to the project team.
Responsibilities
SCM Planning

Identify the Configuration Items (CIs) to be managed under the SCM

processes
Create, manage and maintain the SCM Plan, standards, and procedures
Communicate any changes to the SCM Plan, standards, and procedures to all
stakeholders
Make sure that all project team members involved in the SCM process receive
training on their roles
Make updates to the SCM Plan, as appropriate
Make sure that any updates to the SCM Plan are communicated to the
appropriate project team members
Form and lead a SCM Team
Approve changes to the SCM Plan

Implementing Changes

Participate as a member of the Configuration Control Board (CCB)

Create SCM products (baselines, application environments), as authorized by
the CCB
Process and track software change requests
Function as the point of contact with Infrastructure Services to analyze
proposed changes and to insure interoperability between hardware and
software components

Tracking, Reporting and Audits

Software Configuration Management Plan 4 of 18

SEM-0302 (Rev. 07/2012)

Make sure that configuration item change requests and problem reports for
all CIs are initiated, recorded, reviewed, approved, and tracked according to
the SCM Plan
Ensure all Functional and Physical Configuration Audits are performed
Respond to requests for status regarding SCM activities from managers and
auditors

2.1.3 Configuration Control Board (CCB)

Responsibilities

Monitor changes and updates to project requirements

Authorize the establishment of baselines and the identification of CIs
Ensure that all approved changes and updates to CIs are placed under
configuration control
Use the SCM Plan as its primary decision-making resource
Support and provide input to Local Change Board (LCB) and Enterprise
Change Board (ECB) functions related to the DTMB Service Management
Center Request for Change (RFC) process
Review and authorize changes to the baselines
Attend regularly scheduled meetings
Review and discuss new change requests
Prioritize change requests
Authorize research on change requests
Approve the commencement of work on change requests (make active)
Review the status of active change requests
Create and communicate minutes from the CCB to affected groups

Roles
Members

Roles

System Owner

Representative from customer agency

with decision making authority

DTMB Project Manager (PM)

Project Manager for the application

system

DTMB Application Development Functional

Manager(s)

Development Manager(s)

Configuration Management Manager (CMM)

Service Provider

2.1.4 Local Change Board (LCB)

Responsibilities

Authorize changes to the system

Software Configuration Management Plan 5 of 18

SEM-0302 (Rev. 07/2012)

Verify that any changes with statewide impact are marked for Enterprise
Change Board (ECB) approval

Roles
Members

Roles

DTMB Agency Services (AS) Client Service

Director (CSD)

Stakeholder

DTMB Application Development Functional

Manager(s)

Development Manager(s)

DTMB Client Support Specialist

Client Support

DTMB Infrastructure Specialist

Agency Services Support

Configuration Management Manager (CMM)

Service Provider

2.1.5 Enterprise Change Board (ECB)

Responsibilities

Ensure changes do not adversely affect other systems

Authorize changes to the systems

Roles
The ECB is primarily staffed with DTMB Infrastructure representatives. Attendance
at ECB meetings by the local staff will vary depending on the scope of the change.
Typically only one or two of the following will attend.
Members

Roles

DTMB Agency Service (AS) Client Service

Director (CSD)

Stakeholder

DTMB Application Development Functional

Manager(s)

Development Manager(s)

DTMB Client Support Specialist

Client Support

DTMB Infrastructure Specialist

Agency Services Support

Configuration Management Manager (CMM)

Service Provider

Subject Matter Expert(s) (SME)

Subject Matter Expert(s)

2.2 Resource Assignments

3. Software Configuration Management Tasks

Software Configuration Management Plan 6 of 18

SEM-0302 (Rev. 07/2012)

This section consists of the following:

Identification of Configuration Items

Configuration Items
Baseline Identification
Repository Identification
Configuration Item Identifier

3.1 Identification of Configuration Items

The terms Configuration Identification and Configuration Item are defined in Section
1.1 of this document.
In this SCM Plan, work products are considered for configuration management based
on the following criteria. A work product is any tangible item that results from a
project function, activity or task.

May be used by one or more work groups

Are expected to change over time either because of errors or change of
requirements
Are dependent on each other in that a change in one mandates a change in
another/others
Are critical to the project

Items in the following categories are selected to be placed under configuration

management:

Project Management documentation, including Project Plan and Project

Charter
SEM documentation, including all deliverables, Structured Walkthroughs
(SWT), Stage Exit Position Response form
Models
Interfaces
Process descriptions
Product/Application data such as lookup tables, system files
Source code and executable code
Test scripts
Test data
Metrics, status reports, quality review reports, etc.
Support tools, including compilers, editors, testing tools
Touch Point documentation including EA solution documents, Infrastructure
Services Request (DTMB-0184), and Security Plan and Assessment (DTMB0170)

Software Configuration Management Plan 7 of 18

SEM-0302 (Rev. 07/2012)

3.2 Configuration Items (CIs)

The following table contains CIs that are included in this SCM Plan.
Configuration
Items

Description/S
UITE Form

Responsible for
placing item under
control

When item is put

under control

Project Charter

PMM-0002

Project Manager

Initiation & Planning

Stage Exit

Project Plan

PMM-0003

Project Manager

Initiation & Planning

Stage Exit

Security Plan

DTMB-0170

OES Liaison

Initiation & Planning

Stage Exit

Software
Configuration
Management Plan

SEM-0302

CM Manager

Initiation & Planning

Stage Exit

Maintenance Plan

SEM-0301

DTMB Analyst/CM
Manager

Initiation & Planning

Stage Exit

Requirements
Specification

SEM-0402

Business Owner

Requirements Stage
Exit

Requirements
Traceability Matrix

SEM-0401

Project Manager/DTMB
Analyst

Requirements Stage
Exit

EA Solutions
Assessment

SEM Touch Point

Project Manager/DTMB
Analyst

Requirements Stage
Exit

Infrastructure
Services Request
(ISR)

SEM Touch
Point, DTMB0184

Project Manager/DTMB
Analyst

Requirements Stage
Exit

Hosting Solution

SEM Touch Point

Project Manager/DTMB
Analyst

Requirements Stage
Exit

Functional Design

SEM-0501

Business Owner/Project
Manager/DTMB Analyst

Functional Design
Stage Exit

Conversion Plan

SEM-0601

Project Manager/DTMB
Analyst

System Design Stage

Exit

Test Plan

SEM-0602

Business Owner/Test
Manager

System Design Stage

Exit

Test Type Approach

and Report (multiple)

SEM-0603

Business Owner/Test
Manager

System Design Stage

Exit

System Design

SEM-0604

Project Manager/DTMB
Analyst

System Design Stage

Exit

System Design
Checklist

SEM-0605

Project Manager/DTMB
Analyst

System Design Stage

Exit

Test Case (multiple)

SEM-0606

Project Manager/DTMB
Analyst

System Design Stage

Exit

Transition Plan

SEM-0701

Project Manager/DTMB
Analyst

Construction Stage
Exit

Installation Plan

SEM-0702

Project Manager/DTMB
Analyst

Construction Stage
Exit

Software Configuration Management Plan 8 of 18

SEM-0302 (Rev. 07/2012)

Configuration
Items

Description/S
UITE Form

Responsible for
placing item under
control

When item is put

under control

Training Plan

SEM-0703

Business Owner

Construction Stage
Exit

Training Plan
checklist

SEM-0704

Business Owner

Construction Stage
Exit

Release Notes

Word/Excel

Project Manager/DTMB
Analyst

Implementation Stage
Exit

Post Implementation
Evaluation Report

PMM-0016

Business Owner/Project
Manager/DTMB Analyst

Implementation Stage
Exit

Request for Change

(RFC)

SEM Touchpoint,
SMC website

Project Manager/DTMB
Analyst

Construction Stage
Exit

Structured
Walkthrough Meeting
Record

SEM-0187

Business Owner/Project
Manager/DTMB Analyst

All Stages

Defect Tracking Log

(or equivalent)

SEM-0186 (or
equivalent)

Project Manager/DTMB
Analyst

All Stages

Stage Exit Approvals

SEM-0189

Business Owner/Project
Manager/DTMB Analyst

All Stages

Project Charter

PMM-0002 EXP

Project Manager

Initiation,
Requirements &
Design Stage Exit

Project Plan

PMM-0003 EXP

Project Manager

Initiation,
Requirements &
Design Stage Exit

Initiation,
Requirements and
Design Plan

SEM-0001 EXP

Business Owner/Project
Manager/DTMB Analyst

Construction &
Testing Stage Exit

Construction and
Testing Plan

SEM-0002 EXP

Business Owner/Project
Manager/DTMB Analyst

Construction &
Testing Stage Exit

Post Implementation
Evaluation Report

PMM-0016 EXP

Business Owner/Project
Manager/DTMB Analyst

Implementation Stage
Exit

C/JAVA Code
(Example)

Application
Source Code

Developer

Initial unit test

Database Stored
Procedures

Database
Source Code

DBA

Initial unit test

Cobol Compiler
(Example)
File Editor (Example)

Support Tools

Infrastructure

After received from

vendor

Graphics/Images

User Interface
Elements

Graphic Designer

Initial unit test

3.3 Baseline Identification

Software Configuration Management Plan 9 of 18

SEM-0302 (Rev. 07/2012)

In this SCM Plan, a software baseline is created by the identification and labeling of
CIs at a specific point in time. A baseline represents the current approved
configuration.

3.4 Repository Identification

3.5 Configuration Item Identifier

Configuration Item Identifiers are used to label all of the CIs that make up a
particular grouping such as an application release, a project development phase or
documentation changes.
This identification scheme preserves all of the files that are used to create each
release and exactly which versions of those files were used. This scheme works for
the application installations and then for subsequent upgrades.
Identifiers are used to label the documentation deliverables in a project. For
instance, at the end of the system design stage, all of the approved deliverables will
be labeled and preserved for future reference. After the completion of the project,
many of the deliverables will need to be updated to reflect changes to the
application. Those deliverables are assigned identification labels so that their
current state can be identified and preserved for future reference.
The following tables show how identifiers are assigned to files and baselines.
Examples 1 and 2 show sample baseline release configuration identification labeling
schemes using these abbreviations for baseline (BL), major (mm), minor (nn), and
revision (rr).
Example 1
Environment

Identification Scheme

Development

N/A

Unit Test

SFSweb.TST.BL.mm.nn.rr

User Acceptance Testing (UAT)

SFSweb.UAT.BL.mm.nn.rr

Production

SFSweb.PRD.BL.mm.nn.rr

Example 2
Environment

Identification Scheme

Development

DEV.BL.00001 through DEV.BL.99999

Test region

TST.BL.00001 through TST.BL.99999

UAT

UAT.BL.00001 through UAT.BL.99999

Production

PRD.BL.00001 through PRD.BL.99999

Software Configuration Management Plan 10 of 18

SEM-0302 (Rev. 07/2012)

Table 1 shows three different schemes for identifying documents. The software
change request number, document identifies (see Table 2 below), and a status
indicator (Initial (I), Final (F)) are used in combination to form an item scheme.
Table 1
Document Name

Document description

S123.PP.I.doc

Change Request S123 Project Plan Initial

PP.F.S123.doc

Project Plan Final Change Request S123

F.PP.S123.doc

Final Project Plan Change Request S123

Table 2
Document Identifiers

Document CI description

PP

Project Plan

PMC

Project Management Charter

SEC

Security Plan

SCM

Software Configuration Management Plan

MAIN

Maintenance Plan

REQ

Requirements Specification

REQT

Requirements Traceability Matrix

INFRA

EA Solutions Assessment

INFRAR

Infrastructure Request

DESN

Functional Design

HOST

Hosting Solution

CONV

Conversion Plan

TESTP

Test Plan

TTAR

Test Type Approach and Report

SYSD

System Design Document

SYSCH

System Design Checklist

TRAN

Transition Planning

INSTP

Installation Plan

TRAIN

Training Plan

TRAINCH

Training Plan Checklist

IRDEXP

Initiation, Requirements and Design for

Express

CTEXP

Construction and Testing for Express

RELEASE

Release Notes

RFC

Request for Change Document

PIER

Post Implementation Evaluation Report

Software Configuration Management Plan 11 of 18

SEM-0302 (Rev. 07/2012)

4. Software Configuration Control

The term Configuration Control is defined in Section 1.1 of this document. Software
Configuration Control includes the following objectives:

Procedures for changing baselines

Change requests approvals
Responsibilities for change control
Change control process
Request for Change process
Level of control
Management of release documentation
Configuration control tools and techniques

4.1 Procedures for Changing Baselines

Activities performed in the SCM Plan for processing changes include:

Defining the information needed for approving the requested change

Identifying the review process and how communication of information is
completed

4.2 Change Requests and Approvals

This SCM Plan contains documented procedures for originating change requests,
enforcing the flow of the change process, capturing CCB decisions, and reporting
change process information. Included in this SCM Plan is a prioritization process for
software change requests.
The software change request process in this SCM Plan requires the use of supporting
tools and procedures. Basic tools used in this SCM Plan are:

Remedy flow and procedures

Rational software
Serena Team Track
Microsoft Excel
Microsoft Word

4.3 Change Control Process

The purpose of the CCB/LCB is to control changes that impact schedule, function,
and the configuration of the system as a whole.

Software Configuration Management Plan 12 of 18

SEM-0302 (Rev. 07/2012)

The change control processes described in this SCM Plan include the following
activities:

Providing direction of the entire configuration management effort

Resolving all problems and situations that arise during the effort
Using the SCM Plan as its primary decision-making resource
Taking into account organizational management considerations for decision
making
Initiating and controlling all activities from the beginning to the approval of
the baselines for SCM establishment
Making decisions on which products should be baselined or managed, the
methods to be used, and the order in which they should be done

4.4 Request for Change (RFC) Process

This SCM Plan supports the DTMB RFC process. The Configuration Management
Manager (CMM) is responsible for ensuring that all LCB and ECB processes are
followed.

4.5 Level of Control

Control of CIs varies depending on environment, action, and responsible party. The
following tables define appropriate levels of control:
Development Environment
Action

Control

Check in Source Code

Developers, Librarians

Promote Source Code

Automatic when checked in

Check in Project Documentation

Project Manager, Developers, Librarians

Check in Application Documentation

Project Manager, Developers, Librarians

System Test Environment

Action

Control

Check in Source Code

Check in to system test not allowed

Authorize Code Promotion to system test

CCB

Promote Source Code to system test

Librarian

Define Release

CCB

Authorize Baseline Label

CCB

Label Baseline

Librarian

Authorize Environment Build

CCB

Build Environment

Technical Operations

Software Configuration Management Plan 13 of 18

SEM-0302 (Rev. 07/2012)

User Acceptance Test (UAT) Environment

Action

Control

Check in Source Code

Check in to UAT not allowed

Authorize Code Promotion to UAT

CCB

Promote Source Code to UAT

Librarian

Define Release

CCB

Authorize Baseline Label

CCB

Label Baseline

Librarian

Authorize Environment Build

CCB

Build Environment

Technical Operations

Production Environment
Action

Control

Check in Source Code

Check in to production not allowed

Define Release

CCB

Authorize Baseline Label

CCB

Label Baseline

Librarian

Authorize Environment Build

CCB

Build Environment

Technical Operations

4.6 Management of Release Documentation

The following documents are required for the release to production:

Installation Plan (including a backout plan)

Release notes
Updated user documentation
Training materials

4.7 Configuration Control Tools and Techniques

These SCM processes use a basic tool set to manage access to the repositories, to
process change requests and to report status. The basic tool set includes:

Basic database management systems

Report generators
Means for maintaining separate dynamic and controlled repositories
File system for managing the check in and check out of units, for controlling
compilations, and capturing the resulting products

Software Configuration Management Plan 14 of 18

SEM-0302 (Rev. 07/2012)

Specific tools include:

Infrastructure Configuration Management Build Application

Remedy
Issue Tracker
Oracle Repository
Serena Version Manager

The tools listed in this SCM Plan provide support to the Configuration Control and
Release processes.

5. Configuration Status Accounting

The term Configuration Status Accounting is defined in Section 1.1 of this
document. Configuration Status Accounting has the following objectives in this SCM
Plan:

Maintain records of the configuration status of all entities that have been
placed under configuration control at the project level or higher
Maintain records for the life of the project
Produce reports that include the current version, revision, or release status of
each CI, a record of changes to the CI since it was placed under configuration
control, and the status of problem reports and change requests that affect
the CI

6. Configuration Audits and Reviews

The term Configuration Audit is defined in Section 1.1 of this document.
This SCM Plan ensures successful completion of functional and physical audits and
is used as a prerequisite for the establishment of the product baseline in the initial
SCM process. It is used throughout the project for the review of SCM processes and
the audit of the configuration repository.
The functional audit determines whether the CI satisfies the functions defined in the
specifications. The physical audit determines that all items identified as part of
system configuration are present in the product baseline. Sections 6.1 and 6.2
describe how these audits are used.

6.1 Functional Configuration Audits

The SUITE Key Terms and Acronyms document defines a Functional Configuration
Audit (FCA) as, An inspection to determine whether the (software) configuration
item satisfies the functions defined in the specifications. Consists of someone
Software Configuration Management Plan 15 of 18

SEM-0302 (Rev. 07/2012)

acknowledging having inspected or listed each item to determine it satisfies the

functions defined in specifications.
The Configuration Management Manager (CMM) is responsible for ensuring that a
FCA is performed. Results of the completed audit are used by the Configuration
Control Board (CCB) to authorize a new baseline.
The Requirements Traceability Matrix (SEM-0401) includes data required to verify
and validate changes against CIs.
The Traceability Matrix contains the following columns:

Requirement Number
Requirement Type
Design Specification Reference No(s)
Program Module
Test Reference Number(s)
Status
Status Date
Requirement Modification(s)/Comments

6.2 Physical Configuration Audits

The SUITE Key Terms and Acronyms document defines a Physical Configuration
Audit (PCA) as the formal examination of the as-built configuration of a
configuration item against its technical documentation to establish or verify the
configuration item's product baseline.
The CMM is responsible for ensuring that a PCA is performed. Results of the
completed audit are used by the CCB to authorize a new baseline.

7. Archive and Retrieval

This project follows DTMB archive policies as well as the agencys business and
continuity planning requirements. The Configuration Control section of this plan
contains information regarding the methods for retention and retrieval.

8. Training
The Project Manager is responsible for determining the SCM training needs of the
team. Potential training topics include:

Roles, responsibilities, and authority of configuration management staff

Configuration management standards, procedures, and methods

Software Configuration Management Plan 16 of 18

SEM-0302 (Rev. 07/2012)

Configuration repository system

9. Related Forms

Requirements Traceability Matrix (SEM-0401)

Installation Plan (SEM-0702)

Approval Information
The signatures relay an understanding of the purpose and content of the document
by those endorsing it.
Approve

Approve with Modifications

Reject

Comments:

Approval Signatures
Role

Name/Title

Signature

Date

Client Sponsor
DTMB Sponsor
Project
Manager
Configuration
Management
Manager

Software Configuration Management Plan 17 of 18

SEM-0302 (Rev. 07/2012)