2. Iterative, Evolutionary & Agile

1. 2. Iterative, Evolutionary& Agile CSE 5324 Quiz 2 due at 5 PM, Tuesday, 26 August 2014

2. Chapter 2 Objectives • Motivate the textbook’s content and order. • Define the iterative, agile process. • Define the Unified Process’ fundamental concepts.

3. Introduction • Iterative development (e.g., the Unified Process) is the most effective way to do OOA and OOD, whose object orientation facilitates software development productivity. • Light-weight agile practices (e.g., Agile Modeling) are the most effective ways of applying UML, which facilitates communications among developers.

4. Introduction – Continued • The sequential “waterfall” software development life cycle (SDLC) attempts to complete requirements analysis, architecture, design, coding and as many layers of testing in distinct phases punctuated by irrevocable peer reviews. It is associated with the highest failure rates among all SDLCs. • Iterative development codes and tests parts of a system in many short cycles. Before require-ments are known in detail, software develop-ment feedback clarifies and improves evolving specifications. It is associated with higher success and productivity rates and lower defect levels.

5. 2.1 UP & Associated Methods • The Unified Process (UP) is the de facto standard iterative SDLC. (An SDLC tells how software is to be built, deployed and maintained. IBM’s Rational UP tool is in 124 ERB.) • Heavier-weight agile practices, such as Extreme Programming (XP) and Scrum, also are consistent with UP. • XP’s test-driven development, refactoring and continuous integration also fit within any UP project. • Developers are encouraged to blend any or all of these complementary methods as needed.

6. R U O K ? 1. What is the most effective way to do OOA/D?__ • Agile Modeling, which is one of many light-weight agile practices. • The Unified Process, which is the most popular form of iterative development. • Both of the above. • None of the above.

7. R U O K ? Match the following descriptions with the terms below: 2. Associated with high success and productivity rates and lower defect levels. __ 3. Attempts to complete requirements analysis, architecture, design, coding and as many layers of testing in distinct phases punctuated by irrevocable peer reviews. __ 4. Develops and tests parts of a system in many short cycles. __ 5. Associated with the highest failure rates of software development life cycles. __ 6. Before requirements are known in detail, software development feedback clarifies and improves evolving specifications. __ 7. A strictly sequential software development life cycle. __ a. Waterfall. b. Iterative development.

8. R U O K ? 8. Which of the following is NOT true of the Unified Process (UP)? __ • UP is the de facto standard iterative software development life cycle; i.e., how software is to be built, deployed and maintained. • Light-weight agile processes and heavier-weight agile practices, such as Extreme Programming (XP) and Scrum, are consistent with UP. • XP’s test-driven development, refactoring and continuous integration also fit within any UP project. • Developers should not attempt to blend combinations of these methods, because that would dilute the UP’s effectiveness.

9. 2.2a Iterative & Evolutionary Development • Each ~3-week iteration is a mini-project, with its own requirements analysis, design, implementation and testing activities, which produce a fully tested, integrated and executable partial system. • The ~5 iterations’ incremental growth depend upon feedback and adaptation to evolve the system’s specifications and design (Fig. 2.1). Fig. 2.1. Iterative and Evolutionary Development.

10. 2.2b An Example Iteration 1st Monday: Team leader clarifies new iteration’s tasks and goals. Team manager prints and displays Rhapsody UML diagrams, which were reverse engineered from the last iteration’s tested (higher risk) subsystem. Together they do agile modeling (i.e., trade studies of design alternatives), and sketch rough UML diagrams of the new iteration’s software, including pseudocode and design notes. 1st Wednesday through 3rd Friday: Implemen-tation, unit/acceptance/usability testing, design refinements, integration and daily builds. Also demonstrations/evaluations with stakeholders, who help plan the next iteration.

11. 2.2c Iterative Projects Embrace Change • Iterative developers welcome change, evolutionand adaptation. • Continually agreed upon requirements converge, as stakeholders clarify their visions in the ever changing marketplace. • After choosing a small subset of the (highest risk) remaining requirements, each iteration quickly designs, code and tests, all of which evokes valuable feedback for the next. For example, users say, “Yes, this is what I asked for, but what I need is a little more of that.” And load testing either proves the partial design or suggests minor course corrections (Fig.2.2). Fig. 2.2. Requirements and design converge.

12. 2.2d Iterative Development Benefits • Fewer failures: successful projects, higher productivity, fewer defects. • Earlier risk mitigation: requirements, technical, usability. • Happy customers: early visible progress, early feedback, more user engagement, adaptation, refined systems that more closely meet stakeholders’ needs. • Complexity management: development team not overwhelmed by “analysis paralysis” or very long, complex steps. • Learning by doing: on-the-job training, innovative design patterns, process improvements.

13. 2.2e Iteration Timeboxing • Choose a 2- to 5-week iteration length, and stick with it…! • Shorter iterations are better, but meaningful work can’t be completed in fewer than 2 weeks. • Longer iterations are too complex, and their feedback comes too late. • The partial system must be integrated, tested and stabilized by the scheduled date. • If deadline is too hard to meet, move planned tasks or requirements into the next iteration.

14. R U O K ? 9. Which of the following is NOT true of iterative and evolutionary development? __ • Each iteration is a mini-project, with its own requirements analysis, design, implementation and testing activities. • Ideally these disparate activities should not overlap. • Each iteration produces a fully tested, integrated and executable partial system. • Incremental growth of the iterations depends upon feedback and adaptation to evolve the system’s specifications and design. • Consistent with your 15-week Fall semester, a project may consist of five 3-week iterations.

15. R U O K ? 10. If each iteration is 3 weeks long, when should Rhapsody UML diagrams be drawn? __ • Throughout the current iteration’s OOA/D cycle, before its coding and testing begin. • Light-weight agile urges developers to roughly sketch UML diagrams, instead of completing those detailed formal diagrams that Rhapsody requires. • On the new iteration’s first day, to reverse engineer the tested code of the prior iteration. • Just before the iteration’s concluding demonstration to stakeholders, because they may want to carefully inspect the UML and possibly edit it. • None of the above.

16. R U O K ? 11. Which of the following does NOT describe an iterative project’s changing requirements? __ • Iterative developers welcome change, evolution and adaptation. • Continually agreed upon requirements converge, as stakeholders clarify their visions of the ever changing marketplace. • An iterative developer would consider the following user response to be good feedback for use in the next iteration: “Yes, this is what I asked for, but what I need is a little more of that.” • Load testing may validate the partial design or suggest minor design course corrections in the next iteration. • Requirements must not be allowed to “creep.” • All of the above are descriptive of iterative projects’ changing requirements.

17. R U O K ? 12. Which of the following is NOT a benefit of iterative development? __ • Fewer failures: successful projects, higher productivity, fewer delivered defects. • Earlier risk mitigation: requirements, technical, usability. • Happy customers: early visible progress, early feedback, more user engagement, adaptation, refined systems that more closely meet stakeholders’ needs. • Jobs for high school graduate C coders. • Complexity management: development team not overwhelmed by “analysis paralysis” or very long, complex steps. • Learning by doing: on-the-job training, innovative design patterns, process improvements.

18. R U O K ? 13. Which of the following is NOT true of iteration timeboxing? __ • After a project commits to a particular iteration length, it must not change. • Plan each iteration to be the shortest possible interval in which significant work can be accomplished. • At each project’s onset, company management estimates the number of iteration timeboxes and the average length of each, to ensure on-time delivery. • If deadline is too hard to meet, move planned tasks or requirements into the next iteration.

19. 2.3a Avoid Waterfall’s Errors • Resist temptation to declare too many requirements before development begins. • Avoid thorough and detailed UML models and designs before coding. • About half of waterfall requirements never deliver as product functions, and waterfall schedule estimates vary by 400%. • Research shows iteration is much better. • Avoid even thinking about waterfall practices; e.g., big, up-front analyses and modeling.

20. 2.3b Waterfall is Failure Prone • It assumes that predictable, stable specifications will be correctly defined at project onset and will never change. • In fact, in the course of a typical software project, 25% of requirements change, and larger projects’ requirements change by 35 to 50%. • Software projects are connected with new product developments, not with traditional mass manufacturing with its small incremental changes. • Stable software requirements and refined designs evolve from continual feedback.

21. 2.4 How To Develop Software Fig. 2.4. Evolutionary analysis and design. 1. Before iteration-n: Developers and stakeholders list the high-level requirements and do an intense OOA of 20% of the most significant; i.e., highest risk and business value. Break down one of the use cases into detailed iteration tasks. 2. Iteration-n: Pick a timebox. Project leader and manager spend a day Agile Modeling the subsystems in many UML-ish sketches. Then they repeatedly code, test and integrate. On the last day, coding stops and testing culminates in an iteration baseline. (They may delay tasks to complete on time.) And they demonstrate the partial system’s performanceto stakeholders for feedback, which enables requirement and design refinements. 3. Repeat steps 1 and 2 till system delivery (Fig. 2-4).

22. 2.5 Risk- and Client-Driven Planning • Early iterations 1) identify and mitigate highest risks and 2) build the features that the client desires most. • To mitigate risk, early iterations focus on building, testing and stabilizing the core architecture, because all other system elements depend so heavily on it. • Author’s disclaimer: early iterations of this textbook’s examples focus on learning goals, not the items listed above for real projects.

23. 2.6 Agile Methods & Attitudes • Timeboxed iterative/evolutionary development, adaptive planning and incremental delivery all encour-age rapid and flexible responses to change; i.e., agility. • Agile Manifesto: 1) individuals & interactions > processes & tools, 2) working software > compre-hensive documentation, 3) customer collaboration > contract negotiation and 4) responding to change > following a plan. • Agile Principles: 1,3,7) weekly software deliveries = happy customer, 2) change = customer’s competitive edge, 4) business people & developers meet daily, 5,10,12,13) support good workers, 6) talk face-to-face, 8,9) steady pace and 11) simplify.

24. R U O K ? 14. True or False: To avoid “waterfall thinking,” good iterative developers do every task incompletely and move on to the next. __ • True. • False.

25. R U O K ? 15. What is the waterfall SDLC’s most fatal flaw? __ • It assumes that 25% of requirements typically change, and larger projects’ requirements change by 35 to 50%. • It assumes regards software projects like traditional mass manufacturing, which has manageably small incremental changes. • It assumes that predictable, stable specifications will be correctly defined at project onset, and they will never change. • It assumes that stable software requirements and refined designs can evolve from continual feedback. • None of the above.

26. R U O K ? Arrange the following software development steps in chronological order: 16. __ 17. __ 18. __ 19. __ 20. __ 21. __ 22. __ 23. __ 24. __ 25. __ 26. __ 27. __ 28. __ • Developers and stakeholders list high-level requirements. • Do an intense OOA of only the highest risk and highest business value 20% of the requirements. • Break down just one of the OOA’s use cases into detailed iteration tasks. • Set the iteration’s time interval. • Agile model the iteration’s partial system in many UML-ish sketches. • Repeatedly code, test and integrate. • Stop coding, so that testing can culminate in an iteration baseline. • Delay tasks as necessary to complete the iteration on time. • Demonstrate the partial system’s performance to stakeholders. • Accept feedback, for use in refining future requirements and designs. • Repeat until the system is complete. • Deploy the system. • Do beta testing.

27. R U O K ? 29. What is the highest risk task in the typical software development project? __ • Accurately assessing users’ needs. • Incorrectly assessing the product’s market. • Developing the core architecture. • Allocating responsibilities to objects. • None of the above.

28. R U O K ? 30. Which of the following is incorrect, according to the Agile Manifesto? __ • Individuals & interactions > processes & tools. • working software > comprehensive documentation. • contract negotiation < customer collaboration. • responding to change > following a plan. • Actually all of the above are correct.

29. 2.7 Agile Modeling Fig. 2.5. An example UML-sketched sequence diagram. • UML sketches help developers understand and talk about the problem (OOA) and see the path to a good OOD, not document its solution. (Don’t give the sketches to a programmer.) • Model and sketch UML only for the trickier parts of the design, and save the easy design elements for the coders. • Use the easiest, highest productivity tools available; e.g., whiteboards, camera (Fig.2.5). Always work in thinker and scribe pairs. Create many models in parallel, trading off complexities. Include only enough detail to be understood. • All models are inaccurate—only tested code demonstrates the (invisible) “true design.” • OOD modelers should code their own designs—Oops…!

30. 2.8 Agile UP • An agile Unified Process (UP) reuses a small subset of UP’s rich set of activities and artifacts. • Continually evolving through feedback, requirements and designs are incomplete before implementation. • The UP suggests applying UML in agile models. • Don’t plan projects in detail. UP’s high-level phase plan identifies project milestone dates, and its iteration plan (adaptively) describes only the current iteration.

31. 2.9 Critical UP Practices • Keep all development short, timeboxed, iterative, evolutionary and adaptive. • Do high risk (e.g., core architecture) and high value (user preferences) tasks first. • Continually accept users’ feedback, evaluations and requirements. • Verify quality by testing early, often and realistically. • Apply use cases as needed, and do UML modeling. • Carefully manage requirements, change requests and software configurations.

32. 2.10 UP Phases Fig. 2.6. UP phases. • Inception: approximate vision, business case, scope, vague estimates (i.e., a stopor go feasibility study). • Elaboration: vision refined, core architecture iterative implementation, high risks resolved, requirements and scope identified, more realistic estimates. • Construction: lower risk and easier elements iteratively implemented, prepare for deployment. • Transition: beta testing, deployment.

33. 2.11 UP Disciplines Fig. 2.7. UP Disciplines. Fig. 2.8. Disciplines &phases. • UP “disciplines” (e.g., Requirements) produce “artifacts” (e.g., tested code). • The Business Modeling discipline produces Object Model Diagrams, which show application concepts. • The Requirements discipline captures functional and nonfunctional requirements as a Use Case Model and Supplementary Specifications. • The Design discipline produces the Design Model, which (momentarily) describes software objects. • Implementation: coding and building the objects. • Environment: setting up UP process and tools.

34. R U O K ? 31. Which of the following is NOT a valid agile UML sketching guideline? __ • UML sketches help developers understand and talk about the problem (OOA) and see the path to a good OOD, not document its solution. • Sketch only enough detail to be clearly understood. • Give the finished OOD sketches to the project’s coders. • Model and sketch UML only for the trickier parts of the design, and save the easy design elements for the coders. • Use the easiest, highest productivity tools available; e.g., many whiteboards and a digital camera. • Always work in thinker and scribe pairs. • Create many models in parallel, trading off complexities. • All models are inaccurate—only tested code demonstrates the (invisible) “true design.” • OOD modelers should code their own designs.

35. R U O K ? 32. Which of the following is NOT true of agile UP? __ • An agile Unified Process (UP) should reuse only a small subset of UP’s rich set of activities and artifacts. • To continually evolving through feedback, requirements and designs nevertheless should be complete before implementation. • The UP suggests applying UML in agile models. • Don’t plan projects in detail. • UP’s high-level phase plan only identifies project milestone dates. • UP’s iteration plan describes only the current iteration.

36. R U O K ? 33. Which of the following practices is NOT critical to UP? __ • Keep all development short, timeboxed, iterative, evolutionary and adaptive. • Do high risk (e.g., core architecture) and high value (user preferences) tasks first. • Continually accept users’ feedback, evaluations and requirements. • Verify quality by testing early, often and realistically. • Apply use cases as needed, and do UML modeling. • Manage requirements, change requests and software configurations to the least possible extent.

37. R U O K ? Match the following UP phases with their definitions: 34. Inception: __ 35. Elaboration: __ 36. Construction: __ 37. Transition: __ a. Vision refined, core architecture iterative implementation, high risks resolved, requirements and scope identified, more realistic estimates. b. Lower risk and easier elements iteratively implemented, prepare for deployment. c. Approximate vision, business case, scope, vague estimates (i.e., a stop or go feasibility study). d. Beta testing, deployment.

38. R U O K ? Match the following UP disciplines with the artifacts that they produce: 38. Business Modeling: __ 39. Requirements: __ 40. Design: __ 41. Implementation: __ 42. Environment: __ a. Set up UP process and tools. b. Coded and built objects. c. Design Model, which (momentarily) describes software objects. d. Functional and nonfunctional requirements captured as a Use Case Model and Supplementary Specifications. e. Object Model Diagrams, showing application concepts.

39. 2.12 The Development Case • The table above summarizes practices and artifacts in each UP discipline for an arbitrary example development project. Table 2.1. Sample Development Case.

40. 2.13 Iterative Development & UP In summary, here is a list of things that should NOT be done in a UP iterative development project: • Defining most requirements before design and most of design before implementation. • Defining designs and models in great detail, so that coding becomes largely mechanical. • Assuming inception = requirements, elaboration = design, and construction = implementation. • Believing that each iteration is 3 months long. • Thinking the UP is a rigid list of practices and artifacts. • Planning a project in detail, from start to finish.

41. 2.14 History 1950s: Evolutionary, iterative and incremental development (IID) used on NASA’s Mercury project. 1960s: IID used on Trident submarine project. 1968: IBM published first paper on IID. 1970s: Seventeen 4-week iterations of IID used on NASA’s Space Shuttle flight control system. 1980s: Boehm published paper describing the “spiral” model, risk-driven IID method. 1990s: IID begat UP, DSDM, Scrum, XP, etc.

42. R U O K ? 43. Who would prepare a “Development Case” table, when and why? __ • Company management, stakeholders and Software Engineers collaborate in writing it as a Software Development Plan in the UP’s Business Modeling discipline. • In the Environment discipline, company management prepares it to list the deliverables promised from every project phase, in compliance with the customer’s development contract. • Software Engineers prepare a part of it on the first day of every iteration to report their progress. • None of the above.

43. R U O K ? 44. How would you translate into POSITIVE instructions the foregoing “list of things that should NOT be done in a UP iterative development project”? __ • Just relax, and do what comes naturally to any competent Software Engineer. • Do the hard work first, and the remainder whenever. • Do whatever your stakeholders want every day. • All of the above. • None of the above.

44. R U O K ? 45. How long have Software Engineers been successfully applying evolutionary, iterative and incremental development? __ a. About a decade. b. For 2 decades. c. About half a century. d. For 6 decades. e. About a century.

45. School Supplies Everyone please bring to ERB124 on Wednesday, August 27th: • pencils, • eraser, • white paper and • an email-enabled camera. Also please bring your completed Confidentiality Agreements, so that our grader can associate you with your teammates. Thanks!