The V-model explained

There are many processes in software development that are designed to facilitate development, whether agile or traditional. One of the best known is the V-model. Read on to find out exactly what it involves, how it differs from the waterfall model and when it is worth using it.

The V-model is a process model in software development that depicts a linear project process. It divides the entire project process into phases that are firmly defined from the outset. In contrast to the waterfall model, which is also a linear model, the V-model has additional test phases that are opposed to the development phases.
The V-model therefore works with fixed project phases that are supplemented by test phases. In practice, this means that not only the system architecture and the specifications of the components are created during software development, but also the test phases at the same time. This ensures that the components and the overall system are thoroughly tested and that everything functions smoothly.
The V-model is not a new invention but was developed back in 1979 by the American Barry Boehm. Boehm illustrated his V-model with a V-shaped diagram. On the left-hand side of the V are the requirements for the project. These become more detailed step by step until they are finally clearly defined at the lowest level with their technical realisation. The top of the V represents the realisation. This is the actual product development, the programming in which the product is created. On the right-hand side of the V are the individual functions and how they are to be tested. These flow together more and more until the overall system is tested in a final step.

Decades have passed since 1979 and many experts have worked with the V-model. Since then, different types or variants of the method have been described, analysed and tested. They cannot be completely separated from each other; there are also mixed types.
The general V-model is a derivation of the waterfall model and describes a general procedure for software development.
A variant of the American model was patented in Germany and used as the V-Modell® of the Federal Republic of Germany for government projects, which is why many public IT projects were developed according to this model. Since 2005, this method has been a standard requirement in public tenders.

The V-model can basically be divided into three phases. In the verification phase, the requirements are recorded and converted into a system analysis. These requirements become increasingly specific according to the top-down principle and represent the left-hand side of the V-model. In the second phase, the coding phase, the product is developed. This is followed by the validation phase, in which the bottom-up principle is applied and tested. This is the right-hand side of the V. You start with the tests at unit level and work your way up to the tests at system level. This phase and the entire project end with product acceptance.

The verification phase

The verification phase comprises several levels. These levels are interdependent, i.e. if a change is made at a higher level, something will also change at the levels below.
An important step in the verification phase is gathering the requirements. Before work can begin, all requirements must be analysed in detail and clearly defined. This determines what the end product must be able to do.
In the system analysis step, it is clarified whether it is even possible to realise all these requirements. A design is developed for the entire system and, depending on the type of project, possible graphic designs are also developed. This also includes the architecture, in which the system is broken down into individual components and the definition of the interfaces and their dependencies.
The verification phase ends with the module design. This is the lowest level at which it is determined how the functions will be implemented in your product.

The coding phase

In the coding phase, the product is programmed and the software is created. The V-model makes no specifications or suggestions as to how this actual phase of software development should proceed.

The validation phase

We are now on the right-hand side of the V. The tests found on this side always correspond to the level on the left-hand side of the V. They are therefore opposite each other in the diagram.
The unit test is at the lowest level. This is where the individual components and features are analysed, and the extent to which they have been implemented as stated in the requirements is determined. It is important to consider only these, and not the dependencies. This is because a failure can occur in both, but the dependencies should not be checked here.
This is followed by the integration test. This checks that the modules work together and that the data exchange between the components works smoothly.
The system test is the latest point at which the customer is also involved and several test runs of the entire system are carried out. One reason for this is to test all the functionalities once again, but the customer can also test to what extent the system is usable for him.
This phase is known as acceptance, and a final test should take place under real conditions, i.e. in the environment in which the software will later be used. Users should be invited to take part in the test in order to obtain a test result that is as realistic as possible.
With the last phase, the test is considered complete and the software development according to the V-model is considered finished, as the product works exactly as agreed in the verification phase.

Like all project management methods, the V-model has strengths and weaknesses and is better suited to some projects than others. One of the advantages is that the tests are designed very early on, which makes it easier to recognize incomplete specifications. The simple structure of the method also proves to be advantageous, as no lengthy and complicated training is required to explain to employees how they should proceed. Another advantage can be that the customer is not present during the actual development phase. This gives the development team a lot of freedom and allows them to work undisturbed. This is also due to the fact that the specifications with the corresponding tests are already defined at the beginning. Another positive aspect is the early involvement of the testers, who can uncover potential problems and generally the high number of tests, which leads to increased security.
The disadvantages are usually cited by representatives of the "new" agile methods or frameworks, as the model is already over 40 years old. The linear approach is generally regarded by many as outdated, but this does not mean that it is no longer used anywhere today.
The fact that the V-model is quite simple is cited by critics as evidence that the method is too simplistic and lulls decision-makers into a false sense of security. It is also less flexible than agile approaches, which use an iterative approach.

The V-model certainly has its raison d'être, above all because of the security it creates. After all, the many tests uncover problems that might not have been noticed until the end. Nevertheless, this linear process is not ideal in today's software development, where agile approaches are becoming increasingly important. One of the reasons for this is that projects cannot be adapted promptly.
It is therefore important to carefully consider whether this method is the right one before starting a project. It is well suited to projects with hierarchical components and low complexity.