Defect prevention
- 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
- 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