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