iSixSigma

Opportunity for software (DPMO)

Six Sigma – iSixSigma Forums Old Forums Software/IT Opportunity for software (DPMO)

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

    new to software
    Participant

    For Six Sigma believers only,
    I’m currently planning for a six sigma deployment on a software / hardware(electronic) development company and I start with the metrics. I want to have a DPMO/Sigma level as our universal metrics.
    My question is how do I count the opportunities for software program? I’m planning to use the defects/line of code multiplied by 1million/OPPORTUNITY
    Thanks,
     
    new to software

    0
    #64609

    McD
    Participant

    DPMO for software is a kind of a tough nut.  Generally, you would like the “opportunity” to be defined in some meaningful way, but also in a way that leads to credible values.  You also want a metric that is reasonably reproduceable and realistic to produce.
    Defining a line of code as an opportunity will lead to very high sigma values.  Since software is perceived as being unreliable, these very high sigma values will be taken by pretty much everyone as being meaningless.  Lines of code are also something that are not visible to the customer, so are not really in keeping with the philosophy of satisfying the customer.  Further, in the early stages of the process where the most critical work occurs, there are no lines of code to count, so almost by definition DPMOs decrease as the project proceeds.
    Another view is to take a requirement as an opportunity.  If you fail to meet the requirement, you have failed to satisfy the customer, and that is your opportunity.  This can be hard because satisfying a requirement is often difficult to measure objectively.
    Still another view is to take the application as an opportunity.  After all, the application is the chance you have to interact with your customer, and whether his experience is good or bad is really what matters.  Obviously, this doesn’t take into account large versus small applications, and puts a lot of pressure on to categorize defects as somehow not counting.
    There has been a fair bit of work around defining opportunities in terms of size.  Some believe that the most useful approach is to count something like five opportunities per function point.  Although this isn’t terribly satisfying in some ways, it does permit meaningful, objective DPMO measurements.
    –McD
     

    0
    #64611

    vignesh
    Member

    hai,
    you cant fix like that, since its not practicable.
    better u take the FUNCTIONAL POINTS as a opportunity.
    it will be ease in collecting the metrics too.
    regards
    vignesh
     
     
     

    0
    #64623

    howe
    Participant

    At the end of the day, DPMO is simply a measure of defect density. In the manufacturing world which was the birthplace of DPMO, it has been proven to be a good metric and of course 3.4 DPMO is a goal that many embrace.Software has long used defect density as a way to normalize the measurement of defects and of course KLOC is the traditional measure. And yes, KLOC has its critics because some computer languages are more verbose than others. Use of function points has its adherents as well.The problem I have with six sigma as a goal for software development is that software development is substantially different than manufacturing. Development by its nature is prone to defects because you are creating something that is new. Can you imagine DEVELOPING anything significant on the first try with only 3.4 defects per million opportunities? On the other hand, most of us feel that it is reasonable to REPLICATE a design thousands, hundreds of thousands, or millions of times with only 3.4 DPMO.In software we want to release our product with very few defects. If DPMO has any application, it would be with respect to post-release defects. This is when you define defects as a product defect. However there are other ways to define defects.One way we look at defects in my company is according to each phase of the development life cycle. Our goal is to find and fix bugs in the phase in which they were injected. Each phase has some method for reviewing work products and trying to detect the bugs injected in that phase and those that escaped from upstream phases. Note that I’ve switched to the word “bug”. If we had perfect bug detection methods, we would find every bug injected in a given phase — and would have zero escapes. We could view any escapes as defects in our bug detection process. We can analyze escapes to understand what went wrong with our bug detection process that allowed those bugs to escape.This is a more realistic approach, IMHO, to defect measurement during the development process. Of course we would like to minimize our bug injection but realistically I doubt that we’ll get to 3.4 DPMO. But measure it anyway to see what your process capability is and then try to make it better. I wouldn’t get hung up on the measure of defect density, however. Pick one and use it consistently.

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

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