Industrial Strength Open Source Code?
dnnrly asks: "I work for a company that writes software for the pharmaceutical industry. We have to work in quite a tight regulatory environment because some of our code ends up in the process of drug testing. Seeing as the FDA are quite picky about making sure that there can be no errors in testing new drugs, our clients have strict rules that we must follow for coding. We have to review all of the code that is written, making sure that everything is traceable to a design specification. Where we use 3rd party software/code we have to make sure that it comes from an ISO9000 source. This is a bit of a problem when we would like to use open source stuff in our code. Projects like log4net and NUnit would be tremendously useful in our code but we're not allowed to use them because they don't tick the right boxes. Now, *I* know that these projects (and others) are incredibly stable just because of the volume of use that they have seen but that isn't enough for some people. How can we certify such software?"
Simply import it into your own code base, and then review it as if it was written internally. Basically, learn it inside out, as if you wrote it yourself. If that is not legally sufficient, then the laws need to be rewritten since the lines they would be attempting to delineate would at this point be completely imaginary. It doesn't matter whose head it originates from, what matters is that it is fully reviewed and completely understood to the point where everyone on your team is prepared to stand behind the entire body of code. If that confidence comes from actual understand, it becomes irrelevant who wrote the code in the first place. How would it be any different if, instead, it was code written by somebody who no longer works at the company.
...
ISO9000 just means you have documented procedures and you track the steps you take when you follow those procedures.
You shouldn't even need to go to the lengths of merging the code bases.
Document the procedures for auditing and verifying external software to the standards of your internally written software, create an ISO9000 process for tracking those procedures, and follow them.
I have a fair bit of experience on the medical device side, not pharma - but they should be somewhat similar.
The FDA has standards for validationg COTS (Commercial Off-The-Shelf Software). ISO9000 is useful, but not necessary for FDA "stuff". For example, I don't think that any OS (Windows, Linux, etc..) is ISO9000 compliant, but your software runs on it, no? How could that be if ISO9000 was mandatory?
It seems to me that, for the FDA to be happy, you'd need to run some sort of reasonable validation of the COTS software, based on how it's being used; write a set of requirements, write a set of tests that prove that those requirements are met, and go to town. It would be good to recognize in the FMEA (Failure Modes and Effecta Analysis) that the COTS software probably has somewhat of a chance of failure - but then, the FDA (at least on the device side) has already announced that you must assume that software will sometimes fail, no matter how it's been tested. Finally, be exacting about audit trail - versions used, how things were built and installed, and so forth.
If your customer insists on third-party code being ISO 9000, despite the FDA not requiring it, then you're SOL. However, that requirement just doesn't make sense, unless they are not using an OS to run their software on (as described earlier).
Good luck!
ISO 9000 is a documentation process, not a quality process. People don't seem to get that, and the marketing spin around it for years has not exactly made that very clear.
One of the engineers at work keeps a photograph of the Firestone plant that produced all the deadly, defective tires for Ford.
The photo shows clearly:
- The plant was shut down and closed.
- The plant has a large "ISO 9000 Certified" sign on the entrance sign.
ISO 9000 just means that you documented your procedures and you can verify and prove that you followed them. It does not tell you whether or not they're smart, safe, profitable, or anything else about your business.
In other words: ISO 9000 forces a company to document what they're doing, but can't save the idiots from doing the wrong things.
+++OK ATH