This presentation inculcates a thorough overview of V and dual V models in Software Engineering.

1. V and dual V SDLC

2. Participants
Muhammad Asim
FA13-BCS-061
Zaheer Alam
FA13-BCS-083

3. V-MODEL

4. History
• Devised 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.
V

5. V Model
• 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.
V

6. Diagrammatic view
Detailed
Design
Unit
Testing
High-level
Design
Integration
Testing
Software
Requirements
Specification
System
Testing
Acceptance
Testing
Coding
User’s
Software
Requirements
Software
Development
Verification and Testing
Sys architecture and design
Actual SW components
V

7. Verification Phases
Following are the Verification phases in V-Model
Business Requirement Analysis:
• This phase involves detailed communication with the customer to
understand his expectations and exact requirement.
• The acceptance test design planning is done at this stage as business
requirements can be used as an input for acceptance testing.
System Design:
• 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.
V

8. Verification Phases
Architectural Design:
• Based on the technical and financial feasibility the final decision is taken.
• System design is broken down further into modules taking up different
functionality.
• 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.
V

9. Verification Phases
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 can be designed at this stage
V

10. 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.
V

11. Validation Phases
Following are the Validation phases in V-Model:
Unit Testing:
• Unit tests designed in the module design phase
• Unit testing is the testing at code level and helps to eliminate bugs at an
early stage
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.
V

12. Validation Phases
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.
V

13. Validation Phases
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

14. Pros and Cons cont.
• 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.
V

15. Pros and Cons cont.
• 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.
V

16. When to use the V?
• The V-shaped model should be used for small to medium sized projects
where requirements are clearly defined and fixed.
• The V-Shaped model should be chosen when technical resources are
available with needed technical expertise.
• High confidence of customer is required for choosing the V-Shaped model
approach.
• Since, no prototypes are produced, there is a very high risk involved in
meeting customer expectations.
V

17. V vs. Waterfall
Feature Waterfall Model V Model
Requirement Specifications Beginning Beginning
Cost Low Expensive
Guarantee of success Low High
Simplicity Simple Intermediate
Flexibility Rigid Little flexible
Reusability Limited To some extent
User involvement Only at beginning Only at beginning
Change incorporated Difficult Difficult
V

18. V vs. Waterfall V
Vs.

19. V-MODELV

20. V-MODEL
• Paul Herzlich introduced the W-Model. In W Model, those testing activities
are covered which are skipped in V Model.
• Deals with the problems that V model could not tackle.
• V Model Represents one-to-one relationship between the documents on the
left hand side and the test activities on the right; not always correct.
• Technical Design and architecture is also considered with the functional
requirements.
• V Model does not cover couple of testing activities; major exception.
• Ensures that testing starts from the very first day of inception of project.
V VV

21. V-MODELV
Requirements
Specification
Architecture
Detailed design
Code Code walkthrough
Test
Requirements
Test
Specification
Test
Architecture
Test Design
Install system
Build system
Build software
Build software
Acceptance testing
System Testing
Integration Testing
Unit testing
VV

22. V-MODELV
Requirements
Specification
Architecture
Detailed design
Code Code walkthrough
Test
Requirements
Test
Specification
Test
Architecture
Test Design
Install system
Build system
Build software
Build software
Acceptance testing
System Testing
Integration Testing
Unit testing
1
2
3
4
5
6
6
6
Regression
test cycles
Static Testing Dynamic Testing
VV

23. V-MODEL
Each phase is verified/validated. Dotted arrow shows that every phase in
black is validated/tested through every phase in sky yellow.
• Point 1 refers to - Build Test Plan & Test Strategy.
• Point 2 refers to - Scenario Identification.
• Point 3 refers to – Test case preparation from Specification document and
design documents
V VV

24. V-MODEL
• Point 4 refers to – Test case preparation from Specification document and
design documents
• Point 5 refers to – review of test cases and update as per the review
comments.
• Point 6 refers to – Various testing methodologies (i.e. Unit/integration
testing, path testing, equivalence partition, boundary value, specification
based testing, security testing, usability testing, performance testing).
• After this, there are regression test cycles and then User acceptance testing.
V VV

25. Regression Test
Regression means retesting the unchanged parts of the application.
• Test cases are re-executed in order to check whether previous functionality
of application is working fine and new changes have not introduced any
new bugs.
• This is the method of verification. Verifying that the bugs are fixed and the
newly added features have not created in problem in previous working
version of software.
VV

26. Static Testing
Static Testing, a software testing technique in which the software is tested
without executing the code.
It has two parts.
• Review - Typically used to find and eliminate errors or ambiguities in
documents such as requirements, design, test cases, etc.
• Static analysis - The code written by developers are analyzed (usually by
tools) for structural defects that may lead to defects.
VV

27. Dynamic Testing
• Involves interaction with the program while it runs.
• Dynamic testing involves testing the software for the input values and
output values are analyzed. Dynamic testing is the Validation part of
Verification and Validation.
VV