35
Chapter 15 Projecting Defec ts( 缺缺缺缺 )

Chapter 15 Projecting Defects( 缺陷预测 ). 山东大学齐鲁软件学院 2 outline Analyze and use your defect data to help improve both planning accuracy and product quality

Embed Size (px)

Citation preview

  • Slide 1
  • Chapter 15 Projecting Defects( )
  • Slide 2
  • 2 outline Analyze and use your defect data to help improve both planning accuracy and product quality. Determine how best to prevent or find the defects you inject. Control the quality of your work.
  • Slide 3
  • 3 Defect rates Defect injection rate typically range from about 50~250 defects per KLOC. With Figure15.1 & 15.2 shown: Defect density as a function of the years. Some quality practices learn with experience. defect levels are largely a matter of personal discipline. After PSP training, engineers understood the numbers and types of defects. And then reduced their total defect injection rates.
  • Slide 4
  • 4 Defect rates number are big! Defect injection is a natural consequence of being human. Average 100 defects/KLOC About 50 defects/KLOC after PSP training. So there are 50,000 defects in a 1,000,000 LOC program. All of them must be found and fixed before delivery.
  • Slide 5
  • 5 Using defect data Gather defects data---help understanding the defects you inject to your program. Design a personal checklist---for code reviewing to remove defects. Establish a code standard---help to prevent defects injected in coding. Then whats our next step? whats our final goal?
  • Slide 6
  • 6 Using Defect Data Task: Using historical defect data to make a reasonably good projections of the number of defects you will inject and remove in each phase of a programming project. Advantage: By accurate estimates of defect levels, you can determine the likely quality of the program being developed. Then you can decide whether additional defect-removal steps are needed. The final goal---defect-free programming, can not be achieved only by estimate, it should be approached by systematic work and step by step. Defects collect, Defect remove and prevent---code review and code standard, Defect estimate. Someday you will likely work on a project where defect-free work is essential!
  • Slide 7
  • 7 Defect density Defect density(Dd): the defects per thousand lines of code, measured by defects/KLOC. Add up the total numbers of defects found. Count the number of new and changed LOC Calculate the defects per KLOC Be sure not include library routine and copy part in counting LOC.
  • Slide 8
  • 8 The calculation of Dd Add up the total number of defects(D) found in all phases of the process, Count the number(N) of new and changed LOC in the program, Calculate the defects per KLOC as Dd = 1000*D/N. For example, a 96 LOC program had a total 14 defects, then Dd = 1000*14/96 = 145.83 defects/KLOC.
  • Slide 9
  • 9 Projecting Defects Projecting defects and then finally we achieve that we have ability to write a defect-free program Then how to project defects in your program? Plan Time Plan project schedule Then can defects be planned?
  • Slide 10
  • 10 Difficulties of Projecting Defects Rates Without experiences Not be sure how some function or procedures works Confused by language construct Encounter new compiler or new programming enviroments Solution: Make more practices, to improve your skills and enrich your experience of programming Gather and analyze defects data to continue improving.
  • Slide 11
  • 11 Difficulties of Projecting Defects Rates The process is not stable The process is a new method and procedure to you, defects injected, defects fix time are all fluctuating, especially defects fix may inject defect again. Solution: Improve the process by spending sufficient time on code reviewing to settle down the process.
  • Slide 12
  • 12 Defect estimation Using data of previously developed programs to calculate the D plan Dd plan = 1000*(D 1 +D 2 ++D i )/(N 1 +N 2 ++N i ) D plan = N plan *Dd plan /1000 or D plan = N plan *D to date /N to date. The calculation of expected number of defects to be injected and removed in each phase. D phase = D planned total *D to date % /100.
  • Slide 13
  • 13 The updated project plan summary form and example By using the project plan summary of a most previously developed program, make time plan and defect plan first. Then by actual data, to complete the project plan summary for the new developed program. Calculate the plan data Calculate the To Date data Entering the actual data
  • Slide 14
  • 14 project plan summary
  • Slide 15
  • 15 project plan summary
  • Slide 16
  • 16 project plan summary
  • Slide 17
  • 17 summary Defect density. Estimate defects injected.
  • Slide 18
  • 18 Assignment For the next program you write: Determine the defects/KLOC rate and estimate the defects to be injected and removed by phase. Inter these data in project plan summary.
  • Slide 19
  • Chapter 16 The Economics of Defect Removal
  • Slide 20
  • 20 outline Its trade-offs ( )between cost, schedule and quality; It concerns three aspects: The relative costs of removing defects during development; The impact of any remaining defects on the customer; The resulting customer support costs. Hence, its a trade-off of risk and benefit.
  • Slide 21
  • 21 The need for quality work Defect-free software: no extra costs for defect removal, no risk for potential costs. But its always a final goal since the beginning of software development. Defect removal costs a lot, especially in later phase. Defect removal lowers benefit explicitly sometimes. Defect removal does not bring benefit, but it can lower risk implied by remaining defects.
  • Slide 22
  • 22 Defect-Removal problem Defect-Removal is a software size and complexity related work. The size and complexity of software system has increased ten times every ten years. Laser printer driver: 20, 000 LOC - --1 million LOC; More and more application, more and more complex;
  • Slide 23
  • 23 Measurement of defect-removal Measure defect-removal effectiveness Defect-Removal Rate: number of defects removed in one hour. Defect-Removal Yield( ): Percentage of the defects found by a removal method.
  • Slide 24
  • 24 Defect-Removal Time Defect types Requirement defect; Design defect; Coding injected defects Defect-removal moment Code reviewing; Compiling; Testing: Unit test and integrated test. Varying from several minutes to several days 250 engineers spent a full year on Microsoft NT system test finding and fixing 30,000 defects. This averages 16 hours per defect.
  • Slide 25
  • 25 Defect injection and defect removal experience The factors which affect the cost of defect- removal Defect injection; Defect removal experience Figure 16.1 shows that bigger defect injection rate is made in coding than in design. Figure 16.2 demonstrates that defect- removal in testing, code reviewing and compile, and in the phase of code reviewing, one can find more defects than in testing phase.
  • Slide 26
  • 26 Defect Removal Savings Compare the results of defect- removal with or without PSP. See table 16.1 in Page 214. With PSP, software engineers have a great time savings. With PSP, software product has less remaining defects (risks).
  • Slide 27
  • 27 Defects/Hour on the PSP project plan summary Comparison of defect injection/ removal rates of different phase Def./Hour = 60*(To date defects injected/removed in one phase)/(To date Time in one phase (Min)). See example in table 16.2 in page 216
  • Slide 28
  • 28 Yield of defect removing Def. Removed/Hour: Defects found rate in one phase Also we would like to know how many defects were found and how many were missed in one defects removing phase--- Yield Moreover, Process Yield = the percentage of the defects found before the first compile and test. That is the percentage of the defects found in review phases (code review and design review), the percentage of the defects found initiatively , not passively .
  • Slide 29
  • 29 Yield Calculation Yield plan Yield actual Yield To Date Yield = 100*(Defects removed before compile)/(Defects injected before compile). See example of calculation in table 16.2
  • Slide 30
  • 30 Improving Defect- Removal Rates Focus on yield first. First objective must be to consistently achieve yields of 70% or more. Do the code review before the first compile, and use the compiler to check the quality of your coding review. Prone your code review checklist to improve your defect removal rates. One definition of insanity is doing the same thing over and over and expecting a different result [Brown].
  • Slide 31
  • 31 Improving Defect- Removal Rates gathering defects data Calculating yield and defect-injection and defect-removal rates Track these data in your programming practices. One Objective of this doings: Making you conscious of the costs and consequences of defects, and then do the code review initiatively and efficiently.
  • Slide 32
  • 32 Reducing Defect- Injected Rates Record all your defects. Be aware of defects, you will work more carefully and will reduce the number of defects of defects you inject. Produce better design Design process runs on the high level, more logically than coding, thus one makes less defects within the same time in design than in coding phase. A complete and better-documented design will prevent defects injection in coding phase. Frame guided Save coding time
  • Slide 33
  • 33 Reducing Defect- Injected Rates Use better methods. Objected oriented method UML (Unified modeling language) and use case Consistent coding convention. Use better tools Integrated programming environment Visual interface of programming.
  • Slide 34
  • 34 Summary Defects are a principal cause of software problems. The remaining defects may lead severe consequences. Defect fixing costs money and delays project schedules, and the defect fix times are unpredictable. So defect management is a economic issue. Therefore, we need capture the key points in defects removing, improve defect removal rates and yield. On the other hand, we need to reduce the defects injection rate by using better design, methods and tools.
  • Slide 35
  • 35 Two measurements Defects/Hour Yield