Life cycle models

1,098 views
984 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,098
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Life cycle models

  1. 1. Software Development Life-Cycle ModelsThese slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  2. 2. Four Essential Phases of anySoftware Development ProcessRequirements Elicitation, Analysis, SpecificationSystem DesignProgram ImplementationTest These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  3. 3. Each Phase has an “Output”Phase OutputRequirements analysis Software Requirements Specification (SRS), Use CasesDesign Design Document, Design ClassesImplementation CodeTest Test Report, Change Requests These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  4. 4. ModelsDifferent projects may interpretthese phases differently.Each particular style is called a “Software Life-Cycle Model” These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  5. 5. “Life-Cycle” ModelsSingle-Version ModelsIncremental Models Single-Version with PrototypingIterative Models These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  6. 6. “Life-Cycle” Models (1)Single-Version Models Big-Bang Model Waterfall Model Waterfall Model with “back flow” “V” model: Integrating testing These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  7. 7. Big-Bang ModelDeveloper receives problem statement.Developer works in isolation for someextended time period.Developer delivers result.Developer hopes client is satisfied. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  8. 8. Waterfall Model Requirements Design ImplementationEach phase “pours over”into the next phase. Test These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  9. 9. Waterfall Model with Back Flow (sometimes this is implied by “waterfall”) Requirements Design Implementation TestAdjustments made to immediately previous phasebased on issues with successive phase. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  10. 10. “V” ModelEach phase has corresponding test or validation counterpartRequirements Acceptance Analysis Test System Design Integration Test Program Design Unit Test Implementation
  11. 11. Sawtooth Model (Brugge)Requirements Demo Prototype Demo Prototype Acceptance Test Analysis 1 2 System Design Integration Test Program Design Unit Test Implementation
  12. 12. Incremental vs. IterativeThese sound similar, and sometimes areequated.Subtle difference: Incremental: add to the product at each phase Iterative: re-do the product at each phaseSome of the models could be used eitherway These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  13. 13. Example: Building a HouseIncremental: Start with a modest house,keep adding rooms and upgrades to it.Iterative: On each iteration, the house isre-designed and built anew.Big Difference: One can live in the incrementalhouse the entire time! One has to move to a newiterative house. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  14. 14. Winchester Mystery House San Jose, CA These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  15. 15. Why Not Waterfall?1. Complete Requirements Not Known at Project Start Creeping Reqs as % of Orig 60 50 40 30 20 10 0 10 100 1000 10000 100000 Project Size in Function Points These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed Jones, 1997. Based on Source: Applied Software Measurement, Capers for ERAU /Prescott SE300 6,700 systems. usage with his kind permission. Slides avaialble online at
  16. 16. Function Point?A function point is a unit of complexityused in software cost estimation. Functionpoints are based on number of userinteractions, files to be read/written, etc.SLOC means number of source lines ofcode, also a measure of programcomplexity.More on this topic later. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  17. 17. Why Not Waterfall?2. Requirements are not stable/unchanging. The market changes—constantly. The technology changes. The goals of the stakeholders change. Source: Craig Larman These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  18. 18. Why Not Waterfall?3. The design may need to change during implementation. Requirements are incomplete and changing. Too many variables, unknowns, and novelties. A complete specification must be as detailed as code itself. Software is very “hard”. Discover Magazine, 1999: Software characterized as the most complex “machine” humankind builds. Source: Craig Larman These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  19. 19. Large vs. Small Steps: Project Duration 80000 70000 66690 60000Person Months 50000 40000 30000 20000 10000 4362 1 20 267 0 10 100 1000 10000 100000 Project Size in Function Points Source: Craig Larman These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  20. 20. Large vs. Small Steps: Productivity 4500 4000SLOC/Person Month 3500 3000 2500 2000 1500 1000 500 0 1 10 100 1000 Project Size in KSLOC Source: Measures For Excellence, Putnam, These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott1992. Based on 1,600 systems. SE300 usage with his kind permission. Slides avaialble online at
  21. 21. “Life-Cycle” Models (3)Iterative Models Spiral Model & Variants ROPES Model Controlled Iteration Model: Unified Process Time Box Model Scrum Model Fountain Model These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  22. 22. Boehm Spiral Model (of which some other models are variants)An iterative model developed by BarryBoehm at TRW (1988), now Prof. at USCIterates cycles of these project phases:1 Requirements definition2 Risk analysis3 Prototyping4 Simulate, benchmark5 Design, implement, test6 Plan next cycle (if any) Prof. Barry Boehm These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  23. 23. Boehm Spiral ModelThese slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  24. 24. Risk? What risk?One major area of risk is that thescope and difficulty of the task is notwell understood at the outset.This is the so-called “wicked problem”phenomenon. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  25. 25. “Wicked Problems”Many software development projects havebeen characterized as “wicked problems”,meaning:“problems that are fully understood onlyafter they are solved the first time”(however poorly)Does not apply only to software These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  26. 26. Source of some of this Prentice-Hall, 1990 basically a criticism of the waterfall model “wicked” term first used in H. Rittel and M. Webber, Dilemmas in a general theory of planning, Policy Sciences, 4, pp. 155-169, Elsevier, 1973.These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  27. 27. Some Roots of WickednessRisk: A customer not knowing exactly whathe/she wants; changing expectations asproject progresses.Risk: Staff who are inexperienced in theproblem domain, or with the appropriateimplementation techniques. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  28. 28. The Waffle Principle“Plan to throw the first one away; you willanyhow.”Fred Brooks, “The Mythical Man-Month: Essays on SoftwareEngineering”, Addison Wesley, 1975.Revised in 1995.another indication that building a largesoftware system is wicked These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  29. 29. The Mythical Man-Month Addison-Wesley First published in 1975, re-published in 1995. Possibly the most widely-read software development book. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  30. 30. Wicked ProblemsThe presence of wickedness is whatmakes the iterative / incrementalapproaches most appealing.Methodologies and organizationaltechniques can help control thedegree of wickedness. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  31. 31. US Air Force Risk ClassificationPerformance risk: The project might notmeet requirements or otherwise be fit foruse.Cost risk: The budget might get overrun.Support risk: The software might not beadaptable, maintainable, extendableSchedule risk: The project might bedelivered too late. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  32. 32. USAir ForceSoftware Risk Impact Classification Negligible Marginal Critical Catastrophic These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  33. 33. Ways to Manage RiskRisk cannot be eliminated; it must bemanaged. Do thorough requirements analysis before the design. Use tools to track requirements, responsibilities, implementations, etc. Build small prototypes to test and demonstrate concepts and assess the approach, prior to building full product. Prototype integration as well as components. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  34. 34. Front-LoadingTackle the unknown and harder parts earlierrather than later.Better to find out about infeasible, intractable, orvery hard problems early.The easy parts will be worthless if the hard partsare impossible.Find out about design flaws early rather than uponcompletion of a major phase. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  35. 35. ROPES Model - Similar to Spiral Rapid Object-Oriented Process for Embedded Systems Bruce Douglass Iterates the following sequence of phases repeatedly: Requirements analysis Detailed design System analysis Coding Object analysis Unit testing Architectural design Integration testing Design Validation testing Mechanistic design Iterative prototypeshttp://www.sdmagazine.com/breakrm/features/s999f1.shtml These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  36. 36. ROPES ModelRapid Object-Oriented Process for Embedded Systems Bruce Douglass These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  37. 37. Controlled-Iteration ModelFour phases per major cycle Inception: Negotiate and define product for this iteration Elaboration: Design Construction: Create fully functional product Transition: Deliver product of phase as specifiedThe next phase is started before the end of theprevious phase (say at 80% point). These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  38. 38. Rational Unified Process (a form of controlled iteration) PhasesProcess Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test DeploymentSupporting Workflows Configuration Mgmt Management Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations within phases These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  39. 39. Time-Box Requirement (can be used in iterative or incremental)Requirements analysisInitial designwhile( not done ) { Develop a version within a bounded time Deliver to customer Get feedback Plan next version } These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  40. 40. Scrum, A cure for the Wicked?Scrum first mentioned in“The New New Product Development Game” (Harvard Business Review 86116:137-146, 1986) These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  41. 41. Scrum Model (incremental model, includes some aspects of team structure, as well as process) StartA small group is responsible for pickingup the ball and moving it toward thegoal. GoalSee http://www.cetus-links.org/oo_ooa_ood_methods.html These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  42. 42. Argument for the Scrum Model over other iterative modelsA software development project might notbe compartmentalizable into nice cleanphases as the Spiral models suggest.Scrum may be “just the thing” for wickedproblems, because the team can quicklyreact to new information. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  43. 43. Some Principles of Scrum ModelAlways have a product that you can theoreticallyship: “done” can be declared at any time.Build early, build often.Continuously test the product as you build it.Assume requirements may change; Have ablilityto adapt to marketplace changes duringdevelopment.Small teams work in parallel to maximizecommunication and minimize overhead. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  44. 44. Concepts Used in Scrum (from http://www.controlchaos.com/ap.htm)Backlog - an identification of all requirements that should be fulfilled in thecompleted product. Backlog items are prioritized.Objects/Components - self-contained reusable modulesPackets - a group of objects within which a backlog item will beimplemented. Coupling between the objects within a packet is high. Couplingbetween packets is low.Team - a group of 6 or fewer members that works on a packet.Problem - what must be solved by a team member to implement a backlogitem within an object(s) (includes removing errors)Issues - Concerns that must be resolved prior to a backlog item beingassigned to a packet or a problem being solved by a change to a packetSolution - the resolution of an issue or problemChanges - the activities that are performed to resolve a problemRisks - the risk associated with a problem, issue, or backlog item These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  45. 45. Use of Iteration in Scrum http://www.controlchaos.com/scrumwp.htmEach iteration consists of all of the standard Waterfallphases,but each iteration only addresses one set of functionality.Overall project deliverable has been partitioned intoprioritized subsystems, each with clean interfaces.Test the feasibility of subsystems and technology in theinitial iterations.Further iterations can add resources to the project whileramping up the speed of delivery.Underlying development processes are still defined andlinear. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  46. 46. Fountain Model (Ian Graham, et al., The OPEN Process Specification OPEN = Object-oriented Process Environment and Notation )These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  47. 47. Additional Models/Acronyms RAD (Rapid Application Development): time-boxed, iterative prototyping JAD (Joint Application Development): Focus on developing models shared between users and developers. See http://faculty.babson.edu/osborn/cims/rad.htm for additional points. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  48. 48. Extreme Programming (XP) (cf. http://www.extremeprogramming.org/rules.html)User stories (something like use cases) arewritten by the customer.Complex stories are broken down into simpler ones(like a WBS).Stories are used to estimate the required amountof work.Stories are used to create acceptance tests.A release plan is devised that determines whichstories will be available in which release.Don’t hesitate to change what doesn’t work. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  49. 49. Extreme Programming (XP)Each release is preceded by a release planningmeeting.Each day begins with a stand-up meeting to shareproblems and concerns.CRC cards are used for design. [XP and CRC werecreated by the same person, Kent Beck.]Spike solutions are done to assess risks.The customer is always available. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  50. 50. Extreme Programming (XP)All code must pass unit tests, which are codedbefore the code being tested (test-drivendesign).Refactoring is done constantly.Integration is done by one pair.Integration is done frequently.Optimization is done last.Acceptance tests are run often. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  51. 51. These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  52. 52. System Metaphor?“Choose a system metaphor to keep the team on the same page bynaming classes and methods consistently. What you name yourobjects is very important for understanding the overall design ofthe system and code reuse as well. Being able to guess at whatsomething might be named if it already existed and being right is areal time saver. Choose a system of names for your objects thateveryone can relate to without specific, hard to earn knowledgeabout the system.For example the Chrysler payroll system was built as a productionline. At another auto manufacturer car sales were structured as abill of materials. There is also a metaphor known as the naivemetaphor which is based on your domain itself. But dont choose thenaive metaphor unless it is simple enough.” These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at
  53. 53. Keller’s Roll-Your-Own Software Life-Cycle Construction KitRequirements System Design Prototype Validate Elicitation Program Design Simulate VerifyRequirements Analysis Detailed Design Implement Integration TestRequirements Code Unit Test Design Review WalkthroughSpecification Acceptance TestRisk Analysis Document Integrate Port Train Fix ErrorsCost Analysis Evaluate Configure Maintain Party These slides prepared by Prof. Bob Keller of Harvery Mudd College and printed for ERAU /Prescott SE300 usage with his kind permission. Slides avaialble online at

×