PDP 11/45 partial success.

Scott wrote: I've seen cases where releasing a new firmware revision requires nearly fifty new part numbers assigned, and over five hundred signatures on all the resulting engineering documents (including but not limited to ECOs). The firmware release has to be signed off, which might take five signatures. Suppose there are eight EPROMs involved. Each one gets a new part number assigned for the new revision, and each of those has an ECO that needs seven signature. The EPROMs go on a daughterboard, so the BOM and parts placement diagrams have to be revised, each of which needs another seven signatures. The motherboard into which the daughterboard plugs in needs its parts list and BOM revised, for another seven. The parent card cage assembly needs its parts list and BOM revised, for another seven. The chassis parts list and BOM are revised... the system parts list and BOM is revised... the ship list is revised... the customer documentation is revised... and I think I missed a bunch of other things in the chain as well. Oh yeah, there was paperwork for the part number assignment for the new revisions of all the subassemblies and assemblies. And updated test specifications and procedures. And that's for a product that was not for use in medical or life- critical applications, and that didn't need any certifications other than the usual UL and FCC Part 15. It turned out that there was *much* less paperwork involved in releasing a software update that shipped as a separate "product", to be installed by the customer or an FE. At one time I thought that perhaps a higher level assembly parts list and BOM should refer to the "most recent revision" of a subassembly, but after a little more thought I realized that doing it that way would be disasterous because you'd completely lose traceability. Eric