Previous Next V-Model Official Homepage by IABG  
PM Homepage  
8.5.1 Project Manual (PMa)  

  Projekthandbuch

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

    The Project Manual comprises the project description, an overview of contract-relevant specifications (activities and products to be realized or deleted, products to be delivered, participation of the customer), the instructions for the realization of the project, i. e. the project-specific V-Model which is represented in four sections (SD, QA, CM and PM regulations), the specification of the project organization, the selected methods and tools, and the standards and regulations defined.

    Document Index

    1. General Information
    2. Project Description
    3. Overview
    4. Development Strategy
    5. Project-Specific V-Model
          5.1. SD Regulations
                5.1.1. Activities
                5.1.2. Products
          5.2. QA Regulations
                5.2.1. Activities
                5.2.2. Products
          5.3. CM Regulations
                5.3.1. Activities
                5.3.2. Products
          5.4. PM Regulations
                5.4.1. Activities
                5.4.2. Products
    6. Selection of Methods and Tools
    7. Project Organization
          7.1. Organizational Structure
          7.2. Tasks and Responsibilities
          7.3. External Interfaces
          7.4. Reporting
          7.5. Participation of Customer
    8. Standards and Regulations

    Document Structure

    1. General Information

    See schema 1. General Information.

    2. Project Description

    The objective of the project is explained to the participants in the project in the form of a short and concise description.

    Information about the following project characteristics must also be included:

    3. Overview

    This chapter includes all essential project specifications relevant for the contract (see Table 8.1: Example for an Activity/Product Overview). The scope of performance and delivery in particular need to be explained.

    The scope of performance is determined by the tailoring of the V-Model where all activities and products of submodels SD, QA, CM and PM have to be listed, by stating the tailoring criteria (deletion reasons for deleted activities and technical deletion conditions for optional deletions during the project development). (For this, the overview illustrations on the last pages of the corresponding submodel in the generic V-Model can be used.) For the individual (sub-) activities and (sub-) products the possibly covered deletion conditions (reference "not applicable" by mentioning the reason for the deletion) or the relevant technical deletion conditions have to be documented. (Sub-) activities/(sub-) products for which no deletion conditions are listed have to be realized/generated in the project.

    The specification of the objects to be assessed to which individual QA activities refer is realized in the QA Plan.

    All products of the V-Model to be delivered (deliveries) are identified. Apart from the SD and QA products, the customer may also demand the delivery of CM and PM products.

    The (sub-) activities and (sub-) products of the project-specific V-Model to be processed with the participation of the customer have to be documented. Further information about participation are defined in chapter 7.5. Participation of Customer.

    No. Activity Product Type of
    Deletion
    not applicable, because (AT
    Reason) when (TT Condition)
    Customer
    Participation
    Delivery
    Object
    ... ...          
    SD 4-SW Preliminary SW Design SW Architecture - - approval yes
    SD 4.1-SW SW Architecture Design   - - -  
    SD 4.2-SW Design of Internal and External SW Interfaces Interface Description - - - yes
    SD 4.3-SW Specification of SW Integration SW Integration Plan TT not applicable, if integration is not complex - no
    SD 5-SW Detailed SW Design - - - - -
    SD 5.1-SW Description of SW Component/Module/ Database Data Dictionary
    SW Design
    AT never applicable for SW Modules and SW Components because the algorithm was sufficiently described in the SW Architecture - no
    SD 5.2-SW Analysis of Resources and Time Requirements SW Design AT never applicable because sufficient resources are available - no
    ... ...          

    Table 8.1: Example for an Activity/Product Overview

    4. Development Strategy

    The development strategy used as a basis for the V-Model is an incremental development. (The Scenarios manual of the Collection of Manuals, Part 3, lists possible application strategies, together with the corresponding effects on the planning and development activities.)

    This chapter has to list (in addition to the activity/product overview) the application of the planned development strategy (incremental, use of off-the-shelf-products, object-oriented, etc.) for the different project sections or upgrades. The effects of the selected development strategy (iteration of development activities) must be considered in the project planning (Project Plan).

    If different scenarios are used for different system parts the use of several scenarios has to be illustrated.

    5. Project-Specific V-Model

    The project-specific V-Model is reached via the tailoring of the (generic) V-Model. To do so all those activity and product regulations are extracted from the generic V-Model for a specific project that will be used as binding work specifications during the project. Thus, only those regulations are contained in the Project Manual that will be applied in the respective project. These are the set of activities and products of the generic model, minus all (sub-) activities and (sub-) products that are not relevant.

    The activities and products can either be completely described here or they may be only listed as a reference to the V-Model activities and products.

    5. 1. SD Regulations

    5. 1. 1. Activities

    5. 1. 2. Products

    5. 2. QA Regulations

    5. 2. 1. Activities

    5. 2. 2. Products

    5. 3. CM Regulations

    5. 3. 1. Activities

    5. 3. 2. Products

    5. 4. PM Regulations

    5. 4. 1. Activities

    5. 4. 2. Products

    6. Selection of Methods and Tools

    Provided that the application of certain methods and tools has been agreed, this chapter includes the allocation of the methods and tools (see Table 8.2: Example for a Method/Tool Allocation) for the activities listed in chapter 5. Project-Specific V-Model of the Project Manual.

    No. Activity Method Tool
    SD 1.1 Recording of Actual Status and Analysis ER Modeling
    Data Flow Modeling
    Tool 1
    Tool 2
    SD 1.5 User-Level System Structure Functional
    Decomposition
    Tool 3
    SD 2.1 Technical System Design Functional
    Decomposition
    Tool 3
    SD 3.3 Definition of Requirements for the Functionality Functional
    Decomposition
    Tool 3
    SD 4.1-SW SW Architecture Design Structured
    Design
    Tool 4
    ... ... ... ...

    Table 8.2: Example for a Method/Tool Allocation

    In addition, more detailed information for the selected methods and tools can be stated here.

    7. Project Organization

    This contains a description of the project's organizational structure. It is clarified which are the members of the project team (i. e. what departments, instances, it is made up), and also how tasks and responsibilities are to be distributed to these members, and which interfaces are included in the project.

    7. 1. Organizational Structure

    This chapter lists the departments in charge of the realization of activities in the submodels (SD, QA, CM, PM).

    This contains an illustration of how the roles in the V-Model are mapped to the internal organizational units; furthermore, project-specific instances or teams (e. g. change control board) may have to be set up. It must be clarified to which extent the organizational model can cope with the role allocation specified in the V-Model.

    The degree of independence of the organizational unit "quality assurance" and the relationships to the system generation, the configuration management, and the project management, as well as to the user and to the customer, must be documented.

    7. 2. Tasks and Responsibilities

    It is also necessary to enter into the project organization plan how tasks and responsibilities are distributed to the above listed organizational units. The instances for decisions and approvals must be minutely defined.

    7. 3. External Interfaces

    Communication and procedure interfaces with company-external instances (customer, subcontractors, partners, bodies and committees, admission boards) are defined here. It is documented who is getting which type and form of information (technical or administrative, in writing or verbally) when (set date, periodically, event-driven) by whom or to whom he is going to pass it on.

    Contacts must be named for the individual interfaces; also, it must be cleared up which activities these contacts must take care of or for which products they are responsible or in which fields they are competent.

    This list should include the following information about every contact:

    7. 4. Reporting

    Communication and procedure interfaces with company-internal instances are defined here. It is documented who is getting which type and form of information (technical or administrative, in writing or verbally) when (set date, periodically, event-driven) by whom or to whom he is going to pass it on.

    Any other information listed in chapter 7.3. External Interfaces also applies to this chapter.

    7. 5. Participation of Customer

    The responsibilities of customer and contractor have to be defined by means of the allocation of tasks (activities of the V-Model) and responsibilities to customer and (sub-) contractors. The allocation to both sides, by taking into consideration the respective areas of responsibility, must be particularly specified for activities of QA, CM and PM.

    The participation of the customer in the project is subject to the customer's own decision. Activity/roles matrices of the V-Model must be adjusted to the plans of the customer.

    8. Standards and Regulations

    Standards and regulations are coding standards, document templates, and naming conventions. This Project Manual may contain either the description of the standards, regulations and guidelines, or a reference to an existing document which can be accessed by all participants in the project.

    Links to the V-Model Mailinglist

    Mail 0629 - PM 1.4 - Wer akzeptiert das Projekthandbuch? (629)
    Mail 0628 - Re: Tailoring / Individuelle Anpassungen (628)
    Mail 0608 - PHB sehr großer Projekte (608)
    Mail 0595 - Re: Unterstützung der Betriebseinführung (595)
    Mail 0593 - Re: Durchführungsentscheidung (593)
    Mail 0566 - Projekthandbuch für Ausbildungssimulatoren (566)
    Mail 0322 - KM 1.1: KM-Plan erstellen (322)
    Mail 0240 - Re: PM Auftragnehmer (240)
    Mail 0173 - Re: QS-Plan nach V-Modell 97 (173)

    Previous Next This page online  •  GDPA Online  •  Last Updated 05.Feb.2003 by C. Freericks