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

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.

Re:The Tao of Programming

[Evil Pete]

Actually, I think it is funny that the parent post is rated "Funny" instead of insightful.

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

[tomhudson]

Of course, if the PHB understood in the first place that ISO is not about initial quality, but about being able to track down who to blame when something fails, they might not be so enthusiastic.

The whole theory behind ISO 9000 is that, by being able to track down what failed, you can fix it and do better next production run. Doesn't work in software, because software is not a "production run". You don't want version 2, 3 and 4 to be an exact copy of version 1.

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

[Anonymous Coward]

ISO-9000 is not meant to ease the software development process.

Wrong.

ISO-9001 can be horribly misused. However, the purpose of the 9001 is to make business sense. Yes, being auditable is one very strong point, usually much more important than some mysterious "ease".

But with "ease" you do not mean ease of calculating defect trends, ease of finding corrections (from e.g. VCS), etc. you mean ease of not doing your job by "easily" correcting bugs without testing or any followup.

ISO9001 does not bury stuff into

Re:Lightweight ISO-9000 is an oxymoron

[dnessl]

I've been at a software development shop that obtained ISO-9000 certification while I was there, mostly just to be able to bid on DoD/GSA (U.S. government) work.

Some ISO 9000 history: Originally, ISO 9000 was for manufacturing. Each station had a written procedure, was detailed enough for even a blue-collar, high-scool dropout, and it had few variables: make 100 ("how many") widgets that are green ("color"). So, not much variability. In 2001, ISO 9000 tried to include service industries, like software deve

Re:Lightweight ISO-9000 is an oxymoron

[Gojira Shipi-Taro]

Every place I've ever encountered ISO-9000, it's been more insideous. It's been a way of trying to get the skilled workers to document everything they did into an instruction manual so that unskilled workers could be hired off the street and "follow the ISO-9000 docs" to get the job done.

A previous employer tried to get me to do that (write ISO 9000 docs) so that he could hire my replacement at an even lower rate than he was paying me. I was working IT as a network administrator right out of college.

He's ou

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.

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.

Re:Standards help keep nimble competitors at bay

[budgenator]

My industry is getting pushed into FDA 501K requirements, primarily to stiffle foreign competition; I'm making dentures, easily removeable, life is about 5 years, If it it was cardiac pacemakers I could see the need, right now document retention is 30 years for a device with a 5 year clinical life expectantcy

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.

Re:Vagueness is Good

[kenh]

I wouldn't say vagueness is good as much as limit yourslef to required specificity.

I worked at a major telcom software house, and they were going for ISO9000 certification in the mid-90's while I was there. The key seemed to be that you have a process, that you follow the process, and that you document your following the process. Also important was a feedback loop that included not only internal sources (bugzilla), but external (a way for customers to lodge complaints/requests that is tracked and managed (b

Re:Vagueness is Good

[Gr8Apes]

Your point is good, but you need to add the clause:

Describe your process with the minimum detail necessary.

ISO9000 isn't about adhering to any particular process, it's about fully documenting your processes and deviations from that process. You get certified by an auditor coming in and comfirming that your processes are adequately documented.

How does this help software? It prevents that "brilliant" new marketing VP from coming in and demanding, simply demanding, that you add targeted customer content based

Yes, ISO is easy this way!

[Roadkills-R-Us]

We went through this at one of the largest computer companies around, 15 years ago. We were told by management, ``Just document what you do enough that anyone can do it from the docs. Since you've already done that for most things, just do it for the rest. Don't get fancy.''

So we didn't. Straight text docs, simple instructions. Just cleaned up what we had laready written (didn't take that much), put things together in order and added a few checklists and charts, filled in the blanks, and made up a high

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

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.

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;

Re:Don't do it.

[stonecypher]

That all said, when NASA switched to the PSP [tri-bit.com] and TSP [tri-bit.com], their bug rate dropped by almost 90% [cmu.edu], 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.

Re:Don't do it.

[stonecypher]

That "non-existant article" is a 25 minute movie with slides and hard statistics. Nice try.

Re:Don't do it.

[rnelsonee]

That might not be an option. I just got an email from my boss today saying I need to read up on ISO compliance since we're going to become an ISO9000 company. The reason is because we do contract work for the government, and we're trying to get some contracts that are only available to ISO9000-compliant companies. So the submitter may be in a similar situation.

As an aside, I'm really glad to see this article. I plan on bookmarking it and printing out the good comments to show to my boss...

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 [uwaterloo.ca].

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.

Re:ISO 9000

[Keick]

I've been through it as well, and I can tell you the most painless solution is to choose a standard software development process, like IEEE 12207. A lot of companies are using the IEEE as of the last 10 years or so. We adopteded it about 5 years back, and it's actually quite nice, and completly tailorable per project.

But no matter which process you use, I HIGHLY recommend that you invenst in tools that will help you follow the process. One such tool is Seapines TestTrack which we've also been using for the

Ha!

[/dev/trash]

Good luck. ISO 9000 is THE biggest scam. Ever.

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

Its all about good change-management

[the_arrow]

ISO 9000 is basicly about tracking changes. That's it.
Everytime you make a change in the program, a document should be written saying who did it, why, when, and what. Everything done to the program should be tracable. And no, a CVS log will not do, but it may help.

Here's your problem!

[montyzooooma]

"There exists a software development process in my organization, but it is extremely heavy-weight -- over two-dozen documents totaling 200 pages each! "

I've no experience of ISO9000 in a software development environment but I just ditched it last year at the engineering company I work for, having run the quality system since BS5750 days (UK).

If you have a few thousand pages of software development processes to be picked over by an ISO auditor then your life is going to be a living hell. Ditch them and try t

Re:Here's your problem!

[MeSat]

I agree with the single sheet idea. The basic idea is if a new employee arrives, they should be able to grab the manual or sheet for the process and know what to do without having to ask questions.

I took an ISO9000 course many years ago as I worked for a small company that needed to become certified for some contracts. Being small, we couldn't afford the ISO Guru.

The one thing that the course taught us was that a single sheet of a clear and easy to follow process is better than a volume of detailed

The case against ISO 9000

[dave_macleod]

You need to get hold of a copy of John Seddon's book "In Pursuit of Quality: Case Against ISO 9000". If you're stuck with a mandate to comply then at least it should help you avoid the most common pitfalls. There's an article at http://www.iso.org/iso/en/iso9000-14000/addresourc es/articles/pdf/viewpoint_4-98.pdf [iso.org] where he summarises his position.

Here's the essense of the requirements

[Geccie]

From what I've seen, the requirements ask you to document what you do as a process and illustrate that you follow the process. The problem is that the process becomes overarching to address the worst case. Therefore, many steps can be skipped.

Here's an example, you produce a web server - You need to build your software - document how you do that. You need to package your software - document how to do that. Deploy on a test server - document that process too. Setup a test server - document that. How d

ISO 9000 is Your Friend

[occamboy]

I've actually run an effort to put software under ISO 9000 control - we passed the third-party audit, and we got a lot of software completed, and our product got approved by the FDA, and we followed our own rules - so I guess that it was a successful effort.

As you write, one key is to keep things lightweight, so that everyone can read and follow the procedures.

Another key is to write your own procedures - what usually happens is that someone snags a copy of another company's procedures and tries to use them

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.

Re:Pick your favorite process and stick to it.

[slcdb]

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.

If I'm ever put in charge of developing an ISO-9000 compliant software development process, I'll be sure to add a requirement that each engineer is required to drink a beer after fixing every bug!

Lightweight PLC

[ChrisLeif]

Many years ago I found Brian Lawrence's product life cycle site: http://www.coyotevalley.com/ [coyotevalley.com] He has one of the simplest, cleanest and most flexible processes I've ever used. I even managed to explain it and get upper management to use it!

Light Weight ISO 9001 Software Development

[richardavitar]

Cliff,

You may not want to hear this, but read on it gets better...

As a consultant who supports companies like yours with ISO 9001 (in fact it was one of the software team who sent me the link) there is a way to set up a light weight system and the only people you'll have trouble with are your internal ISO 9001 advisers. Why, because often the over-kill gets put in to ensure the company and therefore their position does not fail an assessment.

If I was advising you I would be asking you what you actually did

It boils down to...

[smitherz]

Four things...

1) say what you do
2) do what you say
3) be able to repeat the process
4) be able to prove it (audit trails)

This goes for CMM/SEI also.