Downloaded 504 times
Uploaded bydeep sharma
Defect analysis and prevention methods
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.
More Related Content
Similar to Defect analysis and prevention methods
Defect analysis and prevention methods
- 1. Presented by Deep kumarsharma M.Tech (1 sem) 08/17/14 1
- 2. 1. What isDefect Analysis 2. Defect Prevention Key Process Area 3. Defect Analysis Procedure 4. Action Team Activities 5. Summary 08/17/14 2
- 3. • Examination ofinformation 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 CausalChain 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 responsibilityfor 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.
- 9.
- 10. Purpose ◦ Toidentify 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 preventionis 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 (ongoingwork) 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.
- 15.
- 16.
- 17. • Simple graphicaltechnique • 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 PeopleTools Lackof Knowledge LackofConventions 08/17/14 19
- 20.
- 21. • Meets regularlyto 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.
- 23. design code functiontest 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 organizationswith 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 AshokShenvi,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.
Editor's Notes
- #11 Describe DP as defined in the CMM
- #13 Now for a more detailed look. The DP process described in the guidebook is based the DP process pioneered by Robert Mays of IBM in the late 80’s. Every project performs defect prevention. It starts with a team kickoff meeting before every development phase. This sets the stage both the project activities and DP activities. In effect it marries the two sets of activities. Then during the development phase defects are collected from various sources. These are periodically analyzed by a Causal Analysis Team that determines the root cause of the error and suggests preventative action. These preventative actions are then given to one or more Action teams for planning, approval, implementation, and tracking. The improvements implemented by the Action Teams can result in immediate changes to the processes being used during the current phase, or they may result in changes to processes from past or future phases. In any case, these improved processes now become part of the project’s process assets that can be reused over and over again.