The IQ should assess the software's lifecycle management aspects to be sure that necessary support processes are in place to ensure the software can continually deliver the expected performance throughout its life. These include:
· General management processes (change management, software configuration management, problem management);
· Maintenance processes (backup and recovery, database maintenance, disk maintenance).
· Verification that appropriate Disaster Recovery procedures are in place.
These areas are more abstract than the physical aspects. It's fairly easy to determine if the specified amount of disk space is available. It's far more difficult to determine if the software content management system is sufficient to ensure the proper configuration is maintained across multiple branches. Clearly, though, these aspects cannot be ignored if a full assessment is to be made of the software's ability to consistently deliver required functionality. Most large companies have specialists that can help in these areas. If such specialists are not available, outside consulting can provide invaluable feedback.
externally. For example, if your company purchases and distributes a software package, you will need to accept problems from the field and manage them. You will likely pass on these problems to the vendor for correction. So, even if some processes are contracted out, it does not relieve you of the responsibility to ensure their adequacy.
Audits can be carried out either internally or externally to verify that software lifecycle components are being addressed and managed correctly.
The finding of such audits is usually written-up in an audit report and may be cross referenced from a validation report as necessary.
Personnel
If the use of a system requires special training, an assessment needs to be made to determine if the company has the plans in place to ensure that users are properly trained before a system is deployed. Of course, if the system has been deployed and operators are not adequately trained, this would be a cause for concern.
Consider usage scenarios when assessing training needs. For example, general users may not need any training. Individuals assigned to database maintenance, however, may require substantial skills and, thus, training.
As part of any validation effort, training must be verified – an appropriate training plan must be in place to ensure that all users are trained and that any changes to systems or processes trigger additional training. All
Operational Qualification (OQ) consists of a set of tests that verify that requirements are implemented correctly. This is the most straight-forward of the protocols: see requirement, verify requirement. While this is a gross simplification—verifying requirements can be extremely challenging—the concept is straightforward. OQ must:
· Confirm that error and alarm conditions are properly detected and handled;
· Verify that start-ups and shutdowns perform as expected;
· Confirm all applicable user functions and operator controls;
· Examine maximum and minimum ranges of allowed values.
· OQ Tests the Functional Requirements of the system.
OQ can also be used to verify compliance to required external standards. For example, if 21 CFR Part 11 is required, OQ is the place where the system's ability to maintain an audit trail is confirmed.
Be sure to have clear, quantifiable expected results. If you have vague
Operational
Qualification OQ
“Fast” is subjective. Verifiable requirements are quantifiable (for example, “Response time to a query shall always be within 15 seconds.” A good expected result will give the tester a clear path to determine whether or not the objective was met. If vague requirements do slip through, however, at least define something quantifiable in the test via a textual description of the test objectives.
Performance Qualification (PQ) is where confirmation is made that a system properly handles stress conditions applicable to the intended use of the equipment. The origination of PQ was in manufacturing systems validation, where PQ shows the ability of equipment to sustain operations over an extended period, usually several shifts.
Those concepts don't translate well to software applications. There are, however, good cases where PQ can be used to fully validate software. Web-based applications, for example, may need to be evaluated for connectivity issues, such as what happens when a large number of users hit the server at once. Another example is a database application. Performance can be shown for simultaneous access and for what happens when a database begins to grow.
Critical thinking about what could impact performance is key to developing a PQ strategy. It may well be the case that a PQ is not applicable for an application. The decision and rationale should, once again, be documented in the validation plan.
Performance
Qualification PQ
So if you do IQ, OQ, and PQ, do you have a bug-free system? No. Have you met regulatory expectations? To some degree, yes. You are still, however, expected to deliver software that is safe, effective, and, if you want return business, as error free as possible.
Generally, most validation functional testing is, “black box” testing.
That is, the system is treated as a black box: you know what goes in and what's supposed to come out. (As opposed to white-box, where test design allows one to peek inside the "box," and focuses specifically on using internal knowledge of the software to guide the selection of test data.)
There are a number of other tools in the validation toolbox that can be used to supplement regulatory-required validation. These are not required, but agencies such as the US FDA have been pushing for more test-based analysis to minimize the likelihood of software bugs escaping to the customer. They include:
· Static analysis;
· Unit-level test;
· Dynamic analysis; Easy to Understand Guide to oftware