The V - model is SDLC model where
execution of processes happens in a sequential manner in V-shape. It is also
known as Verification and Validation model.
V - Model is an extension of the
waterfall model and is based on 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 next phase starts only after completion of the
previous phase.
V- Model design
Under 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. Coding phase joins the two sides of the V-Model.
The below figure illustrates the
different phases in V-Model of SDLC.
Verification Phases
Following are the Verification phases in
V-Model:
·
Business
Requirement Analysis: This is the first phase in the
development cycle where the product requirements are understood from the
customer perspective. This phase involves detailed communication with the
customer to understand his expectations and exact requirement. This is a very
important activity and need 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.
·
System
Design: Once you have the clear and
detailed product requirements, it.s time to design the complete system. System
design would comprise of understanding and detailing the complete hardware and
communication setup for the product under development. System test plan is
developed based on the system design. Doing this at an earlier stage leaves
more time for actual test execution later.
·
Architectural
Design: 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. 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.
·
Module
Design: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. Unit tests are an
essential part of any development process and helps eliminate the maximum faults
and errors at a very early stage. Unit tests can be designed at this stage
based on the internal module designs.
Coding Phase
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.
Validation Phases
Following are the Validation phases in
V-Model:
·
Unit
Testing: 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: 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: 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 system test execution.
·
Acceptance
Testing: 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
V- Model application is almost same as
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 disciplined domain. Following are the suitable scenarios to
use V-Model:
·
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.
V- Model Pros and Cons
The advantage of V-Model is that it.s
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 following table lists out the pros
and cons of V-Model:
|
Pros
|
Cons
|
|
·
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.
|
·
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.
|
No comments:
Post a Comment