Coordinating the V-Model in its Environment

Contents
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

Contents		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:

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.

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

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:

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?

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:

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.

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

product schemas,
forms,
assessment rules.

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.

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:

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

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:

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.

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:

distribution
training
accumulation of experience/ideas of users
update

b) Users, IT sections and legal organizations

They use the V-Model and the project standards for the

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.

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:

independence of methods and tools,
independence of organizations,
separation into four "submodels",
orientation to activities and products,
adaptability of the model.

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:

submodel System Development (SD) with constructive development tasks,
submodel Quality Assurance (QA) with assessment tasks,
submodel Configuration Management (CM) with tasks with regard to product management and modification,
submodel Project Management (PM) with planning and steering tasks.

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

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.

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: 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:

as a basis for contracts
as instruction

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: 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.

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: 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

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

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: 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:

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 illustrates this situation.

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!

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