Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses and that the particular requirements implemented through software can be consistently fulfilled.
General Principles of Software Validation: Final Guidance for Industry and FDA Staff.
General Concept
MSR Technology Group has domain expertise in end-to-end CSV that FDA and other global governing bodies require. Our team of experts has experience in the entire lifecycle of CSV, as depicted in this diagram.
How We Can Help
What to know
Design and development planning must result in a plan that defines necessary tasks, methods for reporting and resolving anomalies, essential resources, and management review requirements, including formal design reviews.
A software life cycle model and its associated activities, as well as the tasks required for each software life cycle activity, should be identified.
How we can help
Typical planning tasks our professionals assist with include:
- Risk or Hazard Plan
- Configuration Management Plan
- Software Quality Assurance Plan
- Software Verification and Validation Plan
- Reporting Requirements
- Formal Design Review
- Other Technical Review Requirements
- Problem Reporting and Resolution Procedures
What to know
Requirements Development entails identifying, analyzing, and documenting information about the item and its intended application. The allocation of system functions to hardware/software, operating conditions, user characteristics, potential risks, and projected tasks are vital. In addition, the requirements should specify the software’s intended purpose.
How we can help
i3 infotek professionals can help you with
- Preliminary Risk Analysis
- Traceability Analysis
- Description of User Characteristics
- Listing of Characteristics and Limitations of Primary and Secondary Memory
- Software Requirements Evaluation
- Software User Interface Requirements Analysis
- System Test Plan Generation
- Acceptance Test Plan Generation
- Ambiguity Review or Analysis
What to know
The software requirements specification is transformed into a logical and physical representation of the software to be implemented during the design phase. The software design specification describes what and how the software should perform. Due to the project’s complexity or to ensure that individuals with varied technical responsibilities can comprehend design information, the design specification may include both a high-level summary and detailed design information. The finished software design specification requires the programmer/coder to adhere to the agreed-upon criteria and design. A comprehensive software design definition eliminates the need for the programmer to make ad hoc design decisions.
How we can help
Our services during the design phase include:
- Updated Software Risk Analysis
- Traceability Analysis – Design Specification to Software Requirements (and vice versa)
- Software Design Evaluation
- Design Communication Link Analysis
- Module Test Plan Generation
- Integration Test Plan Generation
- Test Design Generation (module, integration, system, and acceptance)
What to know
For usage in a new application, the software may be produced either through coding (i.e., programming) or by assembling previously programmed software components (e.g., from code libraries, commercial software, etc.). Coding is the software activity that implements the comprehensive design specification as source code. Programming is the least abstract stage of the software development process. The final phase of software requirements decomposition is where module specifications are turned into a programming language.
How we can help
Our expertise covers the following tasks of the coding phase:
- Traceability Analysis
- Source Code to Design Specification (and vice versa)
- Test Cases to Source Code and to Design Specification
- Source Code and Source Code Documentation Evaluation
- Source Code Interface Analysis
- Test Procedure and Test Case Generation (module, integration, system, and acceptance)
What to know
Software testing involves executing software products under known settings with defined inputs and documented results that can be compared to their predefined expectations. It is a time-consuming, challenging, and flawed endeavor. Therefore, early planning is necessary for effectiveness and efficiency.
How we can help
Software Developer testing offerings include:
- Traceability Analysis
- Test Planning
- Structural, Functional Test Case Identification
- Traceability Analysis – Testing
- Unit (Module) Test Execution
- Source Code Interface Analysis
- Test Procedure and Test Case Generation (module, integration, system, and acceptance)
What to know
The terminology around user site testing might need to be clarified. User site testing is also referred to as beta testing, site validation, user acceptance testing, installation verification, and installation testing.
The term “user site testing” comprises all these and any additional testing outside the developer’s controlled environment for this guidance. This testing should be conducted at the end user’s location using the hardware and software that will be part of the system’s installed configuration. Either actual or simulated use of the software being tested inside its intended operating environment is used to conduct the tests.
How we can help
Software Developer testing offerings include:
- Acceptance Test Execution
- Test Results Evaluation
- Error Evaluation/Resolution
- Final Test Report
Corrective maintenance refers to alterations made to the software to repair bugs and problems. Perfective maintenance involves modifying the software to increase its performance, maintainability, or other characteristics. Adaptive maintenance is the process of modifying software to make it usable in an altered environment. When changes are made to a software system, either during initial development or post-release maintenance, sufficient regression analysis and testing should be performed to verify that areas of the software unaffected by the change were not affected. This is in addition to evaluating the validity of the implemented change through testing (s).
The validation work required for each software update depends on the type of change, the development products impacted, and the impact of those development products on the software’s operation. Careful and thorough documentation of the design structure and interrelationships of various modules, interfaces, etc., can reduce the effort required for change validation. The effort required to validate a modification entirely also depends on how well the validation of the old software was documented and archived. For example, test documentation, cases, and the results of earlier verification and validation testing must be archived for subsequent regression testing. Failure to preserve this information for future use can dramatically increase the time and cost required to revalidate the software following a modification.