1 / 28

Agile Development: Iterative and Evolutionary Software Engineering Process

Discover the benefits of using an iterative and agile approach in software development, addressing the limitations of the waterfall model and maximizing productivity. Learn about agile values, principles, and practices such as Scrum and Extreme Programming.

Télécharger la présentation

Agile Development: Iterative and Evolutionary Software Engineering Process

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. Iterative and AgileDevelopment http://flic.kr/p/7u4Xr2

  2. Engineering software is a big job • Variety of tasks: • Requirements • Design • Implementation • Verification (testing) • Maintenance http://flic.kr/p/7GereG http://flic.kr/p/5w9rXP

  3. Practical issue:What order should tasks be done in? That is, what process to use? http://flic.kr/p/9ksxQa

  4. The old way: Waterfall (sequential) model http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg

  5. Using Waterfall turns out to be a poor practice • High failure rates • Low productivity • High defect rates Statistic: Statistic: 45% of featuresin requirementsnever used Early scheduleand estimatesoff by up to 400%

  6. Why doesn’t Waterfall work? To find out, let’sread a passage fromSchwaber and Beedle (2001*) *Agile Software Development with Scrum http://flic.kr/p/9ksxQa

  7. Why Waterfall doesn’t work False assumption:Specifications predictable and stable,and can be correctly defined at the start,with low change rates Statistic: Statistic: 25% change in requirements 35% to 50% changefor large projects

  8. Waterfall is a “defined” process control model (think mass manufacturing) Software development needs an “empirical” model (think new product development) http://flic.kr/p/9xmccb http://flic.kr/p/4Xt7Xe

  9. Feedback Basis of empirical process model:Feedback and adaptation • Feedback from early development • Programmers reading specifications • Client demos • Feedback from tests to refine design/implementation • Feedback from progress to refine schedules/estimates • Feedback from client/marketplace to refine/re-prioritize features Adaptation

  10. Iterative and incremental development also called iterative and evolutionary Larman Figure 2.1

  11. How long should iterations be? • Short is good • 2 to 6 weeks • 1 is too short to get meaningful feedback • Long iterations subvert the core motivation http://flic.kr/p/368zW7

  12. Example from Larman As an example (not a recipe), in a two-week iteration half-way through a project, perhaps: • Monday is spent primarily on distributing and clarifying the tasks and requirements of the iteration, while one person reverse-engineers the last iteration's code into UML diagrams (via a CASE tool), and prints and displays noteworthy diagrams. • Tuesday is spent at whiteboards doing pair design work drawing rough UML diagrams captured on digital cameras, and writing some pseudocode and design notes. • The remaining eight days are spent on implementation, testing (unit, acceptance, usability, ...), further design, integration, daily builds, system testing, and stabilization of the partial system. • Other activities include demonstrations and evaluations with stakeholders, and planning for the next iteration.

  13. Iterative and incremental development addresses the “yes…but” problem Yes, that’s what I asked for, but now that I try it, what I really need is something slightly different.

  14. System converges over time Larman Figure 2.2

  15. More benefits of iterative development • Less failure, better productivity, fewer defects • Early mitigation of risk • Early visible progress • Better meet real needs of stakeholders • No “analysis paralysis” • Iterative process improvement http://flic.kr/p/7fD777

  16. Iterative and incremental development is a broad approach But how to operationalize? To help with that, there aremore specific methods and practices In particular, there are agile methods

  17. What is an agile method? Where does it come from? values,principles, practices Agile values, principles beget Agile method Types of advice more general more specific practices principles values

  18. Recall: Agile Values From the Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://flic.kr/p/6Ag67y

  19. Can you think of a principle and a practicethat might be based on the agile values? Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://flic.kr/p/9ksxQa

  20. Examples of agile methods and their practices • Scrum • Common project workroom • Self-organizing teams • Daily scrum • … • Extreme programming (XP) • Pair programming • Test-driven development • Planning game • … http://flic.kr/p/8Mbo3N

  21. So what is this UP thing thatLarman keeps talking about? • UP = Unified Process • See also Rational Unified Process (RUP; IBM’s refinement) • Process framework • Customizable: other methods/practices can be plugged in • Agile methods for example! • But has some practices of its own as well • Iterative and incremental • Defines phases across series of iterations

  22. Phases of UP • Inception: Approximate vision, business case, scope, vague estimates • Elaboration: Refined vision, iterative implementation of core architecture, resolution of high risks, most requirements, more realistic estimates • Construction: Iterative implementation of remaining lower risk and easier elements, prep for deployment • Transition: Beta tests, deployment

  23. Phases of UP (cont’d) Larman Figure 2.6

  24. UP Disciplines • Set of activities in one subject area • Examples: • Business modeling • Requirements • Design • Test • Each discipline typically associated with particular artifacts (e.g., code, models, documents)

  25. Discipline activity across iterations Larman Figure 2.7

  26. Disciplines/artifacts across phases s = started r = refined Larman Table 2.1

  27. A word about agile modeling(quoting Larman) Experienced analysts and modelers know thesecret of modeling: Thus, we favor hand-drawn diagrams over typeset ones The purpose of modeling (sketching UML, …) is primarily to understand, not to document. http://flic.kr/p/7SFKjj

  28. You know you’re doing UP wrong when… • Define most requirements before starting design or implementation • Spend days/weeks modeling before programming • Think inception=requirements, elaboration=design, construction=implementation • Think elaboration is to fully define models • Believe that iterations should be 3 months • Think you need to create many formal documents • Try to plan project in detail from start to finish http://flic.kr/p/6FJZDY

More Related