iSixSigma

DPMO

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #26360

    boettler
    Member

    I would like to calculate DMPO in software development, but I am running into prooblems with calcualting the number of oppertunities in the DPMO calculation.  Any suggestions??

    0
    #64072

    McD
    Participant

    Calculating DPMO for software development has always been problematic.  As long as you never want to compare yourself to other organizations, almost anything will work as long as you apply it consistently.
    There are a couple of fairly obvious approaches.  Many people’s knee-jerk is to assume a line of code is an opportunity.  This leads to defect rates that are artificially good, and tend to make you believe that you are better than you really are.  Another approach is to take a customer centric approach.  One product is an opportunity.  Your customer sees only the product so that is your chance to get it right.  That, of course, leads to artificially high defect rates.
    There is some research that seems to indicate that there are around five opportunities in a function point.  That sort of approach, although not at all intuitive, does lead to defect rates that seem somewhat consistent with what we would expect.  But obviously, it’s hard to make some sort of theoretical justification for that approach.
    At the end of the day, though, it’s not the DPMO that matters.  What we care about is our ability to improve the process.  It may be more helpful, then, to track more software-centric measures like defect containment rates.  Those rates are meaningful, and something we can easily get buy-in to improve.  It doesn’t help us compare ourselves to other parts of the organization or other organizations, though, which can be useful in some contexts.
    So I don’t think there is an easy answer.  The best plan is to do what works best for you.
    –McD
     

    0
    #64073

    boettler
    Member

    Thanks for the info. 
    I was looking at using a standard peer review criteria for each review and having each criteria be used as a oppertunity.  Not sure this approach will work?????
    Any thoughts…..
    Rob
     

    0
    #64074

    McD
    Participant

    If your objective is to improve the review process, then perhaps something like defect find rates for the reviews might be in order.  Or, taking the other tack, how many defects escape the review?  (Hard to know that without historical data on which to base total defect estimates, or waiting until the product has had time to prove itself.)
    If you have historical data, for example, it might be interesting to look at characteristics of the reviews (who participated, how much time was spent) against the success of the reviews as find rates or escape rates.
    –McD
     
    –McD
     

    0
    #64076

    AVY
    Participant

    Hi Rob
    If your metric is defect leaked at each stage of developement process, you already have a variable data with you. So in the case of variable dat, you donot need the number of opportunities.
    If using the opportunties concept in Software develeopement, you need to identify all the falure modes and for that requirement capturing process has to be very robust. When you prepare the unit test plans, you also identify the expected output. The number of expected functional reqmnts. can be taken as the opportunities in this case.
    Hope this helps.
    regards
    AVY
     

    0
    #64104

    AG
    Participant

    DPMO computations in software based on functional or even non-functional requirements as an opportunity could be misleading. Because for the decently sized project the number of opportunities will be a lot and hence the DPMO numbers might reflect a rosy picture, which may not be a true picture perceived by the customers.
    Also, considering Line of Code as an opportunity will also lead to a similar problem of inflating the number of opportunities. At the same time this is not at all a customer centric metric because customer is not really bothered about the size as long as functional & non-functional requirements are met.
    I feel it is more relevant to:
    1- Convert the functional & non-functional requirements to the User Acceptance Tests (UATs)
    2- Short list the critical UATs from the overall list, that is, critical to customer
    3- Treat this Short list of UATs as the number of opportunities and measure DPMO numbers on these opportunities.This will give you a better picture of DPMO of the product quality as perceived by the customer.Thanks!

    0
Viewing 6 posts - 1 through 6 (of 6 total)

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