What is the V-model?

The V-model is one of those things: in the Systems Engineering It is assumed that everyone knows it, so it is rarely explained. And as a result, misunderstandings quickly creep in. The aim of this article is to explain the V-model to the best of our knowledge and belief.

Which V-model?

Especially in Germany, you have to be careful: Because there is the V-Modell 97 and V-Modell XT. These are Development standards for IT projectsand is required for public tenders. In the systems engineering environment, these are not usually meant when the V-model is mentioned. On the one hand, this is about development processes, and on the other hand, it is about software development, not system development. The introduction of the English Wikipedia article also deals specifically with the possible misunderstandings.

Why the V-model was necessary

Today's V-model was developed in 1991 by Kevin Forsberg and Harold Mooz in the paper "The Relationship of System Engineering to the Project Cycle"presented. The aim of the model is to clearly present the technical aspects of the project life cycle and to clarify the responsibility of the systems engineer. However, the models used until then, such as "waterfall" and "spiral", were often rejected by the teams as unfamiliar and unhelpful. Forsberg and Mooz wanted to create an alternative, which they succeeded in doing.

V model or Vee model? In the article by Forsberg and Mooz, the model is referred to as "Vee", but "V" is often used in the literature.

Of course, there were already variants of the V-model before that. NASA had already developed a similar model for space travel in particular, but Forsberg and Mooz then refined it.

The V-model in systems engineering

But now to the actual content. The picture above shows the V-model. What is often forgotten: The V-model has three Dimensions: In addition to the two coordinates in the paper plane, there is a third. But more on this later.

Let's take a look at the most important aspects of the V. You can imagine that various development artifacts are positioned on the V. Depending on how simple or complex the system to be developed is, only a few or very many artifacts are required. However, six are common, which manifest themselves at least in the form of six baselines and formal reviews. The Critical Design Review (CDR), for example, is well known (and feared). The parts of the V basically have the following meaning:

• Links Development begins at the top with the requirements of the system to be developed
• The left arm enriches the requirements with solution-specific information such as architecture and design. The further down you go, the closer you get to implementation.
• In the center belowat the top of the V, you will find the result, i.e. the finished product.
• The right arm of the V covers the results of verification and validation (V&V).

Different points of view

This view also results in a natural direction, from top left to bottom and back to top right. It is important to remember that this is not a chronological sequence. The left leg represents a dependency between the artifacts: If something changes far down (close to the implementation), this usually has no effect on the requirements. Conversely, however, a change in the requirements can have a major impact on the implementation.

The natural direction of the V does not represent a temporal sequence.

On the right-hand side, the dependency goes in the other direction: at the bottom are elementary tests (such as unit tests), while at the top are acceptance tests, and in between are things like integration tests. If a unit test does not pass, then it makes little sense to carry out acceptance tests, for example.

However, we need to distinguish between "Create test" and "Perform test" on the right-hand side. Of course, an acceptance test can be created as soon as the requirements have been defined. It just cannot be carried out before the entire system has been developed. Since the V&V activities on the right relate to the artefacts of the same level on the left, this is often visualized using horizontal arrows.

The third dimension

The article by Forsberg and Mooz introduces a third dimension that goes "into the paper" and is made up of configuration items (CI). This is intended to express the fact that when a system is detailed, it is broken down into further subsystems. This clearly reflects the systems engineering concept of decomposition and interfaces.

Criticism

I consider the V-model to be a very powerful tool for talking precisely about systems engineering. Of course, there is also criticism, justified or not. The article is interesting The seductive and dangerous V Model. This article again points out that there are many "V-models", some of which have very different meanings (the German V-model XT is also mentioned there again). But the main criticism is ultimately that the V-model is too vague and indirectly lends credibility to the waterfall model, i.e. the linear development path from requirements to result (the left-hand part in the V). I agree with this, but as already mentioned, this is not actually intended as a linear process in the V-model. In this respect, I see the V-model more as a reference model that makes communication much easier. There are many approaches to filling it with life, some of which are also presented in the aforementioned article.

Can agile development be carried out according to the V-model? Of course it is!

The topic of agility has been on everyone's lips in recent years. An important question is therefore whether the V-model is compatible with agile development approaches. I have already answered this question with a clear "yes". Although that was about systems engineering (and not the V-model), the conclusion is the same. The V-model describes artifacts and their relationships. There are many ways to arrive at these artifacts. The V-model is a map that can help you not to lose your bearings with a wide variety of approaches.

Image source: Wikipedia