The V-model represents a software development process which may be considered an extension
of the waterfall model.
Instead of moving down in a linear way, the process steps are bent upwards after the coding
phase, to form the typical V shape.
The V-Model demonstrates the relationships between each phase of the development life
cycle and its associated phase of testing.
The horizontal and vertical axes represents time or project completeness and level of
abstraction, respectively.
Verification phases Requirements analysis
In the Requirements analysis phase, the first step in the verification process, the requirements
of the system are collected by analyzing the needs of the user(s).
This phase is concerned with establishing what the ideal system has to perform.
However it does not determine how the software will be designed or built.
Usually, the users are interviewed and a document called the user requirements document is generated.
The user requirements document will typically describe the system’s functional, interface,
performance, data, security, etc. requirements as expected by the user.
It is used by business analysts to communicate their understanding of the system to the users.
The users carefully review this document as this document would serve as the guideline
for the system designers in the system design phase.
The user acceptance tests are designed in this phase.
See also Functional requirements.
There are different methods for gathering requirements of both soft and hard methodologies
including; interviews, questionnaires, document analysis, observation, throw-away prototypes,
use cases and static and dynamic views with users.
System design Systems design is the phase where system engineers
analyze and understand the business of the proposed system by studying the user requirements
document.
They figure out possibilities and techniques by which the user requirements can be implemented.
If any of the requirements are not feasible, the user is informed of the issue.
A resolution is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development
phase is generated.
This document contains the general system organization, menu structures, data structures
etc.
It may also hold example business scenarios, sample windows, reports for the better understanding.
Other technical documentation like entity diagrams, data dictionary will also be produced
in this phase.
The documents for system testing are prepared in this phase.
Architecture design The phase of the design of computer architecture
and software architecture can also be referred to as high-level design.
The baseline in selecting the architecture is that it should realize all which typically
consists of the list of modules, brief functionality of each module, their interface relationships,
dependencies, database tables, architecture diagrams, technology details etc.
The integration testing design is carried out in the particular phase.
Module design The module design phase can also be referred
to as low-level design.
The designed system is broken up into smaller units or modules and each of them is explained
so that the programmer can start coding directly.
The low level design document or program specifications will contain a detailed functional logic of
the module, in pseudocode: database tables, with all elements, including
their type and size all interface details with complete API references
all dependency issues error message listings
complete input and outputs for a module.
The unit test design is developed in this stage.
Validation phases In V-model, each stage of verification phase
has a corresponding stage in validation phase.
Following are phases of validation in V-Model.
Unit testing In V-Model, Unit Test Plans are developed
during module design phase.
In V-Model it is the responsibility of Project implementation team to created UTPs and execute
them.
These UTPs are executed to eliminate bugs at code level or unit level.
Unit is the smallest entity, which can independently exist.
Unit test ensures that smallest entity can function correctly when isolated from rest
of the codes/units.
Integration testing Integration Test Plans are developed during
Architectural Design Phase.
In V-Model, it is the responsibility of project implementation team to create Integration
Test Plans and execute them.
Integration tests ensure that units tested independently can coexist and communicate
among themselves.
Test results are shared with customer's team.
System testing System Tests Plans are developed during System
Design Phase.
Unlike Unit and Integration Test Plans, System Test Plans are composed by client's business
team.
System Test ensures that expectations from application developed are met.
Whole application is tested for its functionality, interdependency and communication.
System Test ensures that functional and non-functional requirements are met.
Load and performance testing, stress testing, regression testing etc. are sub set of system
testing.
User acceptance testing User Acceptance Test Plans are developed during
Requirement Analysis phase.
Test Plans are composed by business users.
UAT is performed in production kind of user environment with almost real time data.
UAT ensures that delivered system meets user's requirement and system is ready for use in
real time.
Criticism The V-Model has been criticized by Agile advocates
and others as an inadequate model of software development for numerous reasons.
Criticisms include: It is too simple to accurately reflect the
software development process, and can lead managers into a false sense of security.
The V-Model reflects a project management view of software development and fits the
needs of project managers, accountants and lawyers rather than software developers or
users.
Although It is easily understood by novices, that early understanding is useful only if
the novice goes on to acquire a deeper understanding of the development process and how the V-Model
must be adapted and extended in practice.
If practitioners persist with their naive view of the V-Model they will have great difficulty
applying it successfully.
It is inflexible and encourages a rigid and linear view of software development and has
no inherent ability to respond to change.
It provides only a slight variant on the waterfall model and is therefore subject to the same
criticisms as that model.
It provides greater emphasis on testing, and particularly the importance of early test
planning.
However, a common practical criticism of the V-Model is that it leads to testing being
squeezed into tight windows at the end of development when earlier stages have overrun
but the implementation date remains fixed.
It is consistent with, and therefore implicitly encourages, inefficient and ineffective testing
methodologies.
It implicitly promotes writing test scripts in advance rather than exploratory testing;
it encourages testers to look for what they expect to find, rather than discover what
is truly there.
It also encourages a rigid link between the equivalent levels of either leg, rather than
encouraging testers to select the most effective and efficient way to plan and execute testing.
It lacks coherence and precision.
There is widespread confusion about what exactly the V-Model is.
If one boils it down to those elements that most people would agree upon it becomes a
trite and unhelpful representation of software development.
Disagreement about the merits of the V-Model often reflects a lack of shared understanding
of its definition.
Current state Supporters of the V-Model argue that it has
evolved over time and supports flexibility and agility throughout the development process.
They argue that in addition to being a highly disciplined approach, it promotes meticulous
design, development, and documentation necessary to build stable software products.
Lately, it is being adopted by the medical device industry.
See also
V-Model Dual Vee Model
Systems Development Life Cycle Product lifecycle management
Portal:Software Testing References
Further reading Roger S. Pressman:Software Engineering: A
Practitioner's Approach, The McGraw-Hill Companies, ISBN 0-07-301933-X
Mark Hoffman & Ted Beaumont: Application Development: Managing the Project Life Cycle, Mc Press,
ISBN 1-883884-45-4 Boris Beizer: Software Testing Techniques.
Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3
External links A paper by Christian Bucanac
The SDLC and SixSigma SDLC for small and medium DB applications