1. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M38 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 38 Process Improvement

2. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 2 Objective of This Module  To discuss various issues related to process improvement

3. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 3 Contents General Issues of Process Improvement Continuous Process Improvement Process Reengineering

4. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M38 - Version 9.01 General Issues of Process Improvement

5. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 5 Types of Changes Do Nothing to Improve

6. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 6 Types of Changes Time -----> Capability 0 10 20 30 40 50 60 70 80 Do Nothing Continuous Improvement

7. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 7 Types of Changes Time -----> Capability 0 10 20 30 40 50 60 70 80 Do Nothing Continuous Improvement Reengineering

8. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 8 Text References to Process Improvement Topics Topic Humphrey Chapter  Defining the Process 13  Changing the Process14  Improving the Process 17  All of the above Futrell, chapter 26

9. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 9 Process Improvement Begins with Process Management  Know the process  Know the implications of changes -- on the outcome -- on the people -- on the reward system -- on the organizational infrastructure -- on the culture

10. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 10 Change Requires Dealing with People  Define what will happen  Document the actual processes  Teach people  Deal with their concerns  Buy-in is earned –Show by actions that you are serious –“Walk the Talk” –Avoid preaching –Let the people own the process and the change

11. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 11 Quality Management Goal: Manage the software engineering function to achieve high quality at low cost and cycle time Time Cost Productive and Competitive Quality }

12. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 12 The Quality Management Concept Historical Data Base - Metrics - Lessons - etc. Process Models Knowledge and Experience Project Goals

13. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 13 Data Base  Know about your organization -- Metrics -- Lessons Learned -- etc.  Know about your industry and competitors -- What is best in class? -- Improvement rates -- etc.  Facts to help you manage Historical Data Base - Metrics - Lessons - etc.

14. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M38 - Version 9.01 Continuous Process Improvement

15. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 15 Basic Concept of Continuous Process Improvement  Keep watching what you do, learning from mistakes, and fixing root causes of problems

16. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 16 Models of Process Behavior  Theoretical models have scientific or statistical bases for their predictions  Historical data of actual experience gives valuable insight that theory may miss  Actual experience on current program is the most relevant, if you can accurately measure it All models give you a starting point and insight, but you must never fail to look at the facts

17. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 17 Using Models of Process Behavior  Models can be used for training in what is expected  Validation of experience against history and theory can help you understanding what is happening and why  Assessment of differences between models and actuality can give insights into key attributes of your process  Effective use of models will change management behavior, especially your own

18. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 18 Example of Experience vs. History (we saw this example earlier)  Suppose your experience suggests that for C++ doing your kind of software, you should be generating -- 25 lines of code per day during the coding phase with -- 3 errors per 1000 lines of code during module test  Suppose your actual experience is -- 40 lines of code per day with -- 0.5 errors per 1000 lines of code during module test

19. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 19 Possible Conclusions 1) We are doing much better than in the past -- Do you have a solid reason to explain this difference? I.e., why are you better? o Is the process different? o Are the people a lot better? o Are the tools better? 2) Our testing is no good (perhaps because it is being rushed due to deadlines) o Are the tests being performed? o Is the coverage adequate? o etc.

20. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 20 You Want to Achieve Optimal Performance  Don’t over-measure or under-measure  Don’t over-test or under-test  Don’t over-inspect or under-inspect  etc. Data + Models + Knowledge = Optimal Management

21. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 21 Monitoring is Essential  Recall that our software cost and size estimating models are based on -- historical data -- process models -- insight of model designer  These models are used to predict cost and schedule  But the predictions are not exact  They identify the risks and they give you a starting point for management

22. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 22 Update Projections and Estimates

23. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 23 If You Monitor Actuals Against the Predictions of Models, You Can  Revise the estimates based on new insight on parameters, assumptions, etc  Calibrate the models based on your experience original estimate real data recalibration updated estimate

24. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 24 Things You Can Predict and Monitor  Costs  Sizes  Quality  Reliability  Schedules  Staffing  etc.

25. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 25 Predictions vs Process Requirements Analysis Design Code & Module Test SW Integ. & Test Released Software Predictions based on actual code Predictions based on process and design info Actuals known

26. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 26 In Order to Improve the Process, You Need a Measure  Most organizations measure process in terms of three quantities: -- productivity -- what is produced per unit of cost -- cycle time -- time required to produce -- quality -- customer satisfaction level or defects identified in released products  But few organizations have defined these in a consistent way  So you need to start by defining these in a way that fits your goals

27. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 27 Example of a Measurement and a Model - Defect Density  We will look briefly at models and how they might be used for managing defect levels

28. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 28 Models of Defect Density Goal: reduce defects to levels acceptable to the customer Question: “how many defects are present in the system”?

29. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 29 Initial Model Approach: each step is modeled as something that can inject new defects and eliminate defects Process Step I = Defects InputO = Defects Output F = Defects Found and Fixed C = Defects Created O = I + C - F

30. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 30 A More Detailed Defect Model of a Process Step Inject Defects escaping defects incoming defects undetected defects detect defects repair defects incorrect repairs defects removed This model accounts for the mistakes we make when fixing defects - I.e., the new defects we may accidentally introduce

31. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 31 Rayleigh Model of Defect Density (1) 2 t 2 -(t/c) 2 f(t) = ----- * ---- * e t c ( ) (1) Kahn, S. H., IBM Systems Journal, Vol. 30, #3 (1991)

32. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 32 Exponential Model of Defect Density

33. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 33 Strategies for Reducing Defects  Problem - process variation is too wide, resulting in too many cases that are outside the acceptable limits Unacceptable Quality

34. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 34 Strategy 1: Be More Robust (widen the road) Be robust enough to accommodate errors in incoming products -- for software, this means each process step should tolerate incoming defects (e.g., prototypes, etc.) -- it also means you should cultivate customers who tolerate lots of problems Widen the Road

35. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 35 Strategy 2: Produce fewer defects (narrow the car) Reduce defects -- for software, this means inspections, etc. to minimize defects in released software Narrow the Car

36. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 36 Combine Both of These to get Maximum Quality

37. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 37 At each step of the process...  You have more information than before  So you can update your estimates  And make proper management decisions You can also gain insight into process improvement if you tie actual data to models and try to understand what process problem caused you to be incorrect

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 38 As a Rule...  The general principles of management tend to be independent of discipline  But the measures tend to be discipline specific, especially those associated with product and process

39. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 39 Another Tendency The fundamental process problems tend to be organic  That is, they are built into the infrastructure and the culture  So you may need to make fundamental and politically unpopular changes in order to make things better  Sometimes only the need for survival is powerful enough to achieve this –“The competition is killing us because they do it differently”

40. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 40 Final Remarks on Improvement  Start small -- appraisals should result in small, doable improvements  Educate yourself - the more you know about many things the better off you will be  Look for process problems - working hard doing the wrong thing is wasteful, frustrating, and de-motivating -- but many people consider this “business as usual” because they don’t know any better

41. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M38 - Version 9.01 Process Re-engineering

42. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 42 The Concept of Process Reengineering  From time to time, it is necessary to reinvent the process  Motivation can come from: –intense competition –new technologies –new customers –new laws –other changes in the environment –realization that competition does it better –realization that you have not rethought the issues in a long time and may be stagnating

43. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 43 Changes Make Organizations and Processes Obsolete You define your organization to mirror or support a given environment. But environments change and changes can make organizations less effective.

44. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 44 Organizations Need Periodic Redesign or Reengineering “We’ve always done it this way and it works just fine”  Assess the environment  Rethink the processes  Reinstate the direct connections to –customers –suppliers –employees –etc.

45. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 45 Example 1 IBM Credit Approval Process  Before: Credit approval must go through six departments Each department takes 2-3 business days So credit approval takes 3 weeks Meanwhile, the competition is approving credit in 1 week! And we are losing sales because of this.

46. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 46 Wrong Solution IBM Credit Approval Process Each department must reduce its cycle time to 1 day Each department does this through incentives It is accomplished by –Rejecting faulty input (even slightly faulty) –Producing output that is often defective Result: Average Credit Approval takes 6 weeks! Greatly increased rework!

47. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 47 Re-engineered Solution IBM Credit Approval Process  One individual handles all six steps of each transaction  The six former departments become consultants, available to handle special cases but not involved in routine cases Credit approvals reduced to 1 week!

48. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 48 Example 2 Graphic Artist Group  Original Process: Need Graphic Artist Design Group: Assignment Dept G1 G2 G3 G4 G5 Design Graphic Artist Printing Group: Assignment Dept P1 P2 P3 P4 P5 Inspection Good Products Defective Products More defects are generated on the second cycle!

49. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 49 Reengineered Process for Graphic Artist Group  Improved Process: Need Assignment Dept G1 G2 G3 G4 G5 Design P1 P2 P3 P4 P5 Inspection Good Products Defective Products By tying a graphic designer to a printer for the whole job, defects were repaired quickly and good products had greatly reduced cycle time.

50. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 50 White Space A Fundamental Problem of Of Hierarchical Organizations Too many handoffs between departments, where there is no responsibility at the point of need, only much higher in the organization

51. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 51 Module Summary  Process Improvement requires knowing facts (data) and using good models  Continuous process improvement will remove the flaws of the process and improve results  Reengineering is necessary to adjust to changes in the environment that require more substantial process changes In the software business, change is relatively frequent and relatively significant Although some principles do not change

52. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M38 - Version 9.01 52 END OF MODULE 38

53. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M38 - Version 9.01 End of Course Thank you