Computer system validation, Computer software assurance and Digital transformation
From Copy Paste documents, paper printouts work to digital way of validation. Critical thinking approach is required towards validation to challenge
How do we solve this problem with all new age computing where intelligence programmed in system?
We need to adopt computer software assurance where the focus is on the critical thinking and not the documentation. An ideal validation process should have options to create requirements, bugs, tracking the issues and ensuring the critical requirements are well tested. (Both scripted and un-scripted way). Following article explains a sample use case to adopt paperless validation cycle.
- Creating URS from the scratch – Defining problem statement, objective , scope of the requirements
- URS should be internally discussed and recorded in a well-documented way
- Each URS should be categorized and prioritized clearly
- Once this is done, take cross-functional requirements like engineering & maintenance, quality, IT. This should be specific to the business use case and problem statement.
- We should have a web based online tool to collect all these requirements in a specific template and sort the requirements before routing for the approval process
- Decide if the requirements can be an off the shelf product or a custom specific solution
- After defining the requirements, form a validation team with end users, QA, IT , E&M etc.
- Ensure that everyone in validation team knows the complete process of testing and evaluation of the product.
- Validation lead has to be assigned for the project. We should adopt scrum way of project execution. (I will write a separate article on the scrum way of CSV validation)
- Preparation of project plan with expected start and target date for each document. SLA should be defined for the review and approval cycle.
RISK ASSESSMENT (CAN BE A PARALLEL ACTIVITY DURING VENDOR SELECTION PROCESS)
- We should have a system to create risk as we define the requirements. Defining risk and test cases can be a parallel activity while we write the URS.
- As per FMEA guidelines, for all high priority requirements try to have a risk assessment as per the organization template.
- This risk assessment should be a group activity.
- We should have a web-based tool to have feedbacks and discussion on the defined risk, severity, probability of occurrence and detectability.
- These are very subjective assessment. However, if this is executed with cross-functional teams, the quality of risk assessment will be good.
VENDOR SELECTION PROCESS
- If we have multiple service providers for the defined business problem, we should have online evaluation process for each vendor.
- Create a requirement checklist and define the acceptance criteria for the requirements.
- After initial screening & NDA, the registered vendor can do a self-evaluation for the requirements.
- Based on the vendor’s response, decide for the next steps for evaluation , demo , cost vs budget , PO and selection process
LEVEL OF FULFILMENT (1 TO 6) – RESPONSE FROM MULTIPLE VENDOR
- The Feature and/or requirement is covered in the standard layered software or infrastructure
- Standard Feature and/or requirement, where no configuration or only default configuration, which can be done without any analysis, will be required.
- Configured Feature and/or requirement, where function(s) will be highly configured to meet requirements
- Customized Feature and/or requirement, where function(s) will be custom coded to meet requirements
- The Feature and/or requirement has been met by an alternative solution.
- The Feature and/or requirement cannot be met.
PAPERLESS TEST CASES CREATION AND EXECUTION
- Based on the URS, category and priority, the validation team should create test cases.
- Each test case should be associated with one or more requirements.
- Each test case should have environment, checklist to be evaluated, expected result.
- Environment related test cases: All the external factors like power requirement, temperature requirement, facility requirements can be recorded in a video with timestamp or pictures (screen shot) using a tablet or a mobile device.
- Non-LAN related system: If the system or instrument is not within the local network, we should a process to do a USB data transfer of screenshots. This process should be as per IT SOP, as there is a manual way of data transfer between two systems.
- LAN connected system – We can record the screen during the test execution or take screen shots using some desktop tools and update the test case with actual results.
- After the test case execution, route the documents for approval, review and electronic signature.
- In case of any discrepancy, a ticketing system should be there to create a “Bug” and re testing, process should be handled after issue closure.