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

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

3. Unified Process Iterative and Incremental Use Case Driven Architecture Centric Risk Focused 3CS6359 -- 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. 4CS6359 -- 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 5CS6359 -- 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 6CS6359 -- 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 7CS6359 -- John Cole

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

9. The Agile Manifesto We Value Individuals and interactionsover processes and tools Working softwareover comprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan That is, while there is value in the items on the right, we value the items on the left more. 9CS6359 -- 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 10CS6359 -- 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 11CS6359 -- 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 12CS6359 -- 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. 13CS6359 -- John Cole

14. UP Phases Inception: approximate vision, business case, scope, vague estimates Elaboration Construction Transition 14CS6359 -- 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 15CS6359 -- John Cole

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