The V-model is an SDLC model where execution of processes happens
in a sequential manner in a V-shape. It is also known as Verification
and Validation model.
The V-Model is an extension of the waterfall model and is based on
the association of a testing phase for each corresponding development stage.
This means that for every single phase in the development cycle, there is a
directly associated testing phase. This is a highly-disciplined model and the
next phase starts only after completion of the previous phase.
Under the V-Model, the corresponding testing phase of the
development phase is planned in parallel. So, there are Verification phases on
one side of the ‘V’ and Validation phases on the other side. The Coding Phase
joins the two sides of the V-Model.
The following illustration depicts the different phases in a
V-Model of the SDLC.
There are several Verification phases in the V-Model, each of
these are explained in detail below.
This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This phase
involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and needs
to be managed well, as most of the customers are not sure about what exactly
they need. The acceptance test design planning is done at this
stage as business requirements can be used as an input for acceptance testing.
Once you have the clear and detailed product requirements, it is
time to design the complete system. The system design will have the
understanding and detailing the complete hardware and communication setup for
the product under development. The system test plan is developed based on the
system design. Doing this at an earlier stage leaves more time for the actual
test execution later.
Architectural specifications are understood and designed in this
phase. Usually more than one technical approach is proposed and based on the
technical and financial feasibility the final decision is taken. The system
design is broken down further into modules taking up different functionality.
This is also referred to as High Level Design (HLD).
The data transfer and communication between the internal modules
and with the outside world (other systems) is clearly understood and defined in
this stage. With this information, integration tests can be designed and
documented during this stage.
In this phase, the detailed internal design for all the system
modules is specified, referred to as Low Level Design (LLD). It is
important that the design is compatible with the other modules in the system
architecture and the other external systems. The unit tests are an essential
part of any development process and helps eliminate the maximum faults and
errors at a very early stage. These unit tests can be designed at this stage
based on the internal module designs.
The actual coding of the system modules designed in the design
phase is taken up in the Coding phase. The best suitable programming language
is decided based on the system and architectural requirements.
The coding is performed based on the coding guidelines and
standards. The code goes through numerous code reviews and is optimized for
best performance before the final build is checked into the repository.
The different Validation Phases in a V-Model are explained in
detail below.
Unit tests designed in the module design phase are executed on the
code during this validation phase. Unit testing is the testing at code level
and helps eliminate bugs at an early stage, though all defects cannot be
uncovered by unit testing.
Integration testing is associated with the architectural design
phase. Integration tests are performed to test the coexistence and
communication of the internal modules within the system.
System testing is directly associated with the system design
phase. System tests check the entire system functionality and the communication
of the system under development with external systems. Most of the software and
hardware compatibility issues can be uncovered during this system test
execution.
Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user environment. Acceptance
tests uncover the compatibility issues with the other systems available in the
user environment. It also discovers the non-functional issues such as load and
performance defects in the actual user environment.
V- Model application is almost the same as the waterfall model, as
both the models are of sequential type. Requirements have to be very clear
before the project starts, because it is usually expensive to go back and make
changes. This model is used in the medical development field, as it is strictly
a disciplined domain.
The following pointers are some of the most suitable scenarios to
use the V-Model application.
· Requirements
are well defined, clearly documented and fixed.
· Product
definition is stable.
· Technology
is not dynamic and is well understood by the project team.
· There
are no ambiguous or undefined requirements.
· The
project is short.
The advantage of the V-Model method is that it is very easy to
understand and apply. The simplicity of this model also makes it easier to
manage. The disadvantage is that the model is not flexible to changes and just
in case there is a requirement change, which is very common in today’s dynamic
world, it becomes very expensive to make the change.
The advantages of the V-Model method are as follows −
· This
is a highly-disciplined model and Phases are completed one at a time.
· Works
well for smaller projects where requirements are very well understood.
· Simple
and easy to understand and use.
· Easy
to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
The disadvantages of the V-Model method are as follows −
· High
risk and uncertainty.
· Not
a good model for complex and object-oriented projects.
· Poor
model for long and ongoing projects.
· Not
suitable for the projects where requirements are at a moderate to high risk of
changing.
· Once
an application is in the testing stage, it is difficult to go back and change a
functionality.
· No
working software is produced until late during the life cycle.