SCM standards and operation - 2

1         Define SCM Process

1.1  Policy

All the SCM activities are required to follow the policies below:

1)      A SCM plan should be created for every project in the company. The execution of the SCM plan should be consistent with the project plan. Otherwise, the SCM may not help the project to management the resources.

2)      SCM activities should work through the whole project life cycle.

3)      The configuration items include requirement documents, design documents, review documents, source codes, test cases, published products, internal released work products and the specified support tools etc.

4)      Every project should create its own configuration repository to save configuration items and the operation history records.

5)      Regularly audit the software baselines and the configuration management activities.

6)      While making decisions, CCB should adopt the principle that the minority is subordinate to the majority.

1.2  Define SCM Plan

1.2.1        Objective

Defining a SCM plan is very helpful to our configuration management activities.

1.2.2        Roles and Responsibilities

1)      The configuration manager defines the Configuration Management Plan.

2)      CCB approves the Configuration Management Plan. The number of members in CCB could be determined by the size of a project. In general, the members may include project managers, senior engineers, etc.

1.2.3        Entry Conditions

We can commence the SCM process once the following conditions are satisfied:

1)      The 《Project Plan》 is defined.

2)      The configuration managers as well as CCB are both appointed.

1.2.4        Input

《Project Plan》

1.2.5        Steps

In this stage, we’ll perform the activities step by step.

Step 1      Determine the resources allocated for configuration management

Based on the project size and budget, the configuration manager determines which configuration software tool to use as well as the hardware resources. Typically, there is one or more dedicated servers which are hosting the configuration repositories for a project. The server should have high availability. To avoid the data loss because of disk damage, he can use disks that supporting RAID.

Step 2      Define configuration item plan

The configuration manager identifies all the configuration items. He has to tell the team if documents or files can or cannot be stored in the repository. Generally, some types of files may not be submitted. These include, the individual settings file, debug symbol file (.pdb), C++ object file (.obj), etc.

Every configuration item has a unique identifier. Typically, the format of an identifier likes “Project-Type…Type-Number”.

Step 3      Define the baseline plan

The configuration manager defines every baseline (its name, identifier, etc.) and the required configuration items within the baseline. Also, he estimates when each baseline will be established.

Step 4      Define the backup plan

The configuration manager defines a backup plan to backup the configuration repository. He specifies that who will execute the action, when the action will be executed and where the backup files will be stored.

Step 5      Approve the configuration management plan

CCB approves the configuration management plan.

If the plan gets approved, the person who is in charge of CCB must sign his signature. Otherwise, the configuration management plan need to be revised based on the opinions and/or suggestions from CCB, until the plan is finally approved.

Diagram 1 -   The flow of defining a configuration management plan

1.2.6        Output

Configuration Management Plan

1.2.7        Exit Conditions

The configuration management plan gets approval from CCB.

1.2.8        Measurement

The configuration manager computes the work efforts, and reports to the project manager.

1.3  Configuration Repository Management

1.3.1        Objective

While manipulating a configuration repository, the staff must follow the policies defined in the configuration management plan.

1.3.2        Roles and Responsibilities

1)      The configuration manager creates and maintains the repository.

2)      The staff manipulates the repository according to the allocated access privileges.

1.3.3        Entry Conditions

1)       “The Configuration Management Plan” has already been defined.

2)      The required tools and hardware is available.

1.3.4        Input

“The Configuration Management Plan” is required.

1.3.5        Steps

Step 1      Create a repository

The configuration manager creates a repository, and also creates the root directories within the repository.

Step 2      Distribute access privileges

The configuration manager allocates access privileges for every project member. Generally, a project member could have the rights include Add, Check-in/Check-out, Download, etc. To prevent some potential risks, the Delete right may not be delegated to all the project members.

Step 3      Repository operations and management

1)      The project members manipulate the repository based on his/her access privileges. They can create new files, update existing files, or download a snapshot of the project.

2)      According to the baseline plan, the configuration manager creates, maintains the baseline, “froze” the configuration items, controls changes.

3)      The configuration manager periodically cleans up the garbage files in the repository.

4)      The configuration manager backups the repository in a timely manner.

5)      Deliver management. “Deliver” means to extract configuration items from the repository, and deliver it to the customers or the staff outside the project. The delivered configuration items must be recorded to avoid confusion. The flow is as below:

a.      The client submits an application to CCB.

b.      If the request is valid and reasonable, CCB can approve it, and give the user a detailed list that contains all the configuration items to be delivered. Otherwise, CCB refuses the application.

c.      The configuration manager extracts the listed configuration items, and delivers them to the client.

d.      The client must sign his/her signature immediately after validating the configuration items.

Diagram 2 -   Repository Management Flow

1.3.6        Output

The document that generated in this stage is “Configuration Repository Management Report” which is created by the configuration manager.

1.3.7        Exit Conditions

The work will continue till the end of the project.

1.3.8        Measurement

The configuration manager records the work efforts.

1.4  Version Control

1.4.1        Objective

The objective of version control is to properly save all the configuration items based on well-defined rules, so that we can avoid potential version loss and confuse, and get the specified version of a file accurately and quickly.

1.4.2        Roles and responsibilities

While updating the files in a repository, the staff must follow the version control policies.

1.4.3        Entry Conditions

1)      The repository gets created.

2)      The access privileges are distributed.

1.4.4        Input

1)      New work products or modified work products.

1.4.5        Change policy of configuration items

The state of a configuration item could be:

1)      Draft

2)      Released

3)      Changing

How the state of a configuration item is changed is illustrated in Diagram 4.

1)      When a configuration item is created in a repository, its state is “Draft”.

2)      If the configuration item gets reviewed or approved, its state is changed to “Released”.

3)      Hereafter, if the configuration item needs to be changed, we must follow the “Change Control Policy” and change its state to “Changing”.

4)       When the modification is complete, it’s required to review and approve the configuration item again. Then its state can be switched back to “Released”. Or we can just throw away new changes to roll it back to the “Released” state.

1.4.6        Version policy of configuration items

The version number of a configuration item and its state are closed related. The format of a version number can be sorted into the following categories:

1)      The format for a “Draft” configuration item;

2)      The format for a “Changing” configuration item;

3)      The format for a “Released” configuration item.

1.4.7        Version Control Flow

Step 1      Create a configuration item

The project members can create new configuration items in a repository according to the “Configuration Management Plan”. The initial states of them are “Draft”.

Step 2      Modify a draft configuration item

The project members can freely update “Draft” configuration items by using the check-in/check-out functionality of a software tool. This kind of operations may not be restricted by the change control policy.

Step 3      Review or Approve

If the configuration item is a technical document, it needs to be technically reviewed. Otherwise, if it is a management-related document, the project manager or the higher manager has to approve it.

If the document passed the step, go to step 4. Otherwise, back to step 2.

Step 4      Release

The configuration item has been reviewed or approved. Its state is also changed to “Released”.

Step 5      Change

While modify a “Released” configuration item, we has to follow the “Change Control Policy”. The main steps include:

1)      If the change is approved by CCB, the state of the configuration item is changed from “Released” to “Changing”.

2)      Then, the project member can modify the configuration item using the check-in/check-out functions.

3)      If the modification is completed, the configuration item must be reviewed or approved again by jumping to the step 3.

 

Diagram 3 -   State Change of a Configuration Item

1.4.8       

Output

Several types of documents will be outputted.

1)      Baseline/product release application

2)      Product release announcement

3)      Software change application form

4)      Change list

5)      SCM weekly report

6)      SCM stage summary

1.4.9        Exit Conditions

A change request will be completed after CCB signs his/her signature.

1.4.10   Measurement

CCB has to record all the work efforts.

1.5  Change Control

1.5.1        Objective

To prevent configuration items from being casually modified.

1.5.2        Roles and Responsibilities

CCB approves change requests.

1.5.3        Entry Conditions

The state of the configuration item to be changed is “Released”, or it is already a part of a baseline (that is, it is “froze”).

1.5.4        Input

The input is the configuration item to be changed.

1.5.5        Steps

Step 1      Submit a change request

The person who wants to change the existing configuration item should submit a change request to CCB first. Within the request, it must be clearly described that what will be changed and why we need the change.

Step 2      Approve the change request

After receiving the change request, CCB analyzes the impact that the change probably make on the overall project. If it is necessary or reasonable, CCB could approve it. Otherwise, CCB can reject it. The process will therefore get terminated.

While analyzing the request, CCB must be aware of the potential risks as it may possibly affect other configuration items. However, in most situations CCB may not realize that at the moment. Therefore, CCB can delegate the responsibility of changes to the project manager of the producer himself/herself.

Step 3      Prepare for the change

CCB appoints a executor to implement the change. Sometimes, the executor is the one who submitted the change, but sometimes may not.

CCB and the executor must agree on the content of the change.

Step 4      Implement the change

According to the task arrangement, the executor modifies the related files. At the same time, CCB monitors the execution of the change. They have to ensure that the content of the change is accurate, and the change can be done in time.

Step 5      Review or approve the changed configuration items

If the configuration item is a technical document, it must be reviewed again. And if it is a management-related document, it also needs to get approved by the top managers.

If the configuration item passes review or gets approved, we can go to next step. Otherwise, the change should be re-implemented, that is, go to step 4.

Step 6      Complete the change

When all the configuration items required by the change get reviewed or approved, the state of them will be changed from “Changing” to “Released”. Then, CCB signs a signature in the “Report on Configuration Items Change Control” to indicate the completeness.

Diagram 4 -   The Flow of Changing a Configuration Item

 

1.5.6        Output

All the information will be record in the “Report on Configuration Items Change Control”.

1.5.7        Exit Conditions

CCB signs a signature to indicate the termination of completeness of the process.

1.5.8        Measurement

CCB records all the work efforts.