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 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.
- Particularities of critical real-time software result, on the one hand, from the system structure where software is only a part of a complex total, on the other hand, they result from the structure of the development projects themselves, since the software-related aspects are not transparent for the upper level management.
- Requirements that have to be met during a certification of trusted software, according to the IT security criteria.
- Particularities of detailed information modeling the way it is required for the development of IT systems.
- Interaction between software and hardware, the way it influences the procedure of developing real-time systems.
- Interaction between software and method definition the way it is important during the development of IT systems.
- Particularities resulting from the high requirements to the software to be generated, with regard to reliability, changeability, portability, and reusability.
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.
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
- as a guide,
- as a check list and
- for the definition of the desired quality.
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.
- Which products are required?
- Which states must the product run through?
- Which contents must a product have?
- Who has to do what and when in a project?
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.
- Criteria, the fulfillment of which can be assessed formally, e. g. within the scope of the product acceptance.
Example: Existence of certain interim products, use of predefined forms.
- Criteria, the fulfillment of which can only be evaluated in an "evaluation process".
Contrary to the first mentioned criteria, the "yes/no decisions" are not always possible in this case.
Example: Consistency between architecture and user requirements.
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
In order to apply the V-Model according to one of the described uses, it is necessary to differentiate between the following scenarios:
- product schemas,
- assessment rules.
||It is a new development, including the use of off-the-shelf-products within the scope of a newly defined project.
||It is a project already in use, where the V-Model has not been used yet as a guideline.
||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:
- mapping the sub-models and roles of the V-Model to the corresponding authority/corporation structure or the modification of the existing structure and process organization
- tailoring the V-Model to the product- and project-specific conditions
- staff training with regard to application of the V-Model and demonstration of differences to standards previously used that have to be observed
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:
- Allocation of the products and activities between V-Model and the rule used so far.
- Finding out
- any efforts made in advance for V-Model activities and products, and
- still open tasks for V-Model activities and products.
- Definition of an appropriate starting point for the V-Model.
- Integrating all tasks required for the change in regulations and possibly transformation of products according to the V-Model rules (updated documentation).
- Intensive QA assessment of the now completely available results so they can be used for the subsequent application of the V-Model.
- 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.
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:
- accumulation of experience/ideas of users
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.
The V-Model is based on the following principles:
- specification of the User Requirements
The user defines and refines his requirements to the system and special parts. The V-Model is used as a rule for the specification of these requirements PM, QA and CM.
The reasons and purposes of this special concept can be summarized as follows:
- independence of methods and tools,
- independence of organizations,
- separation into four "submodels",
- orientation to activities and products,
- adaptability of the model.
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.
Apart from the regulations of the V-Model, other regulations and standards have normally to be taken into consideration in a project.
Such standards on different levels are only partly compatible with each other. In case of incompatibility it is necessary to define project-specific preferences.
- national and international norms and standards,
- product or project standards,
- standards for certain fields (e. g. /AU 220/ in the German MoD field, phase model according to BVB in the field of Federal Administration),
- corporate standards.
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.
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: 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.
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).
- as a basis for contracts
- as instruction
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:
||Development activities are realized by the authority itself.
||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: 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.
- the deletion conditions of the technical tailoring,
- submodel activities and products to be implemented,
- methods and tools to be applied,
- standards and regulations to be applied, and
- the project rules
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: 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.
- one separate Project Manual per subcontractor, where each subcontractor Project Manual is a subset of the Project Manual of the main contractor,
- a shared Project Manual for each main contractor and his subcontractors, in which case it is necessary to specify which activities and products are binding for the corresponding subcontractor.
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!