iSixSigma

what are Six sigma tools for Sofware?

Six Sigma – iSixSigma Forums Old Forums Software/IT what are Six sigma tools for Sofware?

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

    MG
    Participant

    Hi everyone,
    I am green belt certified and have been working mainly on hardware side. Can anyone help me out with what are the different 6sigma tools available for software industry?
    Mukesh

    0
    #64406

    Felix
    Participant

    Hi,
    We can use many six sigma tools in the software sector like FMEA, QFD, hypothesis testing, KJ, Fishbone, brainstorming, pareto, map, Kano, Gaant chart…. and many.
    Its all about how effectively on the right place we’re going to use.
    Regards,
    Felix
     

    0
    #64407

    MG
    Participant

    Hello Felix,
    Thanks for your response.I was looking more towards examples like –
    a)QFD: I have been using it for requirement analysis and feature extraction.
    b)Fishbone & pareto: for performing the defect-root cause analysis.What is the tool used for brainstorming? Which are the other processes where we can use such tools?Regards,
    Mukesh

    0
    #64417

    McD
    Participant

    Mukesh
    Be a little careful in looking at tools.  Six Sigma is more about the process than the tools, and although most Six SIgma tools are applicable in software, and generally superior to the traditional software tools, there are areas where tools less commonly used in manufacturing are especially valuable in software.
    Further, don’t get DMAIC and DFSS confused. In general (very general), you would use DMAIC to improve your development process and DFSS to design the software.  This doesn’t mean that you might not have a process so bad that you need a clean sheet of paper, and thus would choose DFSS for your process, nor does it exclude the possibility of using DMAIC to improve a piece of software, but these are the exceptions.
    If you think about a new piece of software, problem one is understanding the customer needs.  We have some traditional tools that work reasonably well, and QFD can help us translate the user needs into software features.  But often our understanding of the user needs is weak.  A recent posting spoke of “empathy” as a high prority requirement.  Clearly, that sort of requirement tells us nothing.  Tools like KJ can help us get a deep understanding of what the user is trying to tell us.  More traditional market research tools such as focus groups and surveys shouldn’t be ignored either, but those are often best done by market research organizations that have expertise in the area.
    Once we have taken the user needs and translated them into features perhaps using QFD, the Pugh matrix is a common way to make a feature selection. However, for a more complex situation the Pugh matrix can be a little bit of a problem.
    If we use conjoint analysis to understand the Kano sensitivities, and understand software sizing, we can model the feature-customer satisfaction space, and make data-based decisions on features instead of just putting a finger in the air.
    At this point, we can create our DFSS scorecard and then we can vet future design decisions against their effect on the scorecard, again allowing us to move our decision making in a more data based direction.
    By maintaining our traceability of requirements down to code, perhaps with the help of a little more QFD, we can track whether the feature costs we expected can be maintained, and if course corrections are needed, we can again make defensible decisions.
    As we get down into testing, this traceability helps us understand out coverage of what is important to the user, and of course, DOE, as well as a number of other tools, can often be helpful in developing our test strategy.
    Much of this relies on sizing, which is a place where we tend to be weak in software, but in manufacturing, it is so obvious it doesn’t even bear mention. A successful Six Sigma practitioner in software needs a deep understanding of software sizing, and a commitment to tracking the product size.
    At the end of the day, building software really isn’t all that different from building a car. Once we start thinking about the problem in a systematic way, and with a DFSS prejudice, we find that most of the tools are applicable, and where they aren’t, there is some software analogue that accomplishes the same goal.
    –McD
     

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

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