1 / 56

SMU CSE 8314 / NTU SE 762-N Software Measurement and Quality Engineering

SMU CSE 8314 / NTU SE 762-N Software Measurement and Quality Engineering. Module 19 Cycle Time Reduction Part 2. Outline. Variability Experiment Definitions, Terms and Concepts Solutions to Cycle Time Problems Reducing Variability Reducing Work in Process Observations and Caveats.

Télécharger la présentation

SMU CSE 8314 / NTU SE 762-N Software Measurement and Quality Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SMU CSE 8314 / NTU SE 762-NSoftware Measurement and Quality Engineering Module 19 Cycle Time Reduction Part 2

  2. Outline • Variability Experiment • Definitions, Terms and Concepts • Solutions to Cycle Time Problems • Reducing Variability • Reducing Work in Process • Observations and Caveats

  3. Variability Experiment

  4. Variability Experiment • Line up 5 tokens, like a train • Each turn, move tokens right • See rules on a later slide • How many turns does it take to move the leftmost token 15 positions? Rules: • Round 1 will have low variability • Round 2 will have high variability • Round 3 will have high variability but higher capacity

  5. Token Setup for Experiment  o o o o ... Round 1  o o o o … Round 2  o o o o … Round 3 ^ ^ ^ Left Token Right Token Positions to Move to You may execute the rounds sequentially or in parallel.

  6. Round 1 Rules • Each turn, move each token 3 places, starting with the one on the right (3 places right, per turn) • Result of first turn: o o o  o o o … • Result of second turn: o o o o o o  ... How many turns does it take for the leftmost token to move 16 places to the right?

  7. Round 2 Rules • Each turn, move each token n places, starting with the one on the right, where n is a number from 1 to 5 determined randomly by rolling a die -6’s don’t count. • Roll the die separately for each token • A token cannot move past another • Note that the average move is 3 places • Possible result from first turn o o o o  o o …

  8. Round 3 Rules • Each turn, move each token n places, starting with the one on the right, where n is a number from 1 to 6 determined randomly by rolling a die -6’s do count. • Roll the die separately for each token • A token cannot move past another • Note that the average move is 3 1/2 • Possible result from first turn o o o o o  o …

  9. Why Variability Results in Longer Cycle Time • Slower tokens block faster ones • If you have a low roll on the die you cannot take advantage of opportunities to “catch up” • Even with higher average capacity (round 3), variability results in slower cycle time

  10. Definitions, Terms andConcepts The next few slides address some basic cycle time terminology

  11. Cycle Time is ... The time required to execute all activities in a process • This could be: • First operation to ship • A single operation • A group of operations • Customer order to product delivery • Cycle time includes actual processing time …… and all waiting time • Consider a “10 minute” oil change

  12. Lead Time is ... The maximum time the customer will wait between order placement and product delivery. • What is: • Your customer’s lead time? • Your potential customer’s lead time? How long will it take? Here’s my order!

  13. Cycle Time vs Lead Time • To be competitive, you must make: Cycle Time < Lead Time • Otherwise, you lose business • Or else orders have to be started on speculation, which means higher risk of rework or failing to satisfy the customer

  14. Throughput is ... The number of products produced per unit of time • This could be: • Modules tested per day • Components produced per week • Defects corrected per month • etc. • Throughput is a measure of the output of a process

  15. CT1 + CT2 + CT3 + CT4 +...+ CTn Cycle Time = n How to Measure Cycle Time? Static Cycle Time The average of the actual cycle times (CT) experienced by some number (n) of products

  16. Using This Measure • This can be used to measure cycle time for many situations • For example, measure the cycle times of the tokens in the variability experiment • Or measure the cycle times for cars being serviced in a “10 minute oil change” station • But this is not always easy to measure when many of the products are only partway through the process • So we need a dynamic measure

  17. Cycle Time = WIP (products being developed) THROUGHPUT A Measure to Use when Static Cycle Time is Not Convenient Dynamic Cycle Time The total work in process (WIP) divided by the throughput of the process This equation can be shown from queueing theory. See Gross and Harris, in reference list, p83.

  18. Revised Variability Experiment • Take 5 turns for each round • Measure the total number of tokens that reach the 16th position • After 5 turns, measure WIP • Also measure throughput, cycle time, etc (see next slide) Think of this as a 15 step process, with the tokens being work going through the process

  19. Solution Record forVariability Experiment

  20. Solutions to Cycle Time Problems

  21. What Makes Cycle Time High? • Inventory or work in process (WIP) • Higher overhead, longer delays • Process flow variability • Excessive waiting and long queues • Complexity of processes • Redundant and unnecessary steps These are all related to each other

  22. 3 Steps to Cycle Time Improvement • Reduce variability • Simplify the process • Reduce WIP This order is recommended Due to time limitations, we will only address the first and third of these in this module. Process simplification will be addressed in the next module

  23. Reducing Variability

  24. 1 2 3 4 LSL USL LSL USL LSL USL LSL USL Variability Increases Cycle Time OUTPUT FROM FOUR DIFFERENT PROGRAMMING SHOPS If price and delivery were equal, which supplier would you buy a product from?

  25. Sources of Variability • Movement of programs or documents between workstations or systems • Machines or software not being available • Hot lots / priority tasks that disrupt normal activity • Software defects that require rework and debugging • Special cases that require holds and delays • Inconsistent processes and procedures • Excessive approval requirements • Hundreds more...

  26. Expediting via Priority Tasks • The tendency is to establish many levels of priorities • Hot • Super hot • Immediate • Per the boss • Pressure exists to raise the number of priority tasks • The list always grows

  27. Other Problems Resulting from Priority Tasks • Managing priorities consumes many resources • And it delays other jobs

  28. Cycle Time Multiplier for Non-Expedited Jobs 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Percent expedited Expediting vs Cycle Time • When we expedite a product, other products are delayed • In some cases, each product waits until it is expedited before it moves at all

  29. EXPEDITED LOTS DELINQUENT LOTS NUMBER OF SHIPMENTS 7 14 21 28 CYCLE TIME (DAYS) Variability Management Must Minimize Expediting BAU With managed priorities, you improve the normal case and reduce the need for “priority jobs” NUMBER OF SHIPMENTS 7 14 21 28 CYCLE TIME (DAYS)

  30. A Strategy for Managing Priorities • Allow only two priorities • Hot • Not hot • Control the maximum percentage of “hot” (less than 8% to 10%) • If you add a hot job, you must subtract another • This requires discipline (and faith that it works!)

  31. Further Management of Priorities • Monitor distribution throughout the process • Do not plug up one operation or individual with priority tasks • Monitor frequently • Remove tasks from the priority list when they don’t really need priority

  32. Cycle Time, Utilization and Variability WIP or CYCLE TIME 100% EFFECTIVE UTILIZATION

  33. WIP or CYCLE TIME SOME VARIABILITY 100% EFFECTIVE UTILIZATION Higher Utilization Increases Cycle Time

  34. Variability Affects the Extent of the Added Delay WIP or CYCLE TIME SOME VARIABILITY NO VARIABILITY 100% EFFECTIVE UTILIZATION

  35. Variability Reduction Opportunities Variability Low High WIP or CYCLE TIME Output Opportunity Cycle Time Opportunity EFFECTIVE UTILIZATION OR THROUGHPUT

  36. ReducingWork in Process (WIP)

  37. WIP Dynamic Cycle Time = THROUGHPUT High WIP = High Cycle Time • Any intermediate work in the system is WIP. • Anything that is not being actively processed is excessive WIP. For related background, see Gross and Harris, in reference list, p83.

  38. Examples of Excessive WIP for Software • Code waiting to be tested • Designs waiting to be coded • Specifications waiting to be inspected • Change requests waiting for approval • Hundreds more...

  39. Smooth Flow - Ideal Process • The ideal process flows smoothly, like a train running on tracks. Note: tracks are empty most of the time

  40. Uneven Flow - Typical Process • The typical process runs unevenly, like vehicles on a city street • Lots of exits and entrances • Vehicles of varying sizes and speeds • Some drivers uncertain of what they want to do • Lots of stoplights to “control” the flow (mainly to prevent collisions) Note: streets are usually crowded - with WIP!

  41. Techniques for ObtainingSmoother Flow • Identify bottlenecks and constraints -- and manage/optimize them • Utilize pull systems instead of push systems • “Conduct the orchestra” (keep everyone going at the same speed) • Flow management systems • .....

  42. Observations and Caveats

  43. Too Much Measurement! • The tendency is to measure too much and in too much detail • Rough estimates usually identify the biggest problems and opportunities

  44. Some of The Problems &Solutions are Technical • 30% of the improvement comes from technical changes • Process changes • Tool changes • Changing rules and operations

  45. Most of The Problems &Solutions are Not Technical • 70% of the improvement comes from organizational and people changes, such as • Education • Communication • Management • Teamwork

  46. Independent Observers See Problems and Opportunities the Best • Practitioners generally focus on their work and on what they THINK is happening rather than on what IS happening • They tend not to see all of the waits, queues, etc. that they cause themselves • Their perception of how they spend their time is generally incorrect • They are too busy getting the job done to see how they might improve it

  47. The Athletic Coach Analogy • Just as athletes rely on coaches, software engineers need to learn to trust in others to observe and help them do better

  48. Software Developers areAccustomed toImproving Cycle Time • Think of your software development process as a large computer program that runs too slow. • How would you make it run faster? • Imagine how you would speed up a computer program . . . . . . . . • Then draw analogies to the software development process

  49. Improve the Process the way you would Speed Up a Program Code Speed-up • Faster hardware • Better algorithm • Optimizing compiler • Remove code from inner loops • Optimize code • ….. Process Speed-up • Faster hardware • Better process • Eliminate waste • Remove redundant steps • Eliminate wasteful meetings and approvals • …..

  50. CycleTimeBonus It generally turns out that improved cycle time produces lower costs and higher quality as well! You don’t pay for the steps you don’t do • Fewer steps means fewer opportunities to introduce defects • Shorter cycles means less time to change requirements • Shorter cycles means more time to iterate designs or benefit from cycles of learning

More Related