Content deleted Content added
Tag: |
|||
| (34 intermediate revisions by 13 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=|
{{WikiProject Computing}}
}}
== Duplicate article ==
This article duplicates the wikipedia article
[http://en.wikipedia.org/wiki/V-Model]
[[User:SpeoLeo|SpeoLeo]] ([[User talk:SpeoLeo|talk]]) 15:32, 4 February 2010 (UTC)
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.
Line 22 ⟶ 34:
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."
[[User:Xobbitua|Xobbitua]] ([[User talk: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?
== 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.?[[Special:Contributions/65.217.55.195|65.217.55.195]] ([[User talk:65.217.55.195|talk]]) 15:06, 26 July 2010 (UTC)
"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
<span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/92.40.253.127|92.40.253.127]] ([[User talk:92.40.253.127|talk]]) 14:19, 26 September 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
: A reference to your statement would be needed, but it seems to contradict itself. --[[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 15:36, 26 September 2012 (UTC)
== 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.
[[User:Freddie Threepwood|Freddie Threepwood]] ([[User talk:Freddie Threepwood|talk]]) 11:35, 9 January 2013 (UTC)
: 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. --[[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 15:15, 9 January 2013 (UTC)
: 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. --[[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 15:20, 9 January 2013 (UTC)
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 [http://www.testingstandards.co.uk/living_glossary.htm#V 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. [[User:Freddie Threepwood|Freddie Threepwood]] ([[User talk:Freddie Threepwood|talk]]) 16:10, 9 January 2013 (UTC)
: 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. --[[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 21:09, 9 January 2013 (UTC)
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 [[V-Model|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. [[User:Freddie Threepwood|Freddie Threepwood]] ([[User talk:Freddie Threepwood|talk]]) 12:10, 10 January 2013 (UTC)
: 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, [[:WP:BOLD|make whatever changes you feel are necessary]]. --[[User:Walter Görlitz|Walter Görlitz]] ([[User talk:Walter Görlitz|talk]]) 15:13, 10 January 2013 (UTC)
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. [[User:Freddie Threepwood|Freddie Threepwood]] ([[User talk:Freddie Threepwood|talk]]) 13:29, 12 January 2013 (UTC)
--[[User:Lisaneo|Lisaneo]] ([[User talk: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
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
[[Special:Contributions/2001:7E8:C047:1B01:223:54FF:FE15:1831|2001:7E8:C047:1B01:223:54FF:FE15:1831]] ([[User talk:2001:7E8:C047:1B01:223:54FF:FE15:1831|talk]]) 23:39, 24 February 2013 (UTC)
| |||