Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Otto Vinter - Analysing Your Defect Data for Improvement Potential

Otto Vinter - Analysing Your Defect Data for Improvement Potential

Ratings: (0)|Views: 3 |Likes:
Published by Andries Poepjes

More info:

Published by: Andries Poepjes on Feb 26, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/18/2014

pdf

text

original

 
Otto Vinter
Software Engineering Mentor
 Otto Vinter Email: vinter@inet.uni2.dk Tel/Fax: +45 4399 2662Sthensvej 2F Web site: www.vinter.suite.dk Mobile Tel: +45 4045 0771DK-2630 Taastrup Skype name: otto.vinter CVR nr (VAT): DK 17 58 96 44
 Analysing Your Defect Data for Improvement Potential
Otto Vinter
Software Engineering Mentor,DK-2630 Taastrup, Denmark Email: vinter@inet.uni2.dk www.vinter.suite.dk 
Introduction
Why is it that we seem to make the same mistakes over and over aga
in? It can’t be that we don’t
want to know why
 —that we don’t want to find ways to prevent our mistakes, and ultimately to
improve the quality of our products. Surely we do.Analysis of defect data from previous projects, for example, tells us about our most frequenterrors, and can help us improve. But very few companies take the time to analyse theirexperience data and learn from them.In this paper I will explain
how you can organise and perform an analysis of your company’s
defects in a cost-effective way. The defect analysis process presented uses problem reports frompast projects to help experienced process consultants identify specific, frequently occurringproblems. Defect analysis puts you in a better position to determine how problems might beprevented, and thus serves to implement focused improvement actions.
 
I have practical evidence from a number of real-life projects that defect analysis is a simple and
effective approach that can solve major problems in a company’s software development pr 
ocessand give real benefits to the company.
Defect Analysis Models
Basically, there are two different models you can apply to defect analysis: You can pursuedefect analysis by means of quantitative mathematical models, or you can do it by qualitativemeans.
 
Otto Vinter
Software Engineering Mentor
 Otto Vinter Email: vinter@inet.uni2.dk Tel/Fax: +45 4399 2662Sthensvej 2F Web site: www.vinter.suite.dk Mobile Tel: +45 4045 0771DK-2630 Taastrup Skype name: otto.vinter CVR nr (VAT): DK 17 58 96 44
The quantitative, mathematical approach
The advantages of a quantitative approach are that you can perform:
 
quantitative analysis on the data
 
statistical analysis and regression
 
growth curve modelling
 
comparison to historical dataHowever, a quantitative approach is not easily translatable to corrective action, which is whatyou ultimately want from an analysis of defect. It is not enough just to know that things look acertain way (usually bad), you must to be able to propose improvement actions to yourmanagement.Furthermore mathematical models often fail to predict because:
 
low-level maturity processes are the norm in companies
 
software development is not a production process
 
personal and team issues dominate
The qualitative, causal approach
The advantages of a qualitative approach are that you can:
 
perform causal analysis (root cause)
 
investigate details of a sample of defects
 
have flexibility on what will be analysed
 
translate the results easily to specific improvement actionsFurthermore a causal analysis often works because it:
 
focuses on prevention
 
addresses individual and team issues
 
enables feed-back, education, and motivation
 
promotes a needs based, bottom-up process improvementHowever, a qualitative approach is time consuming and may be difficult to aggregate acrossdifferent types of teams and projects. Because time is money, management often turns awayfrom this approach or puts severe restrictions the use of people and time.
Defect Classifications
Many different defect classifications exist and with widely varying scopes. But for the most partthey are simple ad-hoc check lists developed internally by the process or quality group in thecompany and therefore of little use for large scale defect analyses.There are, however, two prominent defect classifications, which also represent two differentpurposes of defect analysis: You can either perform defect analysis on-the-fly during theexecution of a project, with the purpose of changing the course of the current project; or as aretrospective activity when a project has completed, with the purpose of changing the
team’s
development processes, before the team embarks on the next project.
 
Otto Vinter
Software Engineering Mentor
 Otto Vinter Email: vinter@inet.uni2.dk Tel/Fax: +45 4399 2662Sthensvej 2F Web site: www.vinter.suite.dk Mobile Tel: +45 4045 0771DK-2630 Taastrup Skype name: otto.vinter CVR nr (VAT): DK 17 58 96 44
Orthogonal Defect Classification - ODC
ODC was originally developed by Ram Chillarege et al. at IBM. It has the followingcharacteristics:
 
Tracks projects on-the-fly
 
Separates classification and analysis (performed by different people)
 
Fixed and limited taxonomy
 
No qualitative information is collected during classificationYou can find more information on ODC from the following web sites:www.research.ibm.com/softeng/ODC/ODC.HTM,and www.chillarege.com/odc. 
Boris Beizer’s Bug Taxonomy
 
Boris Beizer originally developed a taxonomy based on a large amount of defects from manysources. He calls them bugs, and therefore I use the same term when I use the taxonomy. I haveintegrated his taxonomy in a defect analysis process, which has the following characteristics:
 
Retrospective defect analysis
 
Combined classification and analysis (performed by the same people)
 
Extensive and expandable taxonomy
 
Qualitative information can be collected during classificationYou can find the taxonomy and Bori
s Beizer’s statistics in his book 
1
or find my amendedversion of the taxonomy and both his and my statistics at: www.vinter.suite.dk/bugtaxst.doc. 
The Proposed Defect Analysis Approach
I propose that you perform defect analysis as a retrospective activity either on a regular basis atthe completion of projects, or as a stand-alone assessment of the development process. In thelatter case, retrospective defect analysis can also be used to measure the change between beforeand after improvements are introduced. Used systematically by a company, it can turn into amodel for experience-driven incremental software process improvement.
8
 Furthermore, I propose that you perform defect analysis based on the qualitative approach,because it directly pinpoints which improvement actions should be suggested to management.However, you should always include whatever quantitative data are available in theorganisation.
Retrospective Defect Analysis Steps
A retrospective defect analysis is a cooperative effort between consultants with deep knowledgeabout process issues, and developers who possess inside knowledge about the issues raised inthe problem reports.

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->