Slashdot Mirror

← Back to Stories (view on slashdot.org)

Light-Weight Software Process for ISO 9000?

Posted by ryuzaki0 on from the distilled-to-its-bare-essence dept.

Disgruntled Software Engineer asks: "I work for a large engineering firm and it was recently decided in our company to have our software be ISO 9000 compliant. There exists a software development process in my organization, but it is extremely heavy-weight -- over two-dozen documents totaling 200 pages each! My team doesn't even have the time to read such a process, much less abide by it. I have been tasked by my team in creating a more light-weight process for our team to follow so that our software can pass the audit that is coming soon, but reading through the convoluted ISO website is not helping, and a 'plain English translation' that I found of the standard contains a bulleted list that is 17 pages long! I have not been able to get any idea of how to design a light-weight software engineering process that is ISO 9000 compliant with all of these extremely verbose documents and somewhat odd requirements. Also, the software that my team produces is more for research than for productization, and the dynamic nature of research does not mix well with the rigidity of a software process. What are the bare-minimum set of requirements for ISO 9000 software engineering compliance? What are some tips for designing a process that is light-weight and causes minimal damage in terms of efficient software development? Do you have any interesting experiences or wisdom regarding ISO 9000 and software engineering?"

6 of 56 comments (clear)

  1. Vagueness is Good by Tteddo · · Score: 5, Informative

    In my experience with ISO 9000 it does not matter how much detail you get into, you just have to document the procedures for a process and everyone must follow the documentation. For instance if you are writing up the process for buttering your toast the following works fine:
    1. Scoop up butter with knife.
    2. Apply to toast.
    as opposed to:
    1. Get butter from fridge.
    2. Get knife from drawer.
    3. Get bread and place in toaster. Wait until done.
    4. Scoop up butter with knife.
    5. Apply to toast in back and forth motion covering toast.
    When they audit you they make sure you follow the procedures you have documented, and you can get into trouble if you really get into details.

  2. Don't do it. by Stoutlimb · · Score: 2, Informative

    RTFA? The wikipedia article you posted about the ISO 9000 standard specifically states that software development and other creative processes do not work well with ISO 9000.

    so the answer is to give up, and just wing it?

    1. Re:Don't do it. by stonecypher · · Score: 2, Informative

      That all said, when NASA switched to the PSP and TSP, their bug rate dropped by almost 90%, and they had to generate far less documentation. Just because you have a team with an amazing record doesn't mean there isn't a better way. NASA has learned this several times.

      --
      StoneCypher is Full of BS
  3. Obligatory Dilbert Cartoon by Chabil+Ha' · · Score: 5, Informative

    I agree with Scott Adams about the whole thing.

    --
    We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
  4. ISO 9000 is easy.... by rogersba · · Score: 4, Informative

    It all boils down to this:

    1) Write down what you're going to do.
    2) Do it.
    3) Write down that you did it.
    4)....
    5) Profit!

    Now, FDA rules for medical device software are a whole other game, so maybe my perspective is skewed. Ah, to forget ISO 13485 and go back to _just_ ISO 9000!

  5. ISO 9000 by JohnWiney · · Score: 5, Informative
    I have written such a process, so I know it can be done.

    The purpose of ISO 9000 is not to tell you what your process is. You can use any process you want, as long as your customers will accept it. What ISO 9000 requires is that you be able to prove you are following it. If your process requires code reviews, you must have recorded minutes describing the results, and the follow-up, for each one. If you require iteration plans, you must keep records of those plans. If you require the use code analysis tools, you have to record the results of the use of those tools regularly, to show you are meeting whatever benchmarks you choose. And so on. You do whatever you want - just prove that you really are doing it.

    Put in your documented process everything that you do that you can document as having been done, and that you (as a group) want to keep doing. Do not put anything in your process that you cannot document. Keep a separate description of "best practices" - things that you expect developers to do, but that you do not want to insist on until you are more comfortable with them. In time, some of these methods may migrate into your documented process, but only when you are sure you want to be held accountable for following them.