Talk:V-model (software development)

message: This article duplicates the wikipedia article 
SpeoLeo (talk) 15:32, 4 February 2010 (UTC)
thread_title:  Duplicate article 

message: 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)
thread_title:  Criticisms of the system 

message: 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)
replies: text: A reference to your statement would be needed, but it seems to contradict itself. --Walter Görlitz (talk) 15:36, 26 September 2012 (UTC)
thread_title:  Time 

message: 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)
thread_title:  Verification (or Validation) on the descending left side of the V makes no sense at all