8.4.1 CM Plan



		8.4.1 CM Plan (CPl)

KM Plan

Contents
Introduction
Document Index
Document Structure
Links to the V-Model Mailinglist

Contents		Introduction Document Index Document Structure Links to the V-Model Mailinglist

Introduction

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.

Document Index

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

Document Structure

1. General Information

See schema 1. General Information.

2. Introduction of the Configuration Management

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.

2. 1. Product Library

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.

2. 2. Project-Specific Regulations

This structural item specifies

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 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:

state
classifies the degree to which the product is completed (planned, b. proc., submitted, accepted)).

owner
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
classification remarks in various degrees

descriptors
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 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).

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.

2. 3. Conventions with Regard to the Identification

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 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.

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).

3. Change Management

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.

3. 1. Change Procedure

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.

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.

3. 1. 1. Change Management Procedures

The following situations must be covered:

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.

The following must be regulated in this chapter:

recording and monitoring of the change request,
course from Change Request/Problem Report via Change Proposal and Change Order to the Change Memo,
instances concerned with their responsibilities and rights with regard to decision making.

3. 1. 2. Change Orders

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.

3. 1. 3. Interfaces to the Customer and other Instances

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.

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.