Post by thread:documentation

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

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}

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

In message <031a01bd4686$0028d580$68000064@up_yours>, jhobbs <spam_OUTjhobbsTakeThisOuTQUIKNET.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.

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

>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

In message <pVmSyHAh6G$0Ew1VKILLspamlfheller.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