V-model

History

The concept of the V-shaped model was developed independently by Germany and the USA in the late 1980s:

• The German V-model was developed by the aerospace company IABG in Ottobrunn near Munich in collaboration with the Federal Department for the Procurement of Arms in Koblenz , for the German Ministry of Defense. The model was adopted by the German federal administration for civilian purposes in the summer of 1992 ^[1] .
• The American V-Model (VEE) was developed by the National System Engineering Council (international since 1995) for satellite systems, including hardware, software and user interaction ^[2] .

The current version of the V-Model is the V-Model XT, which was approved in February 2005 . The V-model is used to control the software development process for the German federal administration. Now it is the standard for German government and defense projects, as well as for software manufacturers in Germany. V-Model is rather a set of standards in the field of projects related to the development of new products. This model is largely similar to PRINCE2 and describes methods for both project management and system development.

Basic Principles

The basic principle of the V-shaped model is that the detail of the project increases when moving from left to right, simultaneously with the passage of time, and neither one nor the other can reverse. Iterations in the project are carried out horizontally, between the left and right sides of the letter.

In relation to the development of information systems, the V-Model is a variation of the cascade model , in which the development tasks go top down on the left side of the letter V, and the test tasks go up the right side of the letter V. Inside V, horizontal lines are drawn showing how the results of each phase developments affect the development of the testing system at each of the testing phases. The model is based on the fact that acceptance tests are based primarily on requirements, system testing on requirements and architecture, comprehensive testing on requirements, architecture and interfaces, and component testing on requirements, architecture, interfaces and algorithms ^{[4 ]} .

Goals

The V-model provides support in the planning and implementation of the project. The following tasks are set during the project:

• Risk minimization: The V-shaped model makes the project more transparent and improves the quality of project control by standardizing intermediate goals and describing the corresponding results and responsible persons. This allows you to identify deviations in the project and risks in the early stages and improves the quality of project management, reducing risks.
• Improvement and quality assurance: V-Model - a standardized development model that allows you to achieve the desired quality from the project. Intermediate results can be checked in the early stages. Universal documentation makes it easier to read, understand, and verify.
• Reducing the total cost of the project: Resources for development, production, management and support can be pre-calculated and monitored. The results obtained are also universal and easily predicted. This reduces the costs of subsequent stages and projects.
• Improving the quality of communication between project participants: A universal description of all elements and conditions facilitates mutual understanding of all project participants. Thus, inaccuracies in understanding between the user, the buyer, the supplier and the developer are reduced ^[5] .

Advantages

• V-Model users are involved in the development and support of the V-Model. The Change Control Committee supports the project and meets once a year to process all received requests for changes to the V-Model ^[6] .
• At the start of any project, the V-shaped model can be adapted for this project, since this model does not depend on the types of organizations and projects ^[7] .
• V-model allows you to break the activity into separate steps, each of which will include the necessary actions for it, instructions for them, recommendations and a detailed explanation of the activity ^[8] .

Limitations

The following points are not taken into account in the V-model, but can be considered separately, or it is possible to adapt the model to them:

• The placement of service contracts is not regulated.
• Organization and implementation of the management, maintenance, repair and disposal of the system are not taken into account in the V-model. However, planning and preparation for these operations by the model are considered.
• The V-shaped model is more concerned with software development in the project than with the entire process organization ^[9] .

Benefits

• The model attaches particular importance to planning aimed at verification and certification of the developed product at the early stages of its development. Unit testing phase confirms the correctness of detailed design. The phases of integration and testing implement architectural design or top-level design. The system testing phase confirms the correctness of the fulfillment of the product requirements stage and its specifications ^[10] .
• The model provides certification and verification of all external and internal received data, and not just the software product itself ^{[10] [11] [12]} .
• In the V-shaped model, requirements are determined before the development of the system design, and software design - before the development of components ^[10] .
• The model defines the products that should be obtained as a result of the development process, and each received data should be tested ^{[10] [12]} .
• Thanks to the model, project managers can track the progress of the development process, since in this case it is quite possible to use the timeline, and the completion of each phase is a control point ^{[10] [12]} .

Weaknesses

• The model does not provide for work with parallel events ^[10] .
• The model does not provide for the introduction of requirements for dynamic changes at different stages of the life cycle ^{[10] [11] [13]} .
• Testing requirements in the life cycle occurs too late, as a result of which it is impossible to make changes without affecting the project implementation schedule ^{[10] [11]} .
• The model does not include actions aimed at risk analysis ^[10] .
• Some result can be seen only when the bottom of the letter V is reached ^[14] .

• Waterfall model
• Dual vee model
• Chaos model

• Details of the V-shaped model (92/97 / XT) (German)
• Official V-Model Documentation