Slide 3 1 Object-Oriented and Classical Software Engineering

Slide 3. 1 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/Mc. Graw-Hill, 2002 Stephen R. Schach srs@vuse. vanderbilt. edu © The Mc. Graw-Hill Companies, 2002

CHAPTER 3 SOFTWARE LIFE-CYCLE MODELS © The Mc. Graw-Hill Companies, 2002 Slide 3. 2

Overview l l l l l 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 © The Mc. Graw-Hill Companies, 2002 Slide 3. 3

Software Life-Cycle Models l l Slide 3. 4 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 © The Mc. Graw-Hill Companies, 2002

Build and Fix Model l Problems – No specifications – No design l l Totally unsatisfactory Need a life-cycle model – “Game plan” – Phases – Milestones © The Mc. Graw-Hill Companies, 2002 Slide 3. 5

Waterfall Model l Characterized by – Feedback loops – Documentation-driven l Advantages – Documentation – Maintenance easier l Disadvantages – Specification document » Joe and Jane Johnson » Mark Marberry © The Mc. Graw-Hill Companies, 2002 Slide 3. 6

Rapid Prototyping Model l l Linear model “Rapid” © The Mc. Graw-Hill Companies, 2002 Slide 3. 7

Three Key Points l l l Slide 3. 8 Do not turn the rapid prototype into the product Rapid prototyping may replace the specification phase—never the design phase Comparison: – Waterfall model—try to get it right the first time – Rapid prototyping—frequent change, then discard © The Mc. Graw-Hill Companies, 2002

Waterfall and Rapid Prototyping Models l Waterfall model – Many successes – Client’s needs l Rapid prototyping model – Not proved – Has its own problems l Solution – Rapid prototyping for the requirements phase – Waterfall model for the rest of the life cycle © The Mc. Graw-Hill Companies, 2002 Slide 3. 9

Incremental Model l Divide project into builds © The Mc. Graw-Hill Companies, 2002 Slide 3. 10

Incremental Model (contd) l Slide 3. 11 Waterfall, rapid prototyping models – Operational quality complete product at end l Incremental model – Operational quality portion of product within weeks l l Less traumatic Smaller capital outlay, rapid return on investment Need open architecture—maintenance implications Variations used in object-oriented life cycle © The Mc. Graw-Hill Companies, 2002

Incremental Model (contd) l Problems – Build-and-fix danger – Contradiction in terms © The Mc. Graw-Hill Companies, 2002 Slide 3. 12

Incremental Model (contd) l More risky version—pieces may not fit – CABTAB and its dangers © The Mc. Graw-Hill Companies, 2002 Slide 3. 13

Extreme Programming l l l l 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 a task are drawn up first Pair programming Continuous integration of tasks © The Mc. Graw-Hill Companies, 2002 Slide 3. 14

Unusual Features of XP l l l Computers are put in the center of a large room lined with cubicles A client representative is always present Cannot work overtime for 2 successive weeks No specialization Refactoring © The Mc. Graw-Hill Companies, 2002 Slide 3. 15

Evaluating XP l l l Slide 3. 16 XP has had some successes Good when requirements are vague or changing Too soon to evaluate XP © The Mc. Graw-Hill Companies, 2002

Synchronize-and Stabilize Model l l Microsoft’s life-cycle model Requirements analysis—interview potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in parallel © The Mc. Graw-Hill Companies, 2002 Slide 3. 17

Synchronize-and Stabilize Model (contd) l l l Slide 3. 18 At the end of the day—synchronize (test and debug) At the end of the build—stabilize (freeze build) Components always work together – Get early insights into the operation of the product © The Mc. Graw-Hill Companies, 2002

Spiral Model l Simplified form – Waterfall model plus risk analysis preceding each phase © The Mc. Graw-Hill Companies, 2002 Slide 3. 19

Simplified Spiral Model l View of spiral © The Mc. Graw-Hill Companies, 2002 Slide

A Key Point of the Spiral Model l If all risks cannot be resolved, the project is immediately terminated © The Mc. Graw-Hill Companies, 2002 Slide 3. 21

Full Spiral Model l Precede each phase by – Alternatives – Risk analysis l Follow each phase by – Evaluation – Planning of next phase l l Radial dimension: cumulative cost to date Angular dimension: progress through the spiral © The Mc. Graw-Hill Companies, 2002 Slide 3. 22

Full Spiral Model (contd) © The Mc. Graw-Hill Companies, 2002 Slide 3. 23

Analysis of Spiral Model l Strengths – It is easy to judge how much to test – No distinction is made between development, maintenance l Weaknesses – For large-scale software only – For internal (in-house) software only © The Mc. Graw-Hill Companies, 2002 Slide 3. 24

Object-Oriented Life-Cycle Models l Need for iteration within and between phases – – l Fountain model Recursive/parallel life cycle Round-trip gestalt Unified software development process All incorporate some form of – Iteration – Parallelism – Incremental development l Danger – CABTAB © The Mc. Graw-Hill Companies, 2002 Slide 3. 25

Fountain Model l Overlap (parallelism) Arrows (iteration) Smaller maintenance circle © The Mc. Graw-Hill Companies, 2002 Slide 3. 26

Conclusions l Different life-cycle models – Each with its own strengths – Each with its own weaknesses l Criteria for deciding on a model include: – – l The organization Its management Skills of the employees The nature of the product Best suggestion – “Mix-and-match” life-cycle model © The Mc. Graw-Hill Companies, 2002 Slide 3. 27