The document discusses defect analysis and prevention. It defines key terms like errors, defects, and failures. It describes the defect analysis procedure which includes forming a causal analysis team to identify root causes of defects so they can be prevented. The team proposes actions, while an action team implements solutions. Data on defect types and trends is analyzed to prioritize issues. Tools like fishbone diagrams may be used to sort contributing factors. The goal is to systematically eliminate common causes of defects.

1. Presented by
Deep kumar sharma
M.Tech (1 sem)
08/17/14 1

2. 1. What is Defect Analysis
2. Defect Prevention Key Process Area
3. Defect Analysis Procedure
4. Action Team Activities
5. Summary
08/17/14 2

3. • Examination of information about problems
• Intent to identify causes of defects so that they can be
prevented or detected earlier
 Many different approaches called defect analysis or root
cause analysis – employ many different techniques
Software
08/17/14 3

4. • Error - a mistake made by a member of the software team
• Defect - a section of code or documentation that must be changed
to correct a failure
• Failure - a situation in which the software fails to execute as
intended
• Problem Report - usually documentation that a failure has occurred
during testing or use. May also be used to document defects found
in inspections and reviews.
 Software Defect can be defined as “Imperfections in software
development process that would cause software to fail to meet the
desired expectations”.
08/17/14 4

5. 3.The Defect Causal Chain
Defect
(Quality)
Error
(Process)
1 + 1 = 3
Failure
(Reliability)
Pumping
Station
OILCO
Accident
(Safety)
OILCO
Causal
Anaysis
Causal
Analysis
DebuggingDebugging
08/17/14 5

6. Causal
Analysis
Process
Analysis
Action
Planning
Project
Software
Process
Data
Out of Control
Signal & Data
Proposed
Action(s)
Corrective
Action(s)
08/17/14 6

7. • Assigns responsibility for causal analysis of a process to the
software team
• Bases analysis on a sample of problems rather than an
exhaustive study of all problems
• The software team proposes actions to:
– prevent problems
– find problems earlier
• Assigns responsibility for implementing proposals to a
management action team
08/17/14 7

8. Causal
Analysis
Meeting
Software
Evaluation
Software
Production
Problems
Identified
Software
Action
Team
Meeting
Problem
Database
Sample of
Problems
Recommended
Actions
Long-term
Actions
Problems
to Fix
Organization
Process
Short-term
Actions
Baseline for
Future Projects
Improvement Cycle
08/17/14 8

9. 08/17/14 9

10.  Purpose
◦ To identify the cause of defects and prevent them from
recurring
 KPA goals
◦ Defect prevention activities are planned
◦ Common causes of defects are sought out and identified
◦ Common causes of defects are prioritized and systematically
eliminated
08/17/14 10

11.  Defect prevention is an important activity in any software project.
 In most software organizations, the project team focuses on defect
detection and rework..
 It is therefore advisable to make measures that prevent the defect
from being introduced in the product right from early stages of the
project
08/17/14 11

12. Phase
Kickoff
Meeting
Causal
Analysis
Team
Action
Team
Project Phase (ongoing work)
Defects
Suggested
Actions
Process
Improvements
Improved Processes
Lessons Learned
Interim Process
Improvements
Prepared Team
Process
Assets
DP
Activity
Planning
08/17/14 12

13. • Defines focus, composition, roles, and responsibilities of
defect causal analysis team(s)
• Defines charter, composition, roles, and responsibility of
action team(s)
08/17/14 13

14. 08/17/14 14

15. Type of Defect
Number
INTERFACE
DATA
LOGIC
INITIALIZATION
COMPUTATION
08/17/14 15

16. Type of Defect
Rework
INTERFACE
DATA
LOGIC
INITIALIZATION
COMPUTATION
08/17/14 16

17. • Simple graphical technique
• Helps to sort and relate many factors
• Developed as a team (facilitated)
• Focus for discussion - not a definitive result
• Also called an Ishikawa or Fishbone Diagram
08/17/14 17

18. • State problem (effect) - Use statement of Systematic Error -
Draw main branch
• Insert headings for generic causes
– methods
– people
– tools/environment
– Input
• Highlight principal/operative causes(s) - circle
08/17/14 18

19. Misuse of
Computing
Environment
Input Methods
People Tools
Lackof
Knowledge
LackofConventions
08/17/14 19

20. 08/17/14 20

21. • Meets regularly to consider proposed actions
• Must include management - needs resources
• May include technical personnel
• Select and prioritize proposals
• Resolve conflicts and combine related proposals
• Plan and schedule implementation
• Allocate resources and assign responsibility
• Monitor progress and effectiveness
• Communicate actions and status to the teams
08/17/14 21

22. 08/17/14 22

23. design code function test system test
NumberofDefects
Expected Trend
1.Example of ODC Trend
Function
Assignment
Checking
Timing
Legend
ODC(Orthogonal defect classification) defect type process signature
08/17/14 23

24. • Most organizations with well-defined processes can
benefit from some application of DCA
• Maximum benefit obtained from
– Following a systematic approach
– Involving the developers/maintainers
– Pursuing a strategy derived from an objective
understanding of improvement opportunities
• DCA can be applied to any process that receives feedback
on its defects or failures
08/17/14 24

25.  Ajit Ashok Shenvi,2009,”Defect Prevention with
Orthogonal Defect Classification”, In Proc- ISEC ’09,
February 23-26, 2009
 Defect Prevention by SEI’s CMM Model Version 1.1.,
http://www.dfs.mil/technology/pal/cmm/vl/dp
Linda Westfall, Defect Density
 Mukesh soni, 1997, Defect Prevention: Reducing cost and
improving quality” published in IEEE Computer,
(Volume 30, Issue 8), August 1997.
08/17/14 25

26. 08/17/14 26