White paper on Defect and DPA

Table of Contents

     INTRODUCTION

1.  Defect & DPA 
        1.1          Introduction to Defect

        1.2          Type of Defects      

       1.3          Defect classification

2.   Defect Detection

3.  Defect Prevention       

      3.1          How does a defect prevention mechanism work?

      3.2          Defect Prevention (DP) ETVX Diagram

      3.3         Defect Prevention policies         

     3.4          Defect Prevention at Project Level

4.  Causal Analysis and Resolution (CAR) 

5.  Role of Defect Prevention Analyst (DPA) 

6.  Defect tracking tools 

7.   Advantages of DPA in project 

8.   Conclusion                                                                                                                                                                             

INTRODUCTION

Defect Prevention is one of the most important activities of software development life cycle, which has direct impact on controlling the cost of the project and the quality of the deliverables. The Purpose of Defect Prevention is to identify/Track the cause of defects and prevent them from recurring. Defect prevention involves analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of those types’ defects in the future. Trends are analyzed to track the types of Defect that have been encountered and to identify defects that are likely to recur. Based on an understanding of the project defined software process and how it is implemented the root causes of the defect and implications of the defects for future activities are determined. In the below report we have try to educate you what are the different types Defect based on causes, severity ,Type and life cycle. The defect Management Program should give priority to implementing the program on pilot projects so that benefits are realized quickly. Defect prevention should begin with an assessment of the critical risks associated with the system. The strategies can then be developed to prevent them by Defect Detection (finding errors and fixing them during the inspection, reviews, testing and even after customer release) for these four eye principle would give the best result. After knowing what is defect and what are the types of defects  we should know how to detect the defect and to prevent them from reoccurring in future, once the defect are been identified Defect Prevention mechanism (Defect Logger or documentation, Defect prioritization, Root cause analysis and reviews) will be rolled-out  based on the Defect Prevention Policies. Casual Analysis and Resolution (CAR) the analyses of to determine their underlying root cause it is used to identify the highest risk and make suggestion for the new project. When all the necessary action are been taken then Defect Prevention Analyst (DPA) Responsibility to fill the Corrective action and Prevention action (CAPA) Template. Regarding DPA no doubt, the best approach to eliminate the defects by them which will reduce the expected impact which may be strongly affected not only by whether or not a risk becomes a problem, but also by how long it takes for a problem to become recognized and how long it takes to fixed once recognized this techniques to reduce the expected impact are a function of a particularly risk.

Defect & DPA

Defect Prevention Analysis is the feature of tracking or analysis defects to prevent possible documentation errors. In order to meet/satisfy the required quality standards of the project a thorough knowledge of nature of defects is important (Crucial). A documentation error of the project/product consequence it’s failure.

1.1         Introduction to Defect

Below are the few definitions of defects. Defects can be defined by different ways based on nature of error.

Ø  It is an undesirable feature of a work product.

Ø  Anything that either adversely impacts the expected functionality to the user, or otherwise reduces the quality of a work product.

Any error will cause a defect, and the defect will lead to a failure in the work product.

Error àDefect à Failure

Error: Defects in the human thought process made while trying to understand given information, to solve problems, or to use methods and tools.

Defect: A defect is an anomaly in a product (already exists in a product).

Failure: Departures of the operational software system behavior from user expected requirements

1.2         Type of Defects

Basically there are 2 types of defects:

1)                      Process Defects

2)             Project Defects  

  Process Defects:

Ø  A concern to the project manager.

Ø  The strategy for process defect is defect prevention.

Ø  A process defect is like a potential carrier of disease.

e.g.:     Poor scheduling, lack of training, inadequate resources etc.

Project Defects:

Ø   Affect the customer.

Ø  The strategy is defect removal.

Ø  Always a result of process defect.

Ø  Affect the fellow components of the entire system (including hardware).

e.g.:     Incorrect calculations, errors in the documents etc.

  “A Product defect always the result of process defect”

1.3         Defect classification

Defects can be classified based on 4 different categories:

   1)    Type

   2)    Cause

   3)    Severity

   4)    Life cycle

Based on Type

SL. No	Defects based on Type	Description	Suggested  Defect causes mapping
1	Documentation	Poor comments and messages, Inadequate or incorrect descriptions e.g., missing, incomplete,   incorrect comments).	Inadequate training, Inadequate self review, Style difference
2	Interface	Interface defects cover external procedure calls, mismatched parameters, input and output formats. Defects in the communication between software components e.g., incorrect module invocation, incorrect passing of data. Defects in communication with or specification of external data or devices. Human interfaces - Incorrect or improper operating procedures; no specification of what operating procedure to use; unnecessary operator involvement, GUI and related cosmetic errors.	Inadequate self Review, Requirement Change Not Clear, Inadequate Standards
3	Data	The actual data must have proper structure and content. Inadequate screening of data causes checking defects. Defects in data specification; improper declaration, initialization, or description of data; incorrect data usage, conversion of types, or array boundaries.	Environmental Setup, Inadequate Self Review, Requirement changed / Not clear, Inadequate Standards
4	Coding	Poor structure of loops, recursion, and logic Defects in procedures; sequence, selection, iteration of operations (e.g., incorrect boundary condition on loop, incorrect comparison); incorrect algorithms or mathematical computation. This can also be expanded to cover Lack or an orderly, systematic, structured approach and Assignment defects related to variable declaration, duplication of names, and out of bounds and Maintainability defects related to an expectation that the code will be difficult to maintain (e.g., it is not understandable, it has undesirable side effects).	Education, Transcription,  Communication, Requirement changed / Not clear, Inadequate Standards
5	Functional	Defects in the specification of the functions of a component or functions not carried forward to design, functions incompletely / not covered in HLD, LLD or Code.	Training / Education Inadequate Self Review, Communication, Requirement changed / Not clear Process
6	Environmental	Constraints due to system configuration, machine / system software or environment setup. This can be expanded to cover improper version control and change management that can create an improper mix of modules - causing a defect.	Environmental Setup, Process
7	Standards	A deviation from procedural or representational standards	Inadequate coding standards, Inadequate training, Communication, Process
8	Process Reviews	Deviation from the project specific process mentioned in Process Model.	Training / Education Process

Based on Cause

SL. No	Defects based on Cause	Description
1	Inadequate Training / Education	Education or Training of the resources is Inadequate in terms of their knowledge of Operating Environment, Application, Domain Knowledge, Technology, Architecture and Processes.
2	Inadequate standards	Adequate standards for Requirements, Design, Coding & Testing in form of either definite guidelines or Checklists or Templates are not available for Specific technology / Domain.
3	Communication	Someone else did not properly inform you about something or you did not understand something you were told. Communication errors result from a breakdown in communication between groups or among team members. For example, A design concept stated by a higher-level designer is misinterpreted by a lower level designer.
4	Inadequate Self Review	You knew what to do but made a mistake because of not doing adequate self-review. This can result into: (a) Transcription (b) An Oversight. A Transcription error occurs when the programmer knows every thing in detail about a program, but simply makes mistake. (e.g., types in the wrong label) You omitted doing something you understood and meant to do. An Oversight arises when all the possible cases or conditions are not considered or handled. (E.g., an error condition is missed), not followed guidelines / discipline
5	Process	A fault in your process led you to do the wrong thing
6	Environment setup	Environment problem: defect in development environment or support systems (compiler defects or other tool defects, defects in test drivers or TEST DATA etc.) External problem with timing, synchronization, network, or hardware; i.e. errors due to influences from outside the scope of the program itself
7	Requirements Changed / Not Clear	Frequent change in requirement led to this defect. Requirement not clear can be further divided into following: (a) New Function-- The developer does not understand the requirements and make the errors. (b) Old Function -- The basic requirement is not well understood when a new requirement is added to it the implementation causes a problem."

Based on Severity

SL. No	Defects based on Severity	Description
1	Major	The defects which are incorrect or even missing the functionality or specifications can be classified as major defects: the software will not function correctly when these defects are not being solved
2	Minor	The minor defects do not threaten the correct functioning of the software, but are mostly small errors like spelling mistakes in documents or optical issues like incorrect positioning of controls in a program interface
3	Trivial	Defects that affect limited areas of functionality that can be ignored. Formatting, Spell, Grammatical issues in the work products

Based on life cycle

Requirement

Design

Coding

Implementation

Test phase

Inspection

Operation and maintenance

After knowing what is defect and what are the types of defect we should know how to detect the defect and to prevent them from reoccurring in future

2.      Defect Detection

Ø  It is the process of finding errors and fixing them.

Ø  Detected during, inspection, reviews, testing and even after customer release.

Defects can be detected in various phases (stages) of lifecycles like in Requirement, Designing, Coding, Testing, even after release etc. The earlier we detect the defect and correct it, the better it will be for our work product and also the cost will be less to fix the defect. Usually one specific person used to assign for defect detection and prevention activities. But it will be helpful if we all use four eye principle.

Defect Detection Probability

One person review – 30 to 50%

Group Review – 60to 80%.

Defect Prediction

Process of improving the quality & productivity by preventing injection of errors into the work product

Defect collection

Defects can be collect from the following methods:

Ø  Defect Tracking Tool

Ø  Review Reports

Ø  Test Reports

Ø  Client Specified Format (e.g. Problem Reports, E-mail)

3.      Defect Prevention

Defect prevention is the set of activities, techniques and processes for identifying existing or potential software defects and preventing them from being introduced into a product.

Defect Prevention involves analyzing defects that were encountered in the past and taking   specific actions to prevent the occurrence of those types of defects in the future. The defects may have been identified on other projects as well as in earlier stages or tasks of the current project. Defect prevention activities are also a kind of mechanism for spreading lessons learned between projects.

3.1                   How does a defect prevention mechanism work?

Ø  The integral part of the defect prevention process begins with requirement analysis – translating the customer requirements into product specifications without introducing additional errors. Software architecture is designed, code review and testing are done to find out the defects, followed by defect logging and documentation.

Ø  The blocks and processes in the gray-colored block represent the handling of defects within the existing philosophy of most of the software industry – defect detection, tracking/documenting and analysis of defects for arriving at quick, short-term solutions.

Ø  The processes that form the integral part of the defect prevention methodology are on the white background. The vital process of the defect prevention methodology is to analyze defects to get their root causes, to determine a quick solution and preventive action. These preventive measures, after consent and commitments from team members, are embedded into the organization as a baseline for future projects. The methodology is aimed at providing the organization a long-term solution and the maturity to learn from mistakes.

Ø  Most of the activities of the defect prevention methodology require a facilitator. The facilitator can be the software development project leader (wearing another hat of responsibility) or any member of the team. The designated defect prevention coordinator is actively involved in leading defect prevention efforts, facilitating meetings and communication among team and management, and consolidating the defect prevention measures/guidelines.

3.2                   Defect Prevention (DP) ETVX Diagram:

ENTRY	TASK	VERIFICATION	EXIT
1. Policy for organization to perform DP activities 2. Policy for projects to perform DP activities 3. Organization-level team exists to coordinate DP activities 4. Project level team exists to coordinate DP activities 5. Adequate resources/funding 6. Training for members of the S/W engineering group and related groups	1. Develop Project’s DP plan 2. Team has kick-off meeting to prepare for DP activities 3. Conduct causal analysis meetings 4. Conduct coordination meetings to review the implementation of action proposals from the causal analysis meetings 5. Document and track DP data 6. Revise the organization’s standard process resulting from DP actions 7. Revise the project’s defined process resulting from DP actions 8. Provide feedback to developers on the status and results of DP actions	1. Reviews with senior management 2. Reviews with project manager 3. Reviews/audits by SQA 4. Measurement of status of DP activities	1. DP activities are planned 2. Common causes of defects are sought out and identified 3. Common causes of defects are prioritized and systematically eliminated

3.3                   Defect Prevention policies

Organization defect prevention policy should state:

Ø  Long-term plans and commitments are established for funding, staffing, and other resources for defect prevention.

Ø  The resources needed are allocated for the defect prevention activities.

Ø  Defect prevention activities are implemented across the organization to improve the software processes and products.

Ø  The results of the defect prevention activities are reviewed to ensure the effectiveness of those activities.

Ø  Management and technical actions identified as a result of the defect prevention activities are addressed.

 Project defect prevention policy should state:

Ø  Defect prevention activities are included in each project's software development plan.

Ø  The resources needed are allocated for the defect prevention activities.

Ø  Project management and technical actions identified as a result of the defect prevention activities are addressed.

3.4                   Defect Prevention at Project Level

Ø  Identify Project Defect Prevention Analyst (DPA).

Ø  Prepare Project specific Defect Prevention plan & Defect list.

Ø  Implement the plan.

Ø  Collect data from Reviews, Testing, NCs, Final Inspection, Internal Audits, Conduct causal analysis meeting.

Ø   Identify action plans  for root causes Update CAR form with corrective and preventive action

Ø  Update the SDC Defect Repository.

Ø  Implement the actions and track the effectiveness of the corrective and preventive action.

Ø  Submit the CAR to SDC DPC and suggest process improvements.

4.      Causal Analysis and Resolution (CAR)

Purpose:

Ø  To identify the cause of defects and prevent them from recurring

  Involves:

Ø  Analyzing defects that were encountered in the past.

Ø  Taking specific actions to prevent the occurrence of those types of defects in the future.

Causal Analysis procedure

Ø  Identifying the defects, and determining which defects to be analyzed further. This is called as Macro problem definition.

For determining the defects for further analysis, several tools are available such as Pareto analysis, histograms, Process capability analysis etc.

Ø  Addressing the causes of defects. This is called as Micro problem definition.

For organizing the possibilities/causes in a way that makes it easier to prioritize and access, several tools are available, among that most popular is “Fish bone diagram”. 

Summary:

Ø  Root Cause the most effective way to eliminate defects.

Ø  The goal is defect prevention.

Ø  It requires on-going maintenance of the data/choices.

The Causal Analysis and Resolution process area involves the following:

Ø  Identifying and analyzing causes of defects and other problems.

Taking specific actions to remove the causes and prevent the occurrence of those types of defects and problems in the future

5.      Role of Defect Prevention Analyst (DPA)

Ø  ssist PM in preparation of Project DP Plan.

Ø  Assist the PM in preparation of Project specific Defect list & ensure actions to prevent them from occurrence.

Ø  Implement the DP plan.

Ø  Monitor the defect symptoms in the project

Ø  Initiate in-process corrective & preventive actions

Ø  Collect & Validate the defect data on a periodic basis for Causal analysis.

Ø  Initiate the causal analysis meetings & conduct causal analysis.

Ø  Identify Corrective and Preventive actions.

Ø  Inform the SDC DPC regarding causal analysis findings.

Ø  Implement the corrective and preventive action.

Ø  Monitor the effectiveness and implementation of the corrective and preventive action.

Ø  Ensure updation of Organization Defect Repository.

Ø  Update the project defect prevention plan.

A brief description of DPA activity for the production support (RTB) project:

We used to collect the defect from the audit report which is on monthly basis the quality people are conduct to verify and validate the projects artifacts.

DPA role is to collect the NC (non compliance) from the audit report, to find out the root cause of the defect leads to NC, find the corrective action and also the preventive action in order to avoid the same defect in future.

Then we have to fill the details ((like defect type, cause, severity etc..) in the CAPA (Corrective action and preventive action) template and in defect log template as well which is available in quality portal accordingly and update the team by conducting a meeting. On monthly basis we maintain the CAPA for the defects from the audit feedback.

6.      Defect tracking tools

After defects are logged and documented, the next step is to analyze them. Generally the designated defect prevention coordinator or development project leader facilitates a meeting to explore root causes.

The root cause analysis of a defect is driven by three key principles:

Ø  Reducing the defects to improve the quality: The analysis should lead to implementing changes in processes that help prevent defects and ensure their early detection.

Ø  Applying local expertise: The people who really understand what went wrong are the people present when the defects were inserted – members of the software engineering team. They can give the best suggestions for how to avoid such defects in the future.

Ø  Targeting the systematic errors: There may be many errors or defects to be handled in such an analysis forum; however, some mistakes tend to be repeated. These systematic errors account for a large portion of the defects found in the typical software project. Identifying and preventing systematic errors can have a big impact on quality (in terms of defects) for a relatively small investment.

With these guidelines, defects are analyzed to determine their origins. A collection of such causes will help in doing the root cause analysis. The defects are classified based on their types. A Pareto chart is prepared to show the defect category with the highest frequency of occurrence – the target. An example of defect classification in a Pareto chart is show in the below fig.

Root cause analysis is the process of finding and eliminating the cause, which would prevent the problem from recurring. Finding the causes and eliminating them are equally important.

Each defect category and the causes making those defects happen can be represented using a cause-and-effect diagram, as shown in the below fig.

The cause-and-effect diagram, also known as a fishbone diagram, is a simple graphical technique for sorting and relating factors that contribute to a given situation. A team usually develops the cause-and-effect diagram in a facilitated brainstorming session. Once the root causes are documented, finding ways to eliminate them requires another round of brainstorming. The object is to determine what changes should be incorporated in the processes so that recurrence of the defects can be minimized.

7.      Advantages of DPA in project

To identify the errors (NC’s) and to correct it by giving proper validate methods, is nothing but the task of a DPA (Defect Prevention Analyst). She/he closely monitor the issues /errors in relation to project /process specific and  by following many methods like fish-bone diagram,pareto chart  clear the error and also prevent the error to occur in future.

By use of DPA, defect can be prevented which will lead to the following benefits:

Ø  Checklist developed for reviews have improved.

Ø  Rework effort has reduced.

Ø  Numbers of weighted defects have reduced.

Ø  Training program has improved.

Ø  Projects are now operating with lesser defects even with a lesser percentage of experienced resources.

8.      Conclusion

The document is to understand the defect, its causes, classifications, how to identify it and to correct it by providing necessary corrective and preventive actions. The focal point of quality cost investment is to invest in right DP activities rather than investing in rework which is seen as an outcome of uncaptured defects.DPA helps the project teams to concentrate the few vital factors that are causing most of the problems when root cause analysis is done. It is the “WALL OF AGREEMENT” between the deliver teams to stay focused and committed in aligning organizational objectives into execution. Hence, management plays a vital role in driving quality dashboard. I agree that an effective utilization of DPA results in finest quality and on time deliverables. Thus apart from manger’s and DPA responsibility, every team member needs to contribute for the first-rate quality of the project. I also realize that Defect Prevention plays a vital role at every stage of project development (Requirement, Designing, Coding, Testing and maintenance (Production Support). The absences of Defect Prevention directly equates with lost sales since a customer dissatisfied with a product quality will not continue or outsources the new project with the same company. From the above report it is easy to understand by Defect Prevention activities it will increase the quality dashboard, costumer satisfaction (CS) and it give a value add to the product quality and improve the continuous Process Improvement (CPI) finally this results a more business from the customer.