Chapter 4

1. Chapter 4 Dynamic Structure: Iterative Development

2. Outlines • Using sequential Process (Waterfall) on engineering problems • What is wrong with sequential process? • Iterative technique: phases and milestones • Inception • Elaboration • Construction • Transition • Risk mitigation

3. Sequential Process It’s become common to blame many problems and failure in software development on sequential, or waterfall, process.

4. Solving Engineering Problems • Many engineering problems are solved by using sequential process. • The main steps are described as follows: 1) Understand problem to be solved, its requirements and constraints 2) Design solution that satisfies all requirements and constraints 3) Implement the solution 4) Verify that the implementation satisfies the requirements 5) Deliver.  PROBLEM SOLVED! • This is how buildings and bridges are built.

5. What is wrong with sequential process? • Why is sequential process not successful in modern software development? • We made wrong assumption. • The context of software development is different from other engineering disciplines. • We fail to incorporate human factors. • We try to stretch the approach beyond what it can bear. • We have little experience on developing software projects.

6. Wrong Assumption 1: Requirements Will Be Frozen • We assume we know all the requirements in writing. In fact, requirements will change for many reasons: • The users change • Users see other systems and products and they want those features. • Users’ work environment evolves. • The problem changes • IKIWISI: “I’ll Know It When I See It”. • Users see more when the system is implemented. • The underlining technology changes • New software or hardware emerges. • The market changes • The competitor introduces better product to market. We cannot capture requirements with sufficient detail and precision.

7. Wrong Assumption 2 • We can get the design right on paper before proceeding. • The sequential process works fine on small projects but it cannot handle novelty projects. • The lifetime of software tools, techniques, and products is short. • We cannot stretch what works for a three-month project to fit a three-year project. • User’s feedback is limited. • Volume-Based versus Time-Based scheduling • It will take nine months to complete this project. • In three months, we can do first three items and next two items in next three months. • Developers have only one shot at each activity.

8. From a sequential to an iterative lifecycle Overcoming Difficulties: Iterate • How do you eat an elephant?

9. Iterative Technique • Questions in using iterative technique: • How do we avoid having each iteration start over from scratch? • How do we select what to do in each iteration? • How does this approach solve major issues we identified earlier? • RUP answers these questions.

10. Phases and Milestones • Milestones provides points at which we can decide to proceed, abort, or change course. • Progress will be measured in number of: • Use cases or features completed. • Test cases passed. • Performance requirements satisfied. • Risks eliminated.

11. The Four Phases • Inception • Specifying end-product vision, business case and define scope of the project. • Elaboration • Planning necessary activities and required resources. • Specifying features and designing the architecture. • Construction • Building the product and evolving the vision, architecture, and plans until it’s ready for delivery. • Transition • Transitioning product to users. • Manufacturing, delivering, training, supporting, and maintaining product.

12. Initial and Evolution Cycles • I E C T constitute a development cycle and product a software generation. • Evolution cycles can be triggered by: • User-suggested enhancement, changes in user’s context, changes in technology, or reaction to the competition.

13. 2.5 months 12 months 2.5 months 7 months I 10% E 30% C 50% T 10% Time Typical Time Line for Initial Dev Cycles (two-year project)

14. Iteration, Internal & External Realeases

15. Activities Across One Development Cycle

16. Emphasis of Activities in Phases • Inception Phase • Focus is on understanding overall requirements • Determining the scope of the development process • Elaboration Phase • Focus is on requirements • Design and implementation is aimed at prototyping the architecture. • Mitigating technical risks by trying solution • Learning how to use tools and techniques. • Producing executable architectural prototype that will serve as the baseline for next phase

17. Emphasis of Activities in Phases • Construction Phase • Focus is on design and implementation • Evolving and fleshing out the initial prototype into the first operational product • Transition Phase • Focus is on ensuring the system meets level of quality • Fixing bugs • Training users • Adjusting features • Adding missing elements • Producing delivered final product

18. Phases Revisited

19. Inception: Objectives • Establish project’s • scope and boundary condition • Operational concept • Acceptance criteria • Specify parts of product. • Discriminate critical use cases of the system. • Present one candidate architecture. • Estimate overall cost and time for the entire project. • Also provide detailed estimates for elaboration phase. • Estimate risks (sources of unpredictability).

20. Inception: Activities • Formulate scope of the project, that is, capture the context and most important requirements and constraints. • Thus, the acceptance criteria for the end product can be derived. • Plan and prepare a business case • Evaluate alternatives for risk management, staffing, project plan, and trade-off among cost, schedule, and profitability. • Synthesize a candidate architecture • Evaluate trade-offs in design • Assess make/buy/reuse decisions • Thus, cost, time, and resources can be estimated.

21. Inception: Resulting Artifacts • Vision document • A general vision of core project’s requirements, key features, and main constraints. • Use-case model survey • Initial project glossary • Initial business cases • Business context • Success criteria • Financial forecast • Initial risk assessment • Project plan showing phases & iterations • Initial use-case model (10% - 20%) • One or several prototypes

22. Milestone: Lifecycle Objective • The evaluation criteria for inception: • Stakeholder concurrence on scope definition, cost, and time estimates. • Requirements understanding (primary use cases). • Credibility of cost and schedule estimates, priorities, risks, and development process. • Depth and breadth of architectural prototype. • Actual expenditures vs. planed ones. If fails, project may be canceled or considerably rethought.

23. Elaboration: Objectives • Define, validate, and baseline the architecture as rapidly as practical. • Baseline the vision. • Baseline a high-fidelity plan for the construction phase. • Demonstrate that the baseline architecture will support this vision for a reasonable cost in a reasonable time.

24. Elaboration: Activities • The vision is elaborated. • A solid understanding is established for critical use cases that drive the architectural and planning decisions. • The process, infrastructure, and development are elaborated • The process, tools, and automation support are put into place. • The architecture is elaborated and the components are selected • The make/buy/reuse decisions are determined for cost and schedule in construction phase.

25. Elaboration: Resulting Artifacts • A use-case model (at least 80%) in which all use cases have been identified. • Supplementary requirements that capture nonfunctional requirements. • A software architecture description. • An Executable architecture prototype. • A revised risk list and revised business case. • A development plan for the overall project. • An updated development case that specifies the process to be used. • A preliminary user manual (optional).

26. Milestone: Lifecycle Architecture • Is the vision of the product stable? • Is the architecture stable? • Does the executable demonstration show that major risks have been addressed and credibly resolved? • Is the construction phase plan sufficiently detailed and accurate? • Do all stakeholders agree that current vision can be achieved if the current plan is executed to develop the complete system? • Is the actual resource expenditure versus planned expenditure acceptable? If the project fails to pass this milestone, it may be aborted or rethought.

27. Construction: Objectives • Minimize development costs by optimizing resources and avoiding unnecessary rework. • Achieve adequate quality as rapidly as practical. • Achieve useful versions (alpha, beta, and other test releases) as rapidly as practical.

28. Construction : Activities • Resource management, resource control, and process optimization. • Complete component development and testing against the defined evaluation criteria. • Assessment of product releases against acceptance criteria for the vision.

29. Construction : Resulting Artifacts • Software product integrated on the adequate platforms. • User manuals. • A description of the current release.

30. Milestone: Initial Operational Capability • Deciding whether the software, sites, and users are ready for the operational project without high risks. • This release is called a beta release. • The evaluation criteria: • Is this product release stable and mature enough to be deployed in user community? • Are all stakeholders ready for the transition into user community? • Are the actual resource expenditures versus planned expenditures still acceptable? Transition may have to be postponed by on release if the project fails to reach this milestone.

31. Transition Phase • Beta testing to validate the new system against user expectations. • Parallel operation with the legacy system that the project is replacing. • Conversion of operational databases. • Training of users and maintainers. • Rollout of the product to the marketing, distribution, and sales teams.

32. Transition: Objectives • Achieve user self-supportability. • Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision. • Achieve final product baseline as rapidly and cost-effectively as practical.

33. Transition : Activities • Deployment-specific engineering, that is, cutover, commercial packaging and production, sales rollout, and field personnel training. • Tuning activities including: • Bug fixing • Enhancement for performance • Usability. • Assessing the deployment baselines against the vision and the acceptance criteria for the product.

34. Milestone: Product Release • Deciding whether the objectives were met and whether we should start another development cycle. • The primary evaluation criteria: • Is the user satisfied? • Are the actual resources expenditures versus planned expenditures still acceptable?

35. Benefits of Iteration Approach • Compared with sequential process: • Risks are mitigated earlier. • Change is more manageable. • There is a higher level of reuse. • The project team can learn along the way. • The product has better overall quality.

36. Risk Mitigation • In Iterative, developers go through selecting tools, off-the-shelf software, and people skills. • Typically, sequential process discovers risk during final integration. • Iterative process allows developers to mitigate risks earlier. • If a project is to fail, let it fail earlier.

37. Accommodating Changes • Changes in Requirements • Tactical Changes • Technological Changes • Learning as you go • Increased opportunity for reuse • Better overall quality

38. Summary • The sequential process is fine for small projects that have few risks and use a well-known technology and domain. • An iterative process breaks a development cycle into a succession of iterations. • To control the project and to give the appropriate focus to each iteration, a development cycle is divided into a sequence of for phases that partition the sequence of iterations. • The iterative approach accommodates changes in requirements and in implementation strategy. • It confronts and mitigates risks as early as possible.