0
1
Different Lifecycle Models
Linear vs Iterative
22
SDLC Models
A Lifecycle model describes the activities performed at
each stage of a development project.
Linear or Trad...
33
Traditional Waterfall Model
First attempt at controlling large and complex projects
(70’s)
44
Waterfall Model
Strengths
Easy to understand and use, provides structure to
inexperienced staff
Milestones are well und...
55
V-Model
66
V- Model
Evolved from Waterfall
User requirements are fixed as early as possible
Includes iteration and feedback within...
77
Incremental or Phased
Development
A software system is delivered in stages, thereby
avoiding the Big Bang effect.
often...
88
Iterative or Agile approaches
Incremental, repeated development
Prototyping
RAD, DSDM
XP
8
99
Prototyping
Requirements elicitation is difficult
software is developed because the present situation is
unsatisfactory...
1010
Prototyping
Features
Stages are performed quickly
Each version of the prototype is evaluated with customer
(what to k...
1111
Project Suitability
Requirements
Agile: largely emergent, rapid change
Linear: knowable early, largely stable
Archite...
Upcoming SlideShare
Loading in...5
×

Sdlc models

4,240

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,240
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Sdlc models"

  1. 1. 1 Different Lifecycle Models Linear vs Iterative
  2. 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. 3. 33 Traditional Waterfall Model First attempt at controlling large and complex projects (70’s)
  4. 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. 5. 55 V-Model
  6. 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. 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. 8. 88 Iterative or Agile approaches Incremental, repeated development Prototyping RAD, DSDM XP 8
  9. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×