Software configuration management is about the management of software assets. source code, design documentation and other documents, runnable programs, automated test scripts, compilers and other tools and environments... everything that is valuable and worth preserving that is used or produced in the software development process is software assets. software configuration management is the management of these contents.
1. configuration management includes 6 main activities:
(1) make a configuration management plan. define how to do a good job of configuration management.
(2) configure the identity. identify what needs to be managed as a configuration item.
(3) configuration control. there are some changes to the configuration items, and you need to control the configuration changes.
(4) configure status reporting. what is the state of the configuration item that needs to be executed.
(5) configure auditing. audit the configuration effect, summarize the experience and lessons learned.
(6) release management and delivery. control the release of the official release, and keep the parent copies of the code and documentation properly.
2. Typical configuration items
include project plans, requirements documents, design documents, source code, executable code, test cases, and various data required to run software, and they enter the configuration management after review and inspection. configuration items can be modified. some documents are not modifiable after they are generated (e.g. measurement reports, meeting minutes, work reports), so they cannot be treated as configuration items.
3. the configuration items are divided into baseline configuration items (with version numbers) and non-baseline configuration items.
baseline configurations include configuration items for all development processes such as design documents and source programs; non-baseline configuration items include configuration items for management processes such as various plans and reports for projects.
4. the operation authority of all configuration items should be strictly managed by the cmo (configuration administrator).
the basic principle is that baseline configuration items are open to developers with read permissions, and non-baseline configuration items are open to pms, ccbs, and related personnel.
5. configure the version number and status of the item (the version increment is controlled by the user himself, but basically follows the following naming conventions):
0.YZ - > Draft. The state of the configuration item when it was first established. Before version 1.0, it was a draft, such as 0.1, 0.5, 0.99.
X.Y -> official. The reviewed status of the configuration item. Version 1.0 and later major+ minor versions are official. Such as 1.2, 2.3.
X.YZ -> Modified. The state in which the configuration item was modified. The version in the middle of the two official versions is a modification. Such as 1.21.
6. the version management of configuration items is used in multiple configuration management activities,
7. The configuration baseline consists of a set of configuration items,
such as configuration identification, configuration control and configuration auditing, release and delivery, etc. during project development, most configuration items undergo multiple modifications before they can be finalized. any modification to the configuration item results in a new version. since we can't guarantee that the new version will necessarily be better than the old version, we can't throw away the old version. the purpose of version management is to save all versions of a configuration item according to certain rules, avoid loss or confusion of versions, and quickly and accurately find any version of the configuration item.
which constitute a relatively stable logical entity. Configuration items in a baseline can no longer be modified by anyone, and changes to the baseline must follow formal change control procedures. A set of requirements, designs, source code, and corresponding executable code, fabric volumes, and user documentation with unique identification numbers form a baseline. A beta version of a product is a baseline. Baselines often correspond to milestones in the development process, and a product can have multiple baselines or may have only one baseline. The baseline delivered to external customers is generally called the release, and the baseline used for internal development is generally called the build.
for each baseline, define the following: event conditions for establishing a baseline, controlled configuration items, procedures for establishing and changing baselines, and permissions required to approve a baseline change.
8. configuration library type:
(1) development library (dynamic library, programmer library, working library): the configuration entity that the developer is developing can be modified as often as possible.
(2) controlled library (main library): submit the development library at the end of a certain stage to the controlled library. the current baseline plus changes to the baseline. storing stage products can be modified, but the change process must be followed.
(3) product library (static library, distribution library, software repository): submit the version of the controlled library that has no problem testing for release, that is, the product library. an archive of the various baselines that have been published for use. storing the final product, generally no longer modified, really to modify the need to go through the change process.
9. configure the library creation mode:
(1) according to the type of configuration items, the library is classified and built, which is usually used for the development organization of general software.
(2) establish the corresponding configuration library according to the development task, which is suitable for the development organization of professional software.
10. the configuration administrator assigns each project member the right to operate on the configuration library:
Read: Read, but not alterable
Check: Make changes to the contents of the file
Add: Append, rename, delete, etc
Destroy: Irreversible destruction, purging, rollback, etc
for the development, managed, and product libraries, different permissions are set for each member.
11. ccb: configuration control committee (also known as change control committee): responsible for evaluating changes, approving and supervising the implementation of approved changes.
(1) its members can include project managers, user representatives, product managers, development engineers, test engineers, quality control personnel, configuration administrators, etc.
(2) ccb is not a permanent establishment, and a small project ccb can have only one person, or even just a part-time employee.
(3) ccb is also responsible for: configuration management plan approval, baseline establishment approval, product release approval, etc. the ccb is the decision-making body, not the executive body.
12. Software configuration management is to establish and maintain
the integrity of project products throughout the entire software life cycle. the configuration administrator (cmo) is responsible for configuration management activities throughout the project lifecycle. the main activities are:
(1) write a configuration management plan and submit it to the configuration management committee for approval
(2) establish and maintain a configuration management system
(3) establish and maintain configuration libraries
(4) configuration item identification
(5) establish and manage baselines
(6) version management and configuration control
(7) configure status reporting
(8) configure auditing
(9) release management and delivery
(10) conduct configuration management training for project members
13. the main contents of the configuration management plan are:
(1) configure management activities, the main activities covered include configuration identity, configuration control, configuration status reporting, configuration auditing, release management and delivery.
(2) specifications and processes for implementing these activities.
(3) schedule for the implementation of these activities.
(4) the person or organization responsible for carrying out these activities, and their relationship with other organizations.
14. the configuration id is the function of the configuration administrator, and the basic steps are as follows:
(1) identify configuration items that need to be controlled
(2) specify a unique identification number for each configuration item
(3) define the important characteristics of each configuration item
(4) determine the owner of each configuration item and its responsibilities
(5) determine the time and conditions under which the configuration item enters the configuration management
(6) establish and control baselines
(7) maintain the relationship between the revision of documents and components and the product version
15. configuration control is the change control of configuration items and baselines,
including these tasks: identifying and recording change requests; analyzing and evaluating changes; approving or rejecting applications; implementing, verifying, and publishing modified configuration items. the configuration change process is as follows:
(1) application for change
(2) CHANGE ASSESSMENT (CCB)
(3) notification of the assessment results (whether the estimation of the change workload is reasonable)
(4) implementation of changes
(5) change verification and confirmation
(6) release of changes
(7) change control based on the configuration library, the process is as follows:
the following is a summary of the permissions of each role in the configuration management activity:
16. the configuration status report should focus on reflecting
the status of the current baseline configuration items for relevant personnel to understand. the report includes:
(1) the identity and status of each controlled configuration item
(2) the status of each change request and the status of implementation of approved modifications
(3) current and past version states for each baseline
(4) records of other configuration management activities
17. configuration audit,
also known as configuration audit or configuration evaluation, configuration audit sub-function configuration audit and physical configuration audit, the former audits the consistency of configuration items (whether the power and requirements are consistent), and the latter audits the integrity of configuration items (whether the physical existence is consistent with expectations). the role 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, such as:
(1) prevent the submission of unsuitable products to users
(2) found imperfect implementation
(3) find out the mismatch or incompatibility between the configuration items
(4) confirm that the configuration items have been included in the baseline and stored in the library after the required quality control review
(5) confirm that records and documents maintain traceability
18. the main tasks of release management and delivery activities are:
to effectively control the distribution and delivery of software products and documents, and to properly keep the parent copies of code and documents during the lifetime of software products.
(1) storage: ensure the integrity of stored configuration items
(2) reproduction: the software is manufactured by way of copying
(3) packaging: make sure that the delivered media is prepared according to the approved procedures
(4) delivery: deliver products or services in accordance with the provisions of the contract
(5) reconstruction: it should be possible to rebuild the software environment
19. comparison of three commonly used configuration management tools:
(1) SVN: THE KING OF CENTRALIZED VERSION CONTROL, SIMPLE, POWERFUL, SMALL SIZE, MUST BE USED ONLINE
(2) ClearCase (CC): Centralized version control, powerful, too large, slow running, the world's top 500 use
(3) GIT: OPEN SOURCE DISTRIBUTED VERSION CONTROL TOOL, FAST, SUPPORT LOCAL VERSION CONTROL, STRONG BRANCHING FUNCTION
Software configuration management is concerned with whether the historical versions of the file are recorded for future review, and whether the modifiers of each modification and the reason for the modification are recorded, so that the situation at that time can be understood in the future and why such changes were made.
No comments:
Post a Comment