GDPA  
V-Model  

A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z

Identification

V-Model

Definitions/Uses

1999
Reference /Sommerville, 1999/ Software Engineering
Definition/
Use
The V-Model of development.
(from chapter 22) V&V Process: is a whole life-cycle process. V&V must be applied at each stage in the software process.

Has two principal objectives:
- The discovery of defects in a system.
- The assessmento of whether or not the system is usable in an operational situation.

1997
Reference /VM 1997/ V-Model 97, Lifecycle Process Model
Definition/
Use
Regulations setting up all activities, products, and their logical interdependencies during the development and maintenance/modification of systems, realizing the system tasks predominantly by using IT, within the scope o the federal administration.
1979
Reference /Boehm, 1979/ Guidelines for Verifying and Validating Software Requirements and Design Specifications
Definition/
Use
(from the text of the paper): This figure represents a "V-chart" which shows the context of verification and validation activities throughout the software lifecycle [personal communication from J.B. Munson, System Development Coorporation, 1977]. This is done in terms of the levels of refinement involved in defining and developing a software product, and the corresponding levels of V&V involved in qualifying the product for the operational use.

From the V-chart, it is clear that the key artifact idstinguishes verification activities from validation activities is the software requirements baseline. This refers to the requirements specification which is developed and validated during the Plans and Requirements Phase, accepted by the customer and developer at the Plans and Requirements Review as the basis for the software development contract, and formally change-controlled thereafter.

By definition, verification involves the comparison between the requirements baseline and the successive refinements descending from it -- the product design, detailed design, code, data base, and documentation -- in order to keep these refinements consistent with the requirements baseline. Thus, verification activities begins in the Product Design Phase and conclude with the Acceptance Test. They do not lead changes in the requirements baseline; only to changes in refinements descending from it.

On the other hand, validation identifies problems which must be resolved by a change of the requirements specification. Thus, there are validation activities which occur throughout the software life-cycle, including the development phase. For example, a simulation of the product design may establish not only that the design cannot meet the baseline performance requirements (verification), but also that the performance requirements are too stringent for any cost-effective product designs, and therefore need to be changed (validations).

1979
Reference /Myers, 1979/ The Art of Software Testing
Definition/
Use
(from the text of the paper): The testing cycle has been structured to model the development cycle. In other words, one should be able to establish a one-to-one correspondence between development and testing processes. For instance, the purpose of a module test is to find discrepancies between the program's modules and their interface specifications. The purpose of function testing is showing that a program does not match its external specifications. The purpose of system testing is showing that the product is inconsistent with its original objectives. The advantages of this structure are that it avoids unproductive redundant testing and prevents one from overlooking large class of errors. For instance, rather than simply labeling system testing as "testing of the whole system" and possibly repeating earlier tests, system testing is oriented toward a distinct class of errors (those made during the translation of the objectives to the external specification) and measured with respect to a distinct type of documentation in the development process.

As noted earlier, the forms of high-order testing shown in Figure 6.3 (above) are most applicable to software products (programs written as a result of a contract or programs intended for wide usage, as opposed to experimental programs or programs written for use only by the program's author). Programs not written as programs often do not have formal requirements and objectives; for such programs, the function test might be the only higher-order test. Also, the need for high-order testing increases as the size of the program increases. The reason is that the ratio of design errors (errors made in the earlier development processes) to coding errors is considerably higher in large programs than in small programs.

Note that the sequence of testing processes in Figure 6.3 does not necessarily imply a time sequence. For instance, since system testing is not defined as "the kind of testing one does after function testing", but is defined as a distinct type of testing focused on a distinct class of errors, it could very well be partially overlapped in time with other testing processes.

Other Languages

German: V-Modell

This page online  •  GDPA Online  •  Last Updated 24.Jun.2003 by C. Freericks