I need to know for a job I am looking at. Google finds many hits mostly for pharmacutical companies. This also happens to be the type of company that I was looking at when I saw the phrase in the first place.
“COMPUTER VALIDATION DEFINITION
Documenting that the computerized system does what it’s supposed to do, and
ALWAYS does what it supposed to.”
If the answer is this simple, why have I never heard of it before? (I have a CIS degree and have worked at several IT related jobs.) Also, why does this “computer validation” concept seem to be related to the pharmacutical industry?
Just to take a wild guess here, but I would imagine the pharmecutical company is using computer modelling for new drugs and chemicals, and want to make sure their computers are accurate (so their models and simulations don’t give the wrong results).
Remember the Pentium math bug a few years back, where Intel got egg on their face because their Pentium IIs(?) couldn’t divide properly? That’s what Computer Validation tries to prevent.
I don’t think this term is industry specific. IIRC this is an older, somewhat genralized term dealing with circa 1960 and 1970 computers and “certifying” (assumedly via various diagnostic procedures) that the computer is operating correctly which would have been a very big deal in the tube and early transistor eras.
Modern CPU’s are so reliable and have powerful multi-layered built in diagnostic hardware verfication routines built in, so this verification process external to the computer is pretty much un-necessary for the vast majority of tasks.
I would imagine that if a computer is extremely complex and the task is mission critical like some academic, defense or medically related uses, some type of external verification is probably still performed.
Machinery used to count ballots has to be validated with a lot of test runs. Years ago I was marginally involved in counting punch out ballots. After each run, the machine was jammed with chad and had to be vacuumed out.
More on what hedra has to say (she and I work for the same company, in diffent roles).
Validated software, hardware, and processes allow an auditing agency (could be the FDA/Pharma, but it’s also applicable in chemical manufacturing, Law, Financial/Fiscal, etc) to verify that:
Things are done in a standard fashion,
That the ‘standard fashion’ is trackable (who did what, when),
That the standard fashion is appropriate to the task at hand,
That the ‘standard fashion’ does what it claims, and nothing else,
That the ‘standard fashion’ has no undocumented work-arounds,
That the ‘standard fashion’ would not ‘break’ under any forseeable strains or pressures,
That ‘standard software’ is stable and well understood,
That the ‘standard software’ does not alter information in any unplanned and controlled fashion,
That if the ‘standard software’ should fail, that event is captured and reported,
That emergency recovery schemes are robust, well-planned, feasable, and appropriate,
That the hardware will work with all the software, and that various software packages work well with each other and the hardware in any validated configuration,
That the hardware does not change, in any unexpected fashion the information it proccesses,
That the ‘standard hardware’ is reliable, robust, and fault-tollerant…
The list goes on for volumes.
One small example: I helped put together a nifty little hack that filled a technology gap as a client was shifting from one process to another. It took a week and a bit to put the app together, and it was a simple process (although the code wasn’t quite so simple). For a tool that was planned to last in production for less than six months, filled exactly one role, did exactly one thing, my team spent 5 additional weeks validating it. We killed a small forest-worth of trees on documentation, too. Now that it’s going into full-scale production, we’ll kill a few more trees updating the validation, but it’ll only take a week or two to complete the process.
One of the nice things about validated systems, software, and processes: Once it’s validated, it’s easier to maintain, and changes are easy to track and document.
Or: Say you use SAS to analyze your data, as is very common in the pharmaceutical industry. Say SAS comes out with it’s latest version, V9. You’ve been using V8. The FDA does not require you to validate SAS, that would be ridiculous. But if your institution upgrades to V9, they require you validate all of the SAS programs you’ve written, to be sure that they produce the same results in V9 as they did in V8. If not, any discrepancies must be scrupulously tracked down, diagnosed, and documented.