DPMO calculation for a Six Sigma for Imroving DRE
Six Sigma – iSixSigma › Forums › Old Forums › Software/IT › DPMO calculation for a Six Sigma for Imroving DRE
- This topic has 3 replies, 3 voices, and was last updated 14 years, 2 months ago by
Don Strayer.
-
AuthorPosts
-
April 24, 2008 at 9:07 am #26783
Ravi S PandeyParticipant@Ravi-S-PandeyInclude @Ravi-S-Pandey in your post and this person will
be notified via email.Hi All,Can someone help me out on this.
I am in a Software development organization & doing a project aimed at improving the DRE(Defect Removal Efficiency) measure of my organization. But in the measure phase i’m having trouble defining the number of opportunities when i’m taking a Software project as one unit.0April 25, 2008 at 10:47 am #65057Hi Ravi,
The no. of defect opp depends on the total no. of CTQs in your improvement project. for ex. if there are 20 requirements related to your DRE improvement projects, there are 20 defect opp.
hope this clarifies query.
Regards,
Ramesh0April 25, 2008 at 12:43 pm #65058
Ravi S PandeyParticipant@Ravi-S-PandeyInclude @Ravi-S-Pandey in your post and this person will
be notified via email.Thanks Ramesh,But i’m still facing a problem. the actual scenario is as follows.
We are having many field defects in our projects. the projects are tested internally as well. The organization’s business goal is to achieve 90% overall DRE.
Ive counted the field defects across all projects delivered during our sample duration. that Become our Defects. 1 Project is considered as 1 unit.
so if we take the number of oppurtunies in a project , they can be too many e.g. every LOC can have a defect. on the other hand if we take the occurence of one or more fied defects in a project as an opprtunity, then they become very less and we get negative sigma level.
the problem is How many oppurtunities per unit will be there.
Regarding CTQ’s, they are, Internal defects and Delayed delivery.
Please help0April 29, 2008 at 7:45 am #65062
Don StrayerParticipant@Don-StrayerInclude @Don-Strayer in your post and this person will
be notified via email.It’s an interesting problem. Ideally we’d have full requirements traceability into code so that every “place” in the code where a defect might be present traces back to a specific CTQ. In the real world of current software development practice that just doesn’t happen. What I do, and what I recommend to my clients, is to apply three rules:
1. Do not confuse black box with white box. An opportunity is a place where failure to meet a CTQ is possible. The number of opportunities for black box testing will be different from white box. With black box you don’t know what’s happening in the code so it’s valid to treat each field in a form, for example, as one opportunity. With white box, or code analysis, you’re looking for all the places in the code where a defect might be present. LOC is not a valid unit, as you realize, since there may be more than one opportunity in a single line.
2. A defect is a failure to meet a CTQ. Other “defects” may be found during reviews and testing. Document them but do not include them in DPMO. Report them as “non-CTQ issues”.
3. The ratio between opportunities and potential defects must be 1:1. Proper test coverage or code analysis often entails multiple “opportunities” to uncover the same defect. These are not the same as opportunities for the defect to occur. Do not proliferate the counts of either opportunities or defects. Every defect should relate to a specific opportunity. If you find more than one defect for the same opportunity, refer to rule 2.
Admittedly this is fuzzy measurement. But most software development is not software engineering. If it was we wouldn’t be struggling with DPMO.0 -
AuthorPosts
The forum ‘Software/IT’ is closed to new topics and replies.