Static Analysis for FDA Software Validation Compliance
Total Page：16
File Type：pdf, Size：1020Kb
Technical Whitepaper Static Analysis for FDA Software Validation Compliance EXECUTIVE SUMMARY Static analysis, when deployed as part of a continuous quality process, But even with the ideal mixture of testing techniques, quality software has proven to be a very efficient way for developers to expose and cannot be delivered by testing alone. Quality software is delivered prevent many critical defects as the code is being written. The FDA consistently via a solid, repeatable process. Such a process must has publicly recommended that software developers use static embrace everything from software testing and analysis, to quality analysis for ensuring medical device software safety and reliability, planning, to requirements traceability, to change management. This and has touted static analysis as a critical component of an effective process needs to be visible, measurable, and improvable. software development process. To assist organizations that are exploring static analysis for FDA But static analysis is only one piece of the software development compliance, this paper describes Parasoft’s static analysis capabilities puzzle. The FDA also recommends that medical device software in the context of FDA compliance. Because we recognize that static development teams take a software development lifecycle (SDLC) analysis is not a silver bullet for FDA compliance, this paper also approach that integrates risk management strategies with principles describes Parasoft’s broader software solution for medical device for software validation. An integrated SDLC merges validation and software development. Parasoft’s reporting and analytics system verification activities, including unit testing, peer code reviews, extends Parasoft’s static analysis capabilities by combining a pre- static analysis, manual testing, and regression testing. The result of configured system with processes and best practices. The result such an approach is an emphasis on planning, verification, testing, is that organizations are able to produce medical device software traceability, and configuration management. consistently and efficiently with freedom from unacceptable risks. THE FDA COMPLIANCE PARADOX Before jumping into static analysis, it is worth discussing some of the challenges associated with adopting the FDA’s recommended software development approach for gaining approval. Developing software for medical devices that complies with the FDA’s Quality System regulation is a challenging endeavor that’s as much a business issue as it is an engineering feat. One reason for this is the vagueness with which the FDA outlines compliance. The agency does not prescribe specific practices, tools, coding methods, or any other technical activity, but instead prescribes the seemingly innocuous concept of the Least Burdensome Approach. In this approach, organizations determine, and strictly adhere to, their self-defined validation and verification processes. Development activities and outcomes must be clearly defined, documented, verified, and validated against the organization’s process. The goal of this approach is to give medical device makers enough rope to determine how to best ensure public safety. But in practice, the effect has been that organizations have enough rope to hang themselves. This is because the requirements, expressed in FDA 21 CFR, represent extensive planning and testing, which require validation. The following examples are just a few of the challenges software engineers must overcome: • The software validation process cannot be completed without an established software requirements specification, which specifies the intended use. Results must not only verify that the specifications are met, but they must be reproduced consistently (validation). Testing methods like regression testing can be implemented to meet the requirement. © 2017 Parasoft Corporation 2 • Validation must be established and re-established for even small changes. This means that validation activities, including static analysis, unit testing, code review, etc., must be THE VALUE OF PARASOFT’S repeated if the code has changed. Furthermore, as software continues to become more STATIC ANALYSIS TOOLSET and more complex, tests that validate the changes should be conducted in scale with the application to ensure that no other part of the system is affected. Parasoft provides early and effortless de- tection of errors that might otherwise take • Changes to the requirements deemed significantly different enough from the originally weeks to find, through: registered design may require the product to be re-registered per FDA Section 501(K). • STATIC CODE ANALYSIS • There are no “FDA certified” tools or methods. No person, organization, or tool can claim Static analysis prevents defects using any form of some supposed FDA certification. However, any software used to automate thousands of rules tuned to find and any part of the device process or any part of the quality system must also be validated. prevent coding issues. Over 15 years You must be able to run any tools used to assist in the verification and validation efforts of R&D have gone into fine-tuning on a control code base and confirm that the results are consistent, which may affect your Parasoft’s rule set. time-to-market. • DATA FLOW ANALYSIS This technology simulates test case The FDA has established grounds for approval in a way that effectively puts the responsibility execution and detects errors across of ensuring quality and public safety back to the device makers. But device makers are multiple units, components, and files, often dealing with a bigger challenge: bridging the gap between business goals and the exposing runtime errors without hav- development process. ing to run the code. • METRICS ANALYSIS LACK OF SOFTWARE DEVELOPMENT POLICY Calculate a customizable set of industry Software engineers often either don’t know what’s expected or do not understand the business standard metrics and identify pieces objective behind the guidelines driving their products. They are expected to write code that of code that exceed industry standard meets the requirements, without necessarily understanding why requirements have been or custom metrics thresholds. This ex- established in the first place. poses brittle or overly-complex code that could be dangerous to reuse, At Parasoft, we believe that the best way to overcome these challenges, while satisfying the extend, or maintain. FDA’s requirements for medical device software development, is to drive the development process in a platform based on policy-driven development. Policy-driven development involves: To improve overall team productivity, a con- (1) clearly defining expectations and documenting them in understandable polices, (2) training tinuous process ensures that scanning and engineers on the business objectives driving those policies, and (3) monitoring policy adherence remediation tasks are not only deployed in an automated, unobtrusive way. across the SDLC, but also integrated into the team’s workflow. Managers set ex- Integrating these principles into the development process gives businesses the ability to pectations by defining a code compliance accurately and objectively measure productivity and application quality. In addition to reducing policy (e.g., by enabling or customizing risk, the result is lower cost over the total software development lifecycle from build to support. Parasoft’s pre-configured FDA compliance Adopting a policy-driven development process is crucial for achieving the following goals: template). A daily process automatically monitors policy compliance at all layers of • Ensuring that engineers don’t make trade-offs that potentially compromise reliability and the application stack, identifies non-com- performance pliant code, and collects process metrics. • Ensuring that engineers build security into the application, safeguarding it from potential Management gains real-time visibility into attacks overall code-compliance status, allowing • Preventing defects that could result in costly recalls, litigation, or a damaged market teams to document improvements and de- position termine additional actions to ensure appli- • Accurately and consistently applying quality processes cation safety and reliability. • Gaining the traceability and auditability required to ensure continued policy compliance Developers simply respond to tasks report- Software engineers are continually making business decisions. Every line of code, test ed from the automated scan. They can also conducted (or left undone), and guideline or standard followed (or ignored) have profound perform interactive static analysis directly effects on the business. With public safety, potential litigation, market position, and other from their IDE: detected compliance issues consequences on the line, it behooves software development teams and people in traditional are prioritized and automatically assigned business management positions to come together on policy, and implement the strategy into to the developer who introduced it, with di- their software development lifecycle. rect links to the problematic code and an explanation of how to fix it. © 2017 Parasoft Corporation 3 THE IMPORTANCE OF A CONTINUOUS STATIC ANALYSIS PROCESS Having static analysis tightly integrated into the SDLC as described Policy management lies at the core of such an inline process. in the column above — rather than only as an audit at the end of the Parasoft allows you to easily configure policies for specific projects