DPMO in Software

Six Sigma – iSixSigma Forums Old Forums General DPMO in Software

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #65812


    Defect and opportunity count in software development is an interesting concept to deal with.

    DPMO is a high-level management tool to gauge performance and associate dissimilar processes on a common scale. Defect opportunities must matter to the customer, be independent and only increase numerically with increased complexity. For the customer using software, a defect is a failure of functionality in execution, and opportunities could be measured in terms of screens, functions or use. For my PC operating system and myself, one opportunity is using the computer (each day), and one defect is a system crash or program failure (BSD) which requires a tiresome reset. I get about 2 enforced resets each month, about 10% failure or 2.8 sigma. 6 sigma performance is one reset every 800 years.

    At the lower level, defects per unit (DPU) might be a better internal metric for the software developer, as it relates well to the cost of poor quality. The fundamental unit of software code is a statement – which may or may not be a line of code depending on how you write. If the aim at ‘Six Sigma’ is to write only half the code – reuse existing code – and to write code only once (and perhaps have no need to test), then a defect is any write, rewrite or test where unnecessary. This counts any rework (one write where not needed, and three edits to one statement count as four defects) and is a good measure of where the errors are. DPU is a good metric in manufacturing, and can be related back to ‘Sigma’ and DPMO, which is often the only metric that can be used in many service processes.

    If you use DPMO at the low level then you miss all the rework and correction and testing that is wasted effort and costing money. You might write each line three times over and vote on the best, then test and correct then test again. Perfect code but such a lot of wasted effort! Conversely if you use DPU at the high level with the customer, then you may say ‘we write a million lines of code, and there is only one bug – that is 6.4 sigma’. However if that one bug causes my system to fail each and every time I use your code, then I will go elsewhere.

    Think of it like this – perfection for the developer at ‘Six Sigma’ is writing code only once, and not having to test. Perfection for the customer is code that does what they want, when they want it, as expected, and without failure. To be world class you need both!




    How would you define Defects per Million Oppurtunities / Defects per Million Parts in Software ? Does it mean Million Lines of Code ? What is the norm for measuring defects in software for process sigma calculations ?

    Thanks in advance


Viewing 2 posts - 1 through 2 (of 2 total)

The forum ‘General’ is closed to new topics and replies.