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]

Xobbitua (talk) 10:10, 22 January 2019 (UTC) It's been a Decade (!) and there are still 2 duplicate articles with same figures and this one "lacking sources" - how about a merge to fix?[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. The phases are different and the arrows linking the two legs go in different directions. The first diagram contradicts the structuring of the article in Verification Phases and Validation Phases. 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 headings "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]

Don't be surprised. I suspected that there were two different v models since there was a lot of push and pull in the early article that seemed incongruous. Thanks for clarifying that. Again, I watch this page because it's part of the software development and testing projects. I'm not entirely clear on the subject and only monitor it for signs of obvious vandalism. --Walter Görlitz (talk) 21:09, 9 January 2013 (UTC)[reply]

Thanks for this. If you've been keeping an eye on this article for some time you've obviously got a fair understanding of its history. I think it needs improving, but I'm reluctant to spend the time to do a thorough re-write, and I'm also reluctant to do anything that would seem provocative! I do have some professional interest in this topic. I'm a software testing consultant and I'm keenly aware that many novice testers who come looking for information about the V Model as part of their studies get confused.

I've written an introduction to the other V-Model article that tries to explain the different sorts of V Model and why there is confusion. It's intended as a warning so that people know that the existence of these alternatives might be the reason for their confusion.

Would it help if I copied that explanation over into this article?

I also think it would be worth changing the titles of the sections from "Verification Phases" and "Validation Phases" to "Analysis & Build Phases" and "Test & Implementation Phases". This would be more accurate, more conventional and less confusing.

I'd also like to put a caveat that the process described in the article is not a series of necessary steps in the definitive V-Model (because there is no such thing), but an illustration of a development that is consistent with the V-Model concept.

Then, would it make sense to restore the phrases referring to the V-Model's simple and commonly understood form?

I really don't want to take over the article, but I'd feel a bit of professional guilt at walking away without trying to do something to improve matters and reduce the possible confusion. However, sadly this is one of those cases where readers who think that the situation is confusing have probably acquired a deeper understanding of the subject than those who think it's crystal clear. Freddie Threepwood (talk) 12:10, 10 January 2013 (UTC)[reply]

Why copy the material? Why not merge the two? Do you think that that they should be separate?

Also, don't worry about taking the article over, I don't see it that way. It seems more as though you understand the subject and enjoy writing. That makes you an ideal editor. In that light, make whatever changes you feel are necessary. --Walter Görlitz (talk) 15:13, 10 January 2013 (UTC)[reply]

Thanks for this. Yes, I'll do something, but I'm too busy right now. I don't think merging the articles is the right way though. I think it's worth retaining two in the short term; one for the formal German V-Modell, the US government version and the detailed lifecycle version (Forsberg & Mooz), and a second (ie this one) for the more informal software testers' depiction of the lifecycle.

In the longer term the former article should be broken out into its three constituent parts. Otherwise explanations can get hopelessly confused when one is dealing with things that look superficially similar but are really fundamentally different with quite distinct uses. Freddie Threepwood (talk) 13:29, 12 January 2013 (UTC)[reply]

--Lisaneo (talk) 04:38, 20 October 2014 (UTC) Hi, my concern is regarding the 4 validation phases of the V model: 1. Unit testing 2. Integration testing 3. System testing 4. User acceptance testing[reply]

First, I find the definition of "Integration" testing to be somewhat confusing if used in isolation without qualifying whether if it is referring to function, component, or system level. If "Integration" testing here refers to Function or Component Integration testing, I guess the sequence of test will still make sense. However, for System Integration Testing, SIT, I think this is performed after System Test, in cases where there are multiple systems integrating together to form the whole solution.

Verification (or Validation) on the descending left side of the V makes no sense at all

As mentioned above, having Verification or Validation on the V's "left side" doesn't make any sense at all and the heading structure of the article is thus wrong. Verification (and Validation) are tasks performed on the "right side" only. You **verify** that the software and system works and you **validate** it against the (user) requirements. In the real world, "validation" may be ongoing on the left side too insofar as you may validate the requirement list against what the user says during meetings, but the left side is really just the design and top-down decomposition phase.

For example, the Galileo Software Standard (Galileo Industries document "GAL-SPE-GLI-SYST-A/0092" issue 7) has the following definitions:

  - VALIDATION: Confirmation, by examination and provision of objective evidence, that the particular requirements for a specific intended use are fulfilled, i.e. to ensure that specification requirements of the product are met. 
  - VERIFICATION: Confirmation, by examination and provision of objective evidence, that specified requirements have been fulfilled, i.e. check to ensure that the requirements process for a dedicated phase is properly applied.

And "Validation" is done during "Requirement Baseline Validation" and "Technical Specification Validation", at which point the Software System must actually exist so that there is something to validate!

  - RB-VALIDATION: Confirmation, through the validation process, that the Requirements Baseline (RB) functions and performances are correctly and completely implemented in the SOFTWARE PRODUCT and its components.
  - TS-VALIDATION: Confirmation, through the validation process, that the Technical Specification (TS) functions and performances are correctly and completely implemented in the SOFTWARE PRODUCT and its components.

The software lifecycle phases being listed as in order:

  - SW Planning Phase
  - SW Specification Phase
  - SW Design Phase
  - SW Implementation Phase
  - SW Integration and TS-Validation Phase
  - SW RB-Validation Phase
  - SW Acceptance Phase
  - SW Maintenance Phase

2001:7E8:C047:1B01:223:54FF:FE15:1831 (talk) 23:39, 24 February 2013 (UTC)[reply]