<Name of the project> CM Plan

Project Code: <Code of the project> Document Code: <Code of the document > v<x.x> Note: Text displayed in blue italics is included to provide guidance to the author and should be deleted or hidden before publishing the document. This template can be used at it is, or to complete and improve an already existing template. Help: Dont remove headlines level 1 and level 2 (Heading1 and Heading2) Reasons why a section is not applicable shall be documented under the respective headline

<Location, issued date of the Document>

<Project code>-CM Plan

v<x.x>

SIGNATURE PAGE AUTHOR: <Name> Configuration Controller REVIEWERS: <Name> Project Technical Leader <Name> QA APPROVAL: <Name> Project Manager <Date> <Date> <Date> <Date>

2/11

<Project code>-CM Plan

v<x.x>

RECORD OF CHANGE *A - Added M - Modified D Deleted

Effective Date Changed Item A* M, D Change Description Reason for Change Revision Number

3/11

<Project code>-CM Plan

v<x.x>

TABLE OF CONTENTS INTRODUCTION..............................................................................................................................5 CONFIGURATION MANAGEMENT PROCESS..............................................................................6

4/11

<Project code>-CM Plan

v<x.x>

INTRODUCTION
The purpose of this document is to identify and describe configuration management (CM) process implementing in the project <Project code>

1.1. Role & Responsibility

Refer to Project Organization section in Project Plan

1.2. Definitions and Acronyms

Help: Define, or provide references to documents or annexes containing the definition of all terms and acronyms required to properly understand this Plan.
Acronym ADD CC CI CM CSCI DDD PM PTL PIC QA SRS Source URD TP TC WIP WP Definition Architecture Design Document Infrastructure Configuration Controller Configuration Item Configuration Management Computer Software Configuration Items Detail Design Document Project Manager Project Technical Leader Person in Charge Quality Assurance Officer Software Requirement Specification Source Code User Requirement Document Test Plan Test Case Work in Progress Work product Note

5/11

<Project code>-CM Plan

v<x.x>

CONFIGURATION MANAGEMENT PROCESS

1.3. CI Identification & Naming convention
<List here all items identified as CIs in the project. Its recommended to refer to guideline of CI identification in CM Process for proper CI identification Sheet CI Identification in Template_CM Report could be used for the section.>

1.4. CI Baseline Procedure

<Specify CI baseline criteria in CI Identification in Template_CM Report> Help: Customize the below flows to fit with your project. Be noted that CI baseline could be logical (by labeling or naming convention) or physical (through storage). The movement among project repositories described here must be consistent with the section Directory Structure
For Document Member develops & modifies documents in User folder and then moves it to Wip/Document Member moves documents from Wip/Document to his User folder

Member moves documents from Wip/Document to his User folder to work on the change, if any

Reviewers review the doc in Wip/Document

Found

No

The documents are released & baselined in Wip/Document

For Source code:

6/11

<Project code>-CM Plan

v<x.x>

Developers code in Develop area & then move it to Review area for review & integration if passed <criteria to move> Developers move his CIs to his Develop area

Developers move his CIs from Release area to his Develop area to work on the change, if any

Code is reviewed& integrated in Review area, then moved to Test area if passed review & unit test

Found

No

Testers get source code from Test area to execute test

Found

No

CIs are checked-in to Release area

1.5. Project Baseline Schedule

Example:
No. Baseline Name Baseline Criteria PIC

<Name of baseline, it is usually get the name of the Stage in which the baseline is performed>

<Trigger/criteria to perform the baseline> Within 7 days from WO 1.0 approval. It is mandatory requirement that version of all CI at Startup baseline to be archived in separate folders in Archive area Baseline to adapt new methodology to project solution When Architectural design v1.0 is released and baselined Right the end of

<Name of the person responsible for performing Baseline activities>

Startup

CC

Definition

CC

Solution 4
7/11

CC CC

Construction

<Project code>-CM Plan

v<x.x>

No.

Baseline Name

Baseline Criteria

PIC

development phase After the final release. It is mandatory requirement that version of all CI at Wrap-up baseline to be archived in separate folders in Archive area

Wrap-up

CC

1.6. Directory structure & Access right

1.6.1. Promotion Areas

Help: List Promotion Areas used in the project. Specify purpose + criteria to be in of these areas Example:
Area Purpose

Develop Area Review Area

Area for different users to store his/her owned items To store items that is ready for review. Reviewer get to be-reviewed items from this area Just applicable for Source items. To store items passed Unit Test and Code Review To store the items ready for release and all released versions of items Users get the most recent items for their usage from this area To archive all released versions of each CI

Test Area

Release Area

Archive Area

Archive area is a protected area for project baselines where all the CIs can not be changed by any member Directory structure

1.6.2.

Help: Customize the directory structure to fit the projects need Define the projects own access right Example:
Main Folder Sub Folder Purpose Map to Area Access right

Project Directory : \\fsoft.fpt.vn\Gx\Projects\ABC WIP Deliverables Store all CIs that are delivered to customer, be possible to add date to folder name Documents of Requiements, Design, Test, Store project meeting minutes, including meeting minutes with customer Store Proposal, Estimation, Project Plans, Project schedule, Task list Release Modify: PM, CC Read: All Release + Review NA Modify: PM, CC,PIC Read: All Modify: All

Documents

Meeting minutes

Plan

Review + Release

Modify: PM,CC,PTL Read: All

8/11

<Project code>-CM Plan

v<x.x>

Main Folder

Sub Folder

Purpose

Up dat e

Map to Area

Access right

Project Directory : \\fsoft.fpt.vn\Gx\Projects\ABC Report Store Project Reports: Weekly , Milestone, Post-mortem, Acceptance note, other Event-driven reports Store project records, divided into Review: include Review, Test and Inspection records Change request Acceptance Mails ... Source User Refere nce Customer supplied Store VSS file of Source code Users working area, store users owned items store Documents and Other materials/data supplied by customer or those support software development and production operation in the project Store Guidelines/Standards/Forms/Template s/Checklist specified for the project usage Store QA work products Process review Final inspection Work product review Archiv e Baseline Name To released versions of CIs at baselines Archive Modify: PM, CC Read: All Archive Develop Release Refer to VSS directory Modify: All Modify: PM, CC,PIC Read: All NA Modify: PM, CC,PIC Read: All NA Modify: All

Record

Process Template

Release

Audit

NA

Modify right: Project QAs Read right: All

VSS Directory: \\101.102.103.4 <Devel op> Sub folder 1 <purpose> Develop Modify: Developers Read: All Sub folder 2 <Next Build> Sub folder 1 <purpose> <purpose> Review Modify: PM, CC, PIC Read: All Sub folder 2 <Test> Sub folder 1 <purpose> <purpose> Test Modify: PM, CC, PTL Read: All Sub folder 2 <Relea se> Sub folder 1 <purpose> <purpose> Release Modify: PM, CC Read: All Sub folder 2 <purpose>

9/11

<Project code>-CM Plan

Ver sio n

v<x.x>

For physically stored items Items <describe specification of the items and what is it used for on the project> Access right control Location <where are the items placed> Person in charge Re Usage rule <describe Usage rule applied to those items>

visi <Name of person on in charge of storage physical items>

Access right of non-project team members (ex: auditor, external reviewer, etc) must be get permission of PM and granted in the pre-defined duration, then revoked at expiry date by CC. As soon as a member is out of the project, his or her access right is revoked also. The access right is reviewed frequently and updated by CC at <baseline point and project closure time>. After project asset is approved by QA at project closure time, QA.Accounting informs to IT Department to revoke the access right of all project team members. If someone has a request for data reference, audit, etc, he or she must get the approval of authorized person, normally Group Leader or Division Leader, and then send the request to IT Department. IT Department is responsible for implementing such kind of requests.

1.7. Version numbering rule

1.1

Help: Specify version numbering rule applied to the project Example:

For Documents:

The version level is maintained as numbered identifier with two components Ver Re sio visi n on

The original version will be numbered 0.1. Subsequent revisions will be numbered 0.2, 0.3. The release version will be 1.0. Version number, which appears to the left of the decimal. It changes only when the core architecture of the item changes. For example: when an item is completely overhauled, with substantial internal changes, the version 1.0 would become version 2.0 Revision number, which appears to the right of the decimal. It changes when existing content is changed, but the overall structure and 1.1a the item remains the same. The normal sequence of flow of revision is 1.1, 1.2 and so on.
For Software Source Files:

Software executables and support files are generally identified by name and version number, such as Main DB v1.1.a. The scratch edition will be 1.0. The version numbering scheme consists of three components:

Version number, which appears to the left of the decimal. It changes only when the core architecture of the software item changes, as when moving from one area of the development tool to another, when an application is completely overhauled, or the user interface changes fundamentally. In this case, version 1.1a would become version 2.0.

10/11

<Project code>-CM Plan

v<x.x>

Revision number, which appears to the right of the decimal. It changes when new features, functionality or other content are added or significantly changed. In normal case, the core architecture or user interface have been extended or limited in some manner. The most common reason for changing the revision number is when adding a new module or other functionality to the software. The normal sequence of revision is 1.0, 1.1, and 1.2 and so on. Update level is appended or incremented when the only change to the software item is to correct one or more defects, without the addition of any new functionality. Version 1.1 would become v1.1a, v1.1b and so on. This updating is over ridden when a combination revision, involving bug fixes and new feature additions, is performed. In such a case, the software revision number is incremented and any update indicator is dropped, as in v1.1b to v1.2

1.8. Change control

<Describe Change control procedure applied in the project <Refer to Requirement Change Management section in Project Plan and Change Control Report sheet in CM Report could be refered.>.

1.9. Backup strategy

Storage Area to be Backed up Items to be Backed up Backup To Backup Type Backup Frequency PIC

<Where is the backup file is archive>

<Incremental, Full> Twice a week CC

VSS repository

VSS repository

ITLKEC02\\\\ ProjectBackup

1.10. Other CM rules

Specify other CM rules applied in the projects, such as mail subject naming convention, rule for deployment, rule for product releases or deliverables releases.

11/11