I. overview of OO Analysis and Design (Larman, Ch 1) what do we mean by a good object-oriented system or 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 2 weeks: Requirements, Design, Implement, Test 2nd 2 weeks: Requirements, Design, Implement, Test 3rd 2 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? a. timeboxing ------------------------------------------ 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? b. control and management issues c. risk driven development ------------------------------------------ RISK DRIVEN DEVELOPMENT Risk: technical schedule requirements Strategy: first get basic functionality to work, then seek to minimize risk 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 glossary start ref Requirements use-case model start ref vision start ref suppl. spec. 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) 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?