What is a V-Model?

The V-Model is a model that is utilised 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, ori­gin­ated 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­teg­rated. 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­gress­ively 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­pon­ents 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­teg­ra­tion tests
• System in­teg­ra­tion
• Ac­cept­ance

The “V” sym­bol­izes two branches of the model. Here, the de­vel­op­ment phase is situated across from the cor­res­pond­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­passes 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­ment­a­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­men­ted is checked via unit tests. During these tests, the software’s in­di­vidu­al modules are scru­tin­ized 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­teg­ra­tion tests, which are in place to check if the separate com­pon­ents 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­vir­on­ment, which readjusts the actual con­di­tions for users as ac­cur­ately 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­cept­ance of the finished product. During the final ac­cept­ance, 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­cept­ance test.

In 2006, the V-Model was finally over­hauled in order to be able to reflect prin­ciples 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­ment­al 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­ately 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­pli­citly refer to the customer. The old model only deals with the man­age­ment of the project by the con­tract­or 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­nov­a­tion in the software de­vel­op­ment process and improved prac­tic­al­ity. 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­sidered 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­is­tries. 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­it­ate the or­gan­isa­tion and execution of de­vel­op­ment, main­ten­ance, 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 mech­an­ic­al systems in research and science. For these areas of ap­plic­a­tion, there are lightly adapted versions that reflect the typical procedure steps of the re­spect­ive sectors.

The main reason why this de­vel­op­ment model is so popular is that it ensures high trans­par­ency and cleanly-defined, com­pre­hens­ible processes. Below you’ll find an overview of the most important ad­vant­ages and points of criticism.

• Op­tim­isa­tion of com­mu­nic­a­tion between par­ti­cipants through firmly-defined terms and re­spons­ib­il­it­ies
• Min­im­isa­tion of risks and better plan­nab­il­ity through firmly-pre­scribed roles, struc­tures, and results
• Im­prove­ment of product quality through in­teg­rated quality assurance measures
• Cost savings through trans­par­ent re­apprais­al of the entire product life cycle

All things con­sidered, the model helps to avoid mis­un­der­stand­ings and un­ne­ces­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­pletely 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 re­l­at­ively rigid structure hardly allows one to react flexibly to changes during de­vel­op­ment, and thus en­cour­ages a com­par­at­ively 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 utilised.

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 re­l­at­ively 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-utilised in it­er­at­ively-struc­tured projects.