SCM standards and operation - 1

     Software configuration management (SCM) standards and operation - 1

 

Abstract 1.1  Objective

The paper aims to unify software configuration management standards, as well as to give the instructions for the operations in configuration management.

1.2  Scope

Besides applied in all software projects, the paper can also be a reference for other types of projects.

The process of configuration management will cover all the stages in a software life cycle.

1.3  Background

In order to associate with our company’s strategy of developing oversea markets, we defined the standards for Capability Maturity Model Integrated (CMMI) management, especially the Software Configuration Management (SCM) in CMMI.

1.4  Attached Documents 1.5  Glossary & Abbreviation

Name	Description
CMMI	Capability Maturity Model Integrated
CM	Configuration Management
SCM	Software Configuration Management
CI	Configuration Item
Baseline	A baseline provides the official standards or point of reference on which subsequent work is based and to which only authorized changes are made.
CCB	Configuration Control Board
PM	Project Manager
SCME	Software Configuration Management Engineer
QA	Quality Assurance

2         Introduction to SCM

By the process such as version control and change control, Configuration Management (CM) realizes the integrity and trace of all configuration items. CM is an effective protection for our work products. We can tell CM works as a guard to our work.

The Configuration Management Process Area is an important part of SPP model. The document explains the 4 major aspects of the Configuration Management Process Area:

1)      Define a Configuration Management Plan;

2)      Configuration Repository Management;

3)      Version Control of Configuration Items;

4)      Change Control of Configuration Items.

Various work products can be produced during projects’ development and management, such as documents, code, data, etc. They should be properly stored, so that we can conveniently review or modify them. Proper classification and clear order is needed to store work products, otherwise you will find yourself in a mess when you need them.

All the work products that are defined in Configuration Management Scope are called Configuration Items (CI). Configuration Items include:

1)      The work products which are parts of a product. They include requirement documents, design documents, source codes, test cases, etc.

2)      The documents which are created during project management. They are used to support the project management.

The attributes of every configuration item include name, identifier, state, version, author, date, etc. All the configuration items along with their attributes need to be stored in the configuration repository, and to ensure their integrity. The history records of CIs reflect the evolution process of the project.

Baseline is consisting of a group of CIs which form a relatively stable logistical entity. The CIs in a baseline are froze, and don’t support any unauthorized modification (please refer to the Change Control). A baseline is usually known as a milestone in the software development process. A project can have one or more baselines. The attributes of a baseline include name, identifier, version, date, etc. Generally, the baseline which is delivered to customers is called “Release”, comparing with the one for internal development called “Build”.

All the team members should use configuration management tools to protect their work products. The organization should adopt unified configuration management tools, mainly like Microsoft Visual SourceSafe, Rational ClearCase, CVS, etc. To improve the efficiency and security of configuration management, an organization should have dedicated configuration manager (role). The manager defines the Configuration Management Plan for every project, as well as creates and maintains the configuration repository.

The configuration management is very important and complex. So an organization should set up a Configuration Control Board (CCB). CCB is a virtual team. It makes decisions for all kinds of configuration management activities (e.g. configuration management plans, or change requests). In configuration management, CCB is the decision-maker; the configuration manager, on the other hand, is the executor.

If all the projects in an organization have very close relationship (e.g. the projects that belong to a product line), it is recommended to set up a public CCB. It owns the decision-making right for all the projects. However, if the projects are relatively independent, they can have their own CCB. In a CCB, the principle that the minority must obey the majority is usually adopted.

The configuration management flow is illustrated below (Diagram 1 – Configuration Management Flow).

Diagram 1 -   Configuration Management Flow

2.1  Define CM Plan

Configuration Manager defines the Configuration Management Plan. The plan covers the following content: the hardware and software resources allocated for configuration management, configuration item plan, baseline plan, delivering plan, backup plan, etc. It’s required approved by CCB before launch.

2.2  Repository Management

Configuration Manager creates a repository for a project, and allocates access privileges for each team member. Moreover, the manager regularly maintains the repository by cleaning up garbage files, or backuping repository resources.

2.3  Version Control

During the project development, almost all the configuration items will be modified more than one time. Every modification to a configuration item makes a new version. We cannot simply throw away the old file, because we cannot ensure that the new one is better than the old one. The purpose of version control is to save all the versions of a configuration item according to a well-defined rule to avoid version loss and confusion. What’s more, we can rapidly and accurately retrieve every version of a configuration item.

The states of a configuration item could be “Draft”, “Release”, and “Changing”. This document states the rule of version change.

2.4  Change Control

It’s no doubt that the configuration items will be changed from time to time in a project. To avoid the unauthorized changes, we need to do the change control.

Please note that it’s not a “change” to modify a configuration item which is still a “draft”. Therefore, it does not need the approval from CCB. The executor can perform the change himself according to the version control rule.

When a configuration item is marked “released” or “froze”, no one can modify it easily. We have to follow the change rule: “apply – approve – execute the change – review - complete”.

2.5  Configuration Management Audits

To ensure that everyone, including team members, configuration managers and CCB, obey the configuration management policies, QA staff regularly audit the configuration management process. Configuration management auditing is a QA activity. It is one of the responsibilities of QA staff.

The main documents created in configuration management process area include:

1)      Configuration Management Plan

2)      Repository Management Report

3)      Change Request Report