1 / 16

Chapter 2

Chapter 2. Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler. Waterfall Development. Communication: project initiation; requirements gathering Planning: estimating; scheduling; tracking

cindylutz
Download Presentation

Chapter 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related