Configuration management process
Author: Gongyun Qing Write Date: August 13, 2004
1 summary
1.1 content
Specifically configure management activities to ensure that the configuration items are properly identified and easy to access, ensure that the reference configuration items are controlled, and the baseline status is clear, and the integrity and traceability of project products are established throughout the software lifecycle.
1.2 Scope of application
For different categories of software items, configuration management flows, can be cut on the basis of this process.
1.3 Terminology and Abbreviation
1.3.1 Software Configuration Management (SCM)
Software Configuration Management is a technology that identifies, organizes and controls software modifications, which is used to coordinate and control the entire process. It is a series of measures to control software products and their development processes and life cycles through technical or administrative means. The goal of configuring the management is to record the evolution of software products, ensuring that software developers can get exact different versions of product configuration in each phase in the software life cycle.
1.3.2 Configuration
The configuration is to clearly explain the function or physical properties of the software product in the technical documentation. Therefore, the configuration includes all product features that are about to control, their contents, and related documents, software versions, change documents, software running support data, and other components that ensure software consistency, relative to hardware configuration, software products The configuration includes more content and has volatility.
1.3.3 Configuration Item, Ci
Any working outcome of the configuration management category is collectively referred to as configuration items (CI), the configuration item logically constitutes the components of the software system, usually designed, implemented, and tested separately. A pure software CIS is often also known as the software configuration item (CSCIS).
There are two main classes of configuration items:
1) The work results of the product components, such as demand documents, design documents, source code, test cases, etc.
2) Documents generated by project management and institutional support. Although these documents are not part of the product, it is worth saving.
The main properties of each configuration item are: name, identifier, file status, version, author, date, etc. All configuration items are saved in the configuration library to ensure that they will not be confused and lost. The configuration item and its history reflect the process of evolution of the software.
1.3.4 Baseline (Baseline)
In the configuration management system, the baseline is a state in which a CI or a set of CIs enters formal controlled in different time points of its life cycle, and some configuration items constitute a relatively stable logic entity, and this The process is called "baseline". Each baseline is the starting point and reference point for its next development. The baseline determines a version of the element (configuration item) and only one version is determined. In general, baseline is typically created at the specified milestone and keep synchronization with milestones in the project. Each baseline will accept the strict control of configuration management. The configuration items in the baseline are "freeze", and they cannot be modified by anyone, and the changes to their modifications will be strictly in accordance with the process of change control requirements, in a software development phase At the end, the last baseline plus the increased and modified baseline content forms the next baseline.
The main properties of baseline are: name, identifier, version, date, etc. The baseline usually delivered to the customer is called a "release", which is called a "build" for the baseline for internal development.
Establish the benefits of baseline:
1) Reproducibility: return and regenerate the capabilities of the software system given a given release, or re-generate the ability to develop environment earlier in the project. When it is considered to be unstable or untrustworthy, baseline provides a method of canceling a change. 2) Trackability: Establish a front-rear inheritance relationship between project workpieces. The purpose is to ensure that the design meets the requirements, code implementation design, and compile executables with the correct code.
3) Version Isolation: Baseline provides a fixed point and snapshot for the development workpiece, the new project can be established from the fixed point provided by the baseline. As a separate branch, the new project will isolate the change in the original item (on the main branch).
2 related human rights
2.1 Project Manager (PROJECT Manager, PM)
responsibility:
1) Consultation with the CCB to determine the project start baseline and development milestones;
2) Accept the configuration management plan and implement it according to relevant regulations;
3) Accept the report of the Configuration Control Committee.
right:
1) The modification requirements of the configuration management plan are proposed;
2) Suggestions and requirements for management management.
2.2 Configuration Control Board (Configuration Control Board, CCB)
responsibility:
1) Develop and modify the configuration management strategy of the project;
right:
1) Approve, release configuration management plan;
2) Establish, change the settings of the baseline, review the application;
3) Determine the corresponding countermeasure based on the report of the configuration administrator.
2.3 Configuration Administrator (Configuration Management Offer, CMO)
responsibility:
1) Prepare configuration management plans;
2) Perform a configuration item management scheme;
3) Execute version control and change control scheme;
4) Prepare the configuration status report;
right:
Reporting to the CCB Reporting to the Unqualification of the Configuration Management Process.
2.4 Profile Administrator (Program Librarian, PL)
responsibility:
1) Configure the establishment and authority assignment of the library;
2) Daily management and maintenance of configuration management tools;
3) Configure the daily operation and maintenance of the library;
right:
1) Management and maintenance of each configuration item;
2) Training for developers.
2.5 Developer (Developer)
responsibility:
1) Submit a configuration item and baseline according to the determined configuration management plan and related regulations;
2) Responsible for software integration and version generation.
right:
Follow the software configuration management tool to complete the development task.
2.6 Tester (Tester)
responsibility:
Submit the test configuration item and test baseline according to the configuration management plan and related regulations;
right:
Responsible for the test verification of software changes.
2.7 Software Quality Asssurance (SQA)
responsibility:
Responsible for configuring and submitting a report.
right:
Relevant responsible persons are required to be corrected to the non-conformity discovered in the configuration review.
3 implementation rules
3.1 Establishment of CCB
3.1.1 After the project is in design, the project manager is responsible for organizing the CCB.
3.1.2 Members of CCB
The number of people with CCB is generally odd, and the number is in the range of 3 to 7. CCB members generally include:
1) Project manager PM;
2) Configure the administrator CMO;
3) sqa;
4) Tester Tester;
5) Customer representative;
6) Main developers, etc.
3.1.3 Decision mechanism for CCB seeks consensus on CCB members. If it is not possible, it is possible to make a decision by the customer; or take a few principles from the majority of the majority, and the CCB member is verified, and the votes exceeded half.
3.2 Determine configuration strategy
3.2.1 Configuration Policy Determined Timetry
After the CCB is established, the CCB organization meeting determines the project baseline and the project baseline and configuration item list according to the project development plan, and the CMO is responsible for the identified project baseline and configuration item list, and is collected in the preparation of the Configuration Management Plan, collect configuration Item and establish an initial baseline.
3.2.2 Scope of configuration items
1) Technical documentation: Project development plan, demand analysis report, software design book, quality assurance plan, summary design book, detailed design book, test document, technical report, user manual, summary report, etc .;
2) Program: stage products, computer programs, source programs, release products, etc .;
3) Tools: Automatic design tools, development tools, test tools, maintenance tools, etc .;
4) Communications: interact with the customer or project group, such as talks, e-mail, meeting minutes, MSN records, etc.
3.3 Develop a configuration management plan
3.3.1 Preparation of Configuration Management Plan
Normally, after the design is influent, the "Configuration Management Plan" is started; if there is special needs, according to the contract or project requirements, the CMO is set before the "Configuration Management Plan" before a certain phase of a project or project ".
3.3.2 Content of Configuration Management Plan
The Configuration Management Plan should include the following:
1) The project is required for configuration management;
2) The responsible persons, organizations and their duties of allocation management;
3) The configuration management activities that need to be carried out and its schedule;
4) Methods and tools used.
3.3.3 The Configuration Management Plan is approved by the CCB.
3.4 Configuration item identification rules
3.4.1 Configuration Item Identification Requirements
1) When the contract is clearly identified and tracked, the developer is identified by the contract request to ensure the contract tracking requirements.
2) The configuration item submitted by the project group personnel during the development process is identified by the project group in accordance with this section.
3) The project team personnel submitted to the CMO into the configuration library unified management and fill in the configuration status report.
3.4.2 Configuring Item Identification
3.4.2.1 Item Item
Configuration item identity properties include: name, number, file status, version, author, date, etc. This document describes the name, number, file status, and versions of the name.
3.4.2.2 Name
The identity of the file name is subject to the unified name in the document template.
a) number
Document number format is cc_xxx _ *** _ $$$ _ ###, where CC represents company, XXX is the three English letters of the project, *** _ $$$ Representation document category, ### indicates document order number. At the same time, each content has a fixed index file cc_xxx _ ** _ $$$ _ index, the purpose is to create a list of documents to this category to ensure that the document is identified and retrieved.
3.4.2.3 File status
The file status is divided into three kinds of "Draft", "officially released" and "modified".
Modify the configuration item in the "Draft" state is not "change", no need to approval by CCB, the modifier is executed according to the version control rule.
When the status of the configuration item is "officially released", or after being "freezing", anyone cannot modify at this time, and must be executed according to the rules of configuration change control.
3.4.2.4 Document Version Control
For planned documents, technical documents, and user documents, its version is determined in the order of modification. The newly generated document is first issued as the first edition, and the second release will be second edition after the modification will be pushed.
3.4.2.5 Release Control The final software version is represented by triple symbol: "s.x.y". The meaning of each symbolic bit is as follows:
1) "Y" is the second version number, indicating that the version upgrade when the error is correct, indicating one digit: "1 ~
9
"
, Correct the defects in the last product or project, the second version number increases;
2) "X" is the first version number, indicating that the version upgrade when the function is increased, indicating a number: "0 ~
9
"
. Compared with the previous product or project, the function has increased or corrects, the first version number increases, the second version number is zero, the second version number is zero, and the non-written can be omitted;
3) "s" is the main version number. The main version number is increased when the product is improved in function and performance, and the product or project concept is new, the product or project concept is new, and the version number is 1.0.
3.4.2.6 Baseline version identity
Internal baseline, such as plan baseline, design baseline, etc., add builds in front of the version, such as Build 1.0;
The release product baseline plus Release 2.0.
3.5 Configuring Library Management
3.5.1 Classification of Configuration Library (Repository)
The configuration library is divided into two categories:
1) Document library: Managed by CMO, mainly using the document data (including pictures, etc.) other than the program.
2) Program Library: Managed by the PL, mainly using the CVS version tool to manage the program code.
3.5.2 Configuring the establishment of the library
3.5.2.1 After the CCB is established, the PL can set up a configuration library. All projects should establish a configuration library to manage each configuration item.
3.5.2.2 Document Library Space is created by the ESM system, and the PL only creates a baseline document library, only PL can operate it.
3.5.2.3 The library mainly implements the configurable entry management, basically to be divided into three different branches from the establishment of each configuration (Figure 1):
Figure 1 Configuring a library spatial allocation and version migration strategy
1) Private branch: Private branch corresponds to the private development space of the developer. After obtaining the operation license of the corresponding configuration according to the task division, he works on his own private development branch, and all his work results are reflected in the promotion of the private branch of this configuration, except for the developer. In addition, other people do not have to operate the elements in the private space.
2) Integration Branch: The integrated branch corresponds to the public space of the development team. All configuration items shared for the same group will be obtained from the branch. That is, each developer must return the development of the private workspace to the branch to enter the next development activity. All development work involving multiplayers (such as integrated testing, etc.) must work in this space. The development team has read and write permissions on the integration branch, while other members have only read only permissions. The management of the branch is responsible for PL and related specified personnel.
3) CommON Branch: Public branch corresponds to the public space of the entire software development organization. After the task of each development team is completed at this time, the version can be distributed to the branch, and the relevant information will be reviewed in the future, and the version is subject to the version. This branch opens read only permissions to all software personnel within the organization. The management of the branch is responsible by the PL.
3.5.2.4 The three-class branches of the above definitions and document libraries are managed by CMO, and the corresponding version selection rules are customized according to the actual conditions of each development phase to ensure the normal operation of development activities. When changing, the baseline advancement should be made in time. 3.5.3 Assignment Permissions
PL assigns a configuration library operation permission for each project member. Generally, project members have add, checkin / checkout, butnload, etc., but cannot have "delete" permissions. The PL has the highest permission.
3.5.4 Configuration Library Operation and Management
3.5.4.1 Developers conduct project research and development, operational configuration libraries, such as Add, Checkin / Checkout, Download, etc. according to the licensed resources obtained.
3.5.4.2 PL Create and maintain the baseline, "freeze" configuration item, control change according to the configuration management plan.
3.5.4.3 Profile detection
When the change is changed and the review is passed, or the bug is discovered, the COS in the common branch is detected by the COS BRANCH to the developer's Private Branch, and the developer is changed.
3.5.4.4 Input in the configuration library
When the change is ended or the bug correction and test end, and after the review is configured, the changed CIS is checked to the Common Branch.
3.5.4.5 PL regularly clears the garbage file in the configuration library.
3.5.4.6 PL Regular backup configuration library.
3.6 Configuration Items and Baseline Management
3.6.1 CMO The configuration item and baseline are seized according to the configuration management plan.
3.6.2 Project starts
Configuration items include demand instructions, orders and their review results, etc. After the project is influential, the subproject should be blocked and the betting baseline is established.
3.6.3 Analysis of Demand
After the system research, the developer is systematically analyzed, and the demand analysis report is organized. Demand Analysis Reports shall be determined by the review. After obtaining the customer's confirmation, the subproject is blocked and the demand baseline is established. If you need to upgrade, you must approve and get a confirmation of the customer.
3.6.4 Project Plan
After the demand analysis is completed, the project development plan can be developed, including the overall progress of the project, schedule, scheduled modification, configuration management plan, quality assurance plan, test plan, etc. After the project development plan review, block the subproject and establish the baseline baseline.
3.6.5 System Design
The system design can be divided into a summary design, detailed design and database design. System design is performed for system design and configuring the system design, and the correspondence of the requirements of the system design should be explained. After the design book review is passed, the design baseline is established.
3.6.6 Coding
Encoding a functional module molecular item, that is, each module is a configuration item. The code baseline establishes an Alpha version after the end of the unit test, and the BETA version is established after the Alpha test, and the MERGE post is established when the test is integrated.
3.6.7 Test
Test programs, test cases, test results, and test analysis reports should be provided. After the project is started, the project test plan should be submitted, and the project test summary report should be submitted after the end of the project acceptance. The version of the test should be explained when configuring the corresponding relationship between the encoded version. Each phase test (such as unit test, integrated test) is completed, and the test baseline is established.
3.6.8 Delivery and Acceptance
The product baseline, product baseline containing procedures, and related document configuration items, including delivery construction documents, tools, etc.
3.6.9 Project Summary
The project summary should be reviewed within the department, including project quality report, test report, etc.
3.6.10 Related Information and Training
Relevant information and training should also be included as a configuration item into configuration management, including:
1) Relevant laws, regulations;
2) It is necessary to follow the technical specifications of the project group;
3) Imported information records within the customer or project group, such as Question Sheet, Meeting Record, Talks, E-mail, and MSN;
4) The necessary business or technical training, etc.
3.7 Configuration Change Control
3.7.1 Classification of change
Changes in software and related documents are classified according to the impact of changes: 1) A level: Change affects system level requirements, external interfaces, product prices or delivery periods; such changes must be reviewed and confirmed by CCB and confirmed.
2) B-class: Change will affect the functional interface, component level cost or project schedule between the configuration, and this type of change must be approved and approved by the CCB or the superior management department.
3) C - class: Change will affect the design and allocation of the internal function of the configuration; this type of change can be approved by the management personnel of the configuration item.
Figure 2 Change Control Process
3.7.2 Proposal of the change request
3.7.2.1 Determine changes by the initiator (customer, end user or development department), fill in the "Change Request / Review Spend", describe the change reason and change content, and submit it to CMO.
3.7.2.2 CMO is reviewed, clear and integrity, and if the CMO discovery changes are not clear or incomplete, the application form should be returned to the initiator. CMO is assigned a change ID by applying a change in the review to track and record change information.
3.7.3 Change Evaluation
3.7.3.1 CMO Sends the "Change Request / Review Form" to the Project Manager (or other authorized personnel), and the project manager is responsible for evaluating the change.
3.7.3.2 An important part of change control is the change assessment, and the change assessment is to analyze each change on system functions, interface, cost, progress, and aggregate impact. Also analyze software security, reliability, maintainability , The effects of portability and performance.
3.7.3.3 Change assessment The documentation generated by the evaluation should describe if the configuration item, document, and resource that must be changed; the change evaluation document is sent to CMO after completing the change evaluation.
3.7.3.4 CMO Received the "Change Request / Review Form" after the evaluation, update the change record and schedule the CCB conference schedule.
3.7.4 Change audit
3.7.4.1 CCB reviews the submitted change request, and determines the impact level of the change in the change assessment; three of the possible results of the CCB audit: accept changes; reject changes; extension changes. CCB may also require more information on changes.
3.7.4.2 CCB approval changes, by the CMO Send the change item to the specified developer (Assigner) to perform the next implementation change; for the change of the change, the CCB refuses to change the change to the initiator, and saves "Change Request / Review Spend", update change record, turn off change activities; need further analysis, by CMO will change the change item with the Question Sheet of CCB to evaluate analysts; for extension changes, CMO related documentation Archive in order to submit a CCB review in an appropriate time.
3.7.4.3 CMO is responsible for organizing the CCB meeting record, fill in the corresponding audit item in the Change Request / Review Form, updating the change record, if it is accepted, it is also necessary to change the CIS status to "modify"; change the document distribution Give relevant personnel.
3.7.5 Implementation
3.7.5.1 The change is approved, the PL is responsible for migrating the CIS and related documents to be changed to the private branch of the compelling person, and the change shall be implemented by the change, and the content of the change is recorded in detail; the project management department should implement the implementation of the change Track.
3.7.5.2 For code changes, you must modify the design, code, test, and change the correctness of the correctness. And the document related to the change must be revised to reflect changes. When the change and the test are completed, Merge is performed.
3.7.5.3 For development plans, the configuration management plan has changed, the project team should configure the management plan to submit the configuration item in accordance with the changed development plan.
3.7.6 Change confirmation
3.7.6.1 After the change program MERGE is required, it is necessary to return to the test group to ensure that the change is not introduced into the new bug. Changes from documents that do not cause program changes (such as planned documents) do not need to be tested. 3.7.6.2 After testing after MERGE, SQA needs to be reviewed, and the scope of auditing generally involves the following:
1) Test record;
2) Change request;
3) Inspection and detection of the configuration item;
5) Naming of the file;
6) Version number.
3.7.6.3 After the SQA review, developers can generate new versions, updated by PL to the baseline library.
3.7.6.4 PL should reissue all affected configuration items and versions.
3.7.6.5 Class A and B changes may also be generated until the next system release.
3.7.6.6 After generating a new version, CMO is responsible for collecting all change information archives, modifying a more CIS state is "officially released", closes the change, and sends the change report to the initiator.
3.8 Configuring Status Report
3.8.1 Configuring Status Report Purpose
Record and report the entire software life cycle evolution state.
3.8.2 Configuring the status report record
Configuring status report records include:
2) Identifies for software and documentation;
3) Current state;
4) Baseline evolution state;
5) Change status;
6) Version delivery information, etc.
3.8.3 Configuring Status Report Generation
The configuration management report is created from the first baseline, generated by the configuration management system, and reflects the current configuration status in time.
3.9 Configuration Review
3.9.1 Configuring the Category of Audit
Configuration review is divided into:
1) Functional Configuration Audit, FCA: The audit software function is consistent with demand and meets the requirements of baseline documentation; usually review test methods, processes, reports, and design documents.
2) Physical Configuration Audit (PCA): Audit whether the composition to be delivered is existing, whether you contain all the required items, such as the correct version of the source code, resources, documentation, installation instructions, etc.
3.9.2 Configuring the time of review
Usually selecting the following cases by SQA is responsible for implementing configuration review:
1) Software product delivery or software products are officially issued;
2) After the stage of software development is completed;
3) Perform in the product maintenance work.
3.9.3 Distribution of non-conformity
The non-conformity discovered in the configuration review, SQA is recorded, and fill in the "Do not meet the report", and the responsible department is configured to correct it, and SQA is responsible for correcting the verification of the actions. The new version can be issued after all the non-conformity reports are closed.
3.10 issuance management
3.10.1 After the review is configured, the project manager is responsible for producing a new version and checks in the product library by the PL and the version ID is performed in accordance with the 5.4 section configuration identification rules.
3.10.2 Delivery Management
Here "Delivery" refers to the person who extracted a configuration item from the configuration library, delivered to the customer or project. The configuration item delivered must be verified, avoiding chaos. The process is as follows:
1) "Request to take people" to the CCB delivery application.
2) CCB approval of the application. If the application is not legal (reasonable), the delivery configuration item is refused. If you agree to be delivered, the CCB should give a detailed delivery list.
3) The PL is based on the CCB's instructions, and the configuration item is delivered from the configuration library to "Request Man".
4) Sign after the "Request Human" is checked.
4 related documents (omitted)
5 record table (omitted)
