10/23/2019

Software Development Life Cycle (SDLC) Models

Niladri Sekhar Saha (Principal Engineer)

Common SDLC Models

• Waterfall Model
• Iterative Model
• Spiral Model
• V Model
• Agile Model

10/23/2019 www.cdac.in 2

1
 10/23/2019

Waterfall Model

• The Waterfall model is the earliest SDLC approach that was used for
software development.
• Also referred to as a linear‐sequential life cycle model.
• Each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
• Illustrates the software development process in a linear sequential
flow. This means that any phase in the development process begins
only if the previous phase is complete.

10/23/2019 www.cdac.in 3

Waterfall Model
Requirement Analysis

Design

Development

Testing

Deployment

Maintenance

10/23/2019 www.cdac.in 4

2
 10/23/2019

Waterfall Model‐ Applications
Some situations where the use of Waterfall model is most 
appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to
support the product.
• The project is short.

10/23/2019 www.cdac.in 5

Waterfall Model‐ Advantages
• 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.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are
very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

10/23/2019 www.cdac.in 6

3
 10/23/2019

Waterfall Model‐ Disadvantages
• No working software is produced until late during the life cycle.
• High amounts of 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. So, risk and uncertainty is high with this process
model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big‐bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.

10/23/2019 www.cdac.in 7

Iterative Model
• In the Iterative model, iterative process starts with a simple implementation of a
small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed.
• An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just
part of the software, which is then reviewed to identify further requirements.
This process is then repeated, producing a new version of the software at the
end of each iteration of the model.

10/23/2019 www.cdac.in 8

4
 10/23/2019

Iterative Model
Build 1
Design and  Testing Implementation
Development

Build 2

Design and  Testing Implementation

Requirements
Development

Build 3

Design and  Testing Implementation

Development

10/23/2019 www.cdac.in 9

Iterative Model- Applications

Iterative and incremental development has some specific applications in the
software industry. This model is most often used in the following scenarios
• Requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some functionalities or
requested enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team
while working on the project.
• Resources with needed skill sets are not available and are planned to be used
on contract basis for specific iterations.
• There are some high‐risk features and goals which may change in the future.

10/23/2019 www.cdac.in 10

5
 10/23/2019

Iterative Model- Advantages

• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily
managed milestone.

10/23/2019 www.cdac.in 11

Iterative Model- Advantages

• Easier to manage risk ‐ High risk part is done first.
• With every increment, operational product is delivered.
• Issues, challenges and risks identified from each increment can be utilized/applied to
the next increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission‐critical projects.
• During the life cycle, software is produced early which facilitates customer evaluation
and feedback.

10/23/2019 www.cdac.in 12

6
 10/23/2019

Iterative Model- Disadvantages

• More resources may be required.
• Although cost of change is lesser, but it is not very suitable for changing
requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle.
• Defining increments may require definition of the complete system.
• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which is a risk.
• Highly skilled resources are required for risk analysis.
• Projects progress is highly dependent upon the risk analysis phase.

10/23/2019 www.cdac.in 13

Spiral Model
Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling.

Spiral model combines architecture and prototyping by stages. It is a combination

of the Iterative and Waterfall SDLC models with the significant accent on the risk
analysis. The main issue of the spiral model – is defining the right moment to make
a step into the next stage. The preliminary set time frames are recommended as the
solution to this issue. The shift to the next stage is done according to the plan, even
if the work on the previous stage isn’t done yet. The plan is introduced basing on
the statistic data, received during the previous projects even from the personal
developer’s experience.

10/23/2019 www.cdac.in 14

7
 10/23/2019

Spiral Model
Cumulative Cost

1. Determine  2. Identify and 
Objectives resolve risks

Risk Analysis

Prototypes

Review
Design

Code
Integration
4. Evaluation and Plan  3. Development and 
the next iteration Test
Test
Implementation

Release

10/23/2019 www.cdac.in 15

Spiral Model Phases

1. Determine Objectives/Requirement Gathering :‐ This phase, studies and
collects the requirements for continuous communication between the customer
and system analyst. It involves estimating the cost and resources for the
iteration.
2. Identify and Resolve Risks/Risk Analysis :‐ This phase, identifies the risk and
provides the alternate solutions if the risk is found.
3. Development and Test:‐ In this phase, actual development i.e coding of the
software is completed. Testing is completed at the end of the phase.
4. Evaluation and Plan for the next iteration :‐ Get the software evaluated by the
customers. They provide the feedback before the project continues to the next
spiral.

10/23/2019 www.cdac.in 16

8
 10/23/2019

Spiral Model- Applications

• When project is large.
• When releases are required to be frequent.
• When creation of a prototype is applicable.
• When risk and costs evaluation is important.
• For medium to high‐risk projects.
• When requirements are unclear and complex.
• When changes may require at any time.
• When long term project commitment is not feasible due to changes in
economic priorities.

10/23/2019 www.cdac.in 17

Spiral Model- Advantages

• Additional functionality or changes can be done at a later stage.

• Cost estimation becomes easy as the prototype building is done in small
fragments.
• Continuous or repeated development helps in risk management.
• Development is fast and features are added in a systematic way.
• There is always a space for customer feedback.

10/23/2019 www.cdac.in 18

9
 10/23/2019

Spiral Model- Disadvantages

• It works best for large projects only also demands risk assessment expertise.
• For its smooth operation spiral model protocol needs to be followed strictly.
• It is not advisable for smaller project, it might cost them a lot.
• Spiral may go on indefinitely.
• End of the project may not be known early.
• Large number of intermediate stages requires excessive documentation.

10/23/2019 www.cdac.in 19

V Model
• The V‐model is an SDLC model where execution of processes happens in a
sequential manner in a V‐shape. It is also known as Verification and
Validation model.
• The V‐Model is an extension of the waterfall model and is based on the
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 the
next phase starts only after completion of the previous phase.

10/23/2019 www.cdac.in 20

10
 10/23/2019

V Model
V Acceptance
Test Design V
E
A
R Requirement Analysis Acceptance Testing
System L
I  Test Design
I
F
System Design Integration  System Testing D
I  Test Design
A
C
Architecture T
A Design Unit Test 
Integration Testing
I
T Design
O
I Module
Unit Testing
Design N
O
N Coding

Under the 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. The Coding Phase joins the two sides of the V‐Model.

10/23/2019 www.cdac.in 21

V Model
• The V‐model is an SDLC model where execution of processes happens in a sequential
manner in a V‐shape. It is also known as Verification and Validation model.

• The V‐Model is an extension of the waterfall model and is based on the 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 the next phase starts only after completion of
the previous phase.

10/23/2019 www.cdac.in 22

11
 10/23/2019

V Model- Verification Phases

1. Business Requirement Analysis:‐ This is the first phase in the development cycle where the product
requirements are understood from the customer’s perspective. This phase involves detailed communication
with the customer to understand his expectations and exact requirement. This is a very important activity and
needs 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.

2. System Design:‐ Once you have the clear and detailed product requirements, it is time to design the complete
system. The system design will have the understanding and detailing the complete hardware and
communication setup for the product under development. The system test plan is developed based on the
system design. Doing this at an earlier stage leaves more time for the actual test execution later.

10/23/2019 www.cdac.in 23

V Model- Verification Phases

3. 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. The
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.

4. 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. The unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. These unit tests can be designed at this stage based on the
internal module designs.
10/23/2019 www.cdac.in 24

12
 10/23/2019

V Model- Validation Phases

1. 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.
2. 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.
3. 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 this system test execution.
4. 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.
10/23/2019 www.cdac.in 25

V Model- Application
V‐ Model application is almost the same as the 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 a disciplined domain.
The following pointers are some of the most suitable scenarios to use the V‐Model
application.
• 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.

10/23/2019 www.cdac.in 26

13
 10/23/2019

V Model- Advantages
The advantages of the V‐Model method are as follows −

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

10/23/2019 www.cdac.in 27

V Model- Disadvantages
The disadvantages of the V‐Model method are as follows −

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

10/23/2019 www.cdac.in 28

14
 10/23/2019

Agile Model
• Agile model believes that every project needs to be handled differently and
the existing methods need to be tailored to best suit the project
requirements. In Agile, the tasks are divided to time boxes (small time
frames) to deliver specific features for a release.
• Iterative approach is taken and working software build is delivered after each
iteration. Each build is incremental in terms of features; the final build holds
all the features required by the customer.
• Chain of rapid development and deployment.

10/23/2019 www.cdac.in 29

Agile Model
Develop Test
Develop Test Develop Test

Design Deploy
Design Deploy
1st Iteration 2nd Iteration
Design Deploy

3rd Iteration

Plan Review
Plan Review Plan Review
Launch
Launch
Launch

10/23/2019 www.cdac.in 30

15
 10/23/2019

Values of Agile
RESPONDING TO 
WORKING  CUSTOMER 
THE CHANGE 
PEOPLE OVER  SOFTWARE OVER  COLLABORATION 
RATHER THAN 
PROCESS COMPREHENSIVE  OVER RIGID 
FOLLOWING A 
DOCUMENTATION CONTRACTS
PLAN 

• People over process − In Agile development, self‐organization and motivation are important, as are interactions
like co‐location and pair programming.
• Working software over comprehensive documentation − Demo working software is considered the best means
of communication with the customers to understand their requirements, instead of just depending on
documentation.
• Customer collaboration over rigid contracts − As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer interaction is very important to get proper
product requirements.
• Responding to change rather than following a plan − Agile Development is focused on quick responses to change
and continuous development.

10/23/2019 www.cdac.in 31

Principles of Agile
• Satisfy the customer.
• Welcome changing requirements.
• Deliver working software frequently.
• Frequent interaction with stakeholders.
• Motivated individuals.
• Face to face communication.
• Measure by working software.
• Maintain constant pace.
• Sustain technical excellence and good design.
• Keep it simple.
• Empower self‐organizing team.
• Reflect and adjust continuously.

10/23/2019 www.cdac.in 32

16
 10/23/2019

Agile vs Traditional SDLC Models

• Agile is based on the adaptive software development methods, whereas the
traditional SDLC models like the waterfall model is based on a predictive approach.
Predictive teams in the traditional SDLC models usually work with detailed
planning and have a complete forecast of the exact tasks and features to be
delivered in the next few months or during the product life cycle.
• Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle. Any changes to be incorporated go
through a strict change control management and prioritization.

10/23/2019 www.cdac.in 33

Agile vs Traditional SDLC Models

• Agile uses an adaptive approach where there is no detailed planning and there is
clarity on future tasks only in respect of what features need to be developed.
There is feature driven development and the team adapts to the changing product
requirements dynamically. The product is tested very frequently, through the
release iterations, minimizing the risk of any major failures in future.
• Customer Interaction is the backbone of this Agile methodology, and open
communication with minimum documentation are the typical features of Agile
development environment. The agile teams work in close collaboration with each
other and are most often located in the same geographical location.

10/23/2019 www.cdac.in 34

17
 10/23/2019

Agile Model- Advantages

• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned
context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
10/23/2019 www.cdac.in 35

Agile Model- Disadvantages

• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which
it will not work.
• Strict delivery management dictates the scope, functionality to be delivered,
and adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can
be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum
documentation generated.
• Transfer of technology to new team members may be quite challenging due to
lack of documentation.

10/23/2019 www.cdac.in 36

18
 10/23/2019

Thank You

19