meeting -*- Outline -*- * iterative development and the unified process (Larman, Ch. 2) The unified process is an example iterative process, which is associated with the UML In the section, we just give an introduction to the ideas ** iterative development (2.1) *** what is it? ------------------------------------------ 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? ------------------------------------------ the four-week synergistic example, you might use two weeks or some other time. Depending on the size of the project within each cycle, called and iteration, you do a little bit of requirements analysis and design, then start coding and testing, you might also do little iterations within the bigger iterations result of each iteration is an incomplete but executable system, it is not necessarily ready for production, but it is not a prototype to be thrown away either typically each iteration implements some new use cases or requirements, however, sometimes iterations will just tr just try to improve or refactor the software ... - avoid the rush to code - need to learn the requirements and design as we go - mitigate high risks early - have early visible progress - give early user feedback, refine to meet real user needs - manage complexity (each steps small) - learning can be used to improve the process itself *** embracing change We don't believe we can actually forsee all of the requirements or the best design correctly from the very beginning without having some feedback from actual system (if we did, we could use a waterfall process, but we can't) This is a key point, central to OO and actual practice for complex systems, changable systems, etc. So we plan to change my not fixing the design from the beginning, but planning to revise it. ------------------------------------------ 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 ------------------------------------------ ------------------------------------------ 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 ------------------------------------------ Q: does this mean we don't try to plan and anticipate changes, needs? no, but we don't overplan either... Q: what might be the problems if use longer cycles? complexity overwhelming, feedback delayed Q: shorter cycles? difficult to accomplish anything ------------------------------------------ RISK DRIVEN DEVELOPMENT Risk: technical schedule requirements Strategy: minimize by attacking high risk first ------------------------------------------ Don't put it off... Q: What impact does resolving the risks early have on change? ** 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, ... ------------------------------------------ These are not requirements phases each of these may take multiple iterations each of which does requirements, design, implementation, and testing. see figure 2.3 The difference is in the goals. In this course we're going to focus mostly on inception and elaboration however, most projects will spend most iterations in construction ** process customization (2.5) all artifacts are optional (except code) ------------------------------------------ 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 ------------------------------------------ you won't necessarily do all of these things ** algile unified process (2.6) ------------------------------------------ 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: ------------------------------------------ ... accepts change, no detailed plan for resource allocation, iterative ... light and agile Advice is to prefer a small set of activities and artifacts, keep it simple weak iteration, requirements and designs are not completed before implementation there isn't a detailed plan for the whole project there is a high-level plan (the phase plan) estimates project and eight and other major milestone no fine-grained milestones or steps the iteration plan only plans in greater detail one iteration in advance We will also follow this route for the class itself... ** questions (2.8) Q: Is inception the same as requirements planning? Q: Should most of the requirements be defined before starting design? Q: Is programming just a translation to code of the design? Q: Can we accurately bid a project before elaboration is finished?