1. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 SMU CSE 8314 Software Measurement and Quality Engineering Module 21 Productivity Improvement Part 2

2. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 2 Outline  Process simplification –Reducing rework –Making processes more consistent –(Value-added analysis - see module #9) >Flow analysis >Process re-engineering >Managing the white space

3. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 Flow Analysis

4. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 4 Flow Analysis Identifies Process Bottlenecks  Determine what people actually do throughout the entire software development cycle –what is their actual, day-to-day process?  Diagram the actual process flow –(not what you think it does - what it really does!)  Draw a flow chart or other diagram

5. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 Sample Process Flow Diagram START CHECK STATUS CORRECT ERROR COUNT? GO TO DEBUG STEP DEBUG ERRORS LOGOUT INSPECT MODULE OK? LOGOUT IS ERROR CORRECTION CORRECT? APPROVE LOGOUT FINISH DETERMINE WHY? REPEAT INSPECTION CORRECT ERROR CNT CORRECT THE ERROR NO YES NO YES FIND SW MODULE

6. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 6 Show Everything  Include all inputs, outputs, inspections, rework, temporary storage, set ups, etc. –everything that happens  Determine which components do not add value  Identify opportunities to eliminate waste and flow problems  Focus on non-essentials

7. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 7 Areas to Focus On  Procedures and methods –Are they working effectively? –Are they interfacing well with each other?  People –Are they using their time efficiently? –Are they spending too much time waiting between tasks?  Coordination - or lack of it … continued

8. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 8 More Areas to Focus On  Computers and Software –Are they available and effective? –Is too much time spent getting them to work?  Requirements/specifications/other inputs –Are they available when needed?  Queues and waits –Where is the excess WIP?

9. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 9 Identifying Queues and Waits þThink of yourself as the software product being developed. þTake yourself through the process. þAt what points are you just waiting, with no useful work being performed? þThese are bottlenecks, waits or queues that should be removed

10. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 10 Example - Eliminating Queues and Waits Problem: you take a long time to complete unit test because everyone needs the test system at the same time Analysis: the test system is a constraint Solution: optimize the constraint! I must have the test system today! But I must have it too!!

11. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 11 Some Options for Solution  Stagger development schedules to even out use of test system –costs more up-front planning –requires people to be flexible in their schedules  Obtain more test systems –costs more money –but may be worth it

12. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 12 Exercise - The Passing Game  Input: Six coins piled on the end of a long table, with six people lined up on one side of the table  Output: Six coins piled on the other end of the table  Goal: Shortest time / highest productivity Finish Start

13. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 13 Rules for The Passing Game  Each coin must be picked up before it is moved.  Each person must hold each coin for a minimum of 1 second -- if they do not, you get a penalty - the coin moves back to the starting point See how fast you can move the coins by coordinating and synchronizing your handoffs

14. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 14 Typical Results  First time - 22 seconds  After coordination of handoffs - 13 seconds

15. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 Re-engineering the Process

16. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 16  Organizations usually begin by designing themselves to fit the needs of the customer, the business environment and the available technology Organizations Optimize to Fit the Customer Organization Customer, Environment, Technology

17. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 17  After time, the organization no longer fits the customer and/or the available technology But Things Change Organization Customer, Environment, Technology

18. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 18 Process Re-engineering  Basic Idea: 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

19. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 19 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.

20. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 20 Organizations Need Periodic Redesign or Re-engineering “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.

21. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 21 Example 1 Credit Approval Process Before:  Credit approval must go through six departments  Each department takes 2-3 business days  So credit approval typically takes 3 weeks Meanwhile, the competition is approving credit in 1 week! And we are losing sales because of this. Meanwhile, the competition is approving credit in 1 week! And we are losing sales because of this.

22. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 22 Solution Credit Approval Process  Each department must increase productivity and reduce cycle time to 1 day per approval step  Each department does this through incentives (bonuses, rewards, etc.) Will this work? >If so, why? >If not, why not?

23. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 23 Wrong Solution! Credit Approval Process  Time is reduced by –Rejecting faulty input (even slightly faulty) –Hurrying the job, thus producing output that is often defective Result: Average credit approval takes 6 weeks! Greatly increased rework!

24. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 24  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 Re-engineered Solution Credit Approval Process Credit approvals reduced to 1 week!

25. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 25 Analysis  Changed the process  Changed the organization structure –Responsibilities –Authority  Changed the culture –What is important is serving the customer

26. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 26 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 Sample

27. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 27 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 Sample Motive for this approach: even workloads

28. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 28 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 Sample Bad samples are common on the first attempt due to the nature of the work.

29. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 29 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! Sample

30. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 30 Re-engineered 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 Sample

31. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 31 Re-engineered 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. Sample

32. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 32 Problem: there are many delays during software test because of requirements errors and changes –Rework to fix code to match new requirements Analysis: we didn’t have time to examine and rework the requirements earlier Example 3 Software Development Process Takes Too Long

33. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 33 Process changes: –ADD a requirements inspection –ADD time in the requirements phase to correct defective requirements –MODIFY the reward system to foster discovery of requirements defects during the requirements phase Improving the SW Process

34. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 34  Reduced total development time –Modest increment to requirements analysis schedule –Large reduction in debugging time  Reduced cost –The number of staff during requirements was smaller than the number during test –The amount of rework during the test phase was smaller so they saves money Results of Re-Engineering to Reduce Rework

35. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 35 Rethinking The Passing Game  Re-engineer the process  You must follow the rules  But examine the assumptions Hint: it can be done in under 2 seconds!

36. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 What Assumptions were Invalid? Why did we make them?

37. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 37 How Often do you Need to Re-engineer?  Re-engineering is disruptive, so you should not do it too often  Conditions that call for re-engineering: –Changed customer environment –Significant new technology –Significant new competitive circumstances –Need to make the process more efficient from the customer’s perspective –Significant new but different business opportunity

38. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 38 Examples of Successful Re-engineering  Federal express vs post office –Who would’ve thought that flying a package to Tennessee and back is faster than trucking it for 200 miles?  10 minute oil change vs car dealer –Someone realized that  Service stations seldom provide this service anymore  Car dealers set up for major repairs and their process is too slow to satisfy customers on small maintenance tasks

39. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 Managing the White Space

40. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 40 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

41. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 41 Managing the White Space  The “white space” represents all of the parts of your process that nobody is responsible for  Or where the responsibility is too far from the day to day process –handoffs between organizations or activities –changes in responsibility –etc.

42. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 42 The Classic “White Space” Situation 21 43 6 5 87 Organizational Hierarchy 8-step Process for Serving the Customer

43. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 43 The Classic “White Space” Problem 21 43 6 5 87 Who is responsible for this handoff? Organizational Hierarchy

44. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 44 The Classic “White Space” Problem 21 43 6 5 87 Organizational Hierarchy Who is responsible for this handoff?

45. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 45 How Do You Reduce the White Space?  Re-design the process to provide optimal flow to the customer –(minimize white space)  Re-design the organization to align responsibility directly with the process –(minimize mismatches) Consider the credit approval and graphic artist examples.

46. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 46 How Do You Manage the White Space?  Assign responsibility for interfaces –With authority equal to or greater than that of product development steps –This concept requires rethinking how we assign responsibility and authority  Assign overall responsibility for the entire process flow –At a level where day-to-day activity is visible

47. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 47 White Space Management Software Development Example Microsoft “integrate every day” strategy  Interfaces are defined early in the process and placed under change control  Mock-ups of the complete system are defined at the start of the project  Integration team has control over all interface changes  An integration test is run every day

48. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 48 Effect on Software Developer  Your module or function is not complete until it integrates with the rest of the system without introducing any problems  If your module fails this test, you must take it back and fix it

49. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 49 Effect on Software Process  Integration and test errors are minimized at the end of the process  The product can be “shipped” at any time after the major features are successfully integrated –Additional time, if any, allows for less important features –Features that don’t get done in time wait for the next release

50. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 50 Summary of This Module  Simplify the process –Reduce rework –Make processes more consistent –Analyze value-added >Analyze and optimize process flow >Periodically re-engineer the process >but not so often as to be disruptive >Manage the white space

51. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 51 References  Goldratt, Eliyahu M. & Jeff Cox, The Goal, (North River Press, 1984.) Also, Theory of Constraints and It’s Not Luck.  Gross and Harris, Fundamentals of Queueing Theory (Wiley).  Hammer, Michael & James Champy, Reengineering the Corporation, - A Manifesto for Business Revolution (Harper Collins, 1993.)  Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1-56327-043-9.

52. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 52 Additional References 1. Bartlett, Christopher A. and Sumantra Ghoshal, "Changing the Role of Top Management: Beyond Strategy to Purpose" Harvard Business Review, Nov-Dec 1994 (and Jan-Feb 95, May-Jun 95) 2. Beatty, Richard W. and David O. Ulrich, "Re-Energizing the Mature Organization" Organizational Dynamics, date unknown, sometime in 1991 or 1992 3. Belasco, James A., Teaching the Elephant to Dance - Empowering Change in Your Organization, Crown Publishers, 1990 4. Boynton, Andy and Bart Victor "Organizations and Change: A Consultant's View", from a presentation, date unknown, probably Oct 1992 5. Duck, Jeanie Daniel: “Managing Change: The Art of Balancing” Harvard Business Review, Nov-Dec 1993 6. Deming, W. Edwards, Out of the Crisis, MIT, 1982 7. Fiman, Byron: “Accelerating Change” by Implementation Management Associates, Inc, presented by Byron Fiman

53. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 53 Additional References 8. Frey, Robert, "Empowerment or Else" Harvard Business Review, Sep-Oct 1993 9. Hall, Gene, Jim Rosenthal, and Judy Wade, “How to Make Reengineering Really Work” Harvard Business Review, Nov-Dec 1993 10. Kotter, John P., “Leading Change: Why Transformation Efforts Fail” Harvard Business Review, Mar-Apr 1995 (reprint # 95204) 11. Peters, Tom, “The Tom Peters Seminar - Crazy Times Call for Crazy Organizations” 1994 12. Stevenson, Wayne, President and CEO of Control Systems International, from a lecture in Jan 1995 13. Tichy, Noel M. and David O. Ulrich, "The Leadership Challenge - A Call for the Transformational Leader" Sloan Management Review, Massachusetts Institute of Technology, Fall 1984, Volume 26, Number 1

54. Copyright 1995-2007, Dennis J. Frailey CSE8314 - Software Measurement and Quality Engineering CSE8314 M21 - Version 7.09 54 END OF MODULE 21