What is the V-Model?

Table of Contents: Definition – Components and phases – Advantages and disadvantages – Questions – Notes

Smartpedia: The V-Model is a process model for IT development projects that matches definition and design phases with corresponding test phases.

V-Model – a process model for IT development projects

The V-Model is a process model for IT development projects, whereby the “V” is derived from the V-shaped visualisation that contrasts the definition and design phases with corresponding test phases.

The process model was first described in 1979 by Barry W. Boehm, an American software engineer with a focus on the validation¹ and verification² of results.³

What is special about the V-Model is that it considers both functional and technical development and defines quality assurance measures. These measures supplement the phases for defining and developing a product with corresponding test phases so that both individual components and the overall system can be properly tested.

V-Model - a process model that matches definition and design phases with test phases

Components and phases in the V-Model

The V-Model can be presented and applied in different areas and in different forms. The most common use is in software engineering4 and is divided into three components:

The left-hand side of the “V” deals with the definition of requirements and the design of a system, which is continuously developed using the top-down principle.
The implementation at the bottom of the “V”.
The right-hand side of the “V” validates and verifies the left-hand side. Here, tests are carried out from the component to the system level according to the bottom-up principle until the product is finally accepted as a whole.

The V-Model can be divided into the following phases:

The requirements definition, in which user requirements or stakeholder requirements are described,
the system specification as a functional system design with the definition of system requirements, documented, for example, as a system requirements specification,
the system architecture as a technical system design for realising the system requirements
and the component design.
This is followed by the implementation and
the component test (opposite the component specification),
the integration test ( opposite the architecture design or the technical system design),
the system test (against the system specification or the functional system design)
and the acceptance test ( against the requirements definition).

Advantages and disadvantages of the V-Model

The V-Model offers a number of advantages:

As a process model, it describes a clear structure for the development process, in which the design phases are linked to the corresponding test phases. This facilitates the systematic planning and realisation of projects.
By closely linking development and testing activities, errors can be recognised at an early stage. This helps to reduce the costs and effort required to rectify errors in later phases.
The process model emphasises a thorough requirements analysis at the start of the project. This clearly defines the requirements and avoids misunderstandings, resulting in an improved end product.
As the process model provides for detailed documentation of development and testing activities, it is easy to understand which steps have been carried out and what results have been achieved. This can be helpful for quality assurance and the fulfilment of regulatory requirements.
The phase-based approach is relatively well-known, easy to understand and particularly widespread in regulatory areas such as medical technology, the defence industry or the automotive sector. It promotes a systematic and structured approach to the development of systems or software products.

Despite these advantages, there are also some disadvantages:

Due to its fixed structure and strict phase sequences, it is sometimes considered to become rigid. This can lead to problems if changes are required during the project or if agile approaches are favoured.
The approach requires relatively extensive documentation throughout the development process. This can lead to increased administrative effort, which can tie up resources and impair flexibility.
Due to the sequential nature of the process model, development cycles can be longer, especially if extensive testing and reviews need to be carried out at each stage.
The approach may be over-dimensioned and too complex for small projects or teams with limited resources. In such cases, a more flexible and less formalised approach may be more appropriate.
And it suggests a purely sequential process, which is often not the case in practice and does not have to be.

Questions from the field

Here you will find some questions and answers from the field:

What variants of the V-Model exist?

There are a number of variants of the V-Model:

V-Modell 97 was a standard for the development of IT systems for the German Armed Forces and the German Federal Administration and was published in 1997. It was a revision of the first publication in 1992 and consisted of a regulation section, a section for authority-specific additions, a collection of manuals, a method allocation and tool requirements.
V-Modell XT is considered a revision of V-Model 97 and replaced it in 2004. It is a German standard for the planning and implementation of system development projects and is aimed at both clients and contractors. In terms of content, it differs greatly from its predecessor and introduces new basic concepts such as “extreme tailoring”, project types, project type variants, products and activities, process modules, project implementation strategies and decision points.
The V-Modell XT Bund extends the V-Model XT for public authorities and focuses on the implementation of client projects and the in-house development of software systems.
The V-Modell XT Bayern is a process model for Bavarian authorities and supports client projects in the area of software development and customisation.
The V-Modell XT Bw extends the V-Model XT for the German Armed Forces and integrates procedural provisions for determining requirements, meeting requirements and utilisation.
In the automotive sector, there is another variant, ASPICE or Automotive SPICE. SPICE stands for Software Process Improvement and Capability dEtermination and is used to assess the maturity level dimensions of development processes for electronic and software-based systems.

Is the V-Model a trademark and do licence fees apply?

The Federal Republic of Germany was involved in the standardisation of the V-Model at an early stage and registered the V-Modell® as a protected trademark. Neither the use of the current variant V-Modell XT nor the use of the “general” V-Model is subject to licence fees.

What is the difference between the V-Model and the waterfall model?

The waterfall model is a linear planning model from traditional project management. A project is divided into several phases that follow each other sequentially: Analysis -> Design -> Implementation -> Test -> Operation. The model gets its name from the graphical representation in which the phases “flow” or are visualised from top to bottom, similar to a waterfall. It is well suited to projects where the requirements are already clear at the start of the project and there are few changes. It is often claimed that there is no feedback between the phases, but this is not true. Of course, changes can also be managed in the course of the waterfall model, only the processing, i.e. the corresponding activities, is linear.

In contrast to the waterfall model, the V-Model is characterised by the fact that verification and validation are already specified during analysis and design. In the test phases, the testers check against the specifications from the analysis and design phases. This also means that the V-Model is more than just a “folded waterfall model”.

Why is the V-Model also referred to as a " folded waterfall model"?

The V-Model is often referred to as a ” folded waterfall model” because it has some similarities with the waterfall model, but “redraws” some phases and arranges elements on the same horizontal level. However, since verification and validation are already specified during requirements definition, system design, architecture design and component design, the term does not do justice to reality. The V-Model is not a waterfall model, but describes a different procedure in terms of content.

Which roles are typically used in a V-Model project?

As described, the V-Model defines different phases. Different roles are required in these phases:

A requirements analyst or requirements engineer is used in the requirements definition phase and in functional system design or system specification.
The role of the software architect is required for the technical system design or architecture design.
Developers or programmers can get to work on the implementation.
Opinions vary as to whether it makes sense to use separate software testers for the component, integration and system tests or whether it is not better for software developers to take on these tasks at the same time.
However, the acceptance test should then be carried out by a person “external to development”, an “acceptance tester” or a stakeholder.

Many other roles are also conceivable. The V-Modell XT, for example, provides a comprehensive list of roles, whereby one person can take on different roles as long as they do not contradict each other in terms of content.

How relevant is the V-Model today?

The relevance of the V-Model depends heavily on the specific requirements, preferences and contexts of the respective organisations and projects.

In some industries, particularly in safety-critical areas such as aerospace, healthcare and automotive, it remains relevant and is even often used as a standard operating model to ensure compliance with quality and safety standards.

To this end, some organisations prefer traditional, plan-driven approaches to software development and therefore continue to rely on the V-Model as a framework for their projects.

With the emergence of agile development methods such as Scrum and Kanban, as well as the increasing emphasis on DevOps and Continuous Integration/Continuous Deployment (CI/CD), practices and approaches in software development have changed. In agile environments, the V-Model can be perceived as too cumbersome and bureaucratic, which can limit its applicability in such contexts.

In short, while the V-Model remains prevalent in some areas, agile (or hybrid) approaches have proven more popular in others.

Impulses to discuss:

Does the visualisation of the process model simplify the reality of system development to such an extent that users could be lulled into a false sense of security?

Notes:

Feel free to share or link to the content on this page.

[1] Definition of validation according to ISO 9000: “Confirmation by objective evidence that the requirements for a particular application or use are met.”

Validation therefore checks whether the product meets the needs of the user. It checks whether the requirements are in line with the objectives of the stakeholders. In the V-model, validation is carried out by means of an acceptance test, for example.

[2] Definition of verification according to ISO9000: “Confirmation by objective evidence that requirements are met.”

Verification ensures that the result of a development meets the given specifications. In the V-Model, verification is carried out through component, integration and system tests. However, these tests cannot prove that the product under consideration is error-free. Testing what is wrong does not make what is wrong right.

[3] Barry W. Boehm: Guidelines for Verifying and Validating Software Requirements and Design Specifications

[4] In addition to its use in systems engineering, the V-Model can also be used in requirements engineering, for example. Here, for example, business requirements and business cases, stakeholder requirements and system design, solution requirements and architecture design as well as system requirements and component design are juxtaposed. It can also be used in the context of Automotive SPICE.

Here you can find a German-language video explaining the V-Model.

Here you will find a detailed description of the historical development of the process model.

And here you can find additional information from the t2informatik Blog:

Do you still manage processes?

The best process in requirements management

IT analysis as a creative process

t2informatik develops and modernises software as a service provider. Click here to learn more.