The Configuration Management (CM) Plan specifies organizational details with regard to the configuration management. It is to agree project rules and conventions with regard to: introduction of the configuration management, change management (configuration control), as well as data backup and archivation; these have to be adhered to during the entire project development.
1. General Information
2. Introduction of the Configuration Management
2.1. Product Library
2.2. Project-Specific Regulations
2.3. Conventions with Regard to the Identification
3. Change Management
3.1. Change Procedure
3.1.1. Change Management Procedures
3.1.2. Change Orders
3.1.3. Interfaces to the Customer and other Instances
3.1.4. Change Control and Status Report
3.2. Change Forms and their Handling
3.3. Version Control
3.4. Documents of the Configuration Management
4. Data Backup and Archiving
See schema 1. General Information.
All rules required for the introduction of the CM are stated here. This refers to the product library, the identification rules, and other project-specific regulations.
All products-as far as practical and possible-will be collected and maintained in a product library. The systematics of the product, user, access rigths and relations administration of the product library must be described, or appropriate documents and/or manuals must be referred to.
This structural item specifies
To Product Attributes:
It is defined which product attributes are maintained, which is the initial value of those attributes, and what possible attribute values might look like. Examples for product attributes are:
- which products must be taken under CM control,
- based on which criteria the configuration units are set up,
- which states the products are going through,
- which product attributes must be carried along,
- how access rights are allocated and controlled,
- how products of subcontractors are taken under CM control,
- which other objects (development computer, tools, assessment environment, etc.) are taken under CM control,
- how CM instances (e. g. Change Control Board, Interface Control Working Group) are introduced and staffed,
- which aids (e. g. CM tools, forms) have to be made available.
To Product States:
This specifies a project-specific mechanism describing the valid state transitions. It is possible to adopt Figure 6.1: Valid State Transitions of Products to be developed from the V-Model; if necessary, these specifications can be further detailed by refining or adding states, in which case it must be defined exactly, however, by which activity or by which event a state transition occurs. A possibility may be to refine "accepted" into "quality assured" (done by the internal QA) and "released" (done by an external assessment facility), or to add the state "agreed" (after the product has been accepted by the customer).
classifies the degree to which the product is completed (planned, b. proc., submitted, accepted)).
refers to the owner (project, etc.) of the product
- person in charge
refers to the submodel or the person processing and changing the product
- generation date
- change history
- specified processing time
refers to the processing time specified by the project management
- access right
refers to the access rights for the project members
classification remarks in various degrees
identify the product and help in retrieving (possible names might be: driver, etc.)
- other corresponding products
this might result in a link to all products that belong to a SW Module/SW Component
- version attributes
in the case the actual product is a version of a previous product, then the version attributes are entered. Each change of a product which causes a state change automatically refers to the modification of the version name (usually version increment).
To Access Rights:
According to the processing competence of the organizational units (see Project Plan.Process Organization) and the classification of products, the rules for allocation and control of access rights to data (database), programs, procedures, and tools will be specified. Protective and control measures must also be described and determined in this context.
All of the developed products, documents of the reporting and change management, ordered and provided products, referenced and used products (e. g. interfaces, assessment environment), and all components of the development environment (methods, tools, aids) must be uniquely identified (this also includes a unique label for data media).
Identifications are allocated to the products, which uniquely identify these, including their version. For some of the products an identification of product-internal information (e. g. numbering lines of source code) is possible which must be described here as well.
To be described are:
The identification rules are valid for all architecture elements, from System to SW Module, and for all corresponding documents and used products. It is recommended to apply the same systematics for the identifiers of the software as were applied for the hardware (e. g. via drawing number).
This chapter contains regulations in context with the realization of changes: from a Change Request/Problem Report procedure to a Change Memo, all the required change forms and version handling guidelines.
This chapter contains a description of the course of a change, beginning with the request and ending with the final memo. During the change procedure it is often differentiated, whether products have been already delivered to the customer or not. For products that are still under development a simplified change procedure is mostly used. Should different change procedures be applied then both procedures must be described.
- the structure of the identification,
- information which should be mirrored by the identification,
- systematics of the behavior of the identification during "product" changes (e. g. new version, new release),
- means (possibly automatic) enabling an automatic identification of the products, e. g. board-autonomous analysis of the PROM check-sum for identification of the Segment version,
- identification of product-internal units.
It must be taken into consideration that in practice, several changes might be combined. The effects of changes to the baseline specifications have to be documented.
The following situations must be covered:
The following must be regulated in this chapter:
It is defined how to proceed with the Change Orders; this especially comprises the regulation of the issue of releases (combining several changes) and the formalism for the monitoring of changes. The changes or modifications critical for IT security have to be described.
With regard to the change management all communications will be determined. It has to be defined as to the kind of changes, e. g. when the customer has to be informed and in what detail, and who is in charge of making a decision about what kind of changes.
A procedure is defined about how the status of the processing (status in the Change Status List) of problems and ordered changes will be monitored, in particular how still unsolved problems and changes can be identified.
- change request for products still under development as well as for products that have already been delivered,
- change request of project-external (user, customer) and project-internal instances,
- contents of the change request: problem, error, modification, and addition,
- definition of baselines.
Rules for the documentation of changes and procedures for cross-referencing between forms will be defined as well.
This chapter contains a presentation of the change forms. Apart from specifying the content of the documents, the precise and formal structure of
are specified as well.
After the changes have been executed the versions of changed products must be maintained along with those products. The methods are defined with regard to the product.
Here it is to be defined
The data backup procedure is determined:
- which documents must be generated in the scope of configuration management,
- which contents, and
- which layout the documents must have.
- In particular the procedures for cross-referencing between forms have to be defined in order for the changes to be controlled in detail.
performs backups or archives.
- when (fixed date, periodically, event-oriented)
- who (organizational unit)
- what (which products)
- how (data media, procedure)
- where (filing)
Mail 0682 - Re: Freigabe-Verfahren - bitte um Hilfestellung (682)
Mail 0655 - Re: QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (655)
Mail 0589 - Produktbibliothek & KM-Plan: Wo steht die Produktliste ? (589)
Mail 0326 - KM 1.1: KM-Plan erstellen (326)
Mail 0322 - KM 1.1: KM-Plan erstellen (322)
Mail 0173 - Re: QS-Plan nach V-Modell 97 (173)