Chapter 2 Iterative Evolutionary and Agile You should

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

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

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

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. CS 6359 -- John Cole 4

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 CS 6359 -- John Cole 5

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 • • CS 6359 -- John Cole 6

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 CS 6359 -- John Cole 7

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

The Agile Manifesto We Value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. CS 6359 -- John Cole 9

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 CS 6359 -- John Cole 10

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 • • CS 6359 -- John Cole 11

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 CS 6359 -- John Cole 12

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. CS 6359 -- John Cole 13

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

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 CS 6359 -- John Cole 15

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