Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vand

1. Object-Oriented and Classical Software EngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 3 SOFTWARE LIFE-CYCLE MODELS

3. Overview • Build-and-fix model • Waterfall model • Rapid prototyping model • Incremental model • Extreme programming • Synchronize-and-stabilize model • Spiral model • Object-oriented life-cycle models • Comparison of life-cycle models

4. Software Life-Cycle Models • Life-cycle model (formerly, process model) • The steps through which the product progresses • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase • Maintenance phase • Retirement

5. Build and Fix Model • Problems • No specifications • No design • Totally unsatisfactory: expensive since it changes code after it is produced! Plus no documentation done! • Need life-cycle model • “Game plan” • Phases • Milestones

6. Waterfall Model • Requirements determined by client & SQA group • Specs drawn up. Checked by SQA. Client signs. • Draw up software project management plan (detailed timetable for developing software). Plan checked by SQA. Client approves time and cost estimates. • Design phase begins. • may find incomplete, contrary, or ambiguous specs. • Then feed back to step 2. • client must approve new specs • Program. • may find design flaws: too slow, etc. • feed back to step 4 or steps 1, 2 • integrate code as modules are finished

7. Waterfall Model • Testing. • client does acceptance testing • deliverables include user manual and other documents • Installation. • Now in maintenance phase • Maintenance may require changes in specs. • May require changes in documents

8. Waterfall Model • Characterized by • Feedback loops • Documentation-driven (no phase is done until docs are done!) • Advantages • Documentation is enforced • Every deliverable checked by SQA • Testing done in every phase • Maintenance easier

9. Waterfall Model (cont) • Disadvantages • Specifications • Joe and Jane Johnson build house. Architect gives 20 page specification document. Joe and Jane sign, but don’t understand. • This is exactly what software specs are like.

10. Waterfall Model (cont) • Disadvantages • Specifications • Mark Marberry buys suit by mail. Does not get photos, but a written description. Mark buys based on the written description. • In same way client rarely sees software until it is finished in waterfall model • Note that using flowcharts doesn’t help visualize what the final software will do.

11. Rapid Prototyping Model • A rapid prototype is a working model functionally equivalent to a subset of the product. • if product is an accounting system, prototype might only be the screens and report printing, but not DB connectivity. • First step in model is to develop rapid prototype. • When client accepts prototype, specs are drawn up.

12. Rapid Prototyping Model • Linear model • less need for feedback • working prototype has been verified by client, so specs more likely correct. • many design problems have already been identified. • “Rapid” • prototype built quickly • less feedback so entire process completed more quickly.

13. Three Key Points • Do not turn prototype into product • Rapid prototyping may replace requirements phase—never the design phase • Comparison: • Waterfall model—try to get it right first time • Rapid prototyping—frequent change, then discard

14. Waterfall and Rapid Prototyping Models • Waterfall model • Many successes • Client needs may not be met • Rapid prototyping model • Not proved • Has own problems • Solution • Rapid prototyping for requirements phase • Waterfall for rest of life cycle

15. Incremental Model • Software is built piece by piece. • Divide project into builds • a build consists of code pieces from various modules interacting to provide a specific functional capability.

16. Incremental Model • Example builds: • project is a submarine • the navigation system is a build • the weapons control system is a build. • project is an OS • the scheduler is a build • the file management system is a build.

17. Incremental Model • At each stage of the model, • a new build is coded • then integrated into the structure • which is tested as a whole. • Process stops when product achieves target functionality (ie, satisfies specs).

18. Incremental Model • Manager decides how to break product into builds. • too few: get build-and-fix approach • too many: more time spent in integration testing than in implementing.

19. Incremental Model (contd) • Waterfall, rapid prototyping models • Operational quality complete product at end • adequate testing and documentation. • had projected delivery date • Incremental model • Operational quality portion of product within weeks (at each build) • this satisfies a subset of requirements and client can begin using immediately. • Less traumatic…don’t change system all at once. • Smaller capital outlay, rapid return on investment

20. Incremental Model (contd) • Each additional build has to be incorporated into the existing structure. • Existing structure must be extensible. • Thus need open architecture— • maintenance easier….can add features easier

21. Incremental Model (contd) • Too easy to degenerate into the build-and-fix model. • Requirements, specs, and architectural design must be completed before implementing builds. • Contradictory requirements: • developer must view product as a whole to begin with a design that will support the entire product. • must also view product as a sequence of builds, each independent of the next • Variations used in object-oriented life cycle

22. Incremental Model (contd) • More risky version—pieces may not fit • As soon as the specs of one build finished, start the specs on the next, etc. What if builds don’t fit together?

23. Extreme Programming • Somewhat controversial new approach • Stories (features client wants) • Estimate duration and cost of each story • Select stories for next build • Each build is divided into tasks • Test cases for task are drawn up first • Pair programming • Continuous integration of tasks

24. Unusual Features of XP • Computers are put in center of large room lined with cubicles • Client representative is always present • Cannot work overtime for 2 successive weeks • No specialization • Refactoring

25. Evaluating XP • XP has had some successes • Good when requirements are vague or changing • Too soon to evaluate XP

26. Synchronize-and Stabilize Model • Microsoft’s life-cycle model • A version of the incremental model • Requirements analysis—interview numerous potential customers • Extract a list of features with priorities set by the customers. • Draw up specifications

27. Synchronize-and Stabilize Model (contd) • Divide project into 3 or 4 builds • Each build is carried out by small teams working in parallel • First build consists of the most critical features • Next build consists of next most critical features • etc

28. Synchronize-and Stabilize Model (contd) • At the end of the day—synchronize • put together the partially completed components • test and debug the resulting product • ensures that components always work together • At the end of the build—stabilize • test the build • freeze build (no more changes to specs allowed • Components always work together • Get early insights into operation of product from the frequent synchronizations • allows detection of bad requirements and early modification

29. Spiral Model • Every software development project has risks • key personnel leave • hardware manufacturer goes backrupt • find too little (or much) has been spend on testing and QA • new breakthroughs render the product useless • competitor releases a cheaper/better product • components of an incremental process don’t fit together • etc.

30. Spiral Model • One approach to reduce risks: prototypes • rapid prototyping models used prototypes to reduce risk during requirements phase. • example: can build a simple form of a product to test a new algorithm. • The spiral model is based on the use of prototypes through all phases of the development cycle.

31. Spiral Model • Simplified form • Waterfall model plus risk analysis • Precede each phase by • Alternatives • Risk analysis • Follow each phase by • Evaluation • Planning of next phase

32. Simplified Spiral Model • If risks cannot be resolved, project is immediately terminated • prototypes used to provide info about certain classes of risks. • example: timing measurements on a prototype indicate if product will be too slow

33. Simplified Spiral Model • Prototypes cannot solve all risks: • example: can a software team that builds small products also build a large one? • example: can a hardware contractor be trusted to deliver on time?

34. Full Spiral Model • Radial dimension: cumulative cost to date • Angular dimension: progress through the spiral • Each cycle of the spiral corresponds to a phase • phase begins in top left quadrant

35. Full Spiral Model • Stage 1 • determine objectives for that phase • determine alternatives for achieving those objectives • constraints imposed on those alternatives • result: strategy for achieving objectives. • strategy analyzed from the viewpoint of risk • attempt to resolve every potential risk • build prototypes if necessary • If risks cannot be resolved, may terminate immediately • or may scale back project

36. Full Spiral Model (contd)

37. Full Spiral Model • Stage 2 • Development step • corresponds to the requirement phase of the waterfall model • validate requirements • life-cycle plan developed • go to next phase

38. Full Spiral Model (contd)

39. Analysis of Spiral Model • Strengths • Emphasis on alternatives and constraints support software reuse • Easy to judge how much to test: analysis of risks shows how much testing to be done • No distinction between development, maintenance so maintenance not overlooked by software professionals

40. Analysis of Spiral Model • Weaknesses • For large-scale software only • if risk analysis costs as much as development not worth it! • For internal (in-house) software only • external developers don’t want the project halted! • plus, can’t break a contract with an external contractor • internal developers can just be reassigned to a new project • Need highly trained software developers who are skilled at pinpointing and analyzing possible risks.

41. Object-Oriented Life-Cycle Models • Need for iteration within and between phases • Fountain model • Recursive/parallel life cycle • Round-trip gestalt • Unified software development process • All incorporate some form of • Iteration within phases • Parallelism between phases (overlap of activities) • Incremental development • Danger • CABTAB (code-a-bit test-a-bit) • danger of disintegrating into random approach of developing piecemeal.

42. Fountain Model • Circles represent phases • Overlapping circles indicate parallelism • Arrows represent iteration within a phase • Smaller maintenance circle represents reduced maintenance in OOP

43. Conclusions • Different life-cycle models • Each with own strengths • Each with own weaknesses • Criteria for deciding on a model include • The organization • Its management • Skills of the employees • The nature of the product • Best suggestion • “Mix-and-match” life-cycle model

44. Comparisons

45. Comparisons