4 Misconceptions about the V-model

In the Article on the V-model I have already pointed out that there are many misunderstandings and misconceptions about this. But what exactly are they? In this article, I will address the four biggest misconceptions. If we can get these out of the way as a team, we will have already taken a big step forward.

This article was inspired by an article I recently wrote for Jama Software: The Myth of the V-Model

The V-model is actually quite simple: it starts at the top left with the highest requirements or objectives, which are then further specified towards the bottom right. The right arm then covers V&V, i.e. verification and validation via tests, analysis or inspection. These elements are related to each other, which is symbolized by arrows.

Misconception 1: The V-model is just an improved waterfall

The V-model often has a time axis, from left to right. If we interpret this absolutely, then we actually have the waterfall, with the lower right part "folded upwards" to form a V. Traces have also been added.

However, the timeline is not absolute. The waterfall is a linear process, but the V-model is developed iteratively until maturity.

Misconception 2: The V-model is "only" a process

Yes, the V-model is also a process, but not only. The process part is even standardized, for example in the V-modelwhich is a protected trademark in Germany. The V-model is referenced by many standards, e.g. ISO/IEC/IEEE 15288.

However, this view neglects the fact that the model also consists of elements and relations, i.e. a ER model is. This view can deepen understanding in a way that is not possible with the process view alone. Furthermore, the process view often thinks with a different granularity, e.g. requirements "documents". The model view enables a fine-grained view that is based on can be used in many different ways.

Misconception 3: The V-model is not suitable for agile working

The V-model is not only suitable for agile working, but (almost) a prerequisite for it! Because agility accepts change. But change can only be lived sensibly with fine-grained traceability. Robust traceability reflects the triangular relationships between requirements, tests and implementation.

I have already written more about this in the article How modeling enables agile system development.

Misconception 4: In development, we move "from left to right"

As I wrote above, we have to jump back and forth in the V-model during development. Nevertheless, it is often assumed that the requirements have to be written before the tests are written. But this is not the way to proceed.

The V-model is for Behavior-Driven Development (BDD) is suitable. With BDD, behavior is recorded in a testable form before work is carried out on the design. This approach is similar to the one widely used in software development. test-driven development comparable. Here too, the V-model provides the structures that make this approach possible in the first place.

Conclusion

The V-model is a powerful concept. However, it is old and was developed at a time when document-based work was the norm. But it can also be applied in a modern context and enables better products to be developed faster. But it needs to be understood.

Photo by Peter Secan on Unsplash
V-model Jama Software