This document discusses different software development lifecycle models, including linear, iterative, agile, and prototyping models. It provides details on traditional waterfall, V-model, incremental/phased development, and iterative/agile approaches. The key strengths and problems of each model are outlined. The document concludes that there is no single model that fits all projects, and the most suitable model depends on factors like requirements stability, architecture, team size, and development objectives for the specific project.

1. 1
Different Lifecycle Models
Linear vs Iterative

2. 22
SDLC Models
A Lifecycle model describes the activities performed at
each stage of a development project.
Linear or Traditional, models are document-driven:
There is a new pile of paper after each phase is completed
Evolutionary, iterative models recognize that much of
what is called maintenance is inevitable
Latest fashion: Agile methods e.g. eXtreme Programming
There is no one-size-fits-all model; each situation
requires its own approach
If there is nothing that fits a particular project, pick a model
that comes close and modify it for your needs.

3. 33
Traditional Waterfall Model
First attempt at controlling large and complex projects
(70’s)

4. 44
Waterfall Model
Strengths
Easy to understand and use, provides structure to
inexperienced staff
Milestones are well understood and good for management
control (e.g. plan, staff, track)
Sets requirements stability
Works well when quality is more important than cost or
schedule
Problems
All requirements must be known upfront
Very document and planning driven, heavyweight
Deliverables created for each phase are considered frozen –
inhibits flexibility and can give a false impression of progress
Integration is one big bang at the end with little opportunity for
customer to preview the system (until it may be too late)

5. 55
V-Model

6. 66
V- Model
Evolved from Waterfall
User requirements are fixed as early as possible
Includes iteration and feedback within each step
validation (are we building the right system?)
verification (are we building the system right?)
Testing of the product is planned in parallel with a
corresponding phase of development
Good choice for systems
where requirements can be clearly identified and stable e.g.
engineering projects
systems requiring high reliability e.g. hospital patient systems
Problems
Too rigid for projects where requirements are not known or are
subject to change and does not contain risk analysis activities

7. 77
Incremental or Phased
Development
A software system is delivered in stages, thereby
avoiding the Big Bang effect.
often referred to as the Telly-Tubby method......run away!.....
The waterfall model is employed in each phase
Initial product delivery is faster with lower initial cost
Customers get important functionality early and can
respond to each build
Incremental development prevents over complex
systems, which result in less business disruption due to
lack of staff training, and undetected errors (e.g. tax
calculations)
UK government please note!

8. 88
Iterative or Agile approaches
Incremental, repeated development
Prototyping
RAD, DSDM
XP
8

9. 99
Prototyping
Requirements elicitation is difficult
software is developed because the present situation is
unsatisfactory
however, the desirable new situation is as yet unknown
Prototyping is used to obtain the requirements of
some aspects of the system
Prototyping should be a relatively cheap process
use rapid prototyping languages and tools e.g. VB.NET
not all functionality needs to be implemented
production quality is not required

10. 1010
Prototyping
Features
Stages are performed quickly
Each version of the prototype is evaluated with customer
(what to keep, what to change)
Repeat stages until customer is satisfied (good enough)
Final prototype is developed into delivered system
Recommendations
The users and the designers must be well aware of the
issues and the pitfalls
Use prototyping when the requirements are unclear
Prototyping needs to be planned and controlled as well (as
increased cost with each repeated cycle)
Often used within other models during analysis stage

11. 1111
Project Suitability
Requirements
Agile: largely emergent, rapid change
Linear: knowable early, largely stable
Architecture
Agile: designed for current requirements
Linear: designed for current & foreseeable requirements
Size
Agile: smaller teams and products
Linear: larger teams and products
Main Objective
Agile: rapid value
Linear : high assurance