A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> This paper describes two common approaches to measuring and modeling software quality across the project life cycle so that it can be made visible to management. It discusses examples of their application in real industry settings. Both of the examples presented come from CMM Level 4 organizations. <s> BIB001 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> Most large software products have elaborate quality control processes involving many tasks performed by different groups using a variety of techniques. The defects found are generally recorded in a database which is used for tracking and prioritizing defects. However, this defect data also provides a wealth of information which can be analyzed for improving the process. In this paper, we describe the when-who-how approach for analyzing defect data to gain a better understanding of the quality control process and identify improvement opportunities. At the component level, the analysis provides the capability to assess strength of dependency between components, and new ways to study correlation between early and late defects. We also discuss the experience of applying this approach to defect data from an earlier version of Windows, and the improvement opportunities it revealed. <s> BIB002 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> "Learning from the past" to make systems more efficient in terms of cost and time is the hallmark of any engineering discipline. Prevention of defects is the "holy grail" of "learning's from the past" i.e. every product generation we learn from our defects and prevent it from recurring in the next generation. Taking this philosophy further "capturing defects in the earlier stage of the life cycle" is a means of preventing defects in the later stages of the product life cycle. Correction of defects is costly and the cost increases exponentially with every subsequent stage. This also impacts the cycle-time directly. Defect prevention then not only helps in cost reduction but also helps in cutting down the development time. When we talk of software development, we are talking of hundreds of defects (in-process as well as post release). It would be very inefficient and time-consuming to have preventive action planning for each of them, as most of them could be symptoms of some common root cause. If we have to handle software defects of such large magnitude the best way then would be to classify them into patterns and then do root cause analysis on those patterns. There are number of methodologies available in the industry to do this classification and IBM's ODC (Orthogonal defect classification) is one such methodology. The methodology classifies each defect into orthogonal (mutually exclusive) attributes some technical and some managerial. These attributes provide all the information to be able to sift through the enormous volume of data and arrive at patterns on which root-cause analysis can be done. This coupled with good action planning and tracking can achieve high degree of defect reduction and cross learning. The questions always then are -- can methodologies be really applied to do software defect prevention in a structured way? How can an abstract defect classification mechanism really help to identify patterns? How does one measure the effectiveness of such actions? Who should do these activities? How does all this fit into the existing process framework? This paper is an attempt to answer these questions by sharing the experiences of using the IBM-ODC methodology in a case study of real-life software development project (DVD player product). The motivation of this paper is not to discuss the ODC methodology itself but rather to demonstrate through a case study, the structured process for defect prevention using some attributes of ODC for defect classification and its related interpretations for causal analysis, action planning and results tracking. The fitments of the scheme into the bigger picture of defect prevention, cross learning and mapping to elements of the SEI-CMMI framework are some of the highlights of this paper. The paper concludes with a summary of learning's and some points to ponder. <s> BIB003 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> Defect prevention is the most vital but habitually neglected facet of software quality assurance in any project. If functional at all stages of software development, it can condense the time, overheads and wherewithal entailed to engineer a high quality product. The key challenge of an IT industry is to engineer a software product with minimum post deployment defects. This effort is an analysis based on data obtained for five selected projects from leading software companies of varying software production competence. The main aim of this paper is to provide information on various methods and practices supporting defect detection and prevention leading to thriving software generation. The defect prevention technique unearths 99% of defects. Inspection is found to be an essential technique in generating ideal software generation in factories through enhanced methodologies of abetted and unaided inspection schedules. On an average 13 % to 15% of inspection and 25% 30% of testing out of whole project effort time is required for 99% 99.75% of defect elimination. A comparison of the end results for the five selected projects between the companies is also brought about throwing light on the possibility of a particular company to position itself with an appropriate complementary ratio of inspection testing. Keywords—Defect Detection and Prevention, Inspections, Software Engineering, Software Process, Testing. <s> BIB004 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> As the time passes the software complexity is increasing and due to this software reliability and quality will be affected. And for measuring the software reliability and quality various defect measurement and defect tracing mechanism will be used .Software defect prevention work typically focuses on individual inspection and testing technique. ODC is a mechanism by which we exploit software defect that occur during the software development life cycle. Orthogonal defect classification is a concept which enables developers, quality managers and project managers to evaluate the effectiveness and correctness of the software <s> BIB005 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> "An ounce of prevention is worth a pound of cure." In software, these expressions translate into the common observation that the longer a defect stays in process, the more expensive it is to fix [10]. Moreover software defects are expensive and time consuming. The cost of finding and correcting defects represents one of the most expensive software development activities. And that too, if the errors get carried away till the final acceptance testing stage of the project life cycle, then the project is at a greater risk in terms of its Time and Cost factors. A small amount of effort spent on quality assurance will see good amount of cost savings in terms of detecting and eliminating the defects. To gain a deeper understanding of the effectiveness of the software process, it is essential to examine the details of defects detected in the past projects and to study how the same can be eliminated due to process improvements and newer methodologies. This paper will focus on finding the total number of defects that has occurred in the software development process for five similar projects and aims at classifying various defects using first level of Orthogonal Defect Classification (ODC), finding root causes of the defects and use the learning of the projects as preventive ideas. The paper also showcases on how the preventive ideas are implemented in a new set of projects resulting in the reduction of the number of similar defects. <s> BIB006 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> Abstract Measuring the software process effectiveness is the premise to evaluate the quality of software, so it becomes the key of the problem to how to correctly quantify software process effectiveness. In this paper, orthogonal defect classification (ODC) technology is used in the entire process of software development. Analyzing software process effectiveness by ODC attribute measurement method, finally software process improvements can be given from the analysis. <s> BIB007 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> For projects that rely on empirical process control and deliver frequently working versions of software, developers and project managers regularly need to examine the status of their software quality. This study illustrates that simple goal-oriented changes or extensions to the existing data of projects' respective defect tracking systems could provide valuable and prompt information to improve their software quality assessment and assurance. <s> BIB008 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> Default causal analysis (DCA) or defect prevention is required by higher-maturity-level software development processes such as the Brazilian Software Process Improvement Reference Model and Capability Maturity Model Integration. The authors ask and answer questions about implementing it in lower-maturity organizations. In the related web extra entitled “Evidence-Based Guidelines on Defect Causal Analysis,” authors Marcos Kalinowski, David N. Card, and Guilherme H. Travassos discuss the basics of research protocol. <s> BIB009 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> Traditional inspection approaches that are used for more than three decades are not effective for current software and development processes. The studies and experiments by testing and inspection professionals showed that customizing inspections can increase their effectiveness as well as efficiency. The comprehensive software inspection model in this article performs defect removal actions as an important duty of inspection, as well as, using the capabilities of collaborative and knowledge base systems. The process improvement is continuously in progress by creating swap iteration in inspection model kernel. In order to validate the model, it is implemented in a real software inspection project. The varieties of detected and removed defects show the potential performance of the model. <s> BIB010 </s> A Survey on Effective Defect Prevention - 3T Approach <s> Related Work <s> “Discovering the unexpected is more important than confirming the known [7]. In software development, the “unexpected” one relates to defects. These defects when unattended would cause failure to the product and risk to the users. The increasing dependency of society on software and the crucial consequences that a failure can cause requires the need to find out the defects at the origin itself. Based on the lessons learnt from the earlier set of projects, a defect framework highlighting the 5 Dimensions (Ds) of defect origin is proposed in this work. The defect framework is based on analyzing the defects that had emerged from various stages of software development like Requirements, Design, Coding, Testing and T imeline (defects due to lack of time during development). This study is not limited to just identifying the origin of defects at various phases of software development but also finds out the reasons for such defects, and defect preventive (DP) measures areproposed for each type of defect. This work can help practitioners choose effective defect avoidance measures. In addition to arriving at defect framework, this work also proposes a defect injection metric based on severity of the defect rather than justdefect count, which gives the number of adjusted defects produced by a project at various phases. The defect injection metric value, once calculated, serves as a yardstick to make a comparison in the improvements made in the software process development b etween similar set of projects. <s> BIB011
Different analysis strategies to improve software processes in defect prevention have been studied and researched upon. Some of them have been discussed below: Jalote, Munshi and Probsting BIB002 discussed WhenWho-How strategy of analysis of defect data to improve the software quality process. Here the focus is on the three dimensions-time, technique or process and the group which finds the defects. Improvement is shown when these three dimensions are combined together and applied for the analysis of defect data for one version of windows. The analysis was done on the component level, which showed a correlation between early and late defect density rate and monitored the defect density at various milestones. Li, Stalharse, Conradi and Kristiansen BIB008 worked on enhancing the Defect Tracking System (DTS) to improve the quality of the software. The author examined various defect attributes of different tracking system used by ten companies and found that different companies use different defect attributes in DTS, but they were not complete for software process improvement. The authors selected two companies and added some new attributes for these company"s DTS like Effort, Fixing types, Triggers, Root cause etc. The improved DTS provided valuable input to developers and testers and thereby reducing the time spent on fixing defects, identifying the root causes, preventing defects well in advance. Mittal, Solanki and Saroha  mentioned that no Software can be "Defect free", after testing defects should be reported using "Defect tracking system" which can be managed to improve the quality of the software. This paper focused on defect management process and the approach for handling the defects which includes counting and managing the defects, maintaining defect leakage metrics. Control charts were used to measure and improve the processes. Various approaches were discussed to handle the defects like Firefighters, Reactive and Proactive approach. Hafiz Ansar Khan  proposed a defect management process model after viewing the major challenges of ITIL defect management process which is used by most of the organizations. The author applied the proposed model in one of the case organization and found that this model is very easy to use and strengthens the defect management and review process of the organization. The proposed model also observes the defect management from the customer's viewpoint. Card BIB001 discussed two approaches to measure and model software quality throughout the life cycle of the software. Empirical and analytical approaches were used to build up defect profile which when studied makes the quality visible to be managed. These approaches were applied and modelled in some real time industry projects, generating defect profile and analysing the departures from the defect profile early in the life cycle. This process can provide feedback to the developers and testers to work on the discrepancies. Kalinowski, Card and Travassos BIB009 discussed how to implement a Defect Causal Analysis (DCA) efficiently. This paper discussed the readiness of an organization for DCA. For DCA implementation, Pareto charts and cause effect diagrams are very helpful to identify the causes of defects. Indicators that support DCA were also discussed like number of defects found by size unit, the mean number of defects found per hour of inspection, phase input quality, phase output quality which help identify the efficiency of the DP activities. It was shown that up to 50 percent of improvement in the defect rates can be achieved, however, implementation cost varies from 0.5 to 1.5 percent which is very marginal in comparison to the gain. Lehtimen, Mantyla and Vanhanen  introduced lightweight root cause analysis method (ARCA) to detect the causes and how the corrective actions are taken. Unlike the normal RCA methods, this one does not require heavy start-up investment and can be easily applied in small-medium sized companies, unlike normal Root Cause Analysis (RCA) methods. The author evaluated this approach through field studies at four software companies through feedbacks using interviews, meetings and query forms. This method is easy to use, highly adaptable, feasible and looks very promising for defect prevention. According to Dalal and Chhillar  , Root cause analysis was done for some software failures that happened in the past and ongoing software projects. Various RCA methods and processes which help to reduce the chances of software failure were also discussed like Cause-Effect Analysis, Events and Causal Factor Analysis, Fault Tree Analysis, Causal Factor Charting, Brain Storming and 5 Whys. Based on the empirical study of root cause analysis of software failures, it was perceived that lots of software failed at the time of upgrading the software and due to inadequate system and integration testing  . Many good examples of efforts on causal analysis have been published  . Navid Hashemi Taba and Siew Hock Ow BIB010 highlighted some traditional inspections approaches used for more than a decade which are not effective for the current processes. A comprehensive software inspection model was introduced in this paper which performs defect removal activities as an important task of inspection. This proposed model suggested a defect management approach for removing defects iteratively. Customized evaluations of the process prepare important information about the effectiveness of the inspection process. In a real environment, it helps to detect and remove defects. Suma and Nair BIB004 discussed the importance of the effective defect prevention approach in software processes highlighting that on an average 15% of inspection and 30% of testing is required for 99% of defect elimination. Author highlighted that the inspection is most valuable and competent technique BIB004 . A lot of information was provided on various methods and practices for defect prevention and defect detection adopted in five projects. Ajit Ashok Shenvi BIB003 worked on presenting a defect prevention framework using Orthogonal Defect Classification methodologies. The structured process for defect prevention mechanism using ODC attributes for defect classification is discussed along with related interpretations for causal analysis and planning. The suitability of this methodology in some real time project was also presented in the paper. Trivedi and Pachori BIB005 discussed that various defect measurement and defect tracking mechanism are used for measuring the software quality. In software development life cycle, 40% or the more of the time is utilized on defect detection tasks. This paper focused on the ODC implementation in real world application. It explained about various defect classification schemes and how we can adopt ODC in development of software. This paper mentioned various improvements in software project after implementing ODC. According to Sakthi and Baskaran BIB006 , the cost of finding and fixing defects is one of the most expensive software development activities, hence better methodologies have to be applied to defect prevention process. Five projects were selected, and different types of defects were first identified, classified using Orthogonal Defect Classification and analysed for patterns to improve the quality of software processes. Defect prevention methods were established for reducing these patterns of similar defects in future projects thereby improving the quality of the projects. LI and HOU BIB007 described ODC, analysed the classification of its attributes and effectiveness of software process by the ODC measure method. This study helped in understanding how ODC provides a new software process measurement to improve the software development process and provides a reasonable quantitative standard. It is important how to choose the ODC measure mode corresponding to the different measure objectives to evaluate the software development process and software quality. Bridge  showed how ODC can be used to provide process enhancement feedback to developers also how to measure the progress of development and to emphasise improvement activities where the customer is most impacted. The principals behind ODC were shown by the results of feasibility studies. ODC forms an excellent foundation for the development of defect prevention and quantitative process management techniques  . Wagner  summarized the work on defect classification approaches that have been proposed by two IT companies IBM and HP. The IBM approach is Orthogonal Defect classification. In IBM, a defect is classified based on defect type, source, impact, trigger, phase found and severity. In HP, defects are classified across three dimensions -Defect origin; types and modes  . Kumaresh and Bhaskaran BIB011 proposed defect framework highlighting the 5 Dimensions (D"s) of the defect origin. Each one of the D"s concentrates on defects in one particular stage of the software development Lifecycle like Deficiency in Requirements, Design Flaws, Defective Coding Process, Delinquency in Testing and Duration Slippage. Analysis of various defect types was done and the most prominent defects were identified. For each one of the defect type, the reason for such defect was found out, and the Defect Prevention actions were suggested. The author also proposed a defect injection metric based on the severity of the defect instead of defect count. The defect injection metric value, once calculated, serves as a standard to make improvement in the software process development among similar kind of projects. Langari and Pidduck [25] proposed a new approach by merging Cleanroom methodologies and formal methods for software quality. Cleanroom highlights defect prevention rather than defect removal and Formal methods use mathematical and logical formalizations to find defects early in SDLC [25] . The techniques identified (T1-T13) are mapped to different publications as shown in Table 2 . 