This document discusses defect prevention as a way to reduce costs and enhance quality in software development. It notes that preventing defects is better than fixing them later. The key points made include: - Defects are imperfections that cause software to fail to meet expectations. Most defects are introduced early but found later in the process. - Defect prevention identifies root causes through analysis of past defects to prevent recurrences. This improves productivity and reduces rework. - Fixing defects gets significantly more expensive later in the process, from design to maintenance. Methods of prevention include reviews, inspections, walkthroughs, logging defects, and root cause analysis techniques like Pareto analysis and fishbone diagrams. -

1. Defect Prevention
Reducing Costs and Enhancing Quality
Vamsi Krishna P Y

2. Agenda
- Concepts
- Why Defect Prevention?
- Phase Cost Ratio
- Methods of Defect Preventions
- Process Improvement Workflow

3. Concepts
 Universal thought “Prevention is Better than Cure” applies to
Software development Life cycle as well as illness in medical
science.
 Defects:
Imperfections in software development process that would cause software
to fail to meet the desired expectations”.
 Misconceptions:
Lots of defects would emerge during the development process. but believe
that defects get injected in the beginning of the cycle and are removed
through the rest of the development process.

4. Defect Prevention
 The purpose of Defect Prevention is to identify the Root cause of
defects and prevent them from recurring.
 This 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.
 It also enhances the Productivity.
 It Reduces rework effort.

5. Impact of Defects at Later Stage:
Phase V/s Cost
100
90
80
70
60
Cost
50
40
30
20
10
0
Design Implementation Testing Maintenance
Phase

6. Methods of Defect Preventions
 Reviews & Inspections: Self-Review, Peer Review &
Inspections.
 Walkthroughs: prototyping of the actual design that gives the
you the basic idea of the product functionality along with its look
& feel.
 Defect Logging and Documentation.: provide key parameters
that supports Defect Analysis and Measurements.
 Root Cause Analysis.
 Pareto Analysis.
 Fishbone Analysis.

7. Targeting Process Improvement
Defect
Identification
Process Defect
Improvement Classification
Preventive Defect
actions Analysis
Root Cause
Analysis

8. Pareto Analysis (80/20 Analysis):
140 100
Count
120 90
120
Cumlative
80 Percent
100 70
C 60
o 80
u 65 50 %
n 60
t 40
42
40 30
21 20
18
20 14
11 10
0 0
Coding Inadequate Design Framework Lack of Thirdparty Lack of
Issue req Issue Issue Knowledge Issue Training
Categories

9. Fishbone Analysis

10. Output of Defect Prevention Method
Category Observations Conclusion
1. Lack of Domain knowledge. 1. Domain knowledge: Training should be given to the team members
2. Improper Algorithm before starting the next phase.
3. Developer without experience
4. Introduction of new programming 2. Make available of trained and experienced resources for coding and
language testing
Person
3. Generally introduction of new programming language should be known
well in advance to the team and proper training should be given well in
advance.
1. Assumption of the Requirement 1. Discuss more about the boundary of the applications and granularity of
gathering person in the grey Area. each requirement Using Business Analysts /Domain professionals during
2. Ambiguity in requirement documentation requirement elicitation.
3. Incorrect requirement specification
4. Wrong elicitation technique 2. Frequent communications with customer will help to know his
Requireme 5. Not enough preparation for review by requirements.
nt reviewers
3. A formal sign off from all Business Users who would handle the
application should be mandated before starting the design phase

11. Questions ?

12. Thank You