What is a V-Model?

The V-Model is a model that is utilized for different de­vel­op­ment processes, such as software de­vel­op­ment. It was developed in its original form in the 1990s, refined again and again over time, and adapted to current de­vel­op­ment methods. The basic idea, however, orig­i­nat­ed in the early 1970s and was conceived as an advanced de­vel­op­ment of the waterfall model.

In addition to the par­tic­u­lar de­vel­op­ment phases of a project, the V-Model defines the ac­com­pa­ny­ing procedure for quality assurance and describes how these specific phases can be in­te­grat­ed. The procedure model owes its name to its V-shaped structure.

First of all, the V-Model defines a project course in specific phases that pro­gres­sive­ly gets more detailed:

• At the beginning of the project, the model provides an analysis of the planned system’s general re­quire­ments.
• After this, the project should be augmented with the func­tion­al and non-func­tion­al re­quire­ments of the system ar­chi­tec­ture.
• This is followed by the system design, during which the system com­po­nents and in­ter­faces are designed.
• When these phases are completed, the software ar­chi­tec­ture can be designed in detail.

Now the actual software de­vel­op­ment occurs according to these plans, followed by the quality assurance phases, which always refer to the de­vel­op­ment steps. The model includes the following tasks:

• Unit tests
• In­te­gra­tion tests
• System in­te­gra­tion
• Ac­cep­tance

The “V” sym­bol­izes two branches of the model. Here, the de­vel­op­ment phase is situated across from the cor­re­spond­ing quality assurance phases. The left arm of the letter V contains the tasks for designing and de­vel­op­ing the system. The right arm en­com­pass­es related quality assurance measures. Located in the middle of both these arms, embedded between the de­vel­op­ment phases and quality assurance phases, is the im­ple­men­ta­tion of the product. In the case of a software project, this would be software pro­gram­ming.

Whether the designed software ar­chi­tec­ture has been correctly im­ple­ment­ed is checked via unit tests. During these tests, the software’s in­di­vid­ual modules are scru­ti­nized in-detail to assess whether they perform the required functions and actually deliver the expected results. In order to avoid errors, these module tests are usually run in parallel to de­vel­op­ment where possible.

Situated across from the system design are the in­te­gra­tion tests, which are in place to check if the separate com­po­nents work together as planned, and whether, for example, all processes yield the expected results. Erroneous results at this point can indicate problems with the in­ter­faces, among others.

The system test checks whether the system’s general re­quire­ments – which were defined when the system ar­chi­tec­ture was designed – have been met. These tests normally take place in a test en­vi­ron­ment, which readjusts the actual con­di­tions for users as ac­cu­rate­ly as possible.

At the end of the project, the re­quire­ments analysis of the overall system is performed. In the model, this is placed across from the ac­cep­tance of the finished product. During the final ac­cep­tance, the customer checks whether the software meets the re­quire­ments of routine operation. Here, the software behavior is normally tested on the surface, i.e. to the extent that a customer would use it on a day-to-day basis. One also refers to this as an ac­cep­tance test.

In 2006, the V-Model was finally over­hauled in order to be able to reflect prin­ci­ples such as agile de­vel­op­ment. The result was the V-Model XT. The XT here stands for Extreme Tailoring and refers to the added option of being able to tailor the model to a project’s specific re­quire­ments.

A fun­da­men­tal idea behind the latest ad­vance­ment was to provide a model that can be flexibly adapted to different project sizes. Even for smaller projects, the older method was often dis­pro­por­tion­ate­ly time-consuming, and therefore in­ef­fi­cient. With the V-Model XT, in contrast, it is possible to eliminate certain phases for small projects that would require too much ad­di­tion­al time.

Fur­ther­more, XT includes task blocks that ex­plic­it­ly refer to the customer. The old model only deals with the man­age­ment of the project by the con­trac­tor before it’s finally accepted. In the new model, the customer is more deeply-involved.

The model continues to be updated regularly due to ongoing in­no­va­tion in the software de­vel­op­ment process and improved prac­ti­cal­i­ty. The latest version of the V-Model XT is Version 2.3.

The V-Model XT is a popular procedure model in the industry and is con­sid­ered the official standard for IT projects by federal agencies. The V-Model is mandatory for most tenders for public-sector software projects. As such, it’s an important tool for companies that develop software for agencies and min­istries. It can be used for software projects of any size, whether in commerce, the military or the public sector. The model serves as a tool to fa­cil­i­tate the or­ga­ni­za­tion and execution of de­vel­op­ment, main­te­nance, and ad­vance­ment of diverse IT systems.

Fur­ther­more, the V-Model can be applied to other de­vel­op­ment areas such as elec­tron­ic or me­chan­i­cal systems in research and science. For these areas of ap­pli­ca­tion, there are lightly adapted versions that reflect the typical procedure steps of the re­spec­tive sectors.

The main reason why this de­vel­op­ment model is so popular is that it ensures high trans­paren­cy and cleanly-defined, com­pre­hen­si­ble processes. Below you’ll find an overview of the most important ad­van­tages and points of criticism.

• Op­ti­miza­tion of com­mu­ni­ca­tion between par­tic­i­pants through firmly-defined terms and re­spon­si­bil­i­ties
• Min­i­miza­tion of risks and better plannabil­i­ty through firmly-pre­scribed roles, struc­tures, and results
• Im­prove­ment of product quality through in­te­grat­ed quality assurance measures
• Cost savings through trans­par­ent reap­praisal of the entire product life cycle

All things con­sid­ered, the model helps to avoid mis­un­der­stand­ings and un­nec­es­sary work. Fur­ther­more, it ensures that all tasks are completed at the right time and in an ap­pro­pri­ate sequence, and that, if possible, no idle time arises.

The model is, in part, too simple to com­plete­ly il­lus­trate the de­vel­op­ment process from the developer’s point of view. The process focus is primarily on project man­age­ment. Fur­ther­more, the rel­a­tive­ly rigid structure hardly allows one to react flexibly to changes during de­vel­op­ment, and thus en­cour­ages a com­par­a­tive­ly linear project pro­gres­sion. Nev­er­the­less, with the V-Model it is possible to practice agile de­vel­op­ment, provided that the model is properly un­der­stood and utilized.

There are various procedure models in software de­vel­op­ment that – depending on the project and team structure – are worth con­sid­er­ing as a software de­vel­op­ment process. The selection of procedure models is rel­a­tive­ly large, although models such as the waterfall model or spiral model are widely used. The waterfall model is to some degree best-suited for small, linear on-going projects, while the spiral model can be well-utilized in it­er­a­tive­ly-struc­tured projects.