Previous Next V-Model Official Homepage by IABG  
2 Introduction to the V-Model  

  2 Einführung in das V-Modell

  • 2 Introduction to the V-Model
  • 2.1 Product Structure and Embedding into the Organizational Environment
  • 2.2 Marginal Conditions for the Generation of IT Systems
  • 2.3 Contents and Techniques of Representation
  • 2.3.1 Activities and Products
  • 2.3.2 Product States
  • 2.3.3 Activity Schema
  • Section "Product Flow"
  • Section "Handling"
  • Recommendations and Explanations
  • 2.3.4 Product Schema
  • 2.3.5 Submodels

    2 Introduction to the V-Model

    The V-Model regulates all

    activities and products

    as well as

    states of products and logical interdependencies between activities and products

    during the IT system development process and the maintenance and modification of IT systems.

    The V-Model is structured into four submodels.

    The V-Model describes the development process from a functional point of view. It does not describe any special organizational models because it shall be used in different organizations/companies. Therefore, it is necessary for a concrete project to determine the personnel in charge or the organizational units for the tasks ("activities") given in the V-Model.

    This introduction to the V-Model informs about the basic concepts and means of description that are used to represent the V-Model.

    2.1 Product Structure and Embedding into the Organizational Environment

    The V-Model describes the development of Individual IT systems that are fulfilling their tasks predominantly by using IT. In this sense, the "System" is a top-level functional unit as seen from the point of view of the V-Model.

    The product structure of the V-Model defines of which generic items a System to be developed is basically comprised.

    The System Architecturestructure. Dynamic System aspects are represented with the help of the description about the functionality and the cooperation of the elements of the product structure via the corresponding interfaces.

    Next follows a description about the component parts of a System as seen by the V-Model (see Figure 2.1: Product Structure and Application Fields of the V-Model).

    A System is structured into Segments; it is differentiated between Segments with IT portions and Segments without IT portion. The Segments themselves may be composed of several other Segments.

    Segments are further structured into SW Unit and HW Units.

    Systems can also be structured directly into SW Units and HW Units. It is also possible that a System is structured both in Segments and directly in SW Units/HW Units.

    From the point of view of the System Architecture, SW Units (e. g. load modules) and HW Units (e. g. module groups or smaller devices) are elementary objects. The development of SW Unit is described in Part 1 of the V-Model ("Regulations"); the development of the HW Units is described in Hardware Generation of Part 3 "Collection of Manuals".

    SW Units consist of SW Components, whereby SW Components in turn may be comprised of SW Components of a lower order, SW Modules and/or Databases. SW Components are complete software units of a higher level. SW Modules are the smallest programmable software item in a SW unit. Databases are used for the description, storage and retrieval of data.

    HW Units consist of HW Components, whereby HW Components in turn may be comprised of HW Components and/or HW modules. HW modules are the smallest items in a HW Unit.

    Figure 2.1 shows the hierarchical product structure of the System. It is also depicted which of the development activities are regulated by the V-Model.

    Figure 2.1
    Figure 2.1: Product Structure and Application Fields of the V-Model

    2.2 Marginal Conditions for the Generation of IT Systems

    Figure 2.2: Marginal Conditions for the Generation of IT Systems shows schematically the (main) activities in the generation of an IT system.

    In case the development of hardware portions has to be taken into consideration, the software development must be realized in close cooperation with the hardware development (1), or the software must be realized by taking constantly into consideration both the selected hardware and its characteristics. The User Requirements can only be met, controlled and guaranteed during the entire development process when this is given. Figure 2.2 indicates the relationships to the non-IT portions of the System during the generation of the IT system.

    Even when the development of specific hardware is not the subject of the project, hardware and software have to correspond to the specified technical marginal conditions and must be adjusted to the organizational environment in any case. Thus, the V-Model must take into consideration all portions of a System under development, in as far as these portions have any impact on the generation of the IT system. It may be used under all available technical marginal conditions existing in the Federal Administration, and in every organizational environment.(2)

    The order of the activities in Figure 2.2 appears sequential. This corresponds to the idea that the IT system generation process is a strict top-down procedure. Normally, however, iterations are common during the development process (see section 3 General Regulations). Figure 2.2 shows a schematized linear representation of the logical sequence of the IT system generation and its embedding in the organizational environment.

    Figure 2.2
    Figure 2.2: Marginal Conditions for the Generation of IT Systems

    2.3 Contents and Techniques of Representation

    Activities and products are the basic elements of the V-Model. They are realized or processed during the IT system development process.

    2.3.1 Activities and Products

    Activities are worksteps in the IT system development process; its results and execution can be described exactly. Activities may consist of a set of "subactivities" as long as each of these subactivities results in defined "interim results". Activities at the highest level are called main activities.

    The processed object, i. e. the result of an activity, is called a product. Analogous to the decomposition of activities into subactivities, products may be decomposed into "subproducts" (e. g. into different chapters of a document).

    An activity may include

    These basic elements "activity" and "product" are represented with special symbols (see Figure 2.3: Symbols for Activities and Products).

    Figure 2.3

    Figure 2.3: Symbols for Activities and Products

    For each activity there exists an activity description to be used as instruction for the activity. The activity description is based on a set pattern, i. e. the activity schema (see section 2.3.3. Activity Schema). If an activity is to be decomposed into subactivities, and logical interdependencies between subactivities and products have to be pointed out, the activity schema includes an additional graphical illustration of the subactivities.

    A product description exists for each product which defines the contents of the product. The product description adheres to a set pattern, i. e. the product schema (see section 2.3.4. Product Schema).

    2.3.2 Product States

    When handling (sub-) products in the V-Model it must be taken into consideration that certain products are undergoing different states.

    The change from one state to another is triggered by an activity only. All state transitions are explicitly mentioned in the corresponding activities (see 2.3.3. Activity Schema).

    Products may take on the following states:

    The minimally required state transitions are shown in Figure 2.4: Valid State Transitions of Products.

    Figure 2.4
    Figure 2.4: Valid State Transitions of Products

    2.3.3 Activity Schema

    Activities are described by the following pattern:

          Name of the activity

          Product Flow

          Handling Section "Product Flow"

    This is where all products or subproducts that are incoming into the (sub-) activity, modified or newly created in the (sub-) activity, listed, and where their handling is described. It is to be done in the form of a table (see Table 2.1: Example of a Product Flow (Activity SD 2.4 "Allocation of User Requirements")), which is filled correspondingly. Subproducts are represented in dot notation. For example, "System Architecture .Requirements Allocation" means that "Requirements Allocation" is a subproduct of the product System Architecture".

    From Productto
    ActivityState Chapter Title Activity State
    SD 1 accepted Existing User Requirements - -
    SD 2.1 being proc. Existing System Architecture - -
    - - 2.1.3 System Architecture.
    Requirements Allocation
    SD 1 (1)
    SD 2.5
    SD 2.6
    SD 3
    SD 4-SW
    PM 4
    PM 5

    Table 2.1: Example of a Product Flow (Activity SD 2.4 "Allocation of User Requirements")

    For each (sub-) product (column 3) referred to by the activity to be described the state at the beginning (column 2) and that at the end of the activity (column 5) is entered. If the activity does not influence the state of the product or should no such state of the product exist, then this is marked in the table by a dash. The input products of an activity are identified in such a manner that the columns "From Activity" and "From State" are filled in and the columns "To Activity" and "To State" are marked by a dash. For output products the "From"-entries are not applicable. Only the columns "To Activity" and "To State" are filled in. In the cases where a product has both "From" and "To" entries it is modified in the corresponding activity.

    All output products of an activity whose end states are "b. proc." should have "planned" as beginning states according to the model. In order to be able to distinguish better visually between input and output products, the beginning state has been substituted by a "-". This should be interpreted as "planned" in these cases. (3)

    Furthermore, it is noted for each (sub-) product, from which activity the product results (column 1) and to which activity the product will be passed (column 4). If there are neither "From" nor "To" activities for a (sub-) product this is illustrated in the table by a dash.

    If subproducts of a product are created in different (sub-) activities (see, e. g., activity QA 2.2 "Definition of Assessment Environment"), it will become necessary to assemble the product by integrating the subproducts. This is realized in the activity where the last generated subproduct of a product is created. In the product flow this is represented by referring to following main activities in column "To Activity". For products that are not updated, the state in "To State" is "submitted".

    The example shown in Table 2.1 means that User Requirements and System Architecture come from activities SD 1 or SD 2.1, and represent input products. The User Requirements have state "accepted" and the System Architecture "b. proc.". Subproduct "Requirements Allocation" of the product "System Architecture" is newly created. The product leaves the activity having the state "submitted" and is input product for activities SD 1, SD 2.5, SD 2.6, SD 3, SD 4-SW, PM 4, and PM 5.

    Any measures for the quality assurance and the configuration management are indirectly referred to by the changed states. Section "Handling"

    This defines how the activity must be handled during realization.

    In a main activity, the corresponding subactivities, their interdependencies and their results are graphically represented at the beginning of the handling section.

    In this connection, the following must be observed: If no result product is listed for subactivities then this means that several subactivities shown in succession are handling parts of the same product. Recommendations and Explanations

    In addition to handling texts, subsections "Recommendations" and "Explanations" may be inserted. Contrary to the above listed definitions, the recommendations are not binding. The explanations are to clarify both the definition of task and handling in the activity.

    2.3.4 Product Schema

    For every product, the product schema contains a short synopsis of the product contents and usually also a listing of the structural items of the product. Within the scope of the V-Model no requirements will be made with regard to the layout.

    When using tools for the generation of products, it is not always possible to observe the detailed structure. In that case, the detailed structure of the documents in question must be decided on a case-by-case basis. It is also necessary to prove if the required contents are covered.

    2.3.5 Submodels

    Certain activities within the V-Model are combined since they represent a self-contained model under certain aspects. "Models" like that are called submodels.

    The V-Model is made up of the following four submodels:

    Figure 2.5: Cooperation of Submodels illustrates the cooperation of submodels. Figure 2.6: V-Model Products (Product Tree) illustrates how the products of the four submodels SD, QA, CM and PM are to be integrated into the hierarchical product structure.

    A combined list of all activities of a submodel can be found at the end of each section in which the corresponding submodel is described (i. e. sections 4 to 7).

    Figure 2.5
    Figure 2.5: Cooperation of Submodels

    Figure 2.6

    Figure 2.6: V-Model Products (Product Tree)


    (1) See section 3.4 and Part 3 "Collection of Manuals", "Hardware Generation" manual.

    (2) Instructions for consideration of the organizational environment while planning IT systems in the Federal Administration are to be found in /IT-Org/ and /IT-RaKonz/. Therefore, a special consideration of these topics is not included in the following.

    (3) In case the concerned product's content is not being processed, the submodel CM is deviating from this rule.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster