The V-Model is a software engineering model used to facilitate development, maintenance and improvement of IT systems and for software security requirements.
Thanks to the benefits it brings in terms of risk reduction and increased efficiency, the V-Model is a development model used in industrial organizations. In fact, it can be used for software projects of any size and in the most diverse sectors, with different versions adapted to reflect typical process steps of the respective sector.
The logical representation of the model, instead of descending along a straight line, after the programming phase, shapes itself with typical form of the letter V. The model shows the relationship between each phase of the lifecycle of the software development and its testing phase (software testing).
The model implements a well-structured method, in which each phase can be implemented through detailed documentation from the previous phase. Testing activities take place at the beginning of the project before the coding, which allows the project time to be shortened. In addition, the respective development phases of a project, the V-Model defines quality assurance procedures in parallel and describes how the individual phases can interact with each other.
Standard model
The main objective to be pursued during the development of the software is to create a product that is understandable, manageable and maintainable. First, the V-Model defines the development of a project individual phases pushed more and more in detail. At the beginning of the project, the model includes an analysis for system architecture. This is followed by the design of the system, where the components and interfaces of the system are planned. Once these steps are completed, the software architecture can be designed more in detail.
Then comes the actual development of the software according to the defined schemes and quality assurance phases, referring to the various steps of the development. The V-Model foresees the chances of feedback between testing / integration and definition phases at the same level. Such feedbacks in between are the corrections and changes to be applied as a negative result of the testing integration phases.
The correct implementation of the planned software architecture is checked by means of unit tests, which make it possible to control in detail whether the individual software modules exactly meet the required functions and deliver the expected results.
At the end of the project, the analysis of the requirements of the entire system is related to the testing of the completed product. Upon final acceptance, the customer checks whether the specifications are met while functioning. As a rule, only the behavior of the software at interface level is tested (acceptance test).
V-Model advantages and disadvantages
The development model is widely used mainly because it guarantees a high degree of transparency and clearly defined and comprehensible processes. Benefits includes optimized communication between the parties involved; minimized risks and better planning; improved product quality; cost saving through transparent activities in the product lifecycle.
Overall, the model can help avoiding unnecessary work and can ensure that all tasks are completed at the correct time in the correct order, minimizing the downtime. In some cases, however, the development model is inadequate to completely map the development process from the point of view of the developers, and the rigid structure most never allows a flexible response to changes.
In these cases alternative development model are available to be used depending on the project and team structure. For example, the cascade model is particularly suitable for small linear projects, while the spiral model can be used for iterative projects. In 2006, the V shaped model was updated to reflect more principles such as the “Agile” development. Those resulted in the V-Model XT. XT stands for Extreme tailoring and describes the new possibility to tailor the model on the needs of the project, simplify some phases and involve the customer more closely.
V-Model in the lifecycle of software
By introducing the “security” variable, the “V” development model differs from the standard one. This is due to the fact that functional safety standards define two lifecycles, one for the system and the other for the software. However, these two cycles are closely related and interdependent according to the strict requirements of the regulation.
In the model applied to the safety lifecycle, the phases of requirements analysis and system design are absent. This is because the design and planning phases are carried out at a system level as they are related to safety analyses. (e.g. hazard & risk analysis).
In this model, the first step is to define the security requirements of the software. These requirements are derived from the system safety requirements such as from the overall safety analysis. In large and complex projects, the architecture specification phase can be divided into the software breakdown phase into its main modules, and the “software system design” phase, which deals with further breakdown of the software until the identification of the individual models.
In addition to the normal validation (testing) activities, the model applied to the safety lifecycle includes a series of verification activities. The objective of these activities is to monitor the consistency of the product at all stages with the safety requirements. Validation and Verification (V&V) are considered among the main activities aimed at ensuring the safety integrity of the system being implemented.
