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? ------------------------------------------ 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: 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?