SCM standards and operation - 3

1         SCM Execution Plan

1.1  Roles and Responsibilities

The roles and their responsibilities are listed below.

Role	Members	Description
CCB Leader	ZHEN Shunzhong	1.      Set up the standards of approving change requests; 2.      Launch the evaluation process for change requests; 3.      Request suggested plans from CCB members; 4.      Coordinate the discussion about change requests; 5.      Make a final decision for change requests; 6.      Write meeting minutes, and also record the actions for every change request.
CCB Member	ZHANG Hua ZHOU Chenglin	1.      Ensure that all the change requests must be properly classified and fully evaluated; 2.      Review and censor change requests; 3.      Ensure that only the approved change requests can be executed; 4.      Determine the priorities of approved change requests.
SCM Manager	HOU Shaohua	1.      Identify configuration items; 2.      Define baselines; 3.      Define and track the “Software Configuration Management Plan”; 4.      Perform regularly SCM maintenance; 5.      Write and publish various records or reports’ 6.      Release baselines; 7.      Release products; 8.      Organize and perform configuration management audit; 9.      Audit baselines.

1.2  Configuration Item and Baseline

At the very beginning of the project, we have to define all the software configuration items (SCI), and to allocate unique identifiers for baselines according to their purposes in the project.

1.2.1        Choose baselines

In the project, we choose to create the following baselines:

Number	Baseline Name	Baseline Identifier
1	Customer Requirement Baseline	CRMBL
2	Software Requirement Baseline	SRMBL
3	Design Baseline	SDBL
4	Code Baseline	SCBL
5	Test Baseline	STBL
6	Release Baseline	PRBL

1.2.2        Configuration Item Plan

The major configuration items include:

Type	Major Configuration Items	Identifiers	Expected Release Time
Plan	Project Plan
	Quality Assurance Plan
	Configuration Management Plan
Requirement	Customer Requirement Specification
	Software Requirement Specification
	Requirement Traceability Report
Design	Architecture Design Report
	Database Design Report
	Component Design Report
	UI Design Specification
Program	Source File
	Binary File
Testing	Test Plan
	Test Cases
	Test Report
Others

1.2.3        The content of a baseline or a configuration item

The content of a configuration item includes:

Major Configuration Item	Released Time	Author	Version History

The content of a baseline includes:

Baseline name	Time Created	Configuration Items Included In the Baseline	Description

1.3  Version Rule of Configuration Items

The version number and the state of a configuration item are closely related:

1)      The version number format of a “Draft” configuration item is “0.YZ”.

a.      The range of “YZ” is typically from 01 to 99.

b.      While developing the configuration item, the value of “YZ” should be incremented. However, its initial or incremental value could be defined by the owner himself/herself.

2)      The version number format of a “Released” configuration item is “X.Y”.

a.      “X” is the major version number, whose value could vary from 1 to 9. “Y” is the minor version number. Its value can be from 1 to 9.

b.      When a configuration item is firstly “released”, its version number is 1.0.

c.      Generally, it is “Y” who could be incremented while updating a configuration item. Only if there is a significant change, could “X” be changed.

3)      The version number format of a “Changing” configuration item is “X.YZ”.

a.      When updating a configuration item, only “Z” could be incremented, whereas, the value of “X.Y” is immutable.

b.      After the change is completed, the state of the configuration item is changed to “Released” again, and “Z” is also set to “0”.

c.      Refer to rule 2 for the format of “X.Y”.

1.4  Control Changes in a Baseline

The change requestor fills in the “Configuration Change Request Form” and submits it, and follows the “Change Control Policy”. The configuration management staff should periodically summarize and publish a report about the configuration item changes.

Form 1 -               Configuration Change Request Form

1. Change Request
CIs to be Changed	<>
The Content and Reason
Assess the Effects to the Project
Requestor Signature
2. Approve the Change Request
CCB Approved Result	<>   CCB Signature Date
Approved CIs	Executor	Due Date
3. Changed CIs
Changed CIs	Review Result	Date	Person Responsible
4. Complete the Change
CCB Signature	<> CCB Signature Date

1.5  Configuration Item State Information

In this project, we use the form below to record and publish the state of every configuration item.

Form 2 -               Configuration Item State Form

Document	Record Method	Date Published	Publish Method and Receivers
Configuration Item State Report	Manually Maintain	Two weeks a time, and publish the report every Monday	Send E-mails to every project members
Change State Report	Manually Maintain
Change Historical Report	Manually Maintain

1.6  Baseline Establishment and Configuration Audits

1.6.1        Baseline Establishment

A baseline is composed of a set of reviewed or approved configuration items. After a baseline is established, we should publish a baseline report to inform the related groups or individuals in time. The establishment time of every baseline in the project is as below:

Form 3 -               Schedule for Baseline Establishment

No.	Baseline Name	Baseline Content	Schedule	Authority
1	Customer Requirement Baseline	Customer Requirement Specification		SCCB
2	Software Requirement Baseline	Software Requirement Specification		SCCB
3	Design Baseline	Design Specification		PM
4	Code Baseline	Source code, documents, tools, etc.		PM
5	Test Baseline	Test code, test cases, tools, etc.		PM
6	Maintenance Baseline	Delivered products		SCCB

1.6.2        Configuration Audits

We must regularly audit all the configuration items to validate the integrity. The configuration audit plan is as following:

Form 4 -               Configuration Audits Schedule

No.	Configuration Items	Schedule	Auditor
1
2
3

1.6.3        Baseline Audits

During the development of a project, SCM will perform baseline audits before a baseline is published according to the actual state of the project. The audit contents include checking the consistency between configuration items and documents, etc.

Below is the plan of baseline audits:

Form 5 -               Baseline Audits Schedule

No.	Baseline Category	Schedule	Auditor
1	Customer Requirement Baseline
2	Software Requirement Baseline
3	Design Baseline
4	Code baseline
5	…

1.7  Publish a Baseline

Below is the plan for publishing baselines:

No.	Baseline Category	Date Published	Publisher	Publish Method and Receivers
1	Customer Requirement Baseline
2	Software Requirement Baseline
3	Design Baseline
4	Code Baseline
5	Test Baseline
6	Maintenance Baseline

1.8  Build

All the build activities are executing on a dedicated build machine.

The purpose of build is primarily for testing the product which will be delivered to the customers. If it passes all the tests, the build could be a candidate for release.

All the source files are storing in SVN. While building the product, it is required to download them to a directory on the build machine.

1.8.1        Build Schedule

Normally, the frequency of building a product relies on the actual project. It may be once a week, or even once a day aka daily build.

1.8.2        Build Approach

The main steps include:

1)      Create 2 directories, “BuildSources_” and “BuildResult_”, on the build machine;

2)      Lock SVN to prevent the source code from being updated;

3)      Download the latest source code from SVN to the build source directory;

4)      Unlock SVN;

5)      Perform the build;

6)      Move the build result files, including the build logs, to the build result directory;

7)      Verify the build results;

8)      If passes the verification, the build result files can be regarded as a candidate for release.

1.8.3        Build Script

The steps descried in 4.8.2 can be implemented using a build script. It can help the team to automatically build the product at a specific time, and can liberate one team member from the build work.

The well-known build tool includes MSBuild, NANT, NMAKER for .NET projects, and ANT for Java Projects.

1.9  Backup

All the materials in the configuration repository and related files must be back up regularly.

The plan for the backup is as below:

Form 6 -               The Table of Configuration Repository Backup Records

No.	Date	Executor	Backup Location	Frequency
1
2
4
4
5

1.10  Training

The main purpose of training is to let all project members know the tasks of SCM, as them can better cooperate with the SCM team.

Form 7 -               Training Schedule

No.	Participants	Date	Training Content	Trainee	Tools Required
1
2
3

2         Tailoring

The paper just describes the general process for a project. However, a project team can tailor some of the process to meet their specific requirement based on the following guidelines:

1)      If a tool can generate a version number for a configuration item, the section described in “4.2 Version Rule of Configuration Items” can be tailored.

2)      In this document, we only describe the minimal set of baselines and their categories. A project team can add other baselines or add other required supporting fields based on the reality, and write it in the Configuration Management Plan.

3)      The build process can be tailored. It is up to the project team themselves, and the decision must be recorded in the Configuration Management Plan.

4)      All the tailoring activities must be approved by CCB, and must be recorded in the Configuration Management Plan.

3         Critical Success Factors

There are many factors to influence the success of the plan, as notes below:

1)      First of all, the execution of the plan must obtain sufficient authorization from top managers;

2)      Training is essential for the project team;

3)      The manner adopted by the organization to apply the plan is also very important. It is suggested to use the principal “stability first, optimize later” to execute the plan.

4         Appendix

4.1  References

1)      CMMI Product Team, CMMI® for Development Version 1.2, August 2006

2)      Jefferson Wat, COMP5226 Software Infrastructure and Software Configuration Management, 2008

3)      Anne Mette Jonassen Hass, Configuration Management Principles and Practice, 2003

4)      NASA, Sample Configuration Management Plan, Nov 21, 2006

5)      ANSI/IEEE Std 828-1998,Configuration Management Plan

Nadine M. Bounds & Susan A. Dart, Configuration Manager (CM) Plans: The Beginning to Your CM Solution, July 1993