Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Light-Weight Software Process for ISO 9000? 56

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?"
This discussion has been archived. No new comments can be posted.

Light-Weight Software Process for ISO 9000?

Comments Filter:
  • Re:Don't do it. (Score:3, Interesting)

    by tomhudson ( 43916 ) <barbara,hudson&barbara-hudson,com> on Wednesday July 26, 2006 @09:16PM (#15788066) Journal
    Actually, they don't work at all.

    Now if you REALLY want to go quality-wise, you could try NASA's approach. Of course, it means that your LOC will be down to almost nothing, but, hey, what you DO write will be amazingly bug-free.

    <url:http://www.fastcompany.com/online/06/writestu ff.html>

    The 420,000 lines of code are backed up by 40,000 PAGES of specifications. And 20 years by 260 people. That's 6 lines of specifications for every line of code.

    In other words, your "hello world" program:

    #include &lt;stdio.h&gt;

    int main(int argc, char( argv[], char* env[])
    {
                    printf("hello, world!\n");

                    return 0x00L;
    } // eof ... would need a full page (66 lines) of documentation specifying what it does, and would take 4.5 days to specify and write. But it WOULD probably be bug-free.
  • by carpeweb ( 949895 ) on Wednesday July 26, 2006 @09:17PM (#15788071) Journal
    ISO-9000 is not meant to ease the software development process. It's design is to make the process auditable. It takes some very good ideas about development and totally buries them in bullshit.

    I wish I had a few mod points ... well said!

    One could infer the same about Disgruntled Software Engineer's firm, which already has

    ... a software development process [with] over two-dozen documents totaling 200 pages each!

    Standards seem like a great idea. Unfortunately, some people extrapolate to conclude that more and more detailed standards must be an even greater idea. (e.g., "a bulleted list that is 17 pages long!")

    Having said that, I think there may be a way to give DSE an improvement on two fronts. As I see it, DSE needs two things:
    1. A document to hand to the PHBs that will hopefully achieve ISO 9000 compliance or satisfy the PHBs that it is "better" (not as crazy as it sounds, or maybe crazier, depending on your PHB quotient)
    2. A streamilined process to follow in the real world
    DSE's own set of documents would make a great basis for an ISO submission. It's already heavy-weight and not even read by the people who are supposed to follow it. Perfect. What needs to be done with this (not a small task, unfortunately, but probably one that can be pawned off on some unsuspecting intern or "process expert", i.e., someone without anything important to do, like work) is to create a mapping between DSE's existing documents and the ISO 9000 documents. The desired outcome of this seemingly pointless and mind-numbing exercise, of course, is to show the PHBs how DSE has already complied with ISO 9000 --- hopefully even exceeded them. No one reads much except section headers and lead/summary paragraphs (and mabye, maybe the first page of a 17-page bulleted list), so this is definitely a feasible direction. Just claim that the existing (documented, not real) processes cover every one of the ISO 9000 requirements by drawing arrows between the two sets of requirements and then saying something like "we developed our own internal discipline in response to intrinsic requirements of our domain and found that they were, in fact, more rigorous than ISO standards". Preferably, the "map" should actually be a wall-sized map with lots and lots of arrows. Color-coding would be a nice touch (e.g., all the arrows proving DSE already complies with ISO category X should be in Cyan ...). If you can somehow laminate the thing, you're golden, because most people are afraid to question anything encased in acetone or plastic, and if they are tempted, DSE can simply remind them how expensive the map is, which should get the PHBs to respect it and even bless it.

    The second objective involves real work, so it needs to involve real people (not interns or "process experts"). Make the existing documentation match what truly works and throw out the rest. Note that, because of the requirements of the first objective, "throw out" needs to mean something like "re-document" (by segregating the truly important and valuable into short documents that are used and keeping the rest in impenitrable documents that no one but interns and process experts will read or discuss. It will also give them something to do.

    Note: if you have an intern or process expert who really adds value and don't think it's fair to relegate them to the space I've identified, then reward them with real titles that reflect real value.

    There is no silver bullet that will address all problems!

    Awww ... and I was so on the same page with you, until you went all cliche on me!
  • by Gojira Shipi-Taro ( 465802 ) on Wednesday July 26, 2006 @11:20PM (#15788678) Homepage
    Meant to mention this. the whole concept was developed for manufacturing (which is the main purpose of my former employer, a Hearing Aid manufacturer). For that purpose it does have a use. It's still abused there to try to create a manual to eliminate the need for skilled workers.

    It's been expanded to IT and Software, as well as other purposes for which it is not suited. These are professions that require actual expertise, rather than the ability to mindlessly and accurately follow a set of instructions.

If all else fails, lower your standards.

Working...