Truncated match.
PICList
Thread
'Documentation'
1998\03\03@135305
by
jhobbs
|
I have a topic here that should be of interest to anyone doing code
development. If you are not familiar with this already, chances are you
will be in the near future.
ISO9000
For software developers, yes firmware as well. BTW if you are developing a
product that will need FDA approval, the FDA is now starting to take a
closer look at firmware.
What does this all mean, document, document, document.
How many of you have in place, have created, or plan on creating a
'Procedure detailing the process for firmware development'?
I am hoping we can share some details of plans already created that work.
I work for a company that designs medical equipment, these devices require
both FDA and ISO documentation. I am now starting a plan to create firmware
procedures. Part of my plan is to look at existing procedures for guidance.
To begin with I found a book called "Software Quality", ISBN 0-201-63198-9
that has plenty of good information on providing a skeletal outlook. I have
an idea of what the procedures need, but I would like to hear from others on
what they think or have experienced.
Here are the ISO Standards that I believe pertain to software/firmware
development.
ISO9001 Quality Systems
ISO9000-3 Guidelines for the Application
ISO9004-2 Quality Management
ISO9004-4 Quality Management and Quality System Elements
If this seems like a dry and overwhelming topic, that is probably because it
is. But unfortunately that does not detract from its importance.
Take care -Jim
1998\03\03@161218
by
Stevenson, Brad
Jim,
We are currently in the process of becomming ISO certified. In fact
there are two auditors walking around here at this very moment.
Currently our procedures require that I submit tenative flowcharts or
pseudo-code to be approved before I cut any code. I use a product
definition given to me by my supervisor to base these flowcharts on.
That's the way I supposed to happen. In a world of "I need it
yesterday" it's sometimes hard to find the time to do things the way
they should be done.
I hope there is some response to this thread. I am looking forward also
to hear how other companies are handling firmware development.
Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880
http://www.dpl.ca
> {Original Message removed}
1998\03\03@185904
by
William Chops Westfield
ISO9000
How many of you have in place, have created, or plan on creating a
'Procedure detailing the process for firmware development'?
We have one. Actually, it covers all software development, and we call it
GEM: Great Engineering Methodology (aka the "funnel, tootsie roll, plunger"
model. Really. We have posters. :-)
While there are clearly good points to this (mostly in terms of saving
documentation of things that have happened - design and code reviews, etc),
it's overall pretty much a joke - ie the actual benefits to eventual product
quality derived from the pieces necessary to pass ISO9000 certification
are about zero. Many of the traditional elements of "quality processes"
seem inapplicable to software development, doubly so in a small shop (ie
our process mandidates peer reviews of specifications, design, and code.
Who does that if you have one programmer?)
(there *is* a fair amount of flexibility to this - you can define your own
process to a large extent, and then you just have to stick to it. cisco's
plan allows for a largely paperless version, for example, and reviews and
such via email.)
I'd also expect the certification costs to be prohibitively expensive for
a small shop (audits every 6 months, etc.) See Dilbert for comments on
iso9000 - copies of those strips are up all over here...
BillW
OOPS. I mean "Of course cisco has a set of iso9000 procedures! We always
follow them exactly and they've been a major factor in our being the #1
vendor of computer networking equipment by ensuring high product quality."
1998\03\04@003931
by
Leon Heller
|
In message <031a01bd4686$0028d580$68000064@up_yours>, jhobbs
<spam_OUTjhobbsTakeThisOuT
QUIKNET.COM> writes
{Quote hidden}>I have a topic here that should be of interest to anyone doing code
>development. If you are not familiar with this already, chances are you
>will be in the near future.
>
>ISO9000
>
>For software developers, yes firmware as well. BTW if you are developing a
>product that will need FDA approval, the FDA is now starting to take a
>closer look at firmware.
>
>What does this all mean, document, document, document.
>
>How many of you have in place, have created, or plan on creating a
>'Procedure detailing the process for firmware development'?
>
>I am hoping we can share some details of plans already created that work.
>
>I work for a company that designs medical equipment, these devices require
>both FDA and ISO documentation. I am now starting a plan to create firmware
>procedures. Part of my plan is to look at existing procedures for guidance.
>To begin with I found a book called "Software Quality", ISBN 0-201-63198-9
>that has plenty of good information on providing a skeletal outlook. I have
>an idea of what the procedures need, but I would like to hear from others on
>what they think or have experienced.
>
>Here are the ISO Standards that I believe pertain to software/firmware
>development.
>ISO9001 Quality Systems
>ISO9000-3 Guidelines for the Application
>ISO9004-2 Quality Management
>ISO9004-4 Quality Management and Quality System Elements
>
>If this seems like a dry and overwhelming topic, that is probably because it
>is. But unfortunately that does not detract from its importance.
Interestingly, ISO9000 just says that you have to have procedures, and
work to them. The procedures could be wrong, and you could be producing
crap, but you could still get ISO9000 certification.
Leon
--
Leon Heller: .....leonKILLspam
@spam@lfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of my AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.
1998\03\05@010727
by
paulb
Of course Bill's shop is ISO9000 certified, isn't it?
*The* Bill.
Cheers,
Paul B.
1998\03\05@121515
by
Tom Handley
|
Jim, this is an excellent subject. While I'm very `meticulous' when
it comes to documentation, I have not studied the ISO900x standards in
detail. I'm looking forward to this topic.
- Tom
At 09:23 AM 3/3/98 -0000, you wrote:
{Quote hidden}>I have a topic here that should be of interest to anyone doing code
>development. If you are not familiar with this already, chances are you
>will be in the near future.
>
>ISO900
>
>For software developers, yes firmware as well. BTW if you are developing a
>product that will need FDA approval, the FDA is now starting to take a
>closer look at firmware.
>
>What does this all mean, document, document, document.
>
>How many of you have in place, have created, or plan on creating a
>'Procedure detailing the process for firmware development'?
>
>I am hoping we can share some details of plans already created that work.
>
>I work for a company that designs medical equipment, these devices require
>both FDA and ISO documentation. I am now starting a plan to create firmware
>procedures. Part of my plan is to look at existing procedures for guidance.
>To begin with I found a book called "Software Quality", ISBN 0-201-63198-9
>that has plenty of good information on providing a skeletal outlook. I have
>an idea of what the procedures need, but I would like to hear from others on
>what they think or have experienced.
>
>Here are the ISO Standards that I believe pertain to software/firmware
>development.
>ISO9001 Quality Systems
>ISO9000-3 Guidelines for the Application
>ISO9004-2 Quality Management
>ISO9004-4 Quality Management and Quality System Elements
>
>If this seems like a dry and overwhelming topic, that is probably because it
>is. But unfortunately that does not detract from its importance.
>
>Take care -Jim
>
>
1998\03\05@192104
by
M Walter
|
>We have one. Actually, it covers all software development, and we call it
>GEM: Great Engineering Methodology (aka the "funnel, tootsie roll, plunger"
>model. Really. We have posters. :-)
>
>While there are clearly good points to this (mostly in terms of saving
>documentation of things that have happened - design and code reviews, etc),
>it's overall pretty much a joke - ie the actual benefits to eventual product
>quality derived from the pieces necessary to pass ISO9000 certification
>are about zero. Many of the traditional elements of "quality processes"
>seem inapplicable to software development, doubly so in a small shop (ie
>our process mandidates peer reviews of specifications, design, and code.
>Who does that if you have one programmer?)
>
Bill;
I have the same type of problem at work, except that we have to follow a
different standard called QS9000. It is the automotive industry's (ie the
Big 3's) way of making sure that everyone (their suppliers but not them) do
things right. I've worked at both QS9000 and ISO9000 companies as well as
military suppliers, and QS9000 is the worst.
But I think I'm getting the hang of it. All you have to do is have some
piece of paper (memo, meeting minutes, etc) to file showing you have done a
particular thing such as a design review. So I call a review with my team
memebers, they stare blankly while I go over my design, and I put the
meeting minutes in the book. Sure is fun (I've got one to do tomorrow). You
just have to learn the game.
Mark Walter
1998\03\15@081200
by
rartym
|
In message <pVmSyHAh6G$0Ew1V
KILLspamlfheller.demon.co.uk>, Leon Heller writes:
> Interestingly, ISO9000 just says that you have to have procedures, and
> work to them. The procedures could be wrong, and you could be producing
> crap, but you could still get ISO9000 certification.
That's right, and as a result it's easy to laugh it off as a load of
nonsense, which we do fairly regularly. However, there's another way
of looking at it, probably not the way it was intended but nevertheless
a useful way: ISO procedures are only as good as the people that
produce them, and therefore a company that values the opinion of its
most competent engineers should allow them to redefine those procedures
as and when they see fit, on a case-by-case basis, so that reality
drives the paperwork rather than the other way around. It's possible
to treat this as an opportunity, a way of treating procedures as a
dynamic way of passing skills downwards rather than as a joke.
I've yet to see a company with that much vision, but I predict that in
the next few years this will change, as the Rise of the Teccies makes
itself felt. For the time being, irrelevant procedures merely get
ignored, rather like inappropriate speed limits on motorways, and on
the whole sanity prevails.
Rich.
--
Existing media are so disconnected from reality that our policy debates
spin around a fantasy world in which the future looks far too much like
the past. nano.xerox.com/nanotech/MITtecRvwSmlWrld/article.html
1998\03\15@083028
by
rich
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- Today
- New search...