I. overview of OO Analysis and Design (Larman, Ch 1) what do we mean by a good object-oriented system or design? what is the difference between the analysis and design? II. iterative development and the unified process (Larman, Ch. 2) A. iterative development (2.1) 1. what is it? What would an iterative design process look like? ------------------------------------------ AN ITERATIVE PROCESS 1st 4 weeks: Requirements, Design, Implement, Test 2nd 4 weeks: Requirements, Design, Implement, Test 3rd 4 weeks: Requirements, Design, Implement, Test etc. Why do iterative development this way? ------------------------------------------ 2. embracing change Why do iterative development? ------------------------------------------ FIGHT OR EMBRACE CHANGE? Waterfall process fights change: - get requirements "right" - customer "signs off" - get design "right" - correctly build the design - test vs. requirements - deliver system to customer Not usually successful: - users learn what they really want - business, technology changes - we don't have that much foresight Better to embrace change - plan to learn - plan to get feedback from system - plan to revise requirements, design ------------------------------------------ What ways to iterations help embrace change? ------------------------------------------ ITERATIVE DEVELOPMENT EMBRACES CHANGE Each iteration: - choose small subset of requirements - quick design, implement, test Timeboxing: - iterations between 2-6 weeks long - fixed length - if schedule slips, reduce requirements ------------------------------------------ does this mean we don't try to plan and anticipate changes, needs? what might be the problems if use longer cycles? shorter cycles? ------------------------------------------ RISK DRIVEN DEVELOPMENT Risk: technical schedule requirements Strategy: minimize by attacking high risk first ------------------------------------------ What impact does resolving the risks early have on change? B. phases (2.3) ------------------------------------------ PHASES OF PROJECT - inception: investigate feasibility - elaboration: implement core architecture mitigate risks - construction: implement easier parts - transition: beta testing, deployment DISCIPLINES (aka WORKFLOWS) - Business modeling: objects in domain - Requirements: use cases, what to do - Design: architecture, objects, databases, networks, ... ------------------------------------------ C. process customization (2.5) ------------------------------------------ OPTIONAL ARTIFACTS AND PHASES Focus on small set of artifacts, tailored to project Incep Elab Discipline Artifact I1 E1..n ========================================= Business domain model start Modeling Requirements use-case model start ref vision start ref suppl. spec. start ref glossary start ref Design design model start SW arch. doc. start data model start ------------------------------------------ D. algile unified process (2.6) What's the difference between an agile and heavyweight process? ------------------------------------------ PROCESS TYPES Heavy process: - many artifacts, - bureaucratic, - rigid control, - elaborate planning for long term. Predictive process: - plans resource allocations in detail - over long time span Adaptive process: Agile process: ------------------------------------------ E. questions (2.8) Is inception the same as requirements planning? Should most of the requirements be defined before starting design? Is programming just a translation to code of the design? Can we accurately bid a project before elaboration is finished?