Sdlc models
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
3,931
On Slideshare
798
From Embeds
3,133
Number of Embeds
2

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 3,133

http://moodle.wortech.ac.uk 3,114
http://beta.moodle.wortech.ac.uk 19

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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