iSixSigma

Ishikawa Diagram for QA in Software development

Six Sigma – iSixSigma Forums Old Forums Software/IT Ishikawa Diagram for QA in Software development

  • This topic has 10 replies, 10 voices, and was last updated 15 years ago by L.
Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #26357

    K
    Participant

    Hello
    I am working in a Software company.We have Quality Assurance(Testing)department as our bottleneck.I am trying to do the root-cause analysis for this.I am working on Ishikawa Deagram.I need inputs from you all regrading the contents of that diagram.considering the software QA field ,what could be the 4P or 4M for my diagram.Or any other inputs are welcome
    Β 
    Thanks
    Priya
    Β 

    0
    #64065

    Adam L Bowden
    Participant

    6m’s work well..
    Man, Machine, Material, Method, Measure, Mother Nature (Environment)
    Regards,
    Adam

    0
    #64068

    Badri
    Participant

    Dear Priya,
    The classical fish bone diagram that is used in manufacturing can be applied. Process is nothing but conversion of an input to output with value addition. Man, material, m/c,methods can be identified and suitable values(weightage) can be assigned. This will help in quantifying the variables thus leading to effective controls.
    Thanx
    Badri

    0
    #64069

    Chugh
    Participant

    Hi All
    ISHIKAWA is nothing but what is the cause wich is giving u an effect which is a loss a graphical representation.
    For you best is go or 5M + 1E
    Man, Material, Method , Machine , Money & Environment
    Then find out probable factors and then solve them and then monitor them.
    Β 

    0
    #64070

    K
    Participant

    Thanks Badri..
    How about DMAIC concepts.Can we use them in software field to make improvements?
    On what basis or how to define the matrix if we have to start?
    Priya
    Β 

    0
    #64077

    Szentannai
    Member

    Hi,
    there is a well-known scenarios that will lead to the Testing department becoming the bottleneck. Basically if the department tries to maximize the “load” ofΒ  the testers, thisΒ will result in a vicious circle thatr will cause testing to be lateΒ and not helping the developers. (See the book by Poppendieck on “Lean Sw development”Β ).
    If I was in your place I’d start by checking on this.
    Regards
    Sandor

    0
    #64081

    Bianka Brauns
    Participant

    you can use 6M or any other way to “join” the information.. the important is not forget the importants inputs.
    best wishes,
    Bianka

    0
    #64082

    Heebeegeebee BB
    Participant

    I’d lean towards DMADV and utilize DFSS/DFMA principles.
    Β 

    0
    #64083

    abhijit
    Participant

    hi! this is abhijit,
    this is my first contribution towards sixsigma,
    i ve been working as an indudustrial engineer and my core focus used to be on reducing fatigue or the work content,
    my say in whatever i ve read in this will be to focus on one basic thing, where is the scrap?
    this does mean ‘inspection will be loaded only when someone makes mistake, and one will make if the person is not trained or not intend too contribute. so make a format by which mistakes will be categorised into certain groups, then track those mistakes to process goofups, u can say architectural or construction flaws, try and train people not to commit mistakes or if they do….
    anyways i am a prod engg, so does not have a lot info about software field, but basic rule remains the same. attack vital reasons contributing to more inspection workload & then start thinking about the trivial reasons.
    first of all document all the mistakes that are leading to increased workload.
    all the best,
    abhijit pandit

    0
    #64084

    Anshul
    Participant

    Hi Priya,Yes we can use DMAIC concepts in software fields.
    First you need to identify a pain area or problem; solving which will give you high dividends(ROI). THe worst thing that one can do is just look at a problem and start with DMAIC. One need to look at the ROI and moreover check if there is a bigger oppertunity/problem waiting ??There are 3 basic requirement for a problem to be considered for DMAIC. They are
    1. There is a gap in desired and existing performace
    2. You don’t know what and where exaclty the problem or problem cause is.
    3. You don’t know the solution for the problem.Hope this helpsRegards
    Anshul

    0
    #64085

    L
    Participant

    Although QC (testing) is part of quality, it should be a separate entity from QA. The QA Manager should be working with you to find the root cause. Is the bottleneck actually in testing or the QA auditing?

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

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