Software Validation Processes - Telecommunications software

M

mmclean

#1
My company sells telecommunications software.

In our Quality Manual, I cover off 7.5.2 by stating:

"Due to the complexity of our software, complete validation of the software against requirements is not possible. As a result, we need to be able to show that the processes we use produce correct results. This is done using:
- Root Cause Analysis to identify and fix faulty processes
- Failure Modes and Effects Analysis (review of Design & Development processes with emphasis on possible types of failures) according to the perceived risks and consequences of failure in design and/or development, followed by appropriate preventive action
- Collection of history of failure modes and effects, and their analysis, followed by appropriate preventive action

in addition to requiring that software designers and developers be qualified to perform their functions."

I'd be interested in your comments.
 
Elsmar Forum Sponsor

Al Rosen

Staff member
Super Moderator
#2
IEEE Definition
VALIDATION
"Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled."
So, you are saying you're not capable of showing that the software is able to fulfill its intrended use. I'm not sure that that is acceptable.
 
M

mmclean

#3
Al Rosen said:
IEEE Definition
VALIDATION
So, you are saying you're not capable of showing that the software is able to fulfill its intrended use. I'm not sure that that is acceptable.
My thought was that in a complex application it is not possible to test all of the feasible combinations of usage in a real-world environment - covering both explicit and implied requirements - before shipping the product. That is, some deficiencies may only become apparent in use in circumstances that were not covered in our test suite.
 

Jim Wynne

Staff member
Admin
#4
mmclean said:
My thought was that in a complex application it is not possible to test all of the feasible combinations of usage in a real-world environment - covering both explicit and implied requirements - before shipping the product. That is, some deficiencies may only become apparent in use in circumstances that were not covered in our test suite.
Your specifications should include specific reference to test conditions. You validate the efficacy of the software by verifying that it will do x (and y and z...) under conditions a and b and c...

Your customer should be made aware of the conditions under which the software has been validated. No one expects that there will never be any surprises, as it's not possible to predict all of the possible combinations of hardware, other software, and environmental conditions that your product might be exposed to.
 
M

mmclean

#5
Jim Wynne said:
Your specifications should include specific reference to test conditions. You validate the efficacy of the software by verifying that it will do x (and y and z...) under conditions a and b and c...

Your customer should be made aware of the conditions under which the software has been validated. No one expects that there will never be any surprises, as it's not possible to predict all of the possible combinations of hardware, other software, and environmental conditions that your product might be exposed to.
So are you saying that 7.5.2 does not apply in this case? And that process validation is a 'nice to have'?
 

Jim Wynne

Staff member
Admin
#6
mmclean said:
So are you saying that 7.5.2 does not apply in this case?
7.5.2 (of ISO9k2k) says, in part,
Validation shall demonstrate the ability of these processes to achieve planned results
Which pretty much repeats the IEEE quote that Al Rosen gave you. This is a slightly different case, because 7.5.2 applies to "special" manufacturing processes. There's a difference between software validatation and process validation. What are you trying to find out?

mmclean said:
And that process validation is a 'nice to have'?
No, it's a "necessary to have." I was simply stating the obvious; it's not always possible to anticipate every possible use of the product.
 

Al Rosen

Staff member
Super Moderator
#7
mmclean said:
So are you saying that 7.5.2 does not apply in this case? And that process validation is a 'nice to have'?
You stated that your company sells software. If you design that software, I believe that the validation of the software is covered under 7.3.6 Design and development validation, not 7.5.2 and it does apply. Yes, you might miss something, but you can't say that you can't do it because it is too complex. Your customer is expecting the software to perform the functions that it was intended to perform, so you must check that it does perform them under the defined conditions.
 
M

mmclean

#8
Al Rosen said:
You stated that your company sells software. If you design that software, I believe that the validation of the software is covered under 7.3.6 Design and development validation, not 7.5.2 and it does apply. Yes, you might miss something, but you can't say that you can't do it because it is too complex. Your customer is expecting the software to perform the functions that it was intended to perform, so you must check that it does perform them under the defined conditions.
Right - we do, of course, test our software (validation of the product), and the validation responds to 7.3.6.

However, the original reason I thought that we should say something under 7.5.2 is that complete validation is not always possible - actually, may never be practical.

My reasoning was this: If we manufactured widgets that were required to be 1" +/- 0.1" long, then we could test each widget and determine conclusively if it met its requirement. Then, because production output can be completely verified by subsequent measurement, there would be no need to invoke the provisions of 7.5.2. In the case of non-trivial software we cannot make a conclusive determination, and I thought that the 'gap' should perhaps be bridged by process validation.

If it is sufficient to make the customer aware of the conditions under which the software has been validated (and assuming, of course, that our testing is done to a reasonable level), then it does seem to me that we may not need to validate the process - that is, process validation becomes a 'nice to have'.

Is my logic OK, or am I still missing something here?
 

Jim Wynne

Staff member
Admin
#9
mmclean said:
If it is sufficient to make the customer aware of the conditions under which the software has been validated (and assuming, of course, that our testing is done to a reasonable level), then it does seem to me that we may not need to validate the process - that is, process validation becomes a 'nice to have'.
I'm not sure what "process" you're referring to. If you're talking about the design/coding/testing of the product (software), then 7.5.2 is irrelevant, I think, because you are testing the product. Once software has been validated, documented and controlled, it can't change. It's possible that the process for transferring the software to some transportable medium (CDs, e.g.) might need to be validated as a manufacturing process, but don't confuse the container (the CD) for the thing contained (the compiled code).

The documentation of the software should include the conditions under which it was tested. You can communicate this to the customer in the form of system requirements that reflect the test conditions, and a statement of known incompatibilities. You should also be providing customers with a simple method of reporting bugs (real or imagined), and there should be a process in place to deal with the bug reports, from acknowledgement to the customer to actual updating of the code when it's called for, or updating of the list of known incompatibilities.
 
Thread starter Similar threads Forum Replies Date
C Equipment, Software and Processes Validation for Medical Devices - 21CFR 820.75 (a) ISO 13485:2016 - Medical Device Quality Management Systems 35
E ISO 13485 software validation ISO 13485:2016 - Medical Device Quality Management Systems 6
Y ISO 13485:2015 Software Validation IQ/OQ/PQ ISO 13485:2016 - Medical Device Quality Management Systems 13
R Debug mode in software/device validation IEC 62304 - Medical Device Software Life Cycle Processes 2
M Software verification and validation AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
P Software verification and validation procedure IEC 62304 - Medical Device Software Life Cycle Processes 6
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6
D Software validation team Misc. Quality Assurance and Business Systems Related Topics 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 3
K Software Validation for Measurement Tools used in Process Validation ISO 13485:2016 - Medical Device Quality Management Systems 2
S SOP for ISO 13485:2016 Quality related Software validation ISO 13485:2016 - Medical Device Quality Management Systems 9
K ERP System Software Validation - ISO13485 2016 4.1.6 Design and Development of Products and Processes 9
D Software validation in Medical Equipment Other Medical Device and Orthopedic Related Topics 20
C Looking for simple Software Validation IQ templates. Qualification and Validation (including 21 CFR Part 11) 4
C Software validation - Off The Shelf Software - Web hosted ISO 13485:2016 - Medical Device Quality Management Systems 6
R Validation of Medical Device Hardware containing Software - How many to Validate ISO 13485:2016 - Medical Device Quality Management Systems 1
F 21 CFR Part 11 - Implicit requirements - Validation plan for a Software as a Service Other US Medical Device Regulations 1
R ISO 13485 Software validation procedure and Quality Objectives Monitoring wanted Document Control Systems, Procedures, Forms and Templates 1
S Validation of COTS Equipment plus Software Qualification and Validation (including 21 CFR Part 11) 12
D Software Validation - Contract manufacturer of Components (PCBA's) Qualification and Validation (including 21 CFR Part 11) 7
Pmarszal Software Validation Training Course - Recommendations Training - Internal, External, Online and Distance Learning 3
T Software Validation Certificate (ISO 13485:2016) ISO 13485:2016 - Medical Device Quality Management Systems 19
R FDA Requirements - Printing Equipment Software Validation Qualification and Validation (including 21 CFR Part 11) 1
G Windows 10 OS build Software Validation US Food and Drug Administration (FDA) 1
S Where to keep Enterprise Resource Planning software (ERP) Validation Records ISO 13485:2016 - Medical Device Quality Management Systems 1
C Software validation (4.1.6 ISO 13485:2016) ISO 13485:2016 - Medical Device Quality Management Systems 20
M Software Validation Guidance Suggestions Various Other Specifications, Standards, and related Requirements 6
S QMS software validation - Documentation ISO 13485:2016 - Medical Device Quality Management Systems 5
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
R CNC Software Validation requirements as per ISO 13485:2016 Other ISO and International Standards and European Regulations 8
R Software validation - off the shelf X-Ray Software Quality Assurance 3
S What is the clause in ISO 13485 for SAP Software Validation? ISO 13485:2016 - Medical Device Quality Management Systems 3
P Software validation of Data Exporter ISO 13485:2016 - Medical Device Quality Management Systems 3
A Process Validation of QMS Software ISO 13485: 2016 Cl. 4.1.6 ISO 13485:2016 - Medical Device Quality Management Systems 26
P Software Validation for Equipment - Question ISO 13485:2016 - Medical Device Quality Management Systems 5
D Medical Device Software Tool Validation - Compilers! IEC 62304 - Medical Device Software Life Cycle Processes 7
N When is Medical Device Software Validation required? ISO 13485:2016 - Medical Device Quality Management Systems 6
O Process Mapping prior to Validation and Software to use to Map Process Maps, Process Mapping and Turtle Diagrams 12
S Software Validation – Clause 4.1.6 of ISO 13485:2016 ISO 13485:2016 - Medical Device Quality Management Systems 12
B Could I combine IQ, OQ and PQ for Minitab Software Validation ? Software Quality Assurance 3
R Document Management Software : Validation and other requirements Medical Information Technology, Medical Software and Health Informatics 8
E Software Validation - Clinical Trials US Food and Drug Administration (FDA) 3
K What are the minimum requirements for Process Validation (Software)? ISO 13485:2016 - Medical Device Quality Management Systems 5
R ISO - Clause 7.5.1.3 - CMM Software Program Validation ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
I Validation Software Experience? (Valgenesis, etc.) Quality Assurance and Compliance Software Tools and Solutions 1
M Injection Molding Machine Software Validation Calibration and Metrology Software and Hardware 2
E FDA Requirements for Implantable Medical Device Software Validation ISO 13485:2016 - Medical Device Quality Management Systems 5

Similar threads

Top Bottom