Light-Weight Software Process for ISO 9000? 56
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 (Score:5, Funny)
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 (Score:2)
Actually, I think it is funny that the parent post is rated "Funny" instead of insightful.
Lightweight ISO-9000 is an oxymoron (Score:5, Insightful)
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 (Score:4, Interesting)
I wish I had a few mod points
One could infer the same about Disgruntled Software Engineer's firm, which already has
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:
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
Re:Lightweight ISO-9000 is an oxymoron (Score:2)
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 (Score:4, Insightful)
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 (Score:1, Insightful)
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 (Score:1)
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 (Score:1)
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 (Score:3, Interesting)
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 (Score:4, Insightful)
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 (Score:2)
Get a consultant for a couple days (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:1)
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 (Score:1)
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! (Score:2)
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 (Score:3, Insightful)
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 (Score:3, Insightful)
That is the most important point (Score:3, Insightful)
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. (Score:3, Informative)
so the answer is to give up, and just wing it?
Re:Don't do it. (Score:3, Interesting)
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 <
Re:Don't do it. (Score:3, Informative)
Re:Don't do it. (Score:2)
Re:Don't do it. (Score:2)
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 (Score:4, Insightful)
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 (Score:5, Informative)
ISO 9000 is easy.... (Score:4, Informative)
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 (Score:5, Informative)
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 (Score:1)
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! (Score:1)
ISO 9000 Compliance (Score:2)
Its all about good change-management (Score:1)
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! (Score:2)
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! (Score:1)
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 (Score:1)
Here's the essense of the requirements (Score:1)
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 (Score:2)
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. (Score:3, Insightful)
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. (Score:2)
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 (Score:1)
Light Weight ISO 9001 Software Development (Score:1)
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... (Score:1)
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.