The V-Model is a software development model that depicts the relationships between system requirements, design, and testing. It emphasizes testing at each development stage with testing occurring in reverse order that modules are developed (top-down). The V-Model includes requirements analysis and system design at the beginning, followed by module design, integration, validation, and operation. Each stage establishes entry and exit criteria and is tested in turn before proceeding to the next stage. Benefits include reduced faults, improved quality, and validation at each stage, while disadvantages include high costs and rigidity.

1. AHEAD TEAM
1
AHEADTEAM©copyright2013
 ShravanKumar
 Sowmya
 Alekhya
 Saisuhas Reddy(TL)
 Anusha

2. V – MODEL (SOFTWARE
DEVELOPMENT)
2
AHEADTEAM©copyright2013

3. HISTORY OF V-MODEL
 Defined by the late Paul
Rook in 1980’s.
 To improve the
efficiency and
effectiveness of software
development.
 Accepted in Europe and
UK as an alternative to
Waterfall model.
3
AHEADTEAM©copyright2013

4. • Evolved from waterfall Model.
• Completion of each phase before the next phase begins.
•Instead of moving in a linear way, process steps are bent upwards.
• Emphasizing on testing is more when compared with the waterfall
model.
• Structured approach to testing.
• High quality development of products can be guaranteed.
THE V SHAPED MODEL
4
AHEADTEAM©copyright2013

5. STEPS IN V-SHAPED MODEL
Quality is guaranteed at each project stage.
5
AHEADTEAM©copyright2013

6. ENTRY AND EXIT CRITERIA
Entry Criteria
Set of generic and specific conditions for permitting a process to go forward with a
defined task.
Exit Criteria
Refers to the output conditions required by a specific process to determine its
thoroughness and correct completion. The Exit Criteria for one stage can constitute
part of the Entry Criteria for the following stage.
6
AHEADTEAM©copyright2013

7. Unit testing
 The most ‘micro’ scale of Testing
The units are tested in isolation.
 Ensures the component is
working according to the detailed
design/build specifications of the
module.
 Not to be confused with
debugging.
 Also known as component,
module, or program testing.
7
AHEADTEAM©copyright2013

8. Integration Testing
 Testing of more than one (tested)
unit together to determine if they
function correctly.
It is done using the integration test
design prepared during the architecture
design phase.
 Helps assembling incrementally a
whole system, ensuring the correct
‘flow’ of data from the first through
the final component.
 Done by developers/designers and
testers in collaboration
 Also called Interface Testing or
Assembly Testing.
8
AHEADTEAM©copyright2013

9. System testing
Testing the system as a whole - Black-box type
testing that is based on overall requirements
specifications; covers all combined parts of a
system.
 Ensures that system meets all functional and
business requirements.
Focus
 Verifying that specifications are met
 Validating that the system can be used for
the intended purpose
 The system test design is derived from the
system design documents and is used in this phase.
 It can involve a number of specialized types of
tests to check performance, stress, documentation
etc. Sometimes testing is automated using testing
tools.
 Done by Independent testing group
9
AHEADTEAM©copyright2013

10. Acceptance testing
 To determine whether a system satisfies its
acceptance criteria and business requirements or
not.
 Similar to System testing in that the whole
system is checked, but the important difference is
the change in focus.
 Done by real business users.
 It enables the customer to determine whether to
accept the system or not.
 Also called as Beta Testing, Application Testing
or End User Testing.
 Approach
 Should be performed in real operating
environment .
 Customer should be able to perform any test
based on their business processes.
 Final Customer sign-off.
10
AHEADTEAM©copyright2013

11. • Fault multiplication can be
reduced.
• Improved quality and
reliability.
• Reduction in the amount of
Re-work.
• Improved Risk Management
• Validation and Verification
at each level of stage
containment
• Developing critical
knowledge and confidence in
the initial stages.
BENEFITS
11
AHEADTEAM©copyright2013

12. DISADVANTAGES
 Lot of money and resources are
required.
 Very rigid and less flexible.
 Suitable for long term / large projects.
 Ignorance of any of the test phases may
lead to poor quality.
 No software prototype available.
 Any modifications, then the test
documents along with requirement
documents has to be updated.
12
AHEADTEAM©copyright2013

13. 13
AHEADTEAM©copyright2013

14. 14
AHEADTEAM©copyright2013