Talk:V-model (software development)

Duplicate article

This article duplicates the wikipedia article [1] SpeoLeo (talk) 15:32, 4 February 2010 (UTC)[reply]

The article describes the V-Model as featuring "verification" along the left (descending or "development") leg, and "validation" along the right (ascending or "deployment") leg. I believe this is a misuse of the terms, verification and validation.

Although the following is a simplification, I believe it is not a distortion:

"Verification" means "confirming that a product is built according to specifications and standards". Sometimes this is represented, confusingly, as "the product meets its requirements"; this should be understood as being opposed to its intended users' requirements. The traditional characterisation of "verification" is, "Are we building the thing right?"

"Validation" means "confirming that a product is fit for a specific use". This is sometimes expressed as "meeting user requirements". A product with multiple uses will require multiple validations. The traditional characterisation of validation is, "Are we building the right thing?"

These terms can apply to any type of product, and not just to executable software. Each work-product created down the development leg should be verified against inputs to the task that created it, and validated against the needs of its downstream users. For example, an external design document (specifying interfaces and external behaviour) should be fit for the specific purposes of architectural design, system test design, technical authoring, and customer signoff.

Given that test cases are derived from the work products created down the development leg, test execution up the deployment leg is mostly verification against specifications, not validation. "Validation testing" is a special class of testing, or perhaps a particular attitude to testing, paying regard to the real use of the test item (at any level), regardless of its specification.

Test execution, whether for verification or validation, may itself be subject to verification that it was performed in accordance with test plans and test specifications.

Donmillion (talk) 11:01, 24 January 2008 (UTC)[reply]

I agree with Donmillion. Verification and Validation are misused. It will be better to switch "Verification Phases" and "Validation Phases", and include citation to the Verification_and_Validation wikipedia article.

User:Anonymous 26 September 2008

Achilles852 (talk) 02:09, 5 February 2009 (UTC) While I agree with the two views above. I was just wondering if I'm misinterpreting it in thinking that there should be a line from "Architectural Design" Phase in the Image leading into "Integration Testing" - which would mean that Integration tests are designed during "Architectural Design"? because that is exactly what "Architectural Design" states i.e. "The integration testing design is carried out in this phase."[reply]

Criticisms of the system

The other articles in the Development Models tree have sections on the method's weakness. Can someone well-versed in V-Model application discuss the potential failings, criticisms, etc.?65.217.55.195 (talk) 15:06, 26 July 2010 (UTC)[reply]

"It's not agile, therefore it sucks." -Joel Nyström

Time

I know that at least some people do not put time on the v-model. It may be a mistake. I think that v-model + time is the waterfall model, but with out time (or specifying what the artefacts are) it fits waterfall, and agile (do a little requirements capture, by talking to on-sight customer. write acceptance tests. do a little system/architecture design. write system tests. write unit tests. write code. re-run tests) -- Richard Delorenzi

— Preceding unsigned comment added by 92.40.253.127 (talk) 14:19, 26 September 2012 (UTC)[reply]

A reference to your statement would be needed, but it seems to contradict itself. --Walter Görlitz (talk) 15:36, 26 September 2012 (UTC)[reply]