You are presented with multiple paper abstracts, alongside the associated literature review and chapter titles. Given the provided information, you are going to do a literature review. Please generate a coherent literature review that synthesizes the content, draws connections between different works, highlights major findings, and identifies any gaps in the existing research.

Literature Review Title: A Survey on Effective Defect Prevention - 3T Approach 
Chapter Title:  Introduction 
1. Abstract of Cited Paper (BIB001):  Orthogonal defect classification (ODC), a concept that enables in-process feedback to software developers by extracting signatures on the development process from defects, is described. The ideas are evolved from an earlier finding that demonstrates the use of semantic information from defects to extract cause-effect relationships in the development process. This finding is leveraged to develop a systematic framework for building measurement and analysis methods. The authors define ODC and discuss the necessary and sufficient conditions required to provide feedback to a developer; illustrate the use of the defect type distribution to measure the progress of a product through a process; illustrate the use of the defect trigger distribution to evaluate the effectiveness and eventually the completeness of verification processes such as inspection or testing; provides sample results from pilot projects using ODC; and open the doors to a wide variety of analysis techniques for providing effective and fast feedback based on the concepts of ODC. > 
2. Abstract of Cited Paper (BIB002):  There are three interdependent factors that drive our software development processes: interval, quality and cost. As market pressures continue to demand new features ever more rapidly, the challenge is to meet those demands while increasing, or at least not sacrificing, quality. One advantage of defect prevention as an upstream quality improvement practice is the beneficial effect it can have on interval: higher quality early in the process results in fewer defects to be found and repaired in the later parts of the process, thus causing an indirect interval reduction. We report a retrospective root cause defect analysis study of the defect Modification Requests (MRs) discovered while building, testing, and deploying a release of a transmission network element product. We subsequently introduced this analysis methodology into new development projects as an in-process measurement collection requirement for each major defect MR. We present the experimental design of our case study discussing the novel approach we have taken to defect and root cause classification and the mechanisms we have used for randomly selecting the MRs to analyze and collecting the analyses via a web interface. We then present the results of our analyses of the MRs and describe the defects and root causes that we found, and delineate the countermeasures created to either prevent those defects and their root causes or detect them at the earliest possible point in the development process. We conclude with lessons learned from the case study and resulting ongoing improvement activities. 
3. Abstract of Cited Paper (BIB003):  Defect prevention in CMM and causal analysis and resolution in CMMI are focused on identifying the root cause of defects and preventing defects from recurring. Actions are expected at a project level as well as organization level. This paper provides a general framework of defect prevention activities which consists of organization structure, defect definition, defect prevention process and quality culture establishment. Implementation of defect prevention results in rapid and sustained improvement in software product quality which is evident from an example in Neusoft Group, where defect density in post release phase decreased from 0.85 defects/KLOC in 2000 to 0.1 defects/KLOC in 2005 
4. Abstract of Cited Paper (BIB004):  "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. 
5. Abstract of Cited Paper (BIB005):  "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. 
6. Abstract of Cited Paper (BIB006):  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 
7. Abstract of Cited Paper (BIB007):  “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. 
8. Abstract of Cited Paper (BIB008):  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.

Literature Review:
It is better to question than to worry later" holds as much importance in software development and quality conformation as in English literature. The illness of software development can truly be healed by concrete verification and validation. The requirement breakdown and analysis from the stakeholders of the engagement is very important and upon stages of software life cycle, they develop into a concrete product. Failing to produce a viable product, can make the customer unhappy and defeat the objective. So, it is quintessential to capture problems (defects) in all stages to ensure zero residual nature of the product and improved quality. Quality comprises of all characteristics and features of a product which refers to satisfy a given requirement. It should conform to specifications, customer satisfaction, and value of the product, people, service, and processes. Many companies that produce software have Software Quality Assurance departments, designed to ensure software quality where the focus is on Defect Prevention  . A defect is a variance from a desired behaviour, which affects the quality of the software. Defect Prevention identifies those defects, correct them and prevent them from reoccurring. The aim of defect prevention is to produce good quality products within the budget and time. We know no software can be built as Defect Free; defects may be introduced during specification, design, and coding of the test application. Hence, defect prevention is an essential part of the software process quality improvement, which cannot be compromised BIB004 BIB008 . Defect analysis and prevention techniques have been applied successfully in a number of software development organizations with significant reductions in errors BIB001 [5] BIB006 . A technique which emphasise on identifying the root causes of defects and initiate the action to correct them is Root cause Analysis which looks simple, but is very deep rooted. Root cause analysis for defects is proved to be a successful process in defect prevention BIB009 [8] BIB003 . Defects are analysed one by one qualitatively which is very time consuming and rigorous process. Hence we need to view them in collections and should be able to find the causes at the right level. Various classifications have been developed over the last decades for improving defect detection or educating developers  [11] BIB002 . Orthogonal Defects Classification (ODC) BIB002 , devised by IBM, is commonly used technique for classifying defects in the software products. Defects are identified and analysed for patterns to improve the quality of the software process. It provides a meaningful classification of defects into classes that collectively point to the process that needs attention BIB002 . Various case studies have shown that ODC can improve the effectiveness and efficiency of development and testing which is important for quality improvements BIB005 BIB007 [15]  . In this paper, an attempt is made to present a comprehensive view of defect prevention techniques and analyses them critically by stating the advantages and limitations of selected approaches and inferring 3T"s of Defect Prevention through this study. The remaining paper is organized as follows: In the next section, data extraction from different sources showing distribution of selected papers is presented. An overview of related work on defect prevention along with the critical analysis of the techniques is presented in the third section. The defect Prevention flow and three pillars of Defect Prevention along with learnings from this study are described in fourth and fifth section respectively and finally a sixth section presents the conclusion.