Software Defect Prevention through Orthogonal Defect Classification (ODC)

“Quality is never an accident; it is always the result of intelligent effort” [10]. In the process of making quality software product, it is necessary to have effective defect prevention process, which will minimize the risk of making defects /errors in software deliverables. An ideal approach would involve effective software development process with an integrated defect prevention process. This paper presents a Defect Prevention Model in which Defect Prevention Process(DPP) is integrated into software development life cycle to reduce the defects at early stages itself, thereby reducing the defect arrival rate as the project progresses to the subsequent stages. Orthogonal Defect Classification (ODC) scheme involving defect trigger, defect type etc. are discussed in this work to illustrate how ODC can be used in the defect prevention process. ODC can be used to measure development progress with respect to product quality and identify process problems, which will help to come out with “Best Practices” to be followed to eradicate the defects in the subsequent projects.


INTRODUCTION
Software defect can be defined as "Undesirable events occurring in the software development process which in turn causes delay and lowers the quality of the software".A defect in software may be due to some type of error or fault.Usually these faults are a result of human mistake, but sometimes they are caused by faulty development tools, vague customer requirements, incorrect design, and wrong test cases etc.The powers of man are not so extra-ordinary to never make mistakes; but from their errors and mistakes the wise and good learn wisdom for a better future [4].It is important to implement a process that individuals and teams can make use of, to learn from their mistakes.A fundamental aspect of this learning is the classification of defects using orthogonal defect classification.With a structured classification scheme, an organization can analyze and learn about the types of defects that have been discovered and their relative frequencies.Such classification scheme provides insight into what improvements are needed to prevent or mitigate those defects in the future.
Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a product.This paper highlights the various components involved at every stage of software development, and the steps needed to implement the defect prevention process.The defect prevention model proposed in this study is a process to continually improve the development process.DPP is integrated into every stage of the development process.This approach ensures that meaningful discussion takes place when it is fresh in everyone's mind.It focuses on defect related actions and process oriented preventive actions.This paper makes an attempt to adopt defect prevention process in mini-ERP project of small and medium scale enterprise and the results were obtained.

LITERATURE SURVEY
The earlier studies in defect prevention were focused on defect prediction and decide upon the team size of the testing resources required in order to complete the project on time and lot of effort were utilized in the debugging and get the defects elimination instead of prevention.With the enhancements to SDLC processes many companies have formulated their own defect prevention solutions.One study by Natesan Karthkeyan [2] was to analyse various defect prevention techniques, its advantages and disadvantages, their cost analysis vis-a-vis alternate solutions.Research executed by Ms Prakriti Trivedi [3] uses a model for defect prevention using ODC as an approach for defect classification and prevention.Another paper by Mohd.Faizan [6] have also analysed various defect prevention techniques with restrictions to recent trends.The paper by Norm Bridge [5] has presented a framework developed by IBM for classifying and analyzing defect data collected during software development and describes how Orthogonal Defect Classification (ODC) can be used to measure development progress with respect to product quality and identify process problems.The paper by Prof. Pankaj Jalote [7] have focussed mostly on monitoring of quality control activities, like defect prevention, for ensuring high quality, are used.In another study by Prof Suma [1] the defect prevention issues faced by Small and Medium scale industries has been analysed and solutions have been suggested.In this paper, we propose to combine and enhance the above methodologies used, such as ODC for defect classification and analyse the defect patterns to arrive at early stage defect reduction.This paper attempts to bring best practices for defect prevention based on this mechanism for small and medium scale enterprise to implement it easily and effectively.

Defect Prevention Model With ODC
In a typical software development project, the test team becomes involved late in the process to find defects and "test quality into the software."Unfortunately, the later a defect is discovered, the more expensive it is to repair and the greater the cost and impact on the overall project, just like the saying "A stitch in time saves nine".Consequently, if defects cannot be avoided altogether, a fundamental goal of a successful defect prevention effort is to move quality verification and improvement to an earlier stage in the software development cycle.Focusing on quality in the planning, design, and early development stages pays big dividends later in the cycle.By moving quality assessment and improvement "upstream" in the software development process [4], the test team can focus more on the end user experience and on integration-level testing, rather than finding design or functional errors.This paper describes a new type of model which integrates the Software Lifecycle development with defect prevention process.Figure 1 show the defect prevention model proposed in this paper.The idea behind this model is that Defect prevention process should be incorporated at each phase of software development life cycle.
In Figure 1 According to ODC, when the defects are collected and analyzed in-process during an ongoing software development, information on defects is available at two specific points in time [9].(1) When a defect is opened, the circumstances leading to the exposure of a defect and the likely impact to the user are typically known.( 2)When a defect is closed after the fix is applied, the exact nature of the defect and the scope of the fix are known.ODC categories capture the semantics of a defect from these two perspectives.By defining the activities during a development process and their mapping to the ODC Triggers, an organization customizes the generic scheme to the local process.

ODC Defect Attributes
IBM's ODC classifies defect into eight defect attributes.Figure 2 depicts the ODC attributes used in this study for defect classification.
Activities in the opener section:  Activity refers to the actual task that is involved (Inspection, Reviews, Testing etc.) when defects are found.
 Trigger describes the condition that had to exist for the defects to escape into subsequent phases.
 Impact relate to impact on users in terms of customer satisfaction.
Activities in the closer section:  Target represents the high-level entity (i.e., design, code, ID, etc.) that was fixed.
 Type represents the nature of corrective action that was made on the defect.
 Qualifier captures the element of either nonexistent or wrong or irrelevant information.


Source identifies the origin of the defect (Design, code etc.)  Age identifies the history of the target (i.e., design, code, ID, etc.) that had the defect O c t 1 5 , 2 0 1 3

Defect Type
Defect type primarily deals with what caused the defect.A programmer making the correction usually chooses the defect type.In each defect type, a distinction is made between something missing or something incorrect.In this study, the five defect types identified were Algorithm, assignment, function, interface and checking.Figure 4 shows the defect types that affect coding and design of software development.
Algorithm: Defect due to problem in procedure or overloaded function.
Assignment: Defects due to values not initialized in few lines of code.
Function: Defect that affects end-user interfaces, product interfaces etc which requires the change in design.
Interface: Defect occur while interacting with other components or modules of the system O c t 1 5 , 2 0 1 3 Checking: Defect in program logic which performs data validation check.

Results and analysis
The following information was observed during the implementation of defect prevention model for Mini-ERP project.While the defect data were classified using ODC, It was found that most of the defects are related to Base Code (83%) and GUI (14%).Some observations were discovered when looking at Triggers of defect and compared to their Category.Figure 3 shows distribution of triggers and targets attributed to defect types represented from Functional testing and GUI.
Analyzing Figure 4 shows how much of these defect targets are attributable to Algorithm, Assignment, Function, Interface and Checking of both coding and design phase.These observations are then analyzed to arrive at best practices approach for defect prevention to come out of these lacunae in the system based on ODC observations which has been tabulated in Table 1(Appendix).These best practices can be applied and further streamlined along with their leanings to make the development process cleaner and defect free.This will enable the company to have more focus on process and systems than on individuals.

CONCLUSION AND FUTURE ENHANCEMENT
To err is human, but defect prevention practices enhance the ability of software developers to learn from those errors and, more importantly, learn from the mistakes of others [13].The benefits of implementing defect prevention are reducing overall cost, schedule, and resources and increasing the quality of a software product and the same is achieved through defect prevention model proposed in this study.The defect prevention model proposed in this study helps to eliminate the defects at every stage of software development, take preventive action for defect elimination and to avoid its recurrence.ODC way of classifying defects helped the practitioners point to the process area where preventive action has to be taken.This study made an attempt to deploy Simple ODC classification scheme into a project developed at medium scale IT industry, and paved the way to arrive at "Best Practices" to be followed for similar projects in order to realize the above benefits of defect prevention.This paper is limited to using some defect attributes of ODC for classification.As the job is human intensive requiring ODC trained personnel, planning to develop an open source tool which will automatically classify defect data based on ODC and generates a diagnostic report for taking preventive actions against the defect.When such a tool is developed, it will be of cost beneficial to small and medium scale IT industry and also help them to produce defect free IT solutions.

APPENDIX
Fig 1: Defect Prevention Model

( a )
Traceability Matrix, to trace each Functional Requirement till Source Code level should be made mandatory and Code to be released for Testing after a formal review of the updated Traceability Matrix for each requirement.An Independent review of the Traceability Matrix by the Quality Team should also be mandated.(b) Before commencing with the actual coding, Developers should document the Program Specification for each Source code and it should be formally reviewed by the Project Lead -This step would validate if the Developer has understood the actual requirement and can transform the Functional coverage in O c t 1 As the code related defects are categorized under Assignment, Algorithm/Method and Checking , which are more of a Source code related issues, the Developer writing the code should do a self code review of all possible criteria.Secondary code reviews by the peers or by the lead to be mandated to avoid such errors.Design (a) Majority of design defect comes under Function/Class/Object Defect Type.The design perspective of each requirement should be understood and dependencies with external interfaces should be taken care.Formal Design review with key Technical members of the project, Interface teams, Vendors (if any), System and Database Administrators should be mandated before proceeding with the Coding phase.(b) The Technical Lead responsible for Design should have Overall knowledge about the Project Functionalities, Technical Implementation, System Environment, Deployment challenges, etc. to Design a perfect solution for the project.Any change in Design at a later stage would have a heavy impact in the Project timeline -so should be taken care in the Design phase itself.Requirement (a) Requirement related defects, captured in the same phase is minimal -so can be ignored for further analysis.Variation Code (a) All negative scenarios and input of negative values should be handled in the Source code.So, developer should document all such negative cases in the Program Specification and it should be reviewed by the Technical Lead for completeness.Design (a) A general list of negative cases to be handled should be included as a part of the Design document.Requirement (a) In most cases, the negative scenarios to be handled are not documented as a part of the Functional Specification.It comes as a part of the experience and the Knowledge Base of the related project can be referred to avoid such errors.Sequence Code (a) Defects arising for the Trigger area 'Sequence', are more related to Integration related issues.It is just not enough for the Developer to understand his/her own code related functionality, but a knowledge on the overall project is essential to avoid such defects.Shared source code / common routine in the project has to be discussed, documented in detail and should be agreed between the stakeholders involved in Integration.A final approved document on common routines is a must to avoid such errors (To be circulated before Source code development).Design (a) The document specified above on Workflow Sequence should be written and agreed in the Design phase.Requirement (a) Scenarios that may have a sequential execution must be well documented with sample Use Cases.This is related more to the 'Sequence' Trigger area, as it involves the error that arrises in the sequence of execution.So, Best practices specified in Sequence Trigger Area can be referred here.GUI Review (14.65%)Widget/ Icon Appearance Code Most of the GUI Review commnets is in the Code (97.78%) -so more attention in this area is essential for Defect Prevention.
Before starting the actual coding, a prototype of the application should be built to finalize on the look and feel of the application.Design (a) Screens of the prototype can be embedded in the Design document to understand the application better.Senior Technical developer along with the team can work in parallel with the Technical lead to assist him in bringing such add on features in the Design document.

Table 1 :
Best Practices To Be Followed -Preventive Measures Decided Based On Defect Data Most of the Functional defect is detected in the Code (85.88%)so more attention in this area is essential for Defect Prevention.