Configuration Management Based on CMM and cmme

This article introduces the configuration management content of the standard based on the requirements of CMM and cmme, and gives a preliminary description of the relevant content, finally, a Configuration Management Guide for project implementation and a model for deploying configuration management in an organization are provided.

1. Configure the logical relationship of management content

In CMM and cmme, the purpose of configuration management is defined as "Building and maintaining product integrity". This goal does not mention support for project management, that is, the goal of configuration management defined by it is somewhat lower than the current industry's understanding of configuration management. However, careful analysis shows that "establishing and maintaining product integrity" is the basis for other configuration management objectives. The following is an analysis of the target. For the logical relationship, see:

Configuration integrity (understanding of standards)

1. Product Integrity: the work results submitted by the project are "complete product set, correct sub-products"

2. complete product set: the sub-products (configuration items) included in the product are complete.

3. Correct sub-products: sub-products (configuration items) meet the requirements and meet the requirements of standards and procedures.

Logical Relationship Analysis

1. "baseline management" supports "complete product set", clarifying the "sub-products" (configuration items) set of products, and managing and controlling them.
2. "configuration item management" provides control and management of sub-products (configuration items) and supports "correct sub-products"
3. "Change Management" and "complete product set and correct sub-products" are supported to control changes to sub-products (configuration items) and products (baselines ).
4. "configuration identifier": identifies and names configuration items (sub-products) and supports "configuration item management"
5. "version control" controls the lifecycle of configuration items (sub-products) and retains the evolution history of configuration items (sub-products ).
6. "Process Management" refers to the establishment of configuration items, baselines, status indication of changes, and process control to ensure that products (or sub-products) are operated in accordance with the prescribed procedures; for example, the "configuration item" enters the "baseline" process, including configuration item labeling, Product verification, configuration entry, and configuration auditing.
7. "configuration plan", "configuration database management", "configuration audit", and "Configuration Report" are supported by the entire configuration management system. Provides "visibility" and supervision management for configuration management

2 configuration and configuration items

In configuration management, "configuration" and "configuration items" are important concepts. "configuration" is a technical document that clearly describes and ultimately forms the functional or physical properties of software products. Therefore, "configuration" includes all the product features to be controlled, its content and related documents, software versions, change documents, and support data for software operation, and all other components that ensure Software consistency. Compared with hardware configurations, the "configuration" of software products includes more content and is variable.
Controlled software is often divided into various configuration items (CIS). This type of Division is the basis and prerequisite for Software Configuration Management, and CIS is a logical component of the software system. For example, a software product includes severalProgramModule, each program module and its related documentation and supporting data may be named as a CI. The number of CIS contained in a system is closely related to the design. A software-only Ci is also called a software configuration item (csci ).
All configuration management tools now provide configuration item management tools, including (check in and check out mechanism) Version Management and version label functions. Because version and label management is cumbersome, we recommend that you use configuration management tools to reduce transactional work.

3 baseline

In the Configuration Management System, a baseline is a status in which a CI or a group of CIS enters the formal control after being officially reviewed at different time points in its lifecycle, this process is called baseline ". Each baseline is the starting point and reference point for the next development. The baseline determines a version of the element (configuration item), and only one version is determined. Generally, baselines are created at specified milestones and synchronized with milestones in the project.

Generally, the first baseline includes the software requirements that pass the review. Therefore, it is called the "requirement baseline". By establishing such a baseline, the controlled system requirements become the starting point for further software development, changes to requirements are formally initialized and evaluated. Controlled requirements are the basis for functional reviews of the software.
Each baseline will be strictly controlled by configuration management, and its modifications will be carried out in strict accordance with the change control requirements. At the end of a software development phase, add and modify the baseline content to the previous baseline to form the next baseline. This is the "baseline management" process.

A baseline has the following attributes: Established through formal review process The baseline exists in the baseline database and is subject to higher permission Control for baseline changes. Baseline is the benchmark and starting point for further development and modification. Changes are not managed or rarely managed before entering the baseline. After entering the baseline, the changes are managed effectively, and this baseline serves as the basis for subsequent work. Do not include things that will not change into the baseline Changes that have no impact on others may not be included in the baseline

Benefits of creating a baseline: Reproducibility: the ability to return and regenerate a given release version of the software system in a timely manner, or to regenerate the development environment earlier in the project. When an update is considered unstable or untrusted, the baseline provides the team with a way to cancel the change. Traceability: Establishes the inheritance relationship between project artifacts. The purpose is to ensure that the design meets the requirements,CodeImplement the design and compile executable files with correct code. Version isolation: The baseline provides a fixed point and snapshot for the development artifacts. New projects can be created from the fixed point provided by the baseline. As a separate branch, the new project will be isolated from subsequent changes to the original project (on the main branch.

4 Relationship Between baselines, configurations, and configuration items

The composition of the baseline, as well as the relationship between configuration items and configurations, such:

Baseline management steps: 1. Determine the "configuration" of the baseline before development" 2. Check whether configuration items are complete Based on configuration items before baseline approval 3. Check whether the version of each configuration item is correct. 4. Create a baseline flag for each configuration item, Example: Test Baseline = (configuration item A = 1, configuration item B = 1, configuration item c = 1) Alpha = (configuration item A = 2, configuration item B = 1, configuration item c = 1) Beta = (configuration item A = 3, configuration item B = 3, configuration item c = 2) Product Baseline = (configuration item A = 4, configuration item B = 4, configuration item c = 4) 5. Baseline change management 6. baseline reports and audit information

For a specific project, you can create a baseline information tracking table based on the baseline content, for example:

[Note]: indicates that the parameter is overwritten by a color block. This parameter belongs to the baseline of the corresponding column.
[Note]: Enter the version number of the corresponding configuration item in the color block section.

5. Change management

After the configuration is effectively marked and managed, how can we ensure that they are truly under control in the complex and variable development process, changes can be quickly restored to any historical State under any circumstances.

Problems caused by the lack of effective change request management: Software Product quality is low, and some defects are corrected. The project manager does not understand the development progress and lacks the ability to objectively assess the current situation of the project. Developers do not know the priority of their jobs. They may put urgent tasks aside and work on general priority tasks. Incorrect Use and reference of changed products may cause confusion in development

Change management process: (Obtained) Submit a change request; It is reviewed and determined by CCB for approval; Allocate a person for (accepted) modification request, extract SCI, and modify; Submit the modified SCI and test (or review ); Rebuilding an appropriate version of the software; Review (Audit) All Sci changes; Release a new version.

In order to better guide the impact analysis of the scope of changes, two types of tables can be used to help find the content affected by the changes. One is the requirement tracking table. one is the configuration item dependency table, which is as follows:

6. Configure Database Management

In the system of actual development activities, in order to allow each developer and each development team to cooperate in a better division of labor without interfering with each other, it is necessary to plan the management of the workspace. The main method is to set the configuration Library (that is, folder settings), and set the version branch to manage the configuration item permissions.

Set version Branch

Basically, each configuration item is divided into three different branches from the very beginning: private branch, Integration Branch, and public (trunk) Branch. Let them correspond to three types of workspace respectively.

Private branch: The private branch corresponds to the developer's 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.

Integration Branch: The Integration Branch corresponds to the public space of the development team. All configuration items to be shared by members in the same group are obtained from this branch. That is, developers must merge the development results in the private workspace (merge) to this branch before entering the next development activity. All development tasks involving multi-person coordination (such as integration testing) must work in this space. The development team has read and write permissions on the Integration Branch, while other members only have read-only permissions. The management of this branch is the responsibility of system integrators and related designated personnel.

Public (trunk) branches: The public branch corresponds to the public space of the entire software development organization. After the current tasks of each development team are completed, the versions that can be released will be merged into the branch. The versions on the branch will prevail when you need to view relevant information in the future. This branch provides read-only permission to all software personnel in the Organization. The system integrator is responsible for the management of this branch.

The three types of workspace (branches) defined above are managed by the configuration administrator in a unified manner, and corresponding version selection rules are customized according to the actual situation of each development stage to ensure the normal operation of development activities. When a change occurs, the baseline should be promoted in a timely manner.

Configuration library settings

Determining the configuration library structure is an important basis for configuration management activities. Generally, two organizational forms are commonly used: database creation by configuration item type and database creation by task.

Database creation by configuration item type is often recommended by some consulting service companies. It is suitable for general application software development organizations. Such organizations generally have strong product inheritance and unified tools, which have certain requirements for parallel development. Using such a library structure is conducive to the unified management and control of configuration items, while also improving the compilation and publishing efficiency. However, because such a library structure is not oriented to the development tasks of various development teams, the working directory structure of developers may be too complex and cause unnecessary troubles.

The corresponding configuration library created by task is suitable for R & D organizations of professional software. In such an organization, there are a wide variety of development tools used, and the development model focuses on linear development. Therefore, there is no need to strictly classify and store configuration items, increasing the complexity of directories manually. Therefore, I believe that, especially for R & D software organizations, this setting policy is more flexible.

Routine work of the configuration Library

The routine work of the configuration library is transactional, mainly to ensure the security of the configuration library, including:

Regular backup of the configuration Library

Clear useless files and versions

Checks and improves the performance of the configuration library.

7. Configuration Report

The configuration status report reports the progress of software development activities to managers based on the configuration item Operation Records. 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 to serve as a reference for the development progress report. The changes should also be reported to describe the project status. Sometimes, the configuration library is also described, such as the number of backups, disk space usage, and so on. Any information of interest can be used as the status report content. This information can be effectively recorded and often used as an important data source for project measurements.

8 configuration 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. The audit mechanism ensures that the modified actions are completely recorded. That is to say, it records who modified the artifacts, when the modifications were made, why the changes were made, and where the changes were made. If some configuration management tools (or version control tools) are supported during version control, then, the four "W" (who, when, why, and what) required for the audit can be automatically recorded ). The configuration audit should be described as follows.

Information that should be described in configuration audit: 1. The change request has been completed and the additional modification has been executed. 2. correct formal verification methods are adopted 3. compliant with standard requirements 4. The 4 W information of the change is fully recorded and associated with the relevant configuration items

9. Project Implementation Guide

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.

At the beginning of a project establishment, the Project Manager 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 software configuration management activities are doomed to become 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.

In the development and maintenance phases, Software Configuration Management activities are divided into three layers, which are an organic whole that is independent and interconnected with each other.

(1) management and maintenance work mainly completed by the configuration personnel;

(2) system integrators and developers should execute software configuration management policies;

(3) change process.

Software Phase	Active	Activity description
PLANNING PHASE	Develop software plans	At the beginning of a project establishment, the project manager must first develop the overall project plan.
	Confirm Configuration Policy	The Configuration Management Board (CCB) identifies milestones and development strategies based on the project's development plan
	Configure a plan	The configuration personnel should formulate detailed configuration management plans based on the CCB plan and submit them to the CCB for review.
	Approve configuration plan	After passing the Configuration Management Plan, CCB submits the plan to the project manager for approval and releases the plan.
Development and Maintenance	Determine the initial baseline	CCB sets the initial baseline for R & D activities
	Configuration Library Management	The configuration personnel should set up the configuration library and workspace according to the Software Configuration Management Plan to prepare for the implementation of Software Configuration Management; and regularly back up and clean up the work.
	Authorized Development	Developers perform project R & D based on the authorized resources according to the unified software configuration management policy.
	Integration	System integrators integrate the work results of developers in the group according to the project progress, build a system, and promote version Evolution
	Manage baselines	Based on the project progress, CCB establishes baselines in a timely manner, approves baseline changes, and ensures orderly development and maintenance.
	Product Release	The system integrator performs product integration and is released with the approval of CCB.
Other	Configure MEETING	CCB regularly holds regular meetings to modify the configuration management plan based on the information of the members, the report of the configuration personnel and the request of the developers, and is responsible to the project manager.
	Configuration Report and audit	The configuration personnel should submit audit reports to the project manager and CCB on a regular basis, and report possible problems and Improvement Plans of the project during the software process at the configuration management meeting.
	Change management	Event trigger execution, approved by CCB, executed by the project team, and audited

10 Configuration Management deployment model

Basic Process

Serial number	Phase	Activity	Remarks
1	Obtain the corresponding management right
1.1		Establish appropriate teams
1.2		Obtain authorization and resources	Hold a kick-off meeting
2	Evaluate the Configuration Management Status
2.1		Draw and evaluate the control chart of the current process	CMM standards available
2.2		Understand employees' attitudes towards Configuration Management
2.3		Understand the technical level of organization Configuration Management
2.4		Understanding Leadership expectations
2.5		Prepare and review the evaluation report	Obtain "status information"
3	Select Configuration Tool
3.1		Prepare and review the evaluation score table
3.2		Evaluate configuration tools and suppliers
3.3		Collect User experience from other users
4	Configuration process definition		Draft Configuration Management Process
4.1		Use "status quo information" and collected experience
4.2		Develop new processes
4.3		Review new processes and create new process baselines
5	Pilot
5.1		Select pilot project
5.2		Determine the pilot team
5.3		Define pilot success criteria and progress
5.4		Pilot Project Personnel training
5.5		Pilot Improvement	Improvements to the draft
5.6		Pilot Summary/promotion	Release the formal process
6	Full implementation
6.1		Set up relevant departments and teams
6.2		Develop implementation plans for each project
6.3		Training on configuration management knowledge, processes, and tools
6.4		Migration of various projects to the new process
6.5		Routine Supervision, spot check, and communication
7	End		Summary and rewards

OperationsCompositionParts

Corresponding process: 2.2 understand the employee's attitude towards configuration management and establish a checklist for investigation, as shown below:

Serial number	Investigation content	Survey results
1	Has a similar attempt been made, succeeded or failed?
2	Is there any painful experience caused by poor Configuration Management?
3	Is the configuration management process supported?
4	Do you think the configuration management process will suppress creativity?
5	Is the configuration management process too cumbersome?
6	Unreasonable expectations for configuration management
7	Is there any quick success?
8	Interested in implementing configuration management tools
9	Personal heroism and division of labor collaboration are the mainstream

Corresponding process: 2.3 understand the Organization's configuration management technology level and establish a checklist for research, as shown below:

Serial number	Investigation content	Survey results
1	Whether the configuration management process and operation time are available
2	Whether the configuration management tool is used.
3	Have you received special configuration management training and training time?
4	Understanding of the Configuration Management Process
5	Usage of configuration management tools
6	Basic Quality and learning ability of enterprise employees

Corresponding process: 3.2 The Configuration tool supplier should establish a checklist for investigation, as shown below:

Serial number	Investigation content	Survey results
1	Can the tool solve the current problem and meet the current needs?
2	Product Market Position
3	Product Price
4	Compatibility with existing environments
5	Running capability (peak value, maturity, and stability)
6	Support future requirements?
7	Availability: workspace management
8	Available or not: Version Control
9	Available or not: Configuration Report
10	Availability: Process Support
11	Security and protection?
12	Availability: tool Integration
13	Supported or not: construction support
14	Graphic Interface?
15	Available or not: Custom support
16	Availability: release management
17	Available or not: Web Support

Corresponding process: 3.2 The Configuration tool supplier should establish a checklist for investigation, as shown below:

Serial number	Investigation content	Survey results
1	Configuration Management Service Time
2	Number and quality of successful cases
3	Training and Technical Support Team
4	Training and guidance and other services provided
5	Recent goodwill, assets, and sales of service configuration
6	Geographic location and service Timeliness

Corresponding process: 4.2 create a new process 1. the configuration management process should include at least configuration tags, configuration control, reporting, and auditing. the following table should be taken into account when the tool is included in the configuration.

Serial number	Considerations
1	Work out transactional and creative work from the configuration process
2	Considering the complexity and precision requirements of transactional work, an automatic priority is proposed"
3	Determine where the tool can be used based on the process
4	Select tool functions based on "automation priority" for Automation
5	Prerequisites and results for automated use of tool Functions
6	Divide "Automation" and "Manual" interfaces and clearly describe them
7	Adjust process elements and adapt to tools to form a configuration management process that is incorporated into the tools.
8	Considering the applicability and benefits of this Process

Corresponding process: 6.1 the team that sets up the corresponding department and team for configuration management deployment and implementation must include

Serial number	Team members	Responsibilities and requirements
1	Team Lead	Responsible for management team and deployment and implementation of Configuration Management
2	Technical staff	Interfaces between various tools to be integrated with the configuration tool
3	Configuration expert	Proficient in configuration tools and theoretical knowledge of Configuration Management
4	Process Expert	Responsible for Process Modeling and main Process Analysis
5	Configuration Management Personnel	Reviews new processes and provides original configuration management experience
6	Project Manager	Reviews the new process and provides reference for configuration management to adapt to the project.

Corresponding process: 6.2 The implementation plan of each project should include:

NO.	plan content
1	Target and completion criteria
2	investment and income analysis
3	stage division and schedule
4	resource investment arrangement
5	division of labor and Organization
6	risk management