The document discusses various software development life cycle (SDLC) models. It describes the phases of SDLC as requirements gathering and analysis, design, development, testing, implementation, and maintenance. Several common models are explained in detail, including the waterfall model, prototyping model, incremental model, and spiral model. The waterfall model follows a sequential process from requirements to maintenance, while other iterative models allow for more customer feedback and flexibility to change requirements over multiple iterations of development. Choosing the appropriate model depends on factors like project risks, requirements stability, and need for early delivery of basic functionality.

1. SOFTWARE
DEVELOPMENT
LIFE
CYCLE (SDLC)
By
Komal Daheriya

2. SDLC MODEL
A framework that describes
the activities performed at
each stage of a software
development project.

3. SDLC PHASES
 Requirements Gathering and Analysis
 Design
 Development
 Testing
 Implementation
 Maintenance

4. SDLC MODEL
To help understand and implement the
SDLC phases various SDLC models have
been created software development
experts, universities, and standards
organizations.

5. REASONS FOR USING
SDLC MODEL
Provides basis for project planning,
estimating& scheduling.
Provides framework for standard set of
terminologies, activities & deliverables.
Provides mechanism for project tracking
and control.
Increases visibility of project progress to all
stakeholders.

6. ADVANTAGES OF CHOOSING
AN APPROPRIATE SDLC
Increased development speed.
Increased product quality.
Improved tracking & control.
Decreased project risk.
Decreased project management
overhead.

7. COMMON LIFE CYCLE MODELS
Waterfall model.
Prototype model.
Incremental Model.
Spiral model.

8. WATERFALL MODEL
Requirement
Design
Implementation
Test
Maintenance
 Requirement :- Defines
needed information, function,
behavior performance &
interface.
 Design :- Data structures,
Software architecture,
interface representation,
algorithm details.
 Implementation :- Source
code, data base, user
documentation, testing.

9. WATERFALL MODEL
Oldest and most well-known SDLC model.
Follows a sequential step-by-step process
from requirements analysis to maintenance.
Systems that have well-defined and
understood requirements are a good fit for
the Waterfall Model.
The waterfall model is also called is linear-
sequentional model or classic life cycle model.

10. BENEFITS OF WATERFALL
MODEL
Easy to understand, easy to use.
Provides structure to inexperienced staff.
Sets requirements stability.
Good for management control (plan, staff,
track)

11. DRAWBACKS OF WATERFALL
MODEL
 All requirements must be fully specified upfront.
Deliverables created for each phase are considered
frozen – inhibits flexibility .
 Can give a false impression of progress.
 Little opportunity for customer to preview
the system (until it may be too late).
 The customer can see the working model of the
project at the end.

12. WHEN TO CHOOSE IT
Requirements are very well known.
Product definition is stable.
Technology is understood.
New version of an existing product Porting
an existing product to a new platform.

13. PROTOTYPING MODEL
Requirement
gathering
Quick
Design
Building
Prototype
Engineering
Product
Refining
Prototype
Customer
Evaluation
Start
Stop
Prototyping Model

14. PROTOTYPING MODEL
 Prototype is a working model of software with
some limited functionality.
 Prototype does not always hold the exact logic
used in the actual software application.
 Prototyping is used to allow the users evaluate
developer proposals and try them out before
implementation.
 It helps get valuable feedback from the
customer and helps software designers.

15. BENEFITS OF PROTOTYPE
MODEL
 Increased user involvement in the product even
before its implementation.
 Quicker user feedback is available leading to
better solutions.
 Missing functionality can be identified easily.
 Confusing or difficult functions can be identified.
 Reduces time and cost as the defects can be
detected much earlier

16. DRAWBACK OF PROTOTYPE
MODEL
 Risk of insufficient requirement analysis owing to too
much dependency on the prototype.
 Users may get confused in the prototypes and actual
systems.
 The effort invested in building prototypes may be too
much if it is not monitored properly.
 The first version may have some compromises.
 Some time developer may make implementation
compromises to get prototype working quickly.

17. WHEN TO CHOOSE IT
 Software application that are relatively easy to
prototype almost always involve human-
machine interaction (HCI) the prototyping model
is suggested.
 A general objective of software is defined but
not detailed input, processing or output
requirements.
 When the developer is unsure of the efficiency
of an algorithm or the adaptability of an
operating system then prototype serves as a
better choice.

18. INCREMENTAL MODEL
Requirem
ent
Analysis
Design
Software
Product
Increment 1
Coding
Requirem
ent
Analysis
Design
Coding
Software
Product
Increment 2
Requirem
ent
Analysis
Design
Coding
Software
Product
Increment n
Iteration1
Iteration2
……
Iterationn
Incremental Model

19. INCREMENTAL MODEL
 The incremental model has some phases that
are in waterfall model. But it is iterative in
nature.
 The first increment in this model is generally a
core product.
 Each increment builds the product and submits
it to the customer for any suggested
modifications.
 The next increment implements on the
customer’s suggestions and additional
requirement in the previous increment.

20. BENEFITS OF INCREMENTAL
MODEL
 The incremental model can be adopted when
there are less number of people involved in the
project.
 Customers gets important functionality early.
 Lowers initial delivery cost.
 Each release is a product increment, so that the
customer will have a working product at hand all
the time.
 Requirements changes can be easily
accommodated.

21. DRAWBACK OF INCREMENTAL
MODEL
 Requires effective planning of iterations.
 Problems may arise pertaining to system
architecture because not all requirements are
gathered up front for the entire software life
cycle.
 Requires early definition of a complete and fully
functional system to allow the definition of
increments.

22. WHEN TO CHOOSE IT
There is a need to get the basic
functionality delivered fast.
 A new technology is being used.
Resource with needed skill set are not
available.
The domain is new to the team.

23. SPIRAL MODEL

24. SPIRAL MODEL
 The spiral model is similar to the incremental
model , with more emphasis placed on risk
analysis.
 Each loop in a spiral represents a development
phase.
 Each loop has four sections or quadrants.
 The spiral model is dived in to a number of
framework activities. The frame work activities
are denoted by task regions.

25. BENEFITS OF SPIRAL
MODEL
 High amount of risk analysis hence, avoidance
of risk is enhanced.
 Strong approval & documentation control.
 Changing requirements can be accommodated.
 Good for large and mission-critical projects.
 Software is produced early in the software life
cycle.

26. DRAWBACK OF SPIRAL
MODEL
 Can be a costly model to use.
 Management is more complex.
 Not suitable for small or low risk projects and
could be expensive for small projects.
 Process is complex.
 Spiral may go on indefinitely.
 Large number of intermediate stages requires
excessive documentation.

27. WHEN TO CHOOSE IT
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because
of potential changes to economic priorities
 Requirements are complex
 New product line
 Significant changes are expected (research and
exploration).

28. Thank
You