The good news. 34% of software projects succeed. Standish Group, CHAOS Report, 2003

Size: px

Start display at page:

Download "The good news. 34% of software projects succeed. Standish Group, CHAOS Report, 2003"

Morris Thompson
6 years ago
Views:

1 The good news 34% of software projects succeed. Standish Group, CHAOS Report,

2 The bad news That means 66% failed! Standish Group, CHAOS Report,

3 Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 3

4 Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 4

5 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

6 Develop Iteratively Risk! Initial planning Planning Requirements Project management Analysis & Design Implementation Evaluation Test Every iteration results in an executable release Deployment 6

7 Iterative Development - Attack Significant Risks Early Risk resolution period Controlled risk management period Waterfall Iterative Risk Risk Reduction Time 7

8 Best Practices Develop Iteratively Manage Requirements Use Component Architecture Model Visually (UML) Continuously Verify Quality Manage Change 8

approach to Eliciting Organising Documenting Managing

9 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

10 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

11 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

12 Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 12

13 Why Model Visually? Models: Capture structure and behaviour Show how system elements fit together Keep design and implementation consistent Enable clear communication 13

14 Unified Modeling Language The UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a software-intensive system 14

15 Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 15

16 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

17 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

18 Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 18

19 Manage Change Change management Configuration management 19

20 The Six Best Practices - a foundation for RUP Develop Iteratively Manage Requirements Model Visually (UML) Manage Change Use Component Architectures Continuously Verify Quality 20

21 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

22 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

23 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

24 Nine disciplines 24

25 Together: The Iterative approach In an iteration, you walk through all disciplines Disciplines group activities logically 25

Rational Unified Process

Rational Unified Process Software development Life Cycle The life of a software system can be represented as a series of cycle. A cycle ends with the release of a version of the system to the customers.