|2 Introduction to the V-Model|
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.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.
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.
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.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.
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
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).
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:
Name of the activity
HandlingTable 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".
|SD 1||accepted||Existing||User Requirements||-||-|
|SD 2.1||being proc.||Existing||System Architecture||-||-|
|SD 1 (1)
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.
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.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.
The V-Model is made up of the following four submodels:
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.6: V-Model Products (Product Tree)
(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.
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|