1. SYSTEM MODELS
OF SDLC :-
‘V’ MODEL
BY:-
MINAL KASHYAP

2. SDLC :- SOFTWARE DEVELOPMENT LIFE
CYCLE
• Definition :-A software development process, also known as a
software development life-cycle, is a structure imposed on the
development of a software product. Similar terms include
software life cycle and software process. It is often considered
a subset of systems development life cycle.

3. CONTINUE…
• It is a framework defining tasks performed at each step in the
software development process. SDLC is a structure followed by
a development team within the software organization. It
consists of a detailed plan describing how to develop, maintain
and replace specific software. The life cycle defines a
methodology for improving the quality of software and the
overall development process.
This term is also known as the software development process.

4. PHASES OF SDLC :-

5. Each Phase has an “Output”
Phase
 Requirements
analysis
 Design
 Implementation
 Test
Output
 Software Requirements
Specification (SRS),
Use Cases
 Design Document,
Design Classes
 Code
 Test Report,
Change Requests

6. Models
 Different projects may interpret
these phases differently.
 Each particular style is called a
“Software Life-Cycle Model”

7. “Life-Cycle” Models
 Single-Version Models
 Incremental Models
 Single-Version with Prototyping
 Iterative Models

8. “Life-Cycle” Models (1)
 Single-Version Models
 Big-Bang Model
 Waterfall Model
 Waterfall Model with “back flow”
 “V” model: Integrating testing

9. ‘V’ MODEL
• V model means verification and validation model.
• The V-model represents a software development process (also
applicable to hardware development) which may be considered
an extension of the waterfall model.
• Each phase has to be completed before the next phase begins.
• Instead of moving down in a linear way, the process steps are
bent upwards after the coding phase, to form the typical V
shape.

10. • Testing is emphasized in this model more than in the waterfall
model.
• It is a structured approach to testing.
• Brings high quality into the development of our products.
• The V-Model demonstrates the relationships between each phase of
the development life cycle and its associated phase of testing. The
horizontal and vertical axes represents time or project completeness
(left-to-right) and level of abstraction (coarsest-grain abstraction
uppermost), respectively.

11. “V” Model
Each phase has corresponding test or validation counterpart
Requirements
Analysis
System Design
Program
Design
Implementatio
n
Unit Test
Integration
Test
Acceptance
Test

12. Steps in the V-Shaped
Model
Quality is guaranteed at each project stage.

13. VERIFICATION PHASES
1.Requirements analysis
• In this phase, the first step in the verification process,
the requirements of the system are collected by analysing the needs
of the user.
• This phase is concerned with establishing what the ideal system has
to perform. However it does not determine how the software will be
designed or built.
• Usually, the users are interviewed and a document called the user
requirements document is generated.

14. • The user requirements document will typically describe the system’s
functional, interface, performance, data, security, etc. requirements
as expected by the user.
• It is used by business analysts to communicate their understanding
of the system to the users.
• The users carefully review this document as this document would
serve as the guideline for the system designers in the system design
phase. The user acceptance tests are designed in this phase.
• There are different methods for gathering requirements of both soft
and hard methodologies including; interviews, questionnaires,
document analysis, observation, throw-away prototypes, use cases
and static and dynamic views with users.

15. • Systems design is the phase where system engineers analyse
and understand the business of the proposed system by
studying the user requirements document.
• They figure out possibilities and techniques by which the user
requirements can be implemented. If any of the requirements
are not feasible, the user is informed of the issue. A resolution
is found and the user requirement document is edited
accordingly.
2. System design

16. • The software specification document which serves as a
blueprint for the development phase is generated. This
document contains the general system organization, menu
structures, data structures etc.
• It may also hold example business scenarios, sample windows,
reports for the better understanding.
• Other technical documentation like entity diagrams, data
dictionary will also be produced in this phase. The documents
for system testing are prepared in this phase.

17. 3.Architecture design
• The phase of the design of computer architecture and software
architecture can also be referred to as high-level design. The
baseline in selecting the architecture is that it should realize all
which typically consists of the list of modules, brief
functionality of each module,
their interface relationships, dependencies, database tables,
architecture diagrams, technology details etc. The integration
testing design is carried out in the particular phase.

18. 4.Module design
• The module design phase can also be referred to as low-level design. The
designed system is broken up into smaller units or modules and each of
them is explained so that the programmer can start coding directly. The low
level design document or program specifications will contain a detailed
functional logic of the module, in pseudo code:
• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.
• The unit test design is developed in this stage.

19. Unit testing
 The most ‘micro’ scale of Testing
 A unit = smallest testable software component
 Objects and methods
 Procedures / functions
 Performed by Programmer
 A tester can help.
 Requires detailed knowledge of the internal
program design and code.
 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.

20. Integration Testing
 Testing of more than one (tested) unit together to
determine if they function correctly.
 Focus on interfaces
 Communication between units
 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.

21. 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

22. 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

23. • Faults are prevented and it stops fault multiplication.
• Avoids the downward flow of defect.
• Lower defect Resolution cost due to earlier detection.
• Improved quality and reliability.
• Reduction in the amount of Re-work.
• Improved Risk Management
• Validation and Verification at each level of stage
containment
• Allows testers to be active in the project early in the
project’s lifecycle. They develop critical knowledge
about the system.
Benefits of V-Model