Slashdot Mirror
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?"
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!
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
"Knowing everything doesn't help..."