5 Part 5: V-Modell Reference Work Products

5.2 Overview of the Product Model of the V-Modell

5.2.3 Generative Product Dependencies

»Product Dependency, Generative describes which models of the initial products will specify the conditions for developing the models of the target products. Thus, the generative product dependencies are a set of important rules which provide appropriate support for the planning and development of a V-Modell project. The following figures depict these generative product dependencies as arrows directed from the generating products to the generated products.

As shown in Figure 7, project management products will be developed in accordance with the specifications of the »Project Manual and the »Project Plan. The quality assurance products will be developed in accordance with the specifications of the »QA Manual and the »Project Plan.

Figure 7: Overview of the Generative »Product Dependency of Management Products

»RFP Concept, »Criteria Catalog for Assessment of Offers and »Request for Proposal will be prepared in accordance with the specifications described in the »Project Manual of the acquirer. When subcontracts will be awarded, the »Make-or-Buy Decision shall also be taken into account as initital point for the preparation of these »Product Instance s.

The acquirer's request for proposal will be forwarded via the »Acquirer/Supplier Interface shown in Figure 8 . On the side of the supplier, this product will be designated as »Request for Proposal (Acquirer). Together with a positive »Assessment of Request for Proposal, this product will be used for the preparation of an »Offer. On the side of the acquirer, this product will be designated as »Offer (Supplier).

Based on these products and the specifications contained in the »Project Manual and - possibly - the corresponding »Make-or-Buy Decision, an »Offer Assessment will be prepared. On the basis of the »Contract and any »Contract Addendum, which will be developed within the scope of a »Change Decision, the »Statement of Acceptance, »Evaluation Specification Delivery and »Evaluation Report Delivery will be prepared.

Based on the »Contract (Acquirer) and any »Contract Addendum (Acquirer), the supplier will prepare the »Delivery (Supplier), »Project Status Reports and the »Final Project Report, which in turn will be forwarded to the acquirer via the »Acquirer/Supplier Interface.

Figure 8: Overview of the Generative Product Dependencies at the Acquirer/Supplier Interface

The system development in the »Project Type »System Development Project (Acquirer/Supplier) is not provided with the »Acquirer/Supplier Interface described above. As shown in Figure Figure 9,the »Delivery (Supplier), the »Statement of Acceptance and the corresponding Evaluation Specifications and Evaluation Records will be generated by the Project Manual.

Figure 9: Generating Product Dependencies for the Delivery/Acceptance in »System Development Project (Acquirer/Supplier)

Figure 10 shows the creation of the »Work Product within the scope of the system development. Architectures, evaluation and integration concepts and the Overall System Specification are marked grey. They include specifications for existence and contents of all products which are listed in the equally colored boxes below.

The »Overall System Specification specifies if and how many enabling systems and logistic support documentations shall be prepared for the system and enabling system. The scope of the required documentation will be specified for every »System, »Enabling System and »Logistic Support Documentation, i.e., it will be specified in accordance with Figure 10 whether a »System Specification, an »User Tasks Analysis and a »Database Design must be prepared for the enabling system.

The products »Evaluation Report System Element , »Evaluation Procedure System Element, »Evaluation Specification System Element, »Evaluation Report Usability, »Evaluation Specification Usability and »Safety and Security Analysis can be prepared for each system element and are only indicated by "..." in order to improve clarity.

Figure 10: Overview of the System Development Product Dependencies

The system to be prepared is based on a »System Architecture, which describes the »System Decomposition down to unit level, i.e., it identifies »Segments, software and »Hardware Units and decides on the possibilities of using external units. Together with the »System Implementation, Integration and Evaluation Concept, it provides specifications for the appropriate documents to be prepared for segments, external units, »Hardware Units and »Software Units. The same applies analogously to the »Enabling System Architecture and the corresponding »Enabling System Implementation, Integration, and Evaluation Concept.

Software and hardware units, in turn, have an architecture and an implementation, integration and evaluation concept of their own, which have the same function as their counterparts at system level. Analogously to the »External Units at system level, there are the system elements »External Hardware Module and »External Software Module at hardware and software level, which can be procured as off-the-shelf products or by a sub-order. The scope of the work product »Logistic Support Documentation is regulated in the »Overall System Specification, which incudes the work product »Logistic Support Concept. The latter specifies the product scope of the Logistic Elements.

Figure 11 shows the generation of the »Market Survey for Off-the-Shelf Products. A market survey of this type can already be conducted during the specification of requirements if the necessary information can be derived from the »Project Proposal or the »Requirements Specification.

Figure 11: Generative Product Dependencies for the Specification of Requirements

As shown in Figure 12, the product maturity of an organization will be evaluated before an »Organization-Specific Process Model can be introduced or maintained. Based on the resulting »Assessment of a Process Model , an »Process Model Improvement Concept and finally the new process model itself will be developed.

Figure 12: Overview of the Generative Product Dependencies of the Organization-Specific Process Model