Software Configuration Management (SCM)

With the rise of the software industry, software engineering technology is attracting more and more attention. Advanced software engineering concepts, especially those represented by CMM, are becoming increasingly popular in China.

Software Configuration Management (SCM), as a key practice area (KPA) of CMM Level 2, plays an important role in the entire software development activity. As Pressman said: "Software Configuration Management is a protective activity throughout the software process. It is designed to (1) identify changes, (2) control changes, (3) ensure that changes are properly discovered and (4) report changes to other persons that may be interested." Therefore, we must design a management process that can be integrated with the existing software development process for Software Configuration Management activities, or even directly use this software configuration management process as a framework, to recreate the software development process of the Organization.

Based on the requirements of Software Configuration Management in CMM Level 2, this article fully considers the possibility of automatic software configuration management with the assistance of the CASE tool, describes the Software Configuration Management process and key activities in an ideal software R & D organization.

I. role responsibilities

For any management process, a clear definition of roles, responsibilities, and permissions is a prerequisite for ensuring the normal operation of the process. Especially after the Software Configuration Management tool is introduced, it is ideal that all the personnel in the Organization perform the corresponding actions according to the requirements of different roles and the permissions assigned by the system. Therefore, the Software Configuration Management process described in this article mainly involves the following roles and Labor Division:

Project Manager (PM ):

The project manager is the owner of the entire software R & D activity. Based on the recommendations of the software configuration control board, he approves configuration management activities and controls their processes. Its specific responsibilities are as follows:

Formulate and modify the project's organizational structure and configuration management policies;

Approve and release the configuration management plan;

Determine the project start baseline and development milestones;

Accept and review the configuration control board report.

Configuration Control Board (CCB ):

Guides and controls the activities of configuration management and provides suggestions for project managers to make decisions. Its specific responsibilities are as follows:

Custom development subsystem;

Custom access control;

Develop common strategies;

Establishes and changes the baseline settings, and reviews the change application;

Determine the corresponding countermeasures based on the configuration Administrator's report.

Configuration Management Officer (CMO ):

Execute various management tasks according to the configuration management plan, submit reports to CCB on a regular basis, and attend regular meetings of CCB. Its specific responsibilities are as follows:

Routine Management and Maintenance of configuration management tools;

Submit the configuration management plan;

Management and maintenance of various configuration items;

Implement version control and change control plans;

Complete configuration audit and submit the report;

Training developers;

Identify problems in software development and propose solutions.

System Integrator (SIO ):

The system integrator is responsible for generating and managing internal and external release versions of the project. The specific responsibilities are as follows:

Integrated modification;

Build a system;

Complete routine maintenance of the version;

Create an external release version.

Developer (Dev ):

Developers are responsible for completing development tasks according to the Software Configuration Management Plan and relevant regulations determined within the organization according to the model used by the Software Configuration Management tool.

Ii. process description

A software development project can generally be divided into three phases: planning, development, and maintenance. However, from the perspective of Software Configuration Management, the activities involved in the last two phases are the same, so they are combined into one to become the "Project Development and Maintenance" phase.

Project planning phase:

At the beginning of a project establishment, PM first needs to develop the overall project plan, which is the basis of the project R & D work. With the overall R & D Plan, the Software Configuration Management activities can be launched, because if you do not plan the Software Configuration Management plan at the beginning of the project, therefore, many key activities of Software Configuration Management cannot be carried out in a timely and effective manner, the direct consequence is that the project development status is disordered and the software configuration management activity is doomed to be a "fire-fighting" action. Therefore, developing a software configuration management plan in a timely manner is an important guarantee for the success of the project.

The main process of the Software Configuration Management Plan should be as follows:

CCB determines milestones and development strategies based on the project development plan;

The CMO formulates detailed configuration management plans based on the CCB plan and submits them to the CCB for review;

After passing the Configuration Management Plan, CCB submits it to the project manager for approval and releases the implementation.

Project development and maintenance phase:

This stage is the main stage of project R & D. In this phase, Software Configuration Management activities are divided into three layers: (1) management and maintenance work mainly completed by CMO; (2) the Software Configuration Management policies are executed by the SiO2 and Dev; (3) the change process. These three layers are an organic whole that is independent and interconnected with each other.

In this software configuration management process, the core process should be as follows: (1) CCB sets the initial baseline for R & D activities; (2) CMO sets up the configuration library and workspace according to the Software Configuration Management Plan, and prepares engineers for implementing the Software Configuration Management. (3) Developers should follow the Unified Software Configuration Management policies, perform Project R & D based on authorized resources; (4) integrate the work results of developers in the team according to the project progress, build a system, and promote version evolution; (5) CCB reviews various change requests based on the progress of the project, and promptly designates new baselines to ensure orderly development and maintenance.

This process repeats until the end of the project. Of course, in addition to the above core processes, there are also some other related activities and operation procedures. The following lists the different roles:

Each developer works according to the development strategy or model released by the project manager;

Sio is responsible for consolidating the work results of each sub-item into the Integration Branch for testing or release;

The requirements for baseline establishment can be raised to CCB, and the approval will be executed by the CMO;

CMO regularly submits audit reports to the project manager and CCB, and reports possible problems and improvement plans during the software process at the CCB meeting;

After the baseline takes effect, all changes to the baseline and development results before the baseline and baseline must be approved by CCB;

CCB regularly holds regular meetings to modify the configuration management plan based on the information of members, CMO reports and developers' requests, and is responsible to the project manager.

 

Iii. Key activities

1. Software configuration item (SCI) Identification

Pressman provides a simple definition for SCI: "the output information of software processes can be divided into three main categories: (1) computer programs (source code and executable programs), (2) documents describing computer programs (for technical developers and users) and (3) data (including internal or external ). These items contain all the information generated during the software process, collectively referred to as software configuration items ."

It can be seen that the identification of configuration items is the basis of configuration management activities and an important part of the Configuration Management Plan.

Software configuration item classification the software development process is a constantly changing process. In order to control changes without seriously hindering reasonable changes, the Software Configuration Management introduces the "baseline (base line). The IEEE defines a baseline as follows: "A protocol or product that has been officially approved by review can serve as the basis for further development, in addition, the change can only be controlled through formal changes."

Therefore, according to this definition, we divide all configuration items to be controlled into baseline configuration items and non-baseline configuration items in the software development process. For example: baseline configuration items may include all design documents and source programs; non-baseline configuration items may include various plans and reports of the project.

Configuration Item Identification and Control

All configuration items should be numbered according to the relevant provisions, generated according to the corresponding template, and the object identification information should be recorded in the specified section (Part) in the document. After Software Configuration Management tools are introduced for management, these configuration items should be stored in the configuration library in a directory structure.

The operational permissions of all configuration items should be strictly managed by CMO. The basic principle is that the baseline configuration items are read and obtained by software developers, and non-baseline configuration items are open to PM, CCB, and relevant personnel.

2. workspace management

After Software Configuration Management tools are introduced, all developers are required to store their work results in the configuration library managed by the Software Configuration Management tools, or work directly under the environment provided by software configuration management tools. Therefore, in order to enable a better division of labor and cooperation between each developer and each development team without interfering with each other, the management and maintenance of the workspace has become an important activity of Software Configuration Management.

In general, the ideal situation is to regard the entire configuration library as a unified workspace, and then divide it into individual (private), Team (integrated), and whole (public) as needed) these three types of workspace (branches) can better support possible concurrent development needs in the future.

Each developer works in different workspaces at different development stages according to task requirements. For example, for a private development space, after a developer obtains the permission to operate the corresponding configuration item based on the task division, the developer will work on his own private development branch, all of his work is reflected in the promotion of the version on the private branch of the configuration item. Except the developer, no one else has the right to operate on the elements in the private space; the Integration Branch corresponds to the public space of the development team. The development team has the read and write permissions for the Integration Branch, while other members only have the read-only permission. Their management work is the responsibility of SiO2; as for public workspace, it is used to uniformly store the staged work achievements of various development teams. It provides a unified standard version for the entire group and serves as the knodge DGE of the entire organization.
Base.

Of course, due to the different Software Configuration Management tools selected, there are significant differences in the implementation of workspace configuration and maintenance, but for CMO, these tasks are his important responsibilities. He must configure the workspace according to the actual situation of each development stage and customize the corresponding version selection rules to ensure the normal operation of the development activities. When a change occurs, the baseline should be promoted in a timely manner.

3. Version Control

Version Control is the core function of Software Configuration Management. All elements in the configuration library should be automatically identified by the version and ensure the uniqueness of the version name. During the version generation process, the system automatically branches and evolves according to the specified model. In addition to the version information automatically recorded by the system, we also need to define and collect metadata (metadata) in order to cooperate with various stages of the software development process) to record the auxiliary information of the version and standardize the development process, and prepare for future measurement of the software process. Of course, if the tool is supported, the auxiliary data will be able to directly collect process data, so that we can facilitate the implementation of software process improvement (SPI) activities.

For each baseline Control item in the configuration library, the access permission should be set based on the location and status of the baseline. Generally, versions earlier than the baseline version should be locked. If you need to change them, you should follow the change control process.

4. Change Control

In the description of SCI, we introduced the baseline concept. From the IEEE definition of baselines, we can find that baselines are closely linked with change control. That is to say, after identifying each SCI and using tools to manage their versions, how can we ensure they are truly under control in the complex and variable development process, in any situation, quickly restoring to any historical state becomes another important task of Software Configuration Management. Therefore, change control is to provide a change control mechanism by combining human procedures and automated tools.

In the previous sections of this article, SCI has been divided into two categories: Baseline configuration items and non-baseline configuration items. Therefore, the objects involved in change control mainly refer to the baseline configuration items in the configuration library.

The general process of change management is:

A) (obtained) requests for changes;

B) It is up to CCB to review and decide whether to approve the request;

C) (accepted) modify the request to assign a person as, extract SCI, and modify;

D) review changes;

E) Submit the modified Sci;

F) Establish and test the test baseline;

G) rebuilding an appropriate version of the software;

H) Review (Audit) All Sci changes;

I) release a new version.

In such a process, CMO uses software configuration management tools for access control and synchronization control, these two types of control are based on the version control and branch policy described above.

5. Status report

The configuration status report reports the progress of software development activities to managers based on the records in the configuration item operation database. Such reports should be conducted on a regular basis and should be generated automatically using CASE tools. objective data in the database should be used to reflect the actual situation of various configuration items.

The configuration status report should focus on the status of the current baseline configuration item based on the report, as a reference for the development progress report. At the same time, developers can also analyze the working relationship of the development team based on the Operation Records of configuration items.

The configuration status report should include the following main content:

A) configure the library structure and related instructions;

B) Composition of the development start baseline;

C) Current baseline position and status;

D) integration branches of various baseline configuration items;

E) distribution of private development branches;

F) version evolution record of key elements;

G) other matters that should be reported.

6. Configure Audit

Configuration audit is mainly used as a supplement to change control to ensure that a change request has been implemented. In some cases, it is used as part of a formal technical review, but when Software Configuration Management is a formal activity, it is executed by SQA personnel separately.

In short, Software Configuration Management targets all development assets in software development activities. All of this should be incorporated into the management plan for unified management as configuration items, so as to ensure timely maintenance and integration of all software development resources. Therefore, the main tasks of Software Configuration Management come down to the following: (1) preparing the project configuration plan; (2) marking the configuration items; (3) Versioning the configuration items; (4) control changes to configuration items; (5) Conduct regular configuration audits; (6) Report the configuration status to relevant personnel.

Here, I would like to note that Software Configuration Management covers the entire software development process, so it is an ideal starting point to improve our software process and improve the maturity of process capabilities. We hope that the role assignment and workflow of this software configuration management described in this article can be continuously improved in practice, so that our software development activities can be conducted in a more orderly and efficient manner!