Software (Souce Code) Documentation Introduction.
Software Validation commences with a user requirement document (URS). When either management by policy; or an employee by cause; requests that a controlled process is instigated or an existing controlled process requires a serious modification (miner modification would be controlled under change control ), a User Requirement Specification (URS) document is raised. Over the course of several meeting the URS is fleshed out to document all aspects of the requirement. It is essential that the document is properly scoped in order that the procurement , installation, commissioning, validation, user training, maintenance, calibration and cleaning tasks are all investigated and defined adequately.
To scope and define an adequate validation procedure the URS has to be detailed sufficiently for various assessments to be made. The main assessment that concerns us with qualification documentation is the risk assessment. This assessment is only concerned with ensuring that the degree of validation that is proposed; is compliant with the regulatory requirements.
So at this early stage it is required to execute a Validation Risk Assessment protocol against the end user’s requirements. This step is purely to ensure that the more obscure pieces of ancillary equipment and support services are fully understood and their requirement investigated, priced and included in the final issue of the URS; which will be sent out with the Request to Tender. This is an essential stage if the URS is to accurately define what depth and scope of validation is appropriate for the verification that the software will deliver all the requirement detailed in the URS.
To learn more about this Validation Risk Assessment contents, click here; VRA
To purchase a ready to use Validation Risk Assessment document, click here; VRA
It is a mandatory requirement that certain aspects of this assessment are documented and held as a regulatory required record. These are;
Does the software validation require Full Life Cycle validation ?
Does the use of the software produce records that must comply with 21 CFR Part 11 ?
If the data requires to be Part 11 compliant, how is that to be being achieved?
The answers to these questions are required to enable the Validation Plan (VP) to provide sufficient information to the protocol writers, to enable them to define the correct content for the Installation Qualification (IQ). Operational Qualification (OQ) and the Performance Qualification (PQ) protocols.
Full Life Cycle & Standard Cycle Validation.
The outcome of the VRA drives a split in software validation documentation scope, if the VRA categorizes the software validation as requiring Full Life Cycle Validation (FLCV); then a considerable amount of thesoftware validation effort is put into establishing how thesoftware originated, was designed and developed, in order to establish that its basic concept and development can be considered robust , sound and in accordance withbest practices.
The original development plans , code reviews, methods reviews and testing plans must be available to enable this software validation documentation to be executed successfully. Once this proof of quality build is establish, validation then follows a more convention path in code / procedural / security verification / functional inspections and verifications.
Software that is not classified as requiring FLCV treatment, does not require thisdepth of verification into quality build history and is validated mainly by the more convention path in code / procedural / security verification / functional inspections and verification’s.
FDA Expectatios are:
SOP for Computer Equipment Validation.
The SOP for Software Validation documentation continues to be an extremely popular document. This document leads you through the validation process, from the URS to the final P2Q.
SOP for Software Validation (Issue-1)
Software Validation and Testing.
Dynamic Testing.
Dynamic testing verifies the execution flow of software, including decision paths, inputs, and outputs. Dynamic testing involves creating test cases, test vectors and oracles, and executing the software against these tests. The results are then compared with expected or known correct behavior of the software. Because the number of execution paths and conditions increases exponentially with the number of lines of code, testing for all possible execution traces and conditions for the software is impossible.
Static Analysis.
Code inspections and testing can reduce coding errors; however, experience has shown that the process needs to be complemented with other methods. One such method is static analysis . This somewhat new method largely automates the software qualification process. The technique attempts to identify errors in the code, but does not necessarily prove their absence. Static analysis is used to identify potential and actual defects in source code.
Abstract Interpretation Verification.
A code verification solution that includes abstract interpretation can be instrumental in assuring software safety and a good quality process. It is a sound verification process that enables the achievement of high integrity in embedded devices.Regulatory bodies such as the FDA and some segments of industry recognize the value of sound verification principles and are using tools based on these principles.
Establish the End Users high level requirements.
These must be based on the functionality as the end user will see it. They must cover all aspects of using the program and be sufficiently detailed to enable the development team to clearly and concisely understand what the future product plans are.
Define the detailed functionality requirements.
This stage develops and expands the end user’s requirements, and drills down to a sufficient level of detail required for the development team. As each detailed requirement document is completed, it is subjected to peer review and acceptance by a representative from development, quality assurance, architecture, product management, and development management.
Define the program structure and technical design specification
Based on the high level requirements (URS level 1 ), establish a suitable product architecture taking the end user requirements and the required functionality requirements into account. This task should be structured in parallel with defining the detailed requirements.
Product Development.
The source code development team executes the detailed requirements and the technical architecture. This process is best commenced only when both parts of the requirements document have been completed, reviewed and approved.
Quality Assurance.
The QA team must sit in at all stages from conception to completion and hand over to end user. They are not there to review the software. They are there to ensure that best industry practices are used and that company software policy and procedures are strictly adhered to. They will ensure that the program created by the development team meets the defined requirements and is supplied to the end user complete with all necessary support documentation. They will ensure the source code is installed and used in accordance with company requirements practices & procedures, and all relevant cGMP regulations.
Continue at: https://www.validation-online.net/software-validation.html
The text above is owned by the site above referred.
Here is only a small part of the article, for more please follow the link
Also see:
https://dadoswebaxx.weebly.com/
