1 / 39

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 15 Six Sigma and Zero Defects - Overview. Contents. Zero Defects Overview Six Sigma Overview Summary. Zero Defects and Six Sigma. General Concepts. Zero Defects and Six Sigma.

morley
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 15 Six Sigma and Zero Defects - Overview

  2. Contents • Zero Defects Overview • Six Sigma Overview • Summary

  3. Zero Defects and Six Sigma General Concepts

  4. Zero Defects and Six Sigma • Each of these is a measure of quality • And also a set of principles and concepts that can be used to establish a program for quality improvement

  5. Goals A measure of quality that can be applied to anything you produce and that will result in unmatched quality across the board • Dimensionless • Fosters & motivates quality improvement • Provides insight into the quality improvement process • Correlates to our innate sense of quality

  6. Zero Defects See Schulmeyer in reference list

  7. Zero Defects is a Stretch Goal Stretch Goal No defects in delivered products Expectation Number of defects will diminish • (asymptotically approach zero) Average Defects per Product time

  8. Many quit about here Experience with Zero Defects

  9. Another Experience withZero Defects

  10. How Do You Know How Well You Are Doing Relative to What Is Possible? • The “Zero Defects” measure is not directly related to “degree of goodness” or “degree of quality” or “what is possible” • It only measures defects on an absolute scale

  11. How Do You Correlate the Defect Rate to What is Possible or to Relative Cost? • What is needed for some products is not needed for others -- you need to know what the customer requires

  12. How Many Products Must Be Defect Free? • 99% • would mean 1 typo per 100 words of course notes which is fairly good • but --- 200,000 wrong drug prescriptions per year - very bad • 99.9% • 1 typo per page - good • 500 surgical errors per week • 99.99% • 2000 mail delivery errors per hour

  13. What about Variance? • Average product vs worst case product • Which one matters more? • Is it better to have an average product with .3 defects or to have a worst case product with 2 defects? • In its simplest form, “zero defects” does not tell us the answer to this kind of question

  14. Other Problems with Zero Defect Programs • How do you gain insight into the nature of the problems? • The measure says nothing about the causes of the defects or how to cure them • How do you justify continuous improvements in defect removal? • There is no good way to know if you can justify the cost

  15. Six Sigma

  16. Premise of Six Sigma Programs • You use a process to produce something • The process can vary as well as the product • Average number of defects is not an acceptable measure . . . • You need to understand the worst case and why it happens • You need to control process variance as well as defects

  17. 3) Production Process (Inputs) (Outputs) 1) Design 2) Materials Products Product Quality Depends on: 1) The design of the product 2) The materials used to construct it 3) The process used to produce it

  18. Applying to Software • For software, the product is essentially a design! • So the three factors become: • Inputs: 1) The architecture of the software 2) The requirements of the software • Process: 3) The software development process

  19. 3) Development Process (Inputs) (Outputs) 1) Architecture 2) Requirements Software Software Quality Depends on: 1) The architecture of the software 2) The requirements used to construct it 3) The process used to develop it

  20. Basic Units ofSix Sigma Programs • Opportunity • Any step of the process, type of material, or design element that can cause a defect • Defect • Anything wrong with the product • Defects per million opportunities (DPMO) • This is the basic measure of quality

  21. DPMO = Number of Defects * 106 Number of Opportunities DPMO DPMO • Defects are problems with the product • Opportunities are steps in the process, materials, or design elements where you can make a mistake

  22. To Improve Quality • Decrease the number of defects or • Increase the number of opportunities? A common mistake when first learning about six sigma concepts is to assume that increasing opportunities is a good thing. In fact, it is a bad thing.

  23. Uses and Abuses of DPMO • Count opportunities in such a way as to inflate the number, so that DPMO goes down. • Make the process more complex so as to increase the number of opportunities • Correct the process to reduce defects • Simplify the process so that opportunities go down and total defects go down as well

  24. Software Defects & Opportunities • A defect is a failure to meet requirements • An opportunity is a process step, architecture element, or requirement where a defect could originate • In a complex product like software, it is very hard to determine all of the opportunities

  25. Characteristics of an Opportunity • Independent from other opportunities • Constant total number for the product/process if there is no change in the process • Consistent measuring method is more important than exact definition The real objective is to measure & improve, not to count opportunities perfectly.

  26. Software Opportunities • One shortcut measure of opportunities is lines of code (if you measure size in lines of code) • Another might be steps of the process, if your process description is very detailed down to the individual work step Do NOT get overly concerned about the definition of an opportunity or defect

  27. Goals • This goal is derived from a specific analysis of processes and has specific rationale behind it • Details in later slides and modules • Other goals (more or less aggressive) can be established, based on understanding the rationale 6 Sigma goal: DPMO < 3.4

  28. 3) Production Process (Inputs) (Outputs) 1) Design 2) Materials Products Techniques to Achieve 6 Sigma 1) Design the product for producability 2) Improve the quality of the materials 3) Design the process to produce quality products

  29. 3) Development Process (Inputs) (Outputs) 1) Architecture 2) Requirements Software Techniques to Achieve 6 Sigma Quality for Software 1) Architect the software for ease of development and maintenance 2) Improve the quality of the requirements 3) Design the development processto produce quality software

  30. Process Analysis forManufactured Products • Each product or raw material has certain measurable characteristics • Example: a bolt could be measured in terms of: • Length • Diameter • Spacing of threads • Diameter of head • Weight • Strength of material under specific conditions

  31. For Each Measurable PropertyYou Establish Specifications Example: “Diameter should be 0.4 inches, plus or minus .002 inches” • Notice that there are two components: • A target value • specification • A range of values that are acceptable • specification limits

  32. Responsibility of Designer • Specify tolerances • Design products with reasonable tolerances relative to the manufacturing capability • Create designs that can be produced within the stated tolerances

  33. Responsibility of Software Architect • Specify bounds of acceptable software behavior • Architect software with reasonable tolerances relative to the design and programming capabilities of the staff • Create software architectures that can be produced and maintained

  34. 1 2 3 4 5 SEI Claim As you increase maturity level, the cost and schedule decrease and the variance goes down

  35. Problems with Software and Sigma • Software generally has low product volume compared with manufactured products • But what if we measure units, tests, objects, screens, functions, etc? • Software development process has very high variance • Does it need to? • Is that necessarily bad?

  36. Problems with Software (continued) • We don’t have the statistical data to back up applying these techniques • But maybe that does not matter if the ideas for improvement still apply • NIH (Not Invented Here)

  37. Summary • Six Sigma and Zero Defects programs involve • Measures of quality, such as • Goals that minimize quality problems • Methods of quality improvement • Six Sigma focuses on variability as well as overall quality The next module will cover six sigma principles and applications.

  38. References • Harry, Mikel J. and J. Ronald Lawson,Six Sigma Producibility Analysis and Process Characterization, Motorola University Press, Addison-Wesley, ISBN 0-201-63412-0 • Schulmeyer, G. Gordon. Zero Defect Software. McGraw Hill, 1990. ISBN 0-07-055663-6. • Schulmeyer, G. Gordon and James McManus. Handbook of Software Quality Assurance, Second Edition (especially chapter 17). Van Nostrand Reinhold, New York, 1992. ISBN 0-442-00796-5.

  39. END OF MODULE 15

More Related