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.

First 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. The key attribute of using a "V" representation was to require proof that the products from the left-side of the V were acceptable by the appropriate test and integration organization implementing the right-side of the V.

In the UK and throughout the testing community worldwide, the V-model is widely seen as a vaguer illustrative depiction of the software development process as described in the International Software Testing Qualifications Board Foundation Syllabus for software testers. There is no single accepted definition of this model, which is more directly covered in the alternative article on the V-Model (software development). There are therefore multiple variations of this version. This problem must be borne in mind when discussing the V-model.

The US also has a government standard V-model which dates back about 20 years like its German counterpart. Its scope is a narrower systems development lifecycle model, but far more detailed and more rigorous than most UK practitioners and testers would understand by the V-model.

The V-model is a graphical representation of the systems development lifecycle. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework.

The V represents the sequence of steps in a project life cycle development. It describes the activities to be performed and the results that have to be produced during product development. The left side of the "V" represents the decomposition of requirements, and creation of system specifications. The right side of the V represents integration of parts and their validation. However, Requirements need to be validated first against the higher level requirements or user needs. Furthermore, there is also something as validation of system models (e.g. FEM). This can partially be done at the left side also. To claim that validation only occurs at the right side may not be correct. The easiest way is to say that verification is always against the requirements (technical terms) and validation always against the real world or the user needs.

...
Wikipedia