Title: Defect Prevention-How to prevent defects in the process!
墨初 知识笔记 133阅读
Defect Prevention Solution
80% of our problems/defects are caused by 20% of our activities! Conception
What is DP? Defect prevention, so that defects will not occur. Defect prevention is a process to improve quality and productivity by preventing defects from being injected into products. DP means that we spend 20% of our energy to solve 80% of the problems! At first, it is the most important part of RUP process, but it is necessary for all software projects that need high quality and efficient development. What does it bring to the project? What are the effects of quality, efficiency and effectiveness defects? We usually know that our development process is as follows. 0 ">
The bug in different step costs different effort. Etc, the requirement phase bug wastes design, develop, test and production; the develop phase bug waste testing and production.
What’s the difference between Defect and Fault?
Defect is the bug happens in development process before UAT (User Accept Testing and Production).
Fault is the bug feedback from Users, Customers and other roles after put into production environment.
What’s DP Function?
Get what’re commonest defects in whole project process in advance. And prevent them happens, no wasting effort happens. Then the efficiency has been improved, the project quality has been improved too.
Indeed, DP is helpful for various stages besides project development own, including personal life, studying and business and so on.
Why Hold DP?
Bugs are wasting project team time, including project managers, developers, testers and all participators. Bugs always cannot be avoided. But we can hold the action preventing/decreasing the repeated bugs. That’s why DP comes. It collects the history bugs data into common causes, and makes all members aware on these common causes to decrease the bugs repeatedly.
DP Objective
The quality objective of activities like defect prevention and phase kick-off meetings to ensure that the project can have more effective and efficient and high quality.
Defect prevention planning is undertaken both at the organization level and at the project level so as to plan the activities well in advance with a specific goal.
The purpose of this document is to provide guidelines for defect prevention planning, conducting, phase kick-off meetings and causal analysis meetings in various projects. However the company adopts RUP/Agile/XP development process.
So, after DP process, it increases each role’s awareness to caused defects.
DP Actions
1. Causal analysis meetings to identify the root cause (top common cause) of defects and suggest preventive actions;
2. The team to implement the preventive actions;
3. Kick-off meeting to increase awareness of quality issues specific to each development phrase;
4. Data collection and tracking of associated data. (Bugs records)
(Work Process I)
(Work Process II)
What’s Pareto chart mentioned in above diagram?
Take a virtual example. The following chart is Pareto chart. The bug number comes from statistics of last few weeks.
In last 4 weeks, there are 38 bugs on IE5.0/5.5, 20 bugs break the GTL Guide Line, 15 bugs is because of environment compatible…
So, from following Pareto chart, we can get IE5.0/5.5 is commonest issue in our last weeks.
So, from the DP process, we got the common cause. And we do the analysis on it. The team member need to take consider: Why it’s the commonest problems? How to avoid it in next months? What’s objective of solving it in next weeks? How measure the actions? When we can improve to a new level?
After we finish the actions/solutions, put it into a document. And give it to every member for awareness. And testers need to analyze and track the bugs weekly and get the recent analysis, indeed, a 10 minutes review meeting for the whole team is preferred.
When the improvement phrase ends, the team holds a meeting reviews the improvement. If the result is fine, we take the action to the next/new common cause.
In this way, we improve our development one by one. That’s clear and definite.
How to get the common cause?
We use fishbone diagram, as following
Every sub pivot in this fishbone diagram represents an abstract bug cause. In this way, we can easily get the common cause: GTL Guide Line.
DP Effect
From my past experience, normally the correct actions will improve the development obviously. But after the actions and main focus, the bug will be back. But compared to the beginning case, it’s much better.
The following chart shows the achievement of DP. (It’s not true data. It just comes from my past experience on DP Coordinator position.)