1 / 24

From Waterfall to Iterative Development Making an effective transition

From Waterfall to Iterative Development Making an effective transition. Steve Wittie, ITS IBM Rational Software. Outline. Software The waterfall lifecycle Iterative development Summary. The Nature of Software. Engineering In the world of atoms, they obey the laws of physics

hiroko
Download Presentation

From Waterfall to Iterative Development Making an effective transition

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. From Waterfall to Iterative DevelopmentMaking an effective transition Steve Wittie, ITS IBM Rational Software

  2. Outline • Software • The waterfall lifecycle • Iterative development • Summary

  3. The Nature of Software • Engineering • In the world of atoms, they obey the laws of physics • In the world of bits, software has no “physical laws” • Extreme modifiability • Used to be a way to fix hardware problems support the business • Has evolved to driving technology and “Being” the business. • Diseconomy of scale • In most manufacturing processes there exists economies of scale • In contrast, the more software you build, the greater the cost per unit item. Software enables our thoughts, our ideas, our innovation.

  4. The Good News with the Bad • Software is everywhere, from: • Our business, to being our business • IT departments, to the Department of Defense • The Space Shuttle, to shuttle buses • Our stock market, to our personal bank accounts • Software problems affect every aspect of our lives, from • The customers we can reach, to the “customers experience” • The job we can do, to our ability to defend our freedom • Our ability to explore, to our ability to get to work • The stability of our currency, to the security of our last paycheck The pervasiveness of software in every walk of life compels us to engineer our software solutions

  5. Outline • Software • The waterfall lifecycle • Iterative development • Summary

  6. Waterfall Software Development • Freeze requirements before design. • Forbid coding prior to detailed design review. • Do the easy stuff first. • Complete unit testing before integration. • Maintain detailed traceability among all artifacts. • Document and maintain the design. • Assess quality with an independent team. • Inspect everything. • Plan everything early with high fidelity • Control source code baselines rigorously.

  7. IntegrationBegins Late DesignBreakage Waterfall: What Happens in Practice Requirements Design Code Integration Test 100% Development Progress(% coded) • Late design breakage • 40% effort on integration and test Original Target Date Project Schedule Problems in the Software are Found too Late to even React; let alone recover

  8. Outline • Software • The waterfall lifecycle • Iterative development • Summary

  9. Iteration 1 Iteration 2 Our Result of Addressing Waterfall Inefficiencies Iteration 3 • Earliest iterations address greatest risks • Each iteration produces an executable release • Each iteration includes integration and test

  10. ModernProject Profile Iterative: What Happens in Practice Prototypes Architecture Functional Product Releases Release 100% • Risk Driven • User Perspective Throughout • Architecture Centric • Results Based Development Progress(% Coded) Project Schedule Problems are Found in the Software in each Iteration, Allowing Time to Recover

  11. Iterative Software Development • Focus the process on the architecture first • Attack risks early with an iterative life cycle • Emphasize component-based development • Change management of all artifacts • Simplify change freedom with round-trip engineering • Use rigorous, model-based design notation • Instrument the process for objective quality control • Emphasize demonstration-based assessment • Plan releases with evolving levels of detail • Establish a scalable, configurable process

  12. RUP Iterative Development Phases In an iteration, you walk through all disciplines Disciplines group activities logically

  13. Benefits of Iterative Development • Accommodating changes • Functional changes, tactical changes, technology • It is inevitable, so make it part of your process • Letting the discovery process work for you • Better opportunity for reuse • Reuse identified early (Elaboration) • Higher quality • Tested early and more often, • Checkpoints for process valuation • Roadmap of how value will be delivered to the customer • Greater predictability, minimize losses • Earlier discovery of potential for failure or cancellation • Defines decision points to reduce surprises • Risk • Organization, process, technology addressed early • Addressed each iteration in small, manageable chunks

  14. Better Progress Profile Sequential phases, but iterative activities Prototypes Architecture Functional Product Releases Release 100% ModernProject Profile Development Progress(% Coded) WaterfallProject Profile Project Schedule

  15. Accelerate Risk Reduction R I S K Risk reduction Waterfallrisk Iterative Iteration Iteration Iteration Iteration Iteration T I M E

  16. Sounds Great! But there is no such thing as a Free Lunch! • Transitioning to iterative development will be a paradigm shift for all stakeholders; whether it be the customer, management, or the development team; especially the project manager. • These Paradigm Shifts manifest TRAPS that we can get caught in if we are not watching for them! • These Paradigm Shifts include: • More Planning Work • Acknowledging Rework Up Front • Putting Software First • Hitting Hard Problems Earlier • Clashes of Lifecycle Models • Different Accounting for Progress • Number, Duration and Content of Iterations • Project Manager & Project Architect

  17. Outline • Software • The waterfall lifecycle • Iterative development • Summary

  18. Number, Duration and Content of Iterations - 2 • Trap: Too many iterations • Tips • Daily, weekly builds are not iterations • Depends on size, team size, familiarity with the approach • the size of the organization, its degree of geographic distribution, and the number of distinct organizations involved

  19. Confused a Little? Change Seems to Do That! • Waterfall lifecycle makes it easy on the manager, hard on the engineers • Early and regular sense of completeness • End of the lifecycle is weighted heavy with risk • Iterative lifecycle brings a bit more complexity to management • Sense of incompleteness in the early iterations • More planning work required; each phase and iteration • Less pain in the end • Iterative does not necessarily mean less work and shorter schedules • Price to pay for greater predictability, consistency, quality

  20. Project Managers: • Do not change everything at once • There are fire-proven recipes & techniques to address this type of change. So, get help! Don’t do it on your own! • Keep in mind: • Software comes first (Keep the ultimate objective in mind.) • Attack the risk actively or they will attack you • Chose an architect and a project manager who can work hand in hand • Do not follow a process blindly, tailor it and use the tailored process as your guide. • Once in a while, revisit the next slide titled: “Benefits”

  21. Benefits of Iterative Development Process • Consistency • Enable clear, consistent communication for all team members with well defined roles and responsibilities • Exploit reuse early by addressing architecturally significant requirements and applying architectural patterns • Predictability • Help identify what resources are needed and when • “Compare to” baseline for addressing bottlenecks and failure points • Defines decision points to reduce surprises; earlier failure recognition • Enables metric development to support future planning and estimation • Quality • Focus on risk reduction, accommodate change, test early and often • Roadmap of how value will be regularly delivered to the customer

  22. Hallmarks of Agile tooling (in Ralf) • Intelligent check out/in. The tool should know what I changed. • Checkin as a group of associated changes, called atomic commits. • Allow Isolated, individual workspaces until ready to commit. • Add your changes to LATEST. • Auto merge when needed (trivial). • Allow Isolated, individual workspaces until wanting to refresh. • Get your changes from LATEST. • Auto merge when needed (trivial). • No developer interaction with tool unless a non trivial merge needs resolution. • Then resolve it immediately

  23. Hallmarks of Agile tooling (in Ralf) • Ability to Roll back/forward any workspace to a point in time, relative to the commits you want. • Facilitates NO STOPPING – constant iteration of the development process. • All roles, developer workspaces, test workspaces, build workspaces, etc. • Don’t wait for other roles (waterfall). Report trends in all phases of iteration, then improve it.

  24. Ralf and ClearCase Questions: • Ralf = Rational Agile Lite Framework • Free plug in to CC explorer / behaves like Tortoise • Why Ralf and who owns it • What about UCM • What about CC ver 7.1 • Is there anything you can’t do with ClearCase? • What about performance (all that meta-data) • What about co-mingling regular CC and RalfCC • What about Agile in multiple vobs • What about Code and file refactoring • Is Ralf easy to install and learn

More Related