The good news 34% of software projects succeed. Standish Group, CHAOS Report, 2003 1
The bad news That means 66% failed! Standish Group, CHAOS Report, 2003 2
Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 3
Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 4
Waterfall Development Characteristics Waterfall process Requirements Design Code Integration System test Delays the critical risk mitigation Measures progress by evaluating working products that is not good at showing the amount of remaining work. Delays and complicates integration and testing Prevents early deployment Often leads to big unplanned iterations. 5
Develop Iteratively Risk! Initial planning Planning Requirements Project management Analysis & Design Implementation Evaluation Test Every iteration results in an executable release Deployment 6
Iterative Development - Attack Significant Risks Early Risk resolution period Controlled risk management period Waterfall Iterative Risk Risk Reduction Time 7
Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 8
Manage Requirements Making sure you Solve the right problem Build the right system by taking a systematic approach to Eliciting Organising Documenting Managing the changing requirements of a software application 9
Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 10
Purpose of a Component-Based Architecture Component-based architecture with layers Basis for reuse Component reuse Architecture reuse Basis for project management Planning Staffing (clean division of work between teams) Delivery Intellectual control Manage complexity Maintain integrity 11
Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 12
Why Model Visually? Models: Capture structure and behaviour Show how system elements fit together Keep design and implementation consistent Enable clear communication 13
Unified Modeling Language The UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a software-intensive system 14
Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 15
Continuously Verify Quality Cost to Repair Software Cost of Lost Opportunities Cost Cost of Lost Customers Software problems are 100 to 1000 times more costly to find and repair after deployment Inception Elaboration Construction Transition 16
Test Each Iteration Iteration 1 Iteration 2 Iteration 3 Iteration 4 UML Model and Implementation Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests It is often cheaper to find a problem through early implementation and testing, than through detailed design review. 17
Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 18
Manage Change Change management Configuration management 19
The Six Best Practices - a foundation for RUP Develop Iteratively Manage Requirements Model Visually (UML) Manage Change Use Component Architectures Continuously Verify Quality 20
Iterative Development Phases Inception Elaboration Construction Transition time Inception Elaboration Construction Transition Understand what to build, project scope, business case, what s the problem Understand how to build it, baseline architecture, most requirements Build the product Validate the solution, user acceptance 21
Iterations and phases Inception Elaboration Construction Transition Iteration I1 Iteration E1 Iteration E2 Iteration C1 Iteration C2 Iteration C3 Iteration T1 Iteration T2 Minor milestones: Internal releases 22
Analysis, Design, Build, Test in each Iteration Inception Elaboration Construction Transition A A A A A A D D D D D D B B B B B B T T T T T T Goal is to have executable, configured, tested code at the end of each iteration An iteration is not equivalent to a release Multiple releases is not equivalent to iterative development Team will issue one final, official release at the end of Transition phase 23
Nine disciplines 24
Together: The Iterative approach In an iteration, you walk through all disciplines Disciplines group activities logically 25