iSixSigma

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 contains 3 replies, has 3 voices, and was last updated by  Don Strayer 11 years, 5 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #26783

    Ravi S Pandey
    Participant

    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.

    0
    #65057

    AT
    Participant

    Hi 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,
    Ramesh

    0
    #65058

    Ravi S Pandey
    Participant

    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 help

    0
    #65062

    Don Strayer
    Participant

    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
Viewing 4 posts - 1 through 4 (of 4 total)

The forum ‘Software/IT’ is closed to new topics and replies.