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]

The V-Model "in its simple and commonly understood form"

Walter - you removed three phrases in successive criticisms of the V-Model; "in its simple and commonly understood form", "in its most commonly understood form" and "in that simple form". There was a specific reason for those phrases. As the last criticism says, there is no clear and agreed definition of the V-Model. A defender of the V-Model might object to the criticisms on the grounds that the V-Model, as they understand it, is really more sophisticated, complex and effective than the criticisms assume. The trouble is that very many people, especially novices and project managers, do have that naive understanding of the V-Model "in its simple and commonly understood form", and can get into considerable trouble trying to make it work.

I can see why you removed the phrases. In any sound model (i.e. one that is coherent and well defined) the phrases would be redundant. However, the point is that the V-Model does have multiple variants, some with only subtle differences and others with massive differences. This makes discussion and criticism very difficult. Perhaps the final criticism should be the first in the list, to set the scene. I do think the three phrases you removed should be restored, to avoid confusion.

Freddie Threepwood (talk) 11:35, 9 January 2013 (UTC)[reply]

An anon has started to restore material, but the phrase is redundant but nowhere does the article explain that it has variants. It only explains that it is one, single process. --Walter Görlitz (talk) 15:15, 9 January 2013 (UTC)[reply]

Also, I've never heard that there are multiple forms so until you provide some reliable source to support your claim it makes no sense to include the phrase. --Walter Görlitz (talk) 15:20, 9 January 2013 (UTC)[reply]

I'm surprised by your suggestion that there are not multiple forms. I assume that that is the reason for two related and overlapping Wikipedia articles. A simple search will reveal multiple variations, from the German V-Modell, to the US government version, and all sorts of more loosely defined versions, which are no more than illustrations of the the software development lifecycle. Indeed, the two illustrations in this article contradict each other. They illustrate models that are similar but different. What is the novice who is looking for guidance to make of that?

One could argue that the Forsberg & Mooz version is the definitive V-Model, but unfortunately that source isn't available online, and it is largely irrelevant to the great majority of people who discuss the V-Model out in the field. There is huge confusion about the V-Model because of these variations, and pretending that this is not so merely adds to the confusion of people who come looking for guidance, often having come across a simplified form in an exam syllabus and then looking for further information.

The article, in its current form, doesn't describe the V-Model. It describes an approach that would be more or less consistent with the V-Model. One could amend the article in countless ways. It would still be consistent with the V-Model, but it wouldn't be ''the'' V-Model. In attempting to provide extra detail and nail down a precise form of the V-Model I think the current article is just making the confusion worse. The section heading "Verification Phases" and "Validation Phases" are highly misleading. That is not what verification and validation mean. See the British Computer Society's glossary of software testing terminology.

The anonymous edit was by me, because I hadn't noticed I was not logged in. However, I didn't restore anything you removed. I merely clarified a point I had made and which you hadn't touched. Freddie Threepwood (talk) 16:10, 9 January 2013 (UTC)[reply]