5 Part 5: V-Modell Reference Work Products
5.3 Products
5.3.2 Planning and Control
5.3.2.2 Project Manual
Process module: Project Management
Responsible: Project Leader (when using process module Project Management)
Activity: Preparing the Project Manual
Participating: Executive, Controller, CM Manager, System Architect, Safety Manager, RFP-Manager, Security Manager, Data Protection Manager
Work Product Attributes: initial
Purpose
The V-Modell is a generic process standard which must be adapted and concretized for an acutal project. The Project Manual determines the adaptations and specifications required for management and development. Thus it documents how and to what extent the V-Modell is applied to the project, and it is a source of information and guideline for all particpants.
The Project Manual includes a brief description of the project, the description of the tailoring result, the basic project execution plan, the required and agreed supplier support and organization and specifications for planning and executing the project as well as the corresponding development tasks. The »Project Leader shall develop this central product in coordination with the key personnel of the project.
The Project Manual determines frequency and necessity of generating follow-on products which are necessary for the planning and execution of the project, bids and contracts and process improvement, e.g. »Project Status Reports, »Risk List, contracts and assessment of process models.
Generates
Assessment of a Process Model (see product dependency 4.1)
Statement of Acceptance, Evaluation Report Delivery, Evaluation Specification Delivery (see product dependency 4.9)
Delivery, Evaluation Report Document, Evaluation Specification Document, Evaluation Report System Element, Evaluation Specification System Element (see product dependency 4.10)
Life Cycle Cost Calculation, Commercial Project Status Report, Product Configuration, Measurement Data, Metrics Analysis, Change Decision, Change Status List, Problem/Change Evaluation, Problem Report / Change Request, Work Order, Meeting Document, Final Project Report, Project Progress Decision, Project Management Infrastructure, Project Status Report, Project Diary, Risk List, Estimation (see product dependency 4.13)
Hardware Implementation, Integration and Evaluation Concept, Software Implementation, Integration and Evaluation Concept, System Implementation, Integration and Evaluation Concept, Enabling System Implementation, Integration, and Evaluation Concept, Safety and Security Analysis (see product dependency 4.27)
Offer Assessment, Request for Proposal, RFP Concept, Criteria Catalog for Assessment of Offers, Contract (see product dependency 4.29)
Depends on
Project Proposal, Project Plan (see product dependency 5.1)
Proposal for the Introduction and Maintenance of an Organization-Specific Process Model, Project Plan (see product dependency 5.8)
Evaluation Specification Product Configuration (see product dependency 5.19)
Project Progress Decision, Project Plan (see product dependency 5.30)
Project Plan, Project Status Report, Risk List (see product dependency 5.32)
Quality Status Report (see product dependency 5.33)
QA Manual (see product dependency 5.37)
Requirements Specification, Overall System Specification (see product dependency 5.45)
Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 5.46)
Overall System Specification, Data Protection Concept, Information Security Concept (see product dependency 5.47)
Request for Proposal (see product dependency 5.48)
QA Manual, Request for Proposal (see product dependency 5.55)
QA Manual, Contract (Acquirer), Contract Addendum (Acquirer) (see product dependency 5.57)
Example Work Products
5.3.2.2.1 Project Overview, Project Targets and Success Factors
The Project Manual is an indispensable source of information and guideline for all participants. This subject presents the common project model in a brief, concise and clear manner.
Exemplary Product Content
It is intended to describe
- the problem situation leading to the project,
- the initial situation including the results already achieved,
- the targets of the project,
- the product type (e.g. company information system, tracked vehicle, etc.),
-
a summary of the significant requirements regarding
- functionality,
- quality,
- maintainability and
- safety and security,
- the rough system architecture as far as it is already known,
- the project type and size, as well as
- the decisive success factors for the project.
5.3.2.2.2 Sub-Projects
The sub-projects are specified based on an outline of the life cycle and the overall system architecture, the functional requirements and the non-functional requirements of the overall project. The specification of the sub-projects includes the number of sub-projects, a brief description and the most important decision gates of the sub-projects, the assignment of functional and non-functional requirements to the sub-projects and the coverage of the overall system architecture elements by the sub-projects.
In this connection the sub-project Integration, which integrates the results of the other sub-projects into the overall project, will also be specified.
The sub-project Integration describes the sequence of the sub-projects to be integrated, the particular procedures or methods for integrating the sub-project results, the schedules, efforts, responsibilities and resources.
5.3.2.2.3 Project-Specific V-Modell
The V-Modell is a generic process model. The project-specific adaptation - the so-called »Tailoring - is documented in this subject which determines the »Application Profile to be developed, the resulting project type, the »Process Modules to be used, the process modules selected in addition, and the selected Project Execution Strategies. This subject may also specify conditions and consequences of foreseeable dynamic tailoring. These specifications must be justified in accordance with the standards of the V-Modell (compare »Tailoring in Section 1: »Fundamentals of the V-Modell).
5.3.2.2.4 Deviations from the V-Modell
Every deviation from the standard of the V-Modell - e.g. deletion of individual products and activities, deviations from the tailoring procedure - must be documented, giving the reasons for this decision. The modifications shall be listed in this subject.
5.3.2.2.5 Project Execution Plan
The V-Modell specifies the rough structure of the project by determining appropriate »Decision Gates. This subject is intended to plan these decision gates by developing a project execution plan, which will include at least the beginning and end of the project and all important decision gates during the project.
Moreover, additional project-specific milestones may be specified if they are relevant for all stakeholders. Milestones which are only relevant within the project will be documented in the project plan.
5.3.2.2.6 Cooperation and Provisions of the Acquirer
The acquirer's cooperation within the scope of the contractually specified range of activities shall be specified in writing. It may include, e.g., the participation in project conferences and reviews - e.g. of the »Overall System Specification and the system architecture - and the cooperation in the »Change Control Board.
In addition, furnishings of the acquirer shall be specified unambiguously, stating particularly technical characteristics, like specifications and interfaces, but also deadlines and other conditions.
The Acquirer specifies his own cooperation and any possible provisions within the topic »Directives for the Project Manual of the Supplier.
5.3.2.2.7 Project Management - Organization and Directives
In this subject, the project management specifications will be adapted and concretized. The internal and external stakeholders will be listed, with the responsible points of contact being named. In addition the key roles of the V-Modell - like »Project Leader , »QA Manager and »System Architect - will be appointed, and their tasks and responsibilities will be determined in accordance with the V-Modell specifications.
The basic organization and execution of cooperation activities between all stakeholders will be defined. This includes e.g. meetings, harmonization procedures, conflict management and escalation strategies, which specify the conditions for the execution of a formal decision process. In addition, the subject defines threshold values, the exceeding of which leads to the initiation of control measures. An example for this is the exceedance of the planning target values by more than 15%. Organization-wide specifications must be taken into account.
For V-Modell products to be developed within the scope of project management - e.g. project plan, work order and »Project Diary - the subject specifies if and when these products shall be developed, on which methods, guidelines and standards they shall be based and with which tools or »Project Management Infrastructure components they shall be processed (compare section Generative Product Dependencies).
5.3.2.2.8 Risk Management - Organization and Directives
In order to ensure that the risks within the project are measured by the same standards, the risk management integrated in the V-Modell will be specified and concretized in this subject. This includes the general decision whether - in addition to the risks - also chances should be considered. Since the same procedure is applied to the assessment of chances and risks, the following paragraphs will not differentiate between them.
This subject specifies when and in accordance with which criteria the risks shall be documented in a »Risk List. In addition it must be defined on which methods, guidelines and standards the risk management shall be based and with which tools or »Project Management Infrastructure components it shall be processed.
The following items must be specified in detail:
- »Risk Classes for the classification of risks
- Risk acceptance criteria
- Escalation levels based on the defined risk classes in accordance with the specifications of the subject »Project Management - Organization and Directives
- Procedures for documenting the identified risks and the planned measures
- Schedule and procedures for risk identification
- Schedule for the re-evaluation of risks
- Schedule and procedures for planning and executing countermeasures
5.3.2.2.9 Problem and Change Management - Organization and Directives
In this subject, the problem and change management integrated in the V-Modell will be specified and concretized. It will be specified if, when and and which problem reports and change requests must be prepared, which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed.
This includes, but is not limited to, the definition of the planned state of problem reports and change requests (prepared, approved, rejected), the staffing of the »Change Control Board, the conflict management and escalation strategies. It may be necessary to appoint several persons in charge of changes and several Change Control Boards with different decision competences and different composition.
If there are different opinions within a Change Control Board, escalation levels will be definied. For example, a Change Control Board with greater decision competences or a »Steering Committee may be specified as escalation instance.
5.3.2.2.10 Configuration Management - Organization and Directives
In this subject, the configuration management integrated in the V-Modell will be specified and concretized. It will be specified which »Product Instance must be managed by the configuration management when and based on which methods, guidelines and standards and when and how often »Product Configuration and Releases must be prepared. The »Configuration Management specifications regarding number and scope of product configurations shall be observed.
All products created within the scope of a V-Modell Project will be entered and administered in the »Product Library in accordance with the specifications contained in the Project Manual. For this purpose, it must be specified which filing structure and naming conventions shall be used in the product library, how the products are named unambiguously in the configuration management, how versions and releases are updated and which product states are passed by the product model from point of view of the configuration management. The product states must include at least the states defined in the Chapter »Quality Assurance and Product State Model.
This subject must specify the administration of the product library and a concept for saving and archiving the models in the product library. It will specify responsibilities, schedules and procedures for data saving and concepts for archiving and storing data for extended periods of time.
The configuration management contributes to the »Project Status Report, which is intended to control the progress of product models and product configurations. It shall be specified when, in which form and to which persons the CM evaluation shall be forwarded.
Furthermore this chapter describes, how entries are inserted into the »History of Change and Review List. I.e., e.g. frequency of entries and which entries are edited under which circumstances.
5.3.2.2.11 Measurements and Analyses - Organization and Directives
In this subject, the measurement and analysis procedure integrated in the V-Modell will be specified and concretized. For this purpose, the project objectives which are to be achieved by the »Metrics, the metrics themselves and the »Measurement Data Types will be collated. The metrics will be allocated to the project objectives. This permits a quantiative or qualitative tracking of these objectives.
If the selected metrics and the corresponding measurement data are not defined in the organization-wide »Metrics Catalog, the required definitions must be made. These definitions correspond to the specifications in the Metrics Catalog. If the metrics and measurement data types adopted from the metrics catalog require project-specific adaptations, these must be documented here.
Finally, it must be specified if, when and by whom which »Measurement Data and »Metrics Analysis are to be collected or prepared. In addition, it must be specified which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed. Particularly the project-specific filing structure of the measurement data must be specified.
5.3.2.2.12 Controlling - Organization and Directives
In this subject, the commercial project management procedure integrated in the V-Modell will be specified and concretized. The economic specifications of the organization must be adapted to the project. It must be specified if and when which products are to be used for commercial project management, which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed.
This includes the specification of the organization and the allocation of commercial project management roles to persons or organizational units of the company. The organization will normally be developed based on the four-eye principle in order to ensure a balanced representation of technical and economical issues.
Escalation instances to be applied to in case of differences of opinion are normally specified within the organization structure of the company, however a »Steering Committee may be determined as escalation instance in great international projects.
5.3.2.2.13 Requirements Management - Organization and Directives
In this subject, the requirement management procedure integrated in the V-Modell will be specified and concretized. It must be specified if and when which products are to be used for requirement management, which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed.
This includes, but is not limited to, the appointment of all stakeholders of requirement management for the entire project life including their responsibilities, the definition of possible conditions, like the harmonization level of a requirement, the determination of a description template for requirements and possibly the specification of a tool for collecting and administering the requirements.
5.3.2.2.14 System Development - Organization and Directives
In this subject, the system development procedure integrated in the V-Modell will be specified and concretized. It must be specified if and when which products are to be used for system development, which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed.
This includes at least the specification of development methods to be applied, development environment, technologies, conflict management and escalation strategy.
5.3.2.2.15 Safety and Security - Organization and Directives
In this subject, the safety and security procedure integrated in the V-Modell will be specified and concretized. This includes functional safety and information security. Safety and security-relevant roles will be assigned to persons or organizational units. It must be specified if and when which »Work Product are to be used for safety and security, which methods, guidelines and standards will be used as basis for their preparation and with which tools or »Project Management Infrastructure components they will be processed.
This includes at least action concepts to be followed in case of inacceptable safety and security risks, the specification of general risk reduction measures to be applied, the information strategy in case of safety and security risks, conflict management and escalation strategies.
The general risk reduction measures will be specified in the safety and security level action matrix. This matrix includes suitable design and test measures depending on the safety and security level. These measures can be selected based on existing safety and security standards, e.g., »DIN EN IEC 61508. The measures suitable for the specific project shall be determined based on the measures proposed in the standards, or the existing standards shall be concretized for the specific project.
Exemplary Product Content
In detail the following measures may be specified:
-
Actions to be followed in case of safety and security risks.
- Methods for determining and selecting risk reduction measures.
- Specifications for problem reports and change requests, based on the safety and security requirements of the specific system.
- Description of the procedure for ensuring the obligation to inform the project management.
- Specification of responsibilities and decision-making authorities.
- Determination of the decision-making procedure.
5.3.2.2.16 Directives for the Project Manual of the Supplier
In this subject, the acquirer can provide the supplier with a variety of specifications for the planning and execution of the project. These specifications will be documented here, integrated into »Annex 2: Directives for the Project Manual (Supplier) of every »Request for Proposal and adapted as required. The specifications may include, e.g., the development process to be used, the »Tailoring and the infrastructure to be used and »Safety and Security procedures.
Exemplary Product Content
Possible specifications include, but are not limited to, the following:
- development process, e.g., development in accordance with the V-Modell
- tailoring of the V-Modell, e.g., process modules like safety and security or off-the-shelf products must be included
- milestones
- deadlines
- infrastructure to be used
- furnished items of the acquirer to be used
- type and frequency of reports
- risk acceptance matrix to be observed
- development of an as-built plan
5.3.2.2.17 Reporting and Communication Channels
The previous subjects determined the organization and specifications for various project planning and execution tasks. This subject provides a survey of the specifed reporting and communication channels. This includes, e.g., the specification as to who has to provide which information when and in which form.
Exemplary Product Content
It must be specified
- who receives
- which type and form of information (technical or administrative, written or oral)
- when (fixed date, periodically or depending on events)
- from whom or provides it
- to whom.