Housekeeping

1. 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

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. *Build and Fix Model • No specifications • No formal design process • Evaluation: • Useful for small or large software? Neither? Both? • What would make this more useful?

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? • Result of extra documentation? • 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.

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!” • Misconception: Must determine what client wants • Real Goal: Must determine client’s needs Techniques: • Rapid prototyping • Key functionality • What client sees • Experimentation and change • Interviewing (primary technique) • Forms analysis/Questionnaires • Scenarios

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… • Is there an effect on Design? Implementation? Maintenance?

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? • Easier or harder to learn/use? • More or less functional/robust?

8. ~Rapid Prototyping vs. Waterfall Model Rapid Prototype Waterfall

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. 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 Spiral Model (intended to help manage risks) • Precede each phase by • Alternatives • Risk analysis

11. Boehm’s Spiral Model

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? • Suitable for large or small projects? Why?

13. Incremental Model • Divides project into builds, each build a subset of product.

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. 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. 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. Comparison of Life-Cycle Models

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)