Light-Weight Software Process for ISO 9000?

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?"

Comments

The Tao of Programming

[Profane MuthaFucka]

This may help you make sense of the ISO 9000 requirements which management has decreed must be used:

  7.2

In the east there is a shark which is larger than all other fish. It changes into a bird whose wings are like clouds filling the sky. When this bird moves across the land, it brings a message from Corporate Headquarters. This message it drops into the midst of the programmers, like a seagull making its mark upon the beach. Then the bird mounts on the wind and, with the blue sky at its back, returns home.

The novice programmer stares in wonder at the bird, for he understands it not. The average programmer dreads the coming of the bird, for he fears its message. The master programmer continues to work at his terminal, for he does not know that the bird has come and gone.

Lightweight ISO-9000 is an oxymoron

[Usquebaugh]

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.

If you look who pushes for ISO-9000 it's large and slow moving companies that are used to a large and wasteful style of doing business. The people that sing the praises of ISO-9000 are not usually the ones who have to do the work.

If I were you I'd look for a way to get out from under ISO-9000. It that's not possible decide wether you want to stay with a company that thinks so little of it's staff that it mandates the use of a procedure that takes thousands of pages to describe.

I've been through BS-5750, ISO-9000, SOX, 21CfrPart11 etc etc etc and it's always the same shit. Software is unlike any other process/tool/discipline that man has ever tried to control, the problems of bad software will not be solved by old and tired audit systems. There is no silver bullet that will address all problems!

Re:Lightweight ISO-9000 is an oxymoron

[carpeweb]

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!

Re:Lightweight ISO-9000 is an oxymoron

[NitsujTPU]

You are wise.

I've witnessed a CMM process developing, but never suffered through ISO-9000.

CMM is interesting in that it has the possibility of being fairly lightweight (at least, level 2 or 3). The problem is that people never get the "point", accountability for ones actions and ability to find out what's going on, and see lots of documents.

It gets worse, because there are always people in charge who practically live for documents, that's why they do things that involve writing lots of them, rather than developing software. Then, you have sycophants who want to ingratiate themselves to these people, they just make lots of "helpful suggestions."

Then, you have a big group of people, kind of lost in what they're doing, but they're going to do it anyway.

In a meeting once, I could sense that our process was getting out of control, and suggested that we have a checklist, so a developer, like I was, at the time, could keep track of all of the pointless crap that he had to do. The checklist idea was added to our process... so, now, the checklist was another thing to do. It had a place for the developer had his manager to sign that he had done each step in the process. My bullets telling me what I had to do to make these people happy became another insane requirement.

When the org in question passed their audit (an external organization that I had been contracted to), they had a celebration touting how many documents they had produced in order to pass. In the end, there was a flood of inconvenient documents that provided no more transparency than there would be in their absence.

I hope that I didn't offend any of my former coworkers with this.

Re:Lightweight ISO-9000 is an oxymoron

[Gojira Shipi-Taro]

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.

Get a consultant for a couple days

[bill_mcgonigle]

Save yourself a man-year of frustration and hire in an ISO9000 consultant for a few days. If you already have a good control process in place (say, Bugzilla and SVN) he can help you write a compliant procedure around it. If you try it on your own, odds are you're going to miss out on some obscure requirement and have to resolve it during an audit anyhow.

I was quite skeptical about ISO9000 at first, but I found that it almost always gets management sign-off and therefore you have an opportunity to encode proper software engineering practices in the procedure. When someone later comes to you with pressure to take shortcuts and crank out crap, you can point back to the procedure and say, 'sorry'. In the end this makes your job happier, despite the bureaucratic trappings of the system.

Vagueness is Good

[Tteddo]

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.

Be Careful

[NullPointer]

When we did our ISO we hired an "expert" who told us, "It is up to you to describe your process, if you want to save a whole lot of grief in the future, make it as simple and sensible as possible."

In other words, forget what you're reading and create your own process, reporting, and compliance documents. Otherwise, you'll be creating a monster that will require several full-time ISO employees whose job description will essentially be, "make all other employees miserable".

Our expert's advice was well worth her fee. Any "expert" you hire who advises a massive documentation effort is simply creating future contract work for themselves.

Re:Be Careful

[clem.dickey]

if you want to save a whole lot of grief in the future, make it as simple and sensible as possible

Ditto. I work for one of the big, slow companies. We just hoped ISO 9000 wouldn't make us any slower. Our ISO experts told us "The specific process is not too important. What is important is to have a process, that you know and follow it, and that you can show [documents which demonstrate] that you follow it."

Don't do it.

[Stoutlimb]

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?

Re:Don't do it.

[tomhudson]

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.

Re:Don't do it.

[stonecypher]

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.

YOU set the standard in ISO 9000

[Invisible Now]

You already have what you seek, grasshopper. People misunderstand the spec to require something ponderous. Maybe that's appropriate for an Airbus flight control system or my anti-lock brakes, but you said you design research systems. Presumably your CUSTOMERS (The ISO key) favor development speed over a few bugs and flexibility over reliablilty (assuming no one gets killed)
So reread the spec - it's asking you a question, not giving you a rulebook. What do your customers really want? What tradeoffs do you plan for to meet their needs? Everything in the spec is a question. The audit process is establishing how well you meet your organizations own unique goals.

Obligatory Dilbert Cartoon

[Chabil Ha']

I agree with Scott Adams about the whole thing.

ISO 9000 is easy....

[rogersba]

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!

ISO 9000

[JohnWiney]

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.

ISO 9000 Compliance

[Statman]

First of all who ever wrote that ISO9000 is a complete joke does not know what he/she is talking about. I work for a medical device manufacturing company and let me tell you I sure as hell would not want a medical device being used on me if the the company manufacturing the device was not ISO 9000/13485 compliant. As for your question, remember the software only has to be validated and a few quick test scripts should do the trick. The hardest part is just writing out validation procedure or work instruction. I do some ISO consultation on the side as well. If you need any help then PM me and I will help you out!

Standards help keep nimble competitors at bay

[ClosedSource]

"If you look who pushes for ISO-9000 it's large and slow moving companies that are used to a large and wasteful style of doing business."

It's not just becuase those companies like to waste time and money. These big, costly standards are a great way for big companies to compete with small, nimble competitors by getting business and government customers to require them. The increased cost and decreased efficiency keeps small companies out of the game.

Pick your favorite process and stick to it.

[Randolpho]

Others have mentioned this, but I feel the need to add my own pair of pennies.

ISO 9000 boils down to two things:

1) Write down how you are going to do something.
2) Do it the way you said you would.

To that end, pretty much any software engineering approach is ISO 9000 compliant, provided that you 1) write down how you are going to develop software and 2) develop software the way you said you would.

That means you can pick any "lightweight" software development process you like. Agile, XP, TDD... whatever you want to do, you can do it, as long as you 1) write down how you are going to develop your software in an Agile/XP/TDD way, and 2) develop software the way you said you would.

That is the most important point

[vinn01]

have a process, that you know and follow it, and that you can show that you follow it .

That is the most important point: "Say what you do - do what you say" -- and be prepared to demonstrate it to someone else.

The "do what you say" part is probabaly the biggest stumbling block. Most corporate cultures are not tuned to that much honestly. Corporations are used to having a pile of rules/regulations/processes and selectivly following them. That does not work with ISO9000.