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

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

[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 shit. It makes it easy to make processes which bury stuff to shit, but its purpose is completely opposite.

I do the (programming/designing) work, I praise the IS0-9001 and I work for a smallish company.

While it is true that bad software will not be solved by audit systems, it is also true that good software can rarely be made without one (unless all the involved are very smart).

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.

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

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.

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.