Previous Next V-Model Official Homepage by IABG  
CM Homepage  
8.4.1 CM Plan (CPl)  

  KM Plan

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 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: 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 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: The following must be regulated in this chapter:

    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.

    3. 1. 4. Change Control and Status Report

    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.

    Rules for the documentation of changes and procedures for cross-referencing between forms will be defined as well.

    3. 2. Change Forms and their Handling

    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.

    3. 3. Version Control

    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.

    3. 4. Documents of the Configuration Management

    Here it is to be defined

    4. Data Backup and Archiving

    The data backup procedure is determined: performs backups or archives.

    Links to the V-Model Mailinglist

    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)

    Previous Next This page online  •  GDPA Online  •  Last Updated 27.Jun.2003 by C. Freericks