1. Ch2: Software Life Cycles Housekeeping  Feedback from Wednesday  Structured vs. Object Oriented Paradigm Structured: Data is an argument, functions separate, maintenance can be difficult Obj. Oriented: Data is hidden, functions imbedded, maintenance much more localized Example: Let’s say you’re redesigning MIDS…  Does everyone have a team?  The next 10 days  Mon 8/26: Sch Ch.3  Wed 8/28: Dei Ch.11  Thurs 8/29: Mile 0 due Lab 1 (Java GUI) w/ group 1

2. Ch2: Software Life Cycles 2 Software Life-Cycle Models (Schach Chap2)  We Examine Several Life-cycle Models:  Build and Fix  Waterfall  Rapid Prototyping  Spiral  Incremental  Evolution-Tree Life-cycle  Focus on how (if!) the Phases of Software Development are Incorporated within each model

3. Ch2: Software Life Cycles 3 *Build and Fix Model  No specifications  No formal design process Evaluation: Useful for small or large software? Neither? Both? Useful for small or large software? Neither? Both? What would make this more useful? What would make this more useful?

4. Ch2: Software Life Cycles 4 *Waterfall Model (circa 1970)   A first cut at improving "build and fix"  Each phase of the lifecycle represented as a discrete entity  Feedback loops between phases  Intentionally Documentation-driven Evaluation: Impact on maintenance? Impact on maintenance? Result of extra documentation? Result of extra documentation? Likely reaction from client/customer upon product delivery? Likely reaction from client/customer upon product delivery? Small Group Exercise: Describe a real-life (non-software) example where customer reaction would be bad to a Waterfall-style delivery method. Describe a real-life (non-software) example where customer reaction would be bad to a Waterfall-style delivery method.

5. Ch2: Software Life Cycles 5 Aside: Requirements Phase (Schach Chap 10) “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!” “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”  Misconception: Must determine what client wants  Real Goal: Must determine client’s needsTechniques:  Rapid prototyping  Key functionality  What client sees  Experimentation and change  Interviewing (primary technique)  Forms analysis/Questionnaires  Scenarios

6. Ch2: Software Life Cycles 6 *Rapid Prototyping as Specification Technique? Advantages of using a Rapid Prototype:  speed  no ambiguities, omissions, contradictions  Should we use a Rapid Prototype instead of a specification? What are some disadvantages of this approach? Evaluation: Consider what specification does for us that Rapid Prototyping would not… Consider what specification does for us that Rapid Prototyping would not… Is there an effect on Design? Implementation? Maintenance? Is there an effect on Design? Implementation? Maintenance?

7. Ch2: Software Life Cycles 7 *Rapid Prototyping Study by Boehm (1984)  7 versions of same product  4 specified using only a specification document,  3 prototyped only (ie., used prototype as specification)  Prototyping vs. specification => yielded equivalent performance (run-time efficiencies). What about code size and functionality? Evaluation (Small Group Exercise): More or less code/effort? More or less code/effort? Easier or harder to learn/use? Easier or harder to learn/use? More or less functional/robust? More or less functional/robust?

8. Ch2: Software Life Cycles 8 ~Rapid Prototyping vs. Waterfall Model Rapid PrototypeWaterfall

9. Ch2: Software Life Cycles 9 Rapid Prototyping Model  Recall Waterfall model view of requirements—try to get it right the first time. Client does not see a version of the product until very late in the life cycle  Rapid prototyping view of requirements—expect frequent changes, plan to discard prototype after determining what client needs  Do not evolve prototype into final product  Rapid prototyping model replaces waterfall's requirements phase  Waterfall then used for the rest of life cycle

10. Ch2: Software Life Cycles 10 Spiral Model (intended to help manage risks)  Idea is evolutionary development, using waterfall model for each step;  Initially, don't define entire system, only the highest priority features:  Define/implement those features, then get feedback from user  Feedback distinguishes "evolutionary“ from "incremental".  With knowledge gained from feedback, go back to define and implement more features in smaller priority features.  Follow each phase by  Evaluation  Planning of next phase  Precede each phase by  Alternatives  Risk analysis

11. Ch2: Software Life Cycles 11 Boehm’s Spiral Model

12. Ch2: Software Life Cycles 12 *Analysis of Spiral Model  Strengths  No distinction between development, maintenance  Risk-driven (focus resources where needed)  Weaknesses? Evaluation (Small Group Exercise): Easier/harder to cancel a large project? What’s different from previous models? Easier/harder to cancel a large project? What’s different from previous models? Suitable for large or small projects? Why? Suitable for large or small projects? Why?

13. Ch2: Software Life Cycles 13 Incremental Model  Divides project into builds, each build a subset of product.

14. Ch2: Software Life Cycles 14 *Incremental Model Analysis  Waterfall, rapid prototyping models yield Operational quality complete product only at end  Incremental model, typically used with OO life cycles  Operational quality portion of product within weeks  Smaller capital outlay, client can stop dev. at any time  An Enhancement (dev/maint) is merely another build  Problem: Build-and-fix danger Microsoft Variant: Synchronize and Stabilize Model Each build carried out by small teams working in parallel End of day—synchronize (test/debug) End of build—stabilize (freeze build) adv: components fit, early insight into OP of product

15. Ch2: Software Life Cycles 15 Extreme Programming  A lightweight methodology that has only a few rules and practices or ones which are easy to follow.  Emphasizes customer involvement and promotes team work.  User story is not complete until it has passed its acceptance tests.

16. Ch2: Software Life Cycles 16 Agile Software Development (text->Evolution Tree)  Development tasks broken down into small increments with minimal planning. Iterations are short duration 'timeboxes' that typically last from 1 to 4 weeks.  Each iteration includes a full software development cycle: planning, requirements analysis, design, coding, unit testing, and acceptance testing.  Helps minimize overall risk, and allows project to adapt to changes quickly.

17. Ch2: Software Life Cycles 17 Comparison of Life-Cycle Models

18. Ch2: Software Life Cycles 18 Conclusions  Different life-cycle models, each with own strengths/weaknesses  Criteria for choosing which Life-Cycle to follow:  organization  management  employees  product  Most commonly used? A variant of the incremental life-cycle (tweaked as per organization’s needs)