V-Model

The V-model is a term applied to a range of models, from a conceptual model designed to produce a simplified understanding of the complexity associated with systems development to detailed, rigorous development lifecycle models and project management models.

There are several radically different forms of the V-model, and this creates considerable confusion. The V-model falls into three broad categories.

Firstly there is the German V-Model "Das V-Modell", the official project management methodology of the German government. It is roughly equivalent to PRINCE2, but more directly relevant to software development. What is probably the earliest use of the V-Model as a basis for a standard is Software Development Standard for the German Federal Armed Forces, 1992. The key attribute of using a "V" representation was to require proof that the products on the right-side of the V were acceptable by the appropriate test and integration organization implementing the left-side of the V. <German Directive 250, Software Development Standard for the German Federal Armed Forces, V-Model, Software Lifecycle Process Model, August 1992>

V-Model (software development)

In software development, the V-model represents a development process that may be considered an extension of the waterfall model, and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

Verification phases

Requirements analysis

In the requirements analysis phase, the first step in the verification process, the requirements of the system are collected by analyzing the needs of the user(s). This phase is concerned with establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated.