Development documents describe the development process itself. Basic development documents include the following eight aspects:

Feasibility study report and project mission statement

Requirements Specification

Functional specifications

Design specifications, including program and data specifications

Development Plan

Software integration and test planning

Quality Assurance Plan

Safety and testing information

Product documentation describes the product of the development process and basically includes the following four aspects:

Training Manual

Reference manual and user guide

Software Support Manual

Product brochures and information ads

Management documents record information for project management

Records of progress and progress changes at each stage of the development process

Records of software changes

Development team responsibilities defined

Project plan, project phase report

configuration management plan

Minimum documentation (Level 1 documentation), suitable for developers whose development workload is less than one person-month. Includes program listing, development records, test data and program introduction

Internal documentation (Level 2 documentation), available for dedicated programs that do not share resources with other users. In addition to the information provided by Level 1 documentation, Level 2 documentation includes sufficient comments within the program listing to assist the user in installing and using the program.

Working documents (Level 3 documents), suitable for programs jointly developed by several people in the same unit, or programs that can be used by other units

Formal documentation (Level 4 documentation), suitable for software products that are to be officially released for general use

Develop configuration management plans, configuration identification, configuration control, configuration status reporting, configuration auditing, release management and delivery

Externally delivered software products and data

Designated internal software work products and data

Designated support tools used to create or support software products

Software provided by suppliers/suppliers and equipment/software provided by customers

program planning proposal

Requirements document

Design documentation

source code

executable code

test case

Various data required to run the software

The operation permissions of all configuration items are managed by the configuration administrator. Baseline configuration items are developed with read-only permissions for developers; non-baseline configuration items are developed with PM, CCB and related personnel.

Configuration item status can be divided into three types: "draft", "formal", and "modified"

The version number format of configuration items in "Draft" status is 0.YZ, and the number range of YZ is 01~99

The version number format of configuration items in the "official" state is X.Y, where X is the main version number and the value range is 1~9. Y is the minor version number, the value range is 0~9

The first time a configuration item becomes an "official" file, the version number is 1.0

The version number format of a 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 X.Y values ​​remain unchanged. When the configuration item is modified and the status becomes "official", set the Z value to 0 and increase the X.Y value.

Baselines typically correspond to milestones in the development process

The baseline delivered to external customers is generally called a release baseline, and the baseline used for internal development is generally called a construction baseline.

Baseline events

Controlled configuration items

Procedures for establishing and changing baselines

Permissions required to approve changes to the baseline

What each baseline defines

Baselines provide a fixed point and snapshot of development work

New projects can be created at fixed points provided by the baseline. The new project acts as a separate branch, isolated from subsequent changes to the original project (on the main branch)

Baselining provides teams with a way to cancel changes when an update is deemed unstable or untrustworthy

Baselining can be used to re-establish a configuration based on a specific release to reproduce reported bugs

Benefits of establishing a baseline

Development library

controlled library

Product library

Build a database

Responsible for evaluating, 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.

Instead of controlling configuration changes, CCB is responsible for more configuration management tasks, such as baseline approval and configuration management plan approval.

Write a configuration management plan

Establish and maintain configuration management systems

Create and maintain configuration libraries

Configuration item identification

Establish and manage baselines

Version management and configuration control

Configure status reporting

Configure auditing

Release management and delivery

Provide configuration management training to project members

Is a software system used for configuration management

Ensure that the software configuration management plan is developed and reviewed and confirmed by relevant personnel

It is necessary to identify the project products to be controlled and formulate relevant control strategies to ensure that these project products are obtained by appropriate personnel.

A control strategy should be developed to ensure that project products are changed within controlled limits

Appropriate tools and methods should be adopted to ensure that relevant groups and individuals can understand the status and content of the software baseline in a timely manner

Configuration management activities, covering the main activities include configuration identification, configuration control, configuration status reporting, configuration audit, release management and delivery

Norms and processes for implementing these activities

Schedule for implementing these activities

The people or organizations responsible for carrying out these activities and their relationships with other organizations

What does a configuration management plan include?

Identify configuration items that need to be controlled

Specify a unique identification number for each configuration item

Define important characteristics of each configuration item

Determine the owner of each configuration item and their responsibilities

Determine the time and conditions for configuration items to enter configuration management

Establish and control baselines

Maintain relationships between document and component revisions and product versions

Configuration item identification is the responsibility of the configuration administrator and needs to include these steps

Change Request

Change assessment

Notify evaluation results

Change implementation

Change verification and confirmation

change release

Configuration repository-based change control

The identity and status of each controlled configuration item

The status of each change request and the implementation status of approved modifications

Status of current and past versions of each baseline and comparison of versions

Records of other configuration management process activities

Configuring what the status report includes

effect

Functional configuration audit

Physical configuration audit

storage

copy

Pack

deliver

reconstruction