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?"
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.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I hereby submit this as the least commented story ever.
Either the subject is just painfully boring or we are having another power outage.....
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)
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.
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.
NULL
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?
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..."
I agree with Scott Adams about the whole thing.
We're all hypocrites. We all have hidden parts, it's the contrast between them that make us more a hypocrite than others
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!
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.
Good luck. ISO 9000 is THE biggest scam. Ever.
The company i work for recently went through this and all you have to do is:
Define what it is you want to document, is it the whole process from start to finish or just one small part. Dont try to do it all at once, when you get certified you can change and refine the process if necessary.
Once you decide what to certify, document what youre already doing.
Then, audit it yourself. can you really prove you did what youre already doing, if you cant, leave it out of the process, you can still do it, just dont document it.
Organize an internal auditing team and make sure youre strict on this.
Next step, once you see that your documentation is too complex and theres no way you can do it, simplify the process by not going into detail, an example of this is, we needed to certify that our new hires were given a tour of the building, we just put that in but didnt specify a timeframe for this, and we schedule this activity with different areas via email notifying when we would be taking new hires in and that is our evidence, the email itself.
last step is simple, make sure everyone knows the process, so keep it simple, and youre ready!!!
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!
"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.
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.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
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 to condense the philosophy down to something that will fit on one side of a single piece of paper. With double line-spacing.
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 where he summarises his position.
Any opinion expressed is also that of my employer - another benefit of being self-employed.
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 do you test the software? Document that. Now put the documents in order.
There are three reasons for this: 1) That a new employee or subordinate can take over a task and perform it properly. 2) A task may be so complex that it is difficult to perform it twice in exactly the same way especially if it is only done every 6 months. 3) Your job can be outsourced.
Have no fear, your value is in your solutions, not in how repetitive or mundane processes are performed.
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. Other companies are different than yours. Do what works for your people and your product.
ISO9000 basically says three things:
1. do what you say you'll do
2. say what you actually do
3. don't let stuff fall between the cracks
1. and 3. are relevant to software development - 2. is aimed at the sales and marketing.
1. is a matter of having a process in place - having specs to work and test against, and so forth. Standard lifecycle stuff.
3. is best served by having a single place for everyone to enter any info that might affect the code - bugs, features, customer gripes, whatever. Once a week, have a cross-functional meeting - decision-makers from R&D, marketing, and whoever else is needed to MAKE DECISIONS. Then go through the list of issues, and make sure priorities are correct.
Having 2-3 pages of coding standards is also helpful. My personal favorite for the first rule is something like "It is the responsibility of those who write code to make the code's function quite clear to other programmers. All of the other standards are suggestions that may be bypassed for the sake of clarity of code - but think twice before you discard them."
Writing all of this up should take no more than 10-20 pages - try to make them somewhat "conversational", and use lots of flowcharts, so it's not too dry to read.
Good luck!
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.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Many years ago I found Brian Lawrence's product life cycle site: http://www.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!
I've also dealt with FDA & Medical Devices & the processes.
This distinction here is that the FDA regulations are *useful*. It is a safer world we live in because of these regulations. After working in that industry for 6 years, I came out with a pretty secure feeling that stuff that does get these approvals works *far* more reliably than your average desktop software. Apparently FAA regulations on airline autopilot software are also very strict and useful.
ISO 9000 in contrast, does *NOTHING* to insure that the resulting software is better. It's a bureaucracy for bureaucracy's sake; and does nothing except act as a barrier to entry for small companies and an excuse for yet another expensive consultant to drain the resources of small companies.
For a 2 line summary
The fact that ISO 9000 is so easy to get if you cough up the $ for a consultant is a joke (as you pointed out) isn't the problem. It's that unlike FDA regs, ISO 9000 does more harm than good.
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 higher level doc. Our department passed with flying colors.
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.
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 to deliver your software and use this as a basis to move forward. It is understanding this core software development thread that is the key and this in turn is how we keep it light and 'real'. Real processes that are audited pass assessment because that is what the people are doing and it can therefore demonstrate without any problems.
So what can get in the way of this panacea?
Firstly, and I have never yet found someone who isn't, it is based on people wanting to do a good job. By this I mean that no-one is actually trying to avoid things like checking what they have done works etc. Secondly, you have not made any reference to the TickIT scheme through which your company may achieve ISO 9001 for software development. In either case we would need to talk further so I leave an open offer to help.
Best regards,
Richard
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.