Configuration management is the discipline to systematically control configuration changes, maintain configuration integrity and traceability throughout the system lifecycle , and identify system configurations at different points in time.
In GB/T 11457- -2006, "configuration management" is formally defined as: " The application of technical and management guidance and monitoring methods to identify and describe the functional and physical characteristics of configuration items, control changes to these characteristics, record and Report change processing and implementation status and verify compliance with stated requirements ."
Configuration management consists of 6 main activities:
Develop configuration management plans, configuration identification, configuration control, configuration status reporting, configuration auditing, release management, and delivery
How to conduct a configuration management plan
There are two main configuration control tasks: ① involves the state transition management of the program ② involves the management of change requests that must be implemented
1. Configuration items
GB/T 11457-2006 (software engineering terminology) defines a configuration item as: "A collection of hardware, software, or both designed for configuration management, which is treated as a single entity in the configuration management process." Examples of configuration items There are: delivered software products and data, support tools used to create or support software products, software provided by suppliers and equipment/software provided by customers, various documents, source codes, executable codes, test cases, various data required .
The configuration items that need to be controlled during the development of information systems can be divided into two categories : baseline configuration items and non-baseline configuration items . For example, baseline configuration items may include all design documents and source programs, etc.; non-baseline configuration items may include various plans and reports of the project, etc.
The operation authority of all configuration items should be strictly managed by the CMO (Configuration Manager). The basic principle is: the baseline configuration items are open to developers to read; the non-baseline configuration items are open to PM, CCB and related personnel.
What are typical configuration items:
requirements specifications, design documents, source code, test plans, test scripts, test procedures, test data, standards used in projects (such as coding specifications and design specifications), acceptance plans, CM plans, and project plans Documentation for classes, user documentation such as user manuals, training material documentation, contract documentation (including support tools such as compilers or tools used internally), quality records (review records, test records) and CM records (release records, status Track record).
2. Configuration item status
The status of configuration items can be divided into "Draft", "Official" and "Modified"
3. The version number of the configuration item
(1) The format of the version number of the configuration item in the "draft" state is 0.YZ , and the number range of YZ is 01~99. As the draft is revised, the value of YZ should be incremented. The initial value and increase of YZ are determined by the user himself. .
(2) The format of the version number of the configuration item in the "official" state is XY, where X is the main version number, and the value range is 1~9. Y is the minor version number, and its value ranges from 0 to 9.
When a configuration item first becomes an "official" document, it has a version number of 1.0.
If the configuration item upgrade is relatively small, the changed part can be made as an attachment of the configuration item, and the attachment versions are 1.0, 1.1, . When the changes of attachments accumulate to a certain extent, the Y value of the configuration item can be increased appropriately, and when the Y value increases to a certain extent, the X value will increase appropriately. It is only allowed to directly increase the X value when the configuration item upgrade is relatively large.
(3) The format of the version number of the configuration item in the "modified" state is X.YZ. When the configuration item is being modified, generally only the Z value is increased, and the XY value remains unchanged. When the configuration item is modified and the status becomes "official", set the Z value to 0 and increase the XY value. See rule (2) above.
4. Baseline
Baselines usually correspond to milestones in the development process (Milestone), a product can have multiple baselines, or only one baseline. The baselines delivered to external customers are generally called release baselines (Release), and the baselines used for internal development are generally called construction baselines (Build).
A baseline is a specific point at the end of each development phase in a project's life cycle, also known as a milestone, at which phase work has ended and a formal phased product has been formed.
The concept of establishing a baseline is to divide the work of each development stage more clearly, so that the development work that was originally carried out continuously is separated at these points, which is more conducive to testing and affirming the results of the stage work, and at the same time it is conducive to change control. . With the provisions of the baseline, it is forbidden to cross the milestone to modify the work product of another development stage, and it is considered that the milestone has been established, and some completed stage results have been frozen.
As a formal product of stage work, the baseline should be stable, such as the design specification as the design baseline should pass the review. If it is only a draft design, it cannot be used as a baseline and cannot be frozen.
If software is regarded as an integral part of the system, the following three baselines are the most concerned: functional baseline, distribution baseline, and product baseline.
1) Allocation baseline (assignment baseline): refers to the formally reviewed and approved specification of software requirements at the end of the software requirements analysis phase . An assigned baseline is an initially approved designation of an assigned configuration.
2) Functional baseline: refers to the specification of the system to be developed in the system design specification that has been formally reviewed and approved at the end of the system analysis and software definition phase ; or refers to the agreement signed and agreed by both the project entrusting unit and the project undertaking unit The specification of the software system to be developed stipulated in the book or contract; or the specification of the software system to be developed stipulated in the project assignment document applied by the subordinate with the approval of the superior or directly issued by the superior. A functional baseline is the initial approved functional configuration flag.
3) Product baseline: refers to the specifications of all configuration items of the developed software product that have been formally reviewed and approved at the end of the software assembly and system testing phase . A product baseline is a sign of the initially approved product configuration.
In addition, the baselines delivered to external customers are generally called release baselines, and the baselines used internally are called construction baselines . Release refers to the process of submitting the products of this stage from that stage to the next stage at the end of each stage of the software life cycle. It also refers to the process of submitting the final product obtained at the end of the integration and system testing phase to the user. This latter process is also known as delivery.
The concept of baseline was originally proposed to better achieve change control, but if each baseline is treated as a whole, it will cause trouble. Because a change is likely to touch only a small part of the baseline. For example, suppose a module in a large piece of software is modified, and it would be inconvenient to treat this change as a change to the baseline of the entire software product.
5. Configuration library
The configuration library can be divided into three types: development library, controlled library, and product library.
6. Configuration Control Board (Configuration Control Board, CCB),
Responsible for evaluating and approving configuration changes and overseeing the implementation of approved changes.
CCB is established at the project level, and its members can include project managers, user representatives, product managers, development engineers, test engineers, quality control personnel, configuration administrators, etc. CCB does not have to be a permanent body, and can be formed according to the needs of the work, for example, different CCBs can be formed according to the change content and change request. A small project CCB can have only one person, or even just a part-time person. Usually, CCB not only controls configuration changes, but also undertakes more configuration management tasks, such as: configuration management plan approval, baseline establishment approval, product release approval, etc.
7. Configuration management key activities
1. Configuration item (Software Configuration Item, SCI) identification
"The output information of a software process can be divided into three main categories: (1) the computer program (source code and executable program), (2) the program's documentation (for technical developers and users), (3) data (contained in the program internal or external).
Establish baseline control - hit lable
IEEE's definition of baseline is as follows: "A specification or product that has been formally reviewed and approved, it can therefore be used as the basis for further development, and can only be changed through a formal change control process." We are in the software development process Divide all configuration items that need to be controlled into baseline configuration items and non-baseline configuration items, for example: baseline configuration items may include all design documents and source programs, etc.; non-baseline configuration items may include various plans and reports of the project wait.
2. Workspace Management
After the software configuration management tool is introduced, all developers will be required to store the work results in the configuration repository managed by the software configuration management tool, or work directly in the environment provided by the software configuration management tool.
- Generally speaking, the ideal situation is to treat the entire configuration library as a unified workspace, and then divide it into three categories: personal (private), team (integration) and whole group (public) according to needs Workspaces (branches) to support parallel development needs.
Each developer works in different workspaces at different development stages according to the requirements of the task. For example, for a private development space, after the developer obtains the operation permission for the corresponding configuration item according to the division of tasks, he is in the Work on his own private development branch. All his work results are reflected in the advancement of the version on the private branch of the configuration item. Except for the developer, no other person has the right to operate the elements in the private space, and the integration The branch corresponds to the public space of the development team. The development team has read and write permissions to the integration branch, while other members only have read-only permissions. Its management is in charge of the SIO; as for the public workspace, it is used to It stores the staged work results of each development team, and it provides a standard version of the whole group system and serves as the Knowledge Base of the entire organization.
3. Version control
Version control is a core function of software configuration management. All elements placed in the configuration library should be automatically identified by version, and the uniqueness of version naming should be guaranteed. Improvement, SPI) activities.
4. Change Control
In the description of SCI, we introduce the concept of baseline. From IEEE's definition of baseline, we can find that baseline is closely related to change control. That is to say, after identifying each SCI and using tools to implement version management on them, how to ensure that they are truly in a controlled state during the complex and changing development process, and can be quickly implemented under any circumstances? The restoration to any historical state has become another important task of software configuration management. Therefore, change control is a mechanism for providing a change control by combining human procedures and automated tools.
In the previous part of this article, SCI has been divided into two categories: baseline configuration items and non-baseline configuration items, so the change control objects involved here mainly refer to each baseline configuration item in the configuration library.
The general process for change management is:
A) make a change request;
B) Reviewed by CCB and decide whether to approve or not;
C) (Accepted) Modify the request to assign personnel to, extract the SCI, and make the modification;
D) review changes;
E) Submit the revised SCI;
F) Establish a test baseline and test;
G) Rebuild the appropriate version of the software;
H) Review (audit) all SCI changes;
|) Release a new version.
5. Configuration Status Report
The configuration status report should be based on the report should focus on reflecting the status of the current baseline configuration items as a reference to the development progress report. At the same time, it can also analyze the working relationship of the development team according to the developer's operation records on the configuration items.
The configuration status report should include the following main contents:
(1) The identification and status of each controlled configuration item. Once a configuration item has been placed under configuration control, its version and status for each subsequent development should be recorded and saved.
(2) The status of each change request and the implementation status of approved modifications.
(3) The status of the current and past versions of each baseline and a comparison of the versions.
(4) Records of other configuration management process activities.
6. Configure auditing
Configuration Audit, also known as configuration audit or configuration rating, includes functional configuration audit and physical configuration audit, which are used to verify the consistency and completeness of current configuration items.
The implementation of configuration audit is to ensure the effectiveness of project configuration management, which reflects the most fundamental requirement of configuration management - no confusion is allowed, for example:
- Prevent delivery of unsuitable products to users, such as delivery of incorrect versions of user manuals.
- Imperfect implementations are found, such as development that does not meet the original specification or changes that are not implemented in response to a change request. Find mismatches or incompatibilities between configuration items.
- Verify that configuration items have been baselined and stored in the repository following the required quality control review. Verify that records and documentation are maintained for traceability.
1) Functional Configuration Audit
Audit the consistency of the configuration items (whether the actual effect of the configuration items is consistent with its requirements), specifically verify the following aspects.
- The development of configuration items has been satisfactorily completed.
- The configuration item has achieved the performance and functional characteristics specified in the configuration identification . ---Function and performance
- Operational and supporting documentation for the CI is complete and in compliance.
2) Physical Configuration Audit
Audit the integrity of configuration items (whether the physical existence of configuration items is consistent with expectations), specifically verify the following aspects.
- Whether the configuration item to be delivered exists.
- Whether all required items are included in the configuration item. .
Reposted from: Project Configuration Management CM (Configuration Management)_908486905's Blog - CSDN Blog