Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
V-Model in its Environment  Homepage  

  • ENV.1 Objective of the V-Model
  • ENV.2 Application of the V-Model
  • ENV.3 Different Application Scenarios
  • ENV.4 Addresses of the V-Model
  • ENV.5 Conception of the V-Model
  • ENV.6 The V-Model's Regulation Environment
  • ENV.7 V-Model and Phase Models
  • ENV.8 How to use the V-Model
  • ENV.1 Objective of the V-Model

    It is the objective of the V-Model to submit the products generated during the development and during the maintenance and modification tasks of IT systems to certain standards. This is to guarantee a minimum quality for the results and to make it easier to reconstruct the development process of a product from the requirements definition up to completion. Precise definitions improve the communication between project members and the project can be better controlled.

    The V-Model regulates the activities and results during the development process. While doing so, not only the generation process in the strict sense is described, but Quality Assurance, Configuration Management and Project Management are considered as integral parts as well.

    The V-Model takes into consideration the various particularities that occur during the development of IT systems in the Federal Administration:

    The V-Model describes the development process as seen from a merely functional aspect. Special organizational models are not handled since the system is to be applied in different authorities/companies/organizations. Therefore, activities and roles of the V-Model must be allocated to the organizational units and to the persons in charge at the beginning of a project.

    Because of this restriction to only technical regulations it is possible to apply this model-after individual adjustments to organizational conditions-also in international projects or as corporate standard.

    While developing the V-Model, the experience and standardization attempts in the national and international field were taken into consideration, as far as this was possible.

    ENV.2 Application of the V-Model

    The various forms of applying the V-Model have been described in section ENV.8 How to use the V-Model.

    In addition to the uses listed in that section, it should be pointed out that the V-Model also offers support

    ENV.2.1 Use as Guide

    The V-Model has been defined in a generally valid way so it could be used in projects with very different characteristics.

    For every project handled according to the V-Model, the extraction (tailoring) of a project-specific concrete V-Model from the overall regulations will be necessary. This extraction cannot be completely automated by stating objectifiable criteria, since projects cannot be schematically classified into the last detail.

    Therefore, in order to write the Project Manual, it is necessary to have a profound knowledge of the dependences during project development.

    The V-Model illustrates these dependences and helps to evaluate the project characteristics.

    ENV.2.2 Use as Check List

    In each project, the following must be defined on the basis of the V-Model: If it is to be used as check list, the V-Model contains complete lists of the corresponding facts and circumstances.

    ENV.2.3 Use for the Definition of the Desired Quality

    With the V-Model, the qualitative characteristics of the interim and final products are defined in such a way that they can be assessed without very much effort.

    Basically, it should be differentiated between:

    The differentiations between criteria types is necessary since dependence on these criteria types may have a different impact on the formulation of the assessment process.

    While a formal assessment can be handled by an (often trivial) actual state inventory, it is necessary to state success criteria in an "evaluation process"; these success criteria are used to realize the evaluation. It is the objective of the V-Model to define the qualitative characteristics of the products to be generated in such a way that formal assessments can be implemented with as little effort as possible (probably computer-aided), and that the usually costly evaluation processes can be realized efficiently while offering objective results.

    In all, the regulations for the definition of the desired quality are handled via

    ENV.3 Different Application Scenarios

    In order to apply the V-Model according to one of the described uses, it is necessary to differentiate between the following scenarios:

    a) It is a new development, including the use of off-the-shelf-products within the scope of a newly defined project.
    b) It is a project already in use, where the V-Model has not been used yet as a guideline.
    c) It is a SWMM project, where the development and possibly any prior SWMM projects had been realized according to other rules or according to a previous version of the V-Model.

    In addition to the steps always required, the following steps are necessary in the mentioned three basic situations when applying the V-Model:

    The following special investigations and initialization activities must also be realized:

    Case a: New Development in a new Project:

    The V-Model is to be applied as development guideline and standard. No special initialization measures are required.

    Case b: Running Project under another Rule:

    1. Allocation of the products and activities between V-Model and the rule used so far.
    2. Finding out
    3. Definition of an appropriate starting point for the V-Model.
    4. Integrating all tasks required for the change in regulations and possibly transformation of products according to the V-Model rules (updated documentation).
    5. Intensive QA assessment of the now completely available results so they can be used for the subsequent application of the V-Model.
    6. Further development in the project according to the regulations of the V-Model.

    Case c: Newly starting or running SWMM Project (previously different regulation or pre-version of the V-Model)

    The procedure should be like case b), though only the still open task in step 2 has to be defined; step 3 is dropped completely.

    ENV.4 Addresses of the V-Model

    The V-Model is of interest to the following addressees:

    a) Cross-sectional organizations

    They are in charge for the introduction of procedures and methods in their corresponding fields. Their task with regard to the V-Model are:

    b) Users, IT sections and legal organizations

    They use the V-Model and the project standards for the This way, each developer is guided in his tasks, so the smooth acceptance of products by the customer can be guaranteed to the highest degree possible, even with regard to SWMM measures.

    ENV.5 Conception of the V-Model

    The V-Model is based on the following principles: The reasons and purposes of this special concept can be summarized as follows:

    Independence of Methods and Tools

    The V-Model has to meet the requirement that it can be applied in various projects and development environments. Therefore its rules and regulations have to be independent of specifications of certain methods or tools. (A standardization of methods to be applied and used must take place separately).

    Independence of Organizations

    The V-Model only refers to functions and roles, but not to instances and organizational units. This is based on the fact that the V-Model is to be applied in various organizational models. These various organizations have, first of all, different structures and terminologies. Second, not all are known in their different instances from the beginning, and third, they themselves are subject to changes in the course of time. Therefore, only if the V-Model is independent of organizations, it can remain stable and universally applicable.

    Separation into four "Submodels"

    In the V-Model, functions/activities handling the same topic are combined into submodels. The V-Model is subdivided into four such submodels:

    Orientation to Activities and Products

    The V-Model is not phase-oriented, like many other models. Phases always reflect a chronological structure which regulate the project development too rigidly. Therefore, the V-Model is oriented to the activities to be realized and to the products to be handled.

    For each project, an integration of activities to be implemented into the chronological phase sequence of a project must be performed individually.

    ENV.6 The V-Model's Regulation Environment

    Apart from the regulations of the V-Model, other regulations and standards have normally to be taken into consideration in a project.

    These are

    Such standards on different levels are only partly compatible with each other. In case of incompatibility it is necessary to define project-specific preferences.

    Corporate standards, of corporations acting as contractors, that are to be applied during the project development, must be compatible with the V-Model. Compatibility means that all activities/subactivities including the corresponding products of the V-Model can be uniquely allocated to description elements of the corporate standard.

    Here compatibility does not preclude that the regulations of the corporate standard have a degree of refinement beyond the refinement level of the V-Model.

    ENV.7 V-Model and Phase Models

    The V-Model describes all activities and results for the development of IT systems. The descriptions of activities consist of instructions of how to proceed. There is no need to realize activities in a certain chronological order. However, the chronological order of the V-Model activities may be specified by other models. The models known best are, e. g. the waterfall model, the lately preferred spiral model, and-based on administrative specifications-phase models like e. g. /AU 220/ in the German MoD field, and the phase model according to BVB (in future EVB) in the field of Federal Administration.

    Figure ENV.1
    Figure ENV.1: Example of a Chronological Activity Sequence

    In order to avoid confusion, the V-Model therefore never uses the term "phase" but only the term "activity". Activities may overlap, they may be executed iteratively or recursively. Order and selection of V-Model activities are determined by the allocated (phase) model.

    Phase models enforce a linear chronological sequence of the phases. Iterative running through phase cycles is basically possible, but usually not common, because of the existing formalism at phase transition.

    Each phase includes a number of preliminary execution instructions and ends with a decision form. All results/know-how from a phase are to be collected in this form. That way it is possible to decide on the basis of this form if the objectives of the present phase have been covered and if a transition to the next phase can be initiated.

    ENV.8 How to use the V-Model

    Essentially, the V-Model can be used in two ways: It is applied in both of these ways in the authorities and the industrial field. Figure ENV.2 illustrates the fields the V-Model is used in, together with main contractor (HAN) and subcontractor (UAN).

    Figure ENV.2
    Figure ENV.2: V-Model Application in Different Situations

    1. Application in authorities for handling of an enterprise.

    In this case, it must be differentiated if:

    a) Development activities are realized by the authority itself.
    b) Only secondary/attended project functions are realized by the authority; the development itself is realized by the industrial contractor.

    In both cases, a Project Manual has to be generated on the basis of the tailoring for the entire project; in case b) only the secondary/attended functions by the authority (usually PM and QA) are to be taken into consideration.

    Figure ENV.3
    Figure ENV.3: Application Scope of the Overall Project Manual

    In cases where the Project Manualis to be used as development guideline, detailed job instructions for the method-based procedure may have to be defined in addition to the actual method and tool specifications.

    2. Application as a basis for contracts between AG (authority) and HAN (main contractor)

    The agreements between customer and main contractor with regard to are of the utmost importance.

    Since an overall project can be handled in several contracts (possibly also with different main contractors) several Project Manuals, one for each section of the total project, must be generated by means of tailoring:

    Figure ENV.4
    Figure ENV.4: Application Scope of two HAN Project Manuals

    In this connection it is necessary to observe that each additional change of tailoring results has impacts on the contract. Therefore, information about the degree of refinement of the project handling should be established as long as they are really required for the contractual relationship.

    3. Application for setting up contracts between HAN and UAN:

    The situation predominantly corresponds with the one between authority and main contractor, though a main contractor may have a contractual relationship with several subcontractors at the same time. There exist several alternatives for the generation of the Project Manuals: Figure ENV.5 illustrates this situation.

    Figure ENV.5
    Figure ENV.5: Application Scope of the Project Manuals

    4. Application as Development Guide for HAN/UAN

    The generic activities and products agreed on by contract in cases 2 and 3 have to be specified by means of the technical tailoring with regard to the required refinement. When placing the work orders, references to internal corporate regulations about task handling should be added. Doing this, the consistency with prior specifications in the Project Manual has to be strictly maintained.

    In this situation it must also be observed that products classified in the tailoring as "not relevant" by the customer for the company-internal development task can be redefined to a binding interim result of the development process for internal use. This way the tailoring decision used as basis for the contract will not be questioned!

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks