Managing Iterative Development as described in the Rational Unified Process Jim Pietrocarlo Rational Software, Eastern Regional Services Manager

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Software Economics  Recommended Reading  Summary

T I M E Traditional Waterfall Development Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis

RISKRISK T I M E Waterfall Development Delays Reduction of Risk Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis

Apply the Waterfall Iteratively to System Increments Earliest iterations address greatest risks Each iteration produces an executable release, an additional increment of the system Each iteration includes integration and test T C D R T I M E Iteration 1Iteration 2Iteration 3 T C D R T C D R

Iterative Development Characteristics  Critical risks are resolved before making large investments  Initial iterations enable early user feedback  Testing and integration are continuous  Objective milestones provide short-term focus  Progress is measured by assessing implementations  Partial implementations can be deployed

Transition Risk Inception Elaboration Construction Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Post- deployment Waterfall Time Staffing Risk Iterative Development Accelerates Risk Reduction

The time and money spent implementing a faulty design are not recoverable Develop Software Iteratively  An initial design will likely be flawed with respect to its key requirements  Late-phase discovery of design defects results in costly over-runs and/or project cancellation $$$

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Software Economics  Recommended Reading  Summary

Common Issues With Iterative Development  How do you know the status of the project?  How do you avoid it to become ‘hacking’?  How do you decide what goes into an iteration?  Delivered code is a rat nest, too expensive to maintain and extend!  How do you know when you are done?  Expensive with all rework during the project…  How do you manage consistent change?

 Mature technology and process  Object-oriented methods / component-based development  Management understands what is different about managing iterative development  Supporting best practices in place  Mature software environment  Advanced, integrated environments  Change management  Integrated configuration control and quality assessment Prerequisites to Successful Iterative Development

Supporting Best Practices ControlChanges DevelopIteratively Use Component Architectures ModelVisually VerifyQuality Ensures users involved as requirements evolve Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally ManageRequirements

Required Tool Support Controlled iterative development Reduces cost of change  Configuration management  Traceability  Round-trip Engineering  Automated Documentation  Automated testing  Automated metrics collection  Automated status updates  Common process Understand priorities

Reasons for Failure of Iterative Development  Lack of planning of each iteration  Lack of commitment to stabilize the architecture early  Poor choice of requirements to implement in earlier iterations  Failure to time box an iteration  Focus on documents and reviews  Treatment of early iterations as throw-away prototypes

Major Issues Slowing Down Adoption  RAD has not delivered on promise - code delivered often too expensive to maintain and extend  Lack of best practices  Detailed guidelines for all team members  Easily accessible  Lack of efficient tool support

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Software Economics  Recommended Reading  Summary

The Rational Unified Process has four phases:  Inception - Define the scope of project  Elaboration - Plan project, specify features, baseline architecture  Construction - Build the product  Transition - Transition the product into end user community time Inception Elaboration ConstructionTransition Major Milestones Phases in the Process

Inception Phase  Purpose  To establish the business case for a new system or for a major update of an existing system  To specify the project scope  Outcome  A general vision of the project’s requirements, i.e., the core requirements Initial use-case model and domain model (10-20% complete)  An initial business case, including: Success criteria (e.g., revenue projection) An initial risk assessment An estimate of resources required

Elaboration Phase  Purpose  To analyze the problem domain  To establish a sound architectural foundation  To address the highest risk elements of the project  To develop a comprehensive plan showing how the project will be completed  Outcome  Use-case and domain model 80% complete  An executable architecture and accompanying documentation  A revised business case, incl. revised risk assessment  A development plan for the overall project

Construction Phase  Purpose  To incrementally develop a complete software product which is ready to transition into the user community  Products  A complete use-case and design model  Executable releases of increasing functionality  User documentation  Deployment documentation  Evaluation criteria for each iteration  Release descriptions, including quality assurance results  Updated development plan

Transition Phase  Purpose  To transition the software product into the user community  Products  Executable releases  Updated system models  Evaluation criteria for each iteration  Release descriptions, including quality assurance results  Updated user manuals  Updated deployment documentation  “Post-mortem” analysis of project performance

Iterations and Phases An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external). PreliminaryIterationArchitect.IterationArchitect.IterationDevel.IterationDevel.IterationDevel.IterationTransitionIterationTransitionIteration InceptionElaborationConstructionTransition Releases

Iterative Development Initial Planning Requirements Analysis & Design Implementation Test Deployment Evaluation Management Environment Each iteration results in an executable release

Iteration N+1 Plan CostCost ScheduleSchedule ContentContent Compare iteration actual cost, schedule, and content with iteration planCompare iteration actual cost, schedule, and content with iteration plan Determine rework (if any) to be doneDetermine rework (if any) to be done Assign to future iteration(s)Assign to future iteration(s) Determine what risks have been eliminated, reduced, or newly identified in this iterationDetermine what risks have been eliminated, reduced, or newly identified in this iteration Update project planUpdate project plan Prepare detailed plan for next iterationPrepare detailed plan for next iteration Use revised risk list and select appropriate scenariosUse revised risk list and select appropriate scenarios Iteration N Assessment Iteration N Cost and Schedule Actuals Revised Risk List Quality Assessment for Iteration N Test ResultsTest Results Defect DensityDefect Density Architecture StabilityArchitecture Stability Other metricsOther metrics Revised Project Plan Total CostTotal Cost Overall ScheduleOverall Schedule Scope/ContentScope/Content Iteration Assessment

Benefits  Each iteration  provides you with exact (objective) status information  allows you to address top risks  allows for stakeholder feedback  allows you to re-prioritize requirements and manage scope  allows your development team to focus on a new short term goal  allows you to decide what needs to be reworked (improved)  allows you to learn from earlier experiences

Iterative Model Graph Phases Process Workflows Iterations Supporting Workflows Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction Workflows group activities logically In an iteration, you walk through all workflows

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Software Economics  Recommended Reading  Summary

 Performance constraints  Time-to-market pressures  Certification requirements  Distributed, real-time requirements  Size and geographic distribution of the engineering team  Reliability and fault-tolerance requirements  Rate of requirements and technology change  The interplay of these factors Complex software costs Diseconomy of scale size/scale Software cost Software costs = E * (Size) P What Makes Systems Complex?

Software Costs = E * (Size) P Current Software Technology Thrusts

R&D ComponentProduction Component Software cost = E Arch (Size Arch ) P Arch + E App (Size App ) P App Team size:Arch: 5 to 10 S/W engineersArch: 5 to 10 S/W engineers Apps: 5 to 10 mission engineersApps: As many as needed Small and expert as possibleLarge and diverse as needed Product:Executable architecture Deliverable, useful function Production plansTested baselines Mission scenarios/modelsWarranted quality Focus:Design and integrationImplement, test, and maintain Host development environmentTarget technology Phases:Inception and elaborationConstruction and transition Next-Generation Cost Models

$ or time Size/complexity P Arch > 1 $ or time Size/complexity P App < 1 N month design phaseN/2 month production increments Risk resolution, low-fidelity plan Schedule/technology driven Risk sharing contracts/funding Low-risk, high-fidelity plan Cost driven Fixed-price contracts/funding Architecture- centric Development Next-Generation Cost Models

 Today’s focus: Maximize SLOC per staff-month  Tomorrow’s focus: Minimize the amount of custom development Component-Based Development Next-Generation Productivities

Target Process Integrated environments Reusable components (architectures, instrumentation, etc.) Platform independence Integrated components (reuse, custom, COTS, adapted) Off-the-shelf solutions to most of the difficult computer science issues Time Development Progress S/W Engineering Experience Conventional Experience Late Design Breakage Range of reusable domain-specific assets Iterative and Component-Based Development

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Software Economics  Recommended Reading  Summary

Rational Unified Process - Books  Software Project Management - A Unified Framework, Walker Royce, Addison-Wesley, 1998  Rational Unified Process - An Introduction, Philippe Kruchten, Addison-Wesley, 1999  Object Solutions - Managing the Object-Oriented Project, Grady Booch, Addison-Wesley, 1996  Unified Software Development Process, Jacobson, Booch, Rumbaugh, Addison-Wesley - coming Q1, 1999

Agenda  Waterfall vs. Iterative Development  Prerequisites and Common Pitfalls  An Approach for Iterative Development  Productizing Best Practices for Iterative Development  Software Economics  Recommended Reading  Summary

Guidelines for Successful Iterative Development  Baseline executable architecture early  Address top risks early  Plan upcoming iteration in detail  Time box each iteration  Focus on objective measures  Control changes  Test throughout the lifecycle  Implement an integrated software engineering environment that supports iterative development  Learn from the experience of others - use a proven process