Chapter 2

1. Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler CS6359 -- John Cole

2. Waterfall Development • Communication: project initiation; requirements gathering • Planning: estimating; scheduling; tracking • Modeling: analysis, design • Construction: code, test • Deployment: delivery, support, feedback CS6359 -- John Cole

3. Unified Process • Iterative and Incremental • Use Case Driven • Architecture Centric • Risk Focused CS6359 -- John Cole

4. Iterative Development • Development is in short cycles, or iterations • Each one is tested and integrated • Each one gives an executable partial system • Feedback from each iteration leads to refinement and adaptation of the next. CS6359 -- John Cole

5. Handling Change • “Change is good. Hard cash is better.” John Cole • Don’t fight changes to the software • Let users guide the development • They cannot tell you what they do not know CS6359 -- John Cole

6. Benefits of Iterative • Fewer failures, lower defect rates • Early mitigation of high risks • Early visible progress • Early feedback, user engagement, and adaptation • Managed complexity: team sees small pieces at a time • Use of learning within an iteration CS6359 -- John Cole

7. Feedback • From early development, programmers reading specs, and users, refine requirements • From tests and developers refine the design or models • From the progress of the team writing early features to refine the schedule and estimates • From the client and market to re-prioritize features for the next iteration CS6359 -- John Cole

8. Risk-Driven and Client-Driven Planning • Identify and minimize highest risks • Build visible features client wants most. CS6359 -- John Cole

9. The Agile Manifesto CS6359 -- John Cole

10. Agile Modeling • The purpose of modeling is to understand, not to document • Purpose is not for designer to create UML diagrams that are then given to a programmer. • Don’t model or apply the UML to all or most of the design. Use it for unusual, difficult, or tricky parts. • Use simplest tools possible CS6359 -- John Cole

11. Agile Modeling (2) • Don’t model alone • Create models in parallel • Use “good enough” simple notation • Know that all models are inaccurate; the final arbiter of the design is the code • Developers should do the OO design modeling for themselves, not other programmers CS6359 -- John Cole

12. Agile Modeling (3) • Use a small set of UP activities and artifacts • There is no detailed plan for the entire project. There is a high-level plan that estimates the end date and other milestones CS6359 -- John Cole

13. Critical UP Practices • Tackle high-risk and high-value activities early • Continuously engage users • Build cohesive core architecture early • Test early, often, and realistically • Apply use cases where appropriate • Do visual modeling • Carefully manage requirements • Practice change request and configuration management. CS6359 -- John Cole

14. UP Phases • Inception: approximate vision, business case, scope, vague estimates • Elaboration • Construction • Transition CS6359 -- John Cole

15. UP Disciplines • Business modeling – visualize concepts in the application domain • Requirements – Use case model and supplementary specifications to capture functional and non-functional requirements • Design • Implementation • Test • Deployment • Configuration and change management CS6359 -- John Cole

16. Customizing the UP • Most activities and artifacts are optional • Choose the ones that make sense for your project CS6359 -- John Cole