Static Analysis for FDA: 3 Keys to Success

Continuing our series of posts on static code analysis for FDA/medical device software compliance

1. Make Static Analysis Process a Continuous Process

Having static analysis tightly integrated into the SDLC as described in last week’s  Static Analysis for FDA: What’s Involved? post—rather than only as an audit at the end of the process—provides two distinct benefits.

• Developers adopt better coding habits that help them write better code faster. The process of fixing a static code analysis violation is more meaningful and more educational when it is done in the context of what the developer was trying to achieve. Therefore, in a continuous process, it is more likely that the developer will learn from his mistakes and eventually start writing compliant code as a matter of habit.

• Developers remediate problems faster and easier. If the code is still fresh in the developer’s mind when the problem is reported, the developer doesn’t need to waste time trying to remember what the code was supposed to do, why he wrote it the way he did, what impacts he needs to consider when modifying the code to meet compliance expectations, and so on. As you can imagine, resolving the same issue weeks or months later would require significantly more work to achieve the same outcome.

2. Keep Static Code Analysis Results Relevant and Meaningful through Context

Take a policy-based approach to static analysis: use static code analysis to monitor a non-negotiable set of expectations around code reliability, security, performance, and maintainability. With this approach, a violation of a particular guideline is not just another suggestion for people building software in an ivory tower—it’s notification that the code failed to meet the organization’s expectations. Otherwise, rule violations are perceived as suggestions for general code improvements—not critical coding issues that need to be addressed immediately.

Effective policy management allows an organization to bridge the gap between management expectations and developer performance. Essentially, if a static code analysis rule enforces something that is part of the policy, fixing a violation of that rule is non-negotiable. If a developer fails to satisfy the defined policy, he is not executing his job as expected by management.

For an analogy, consider the driving rules in your state. If you’re driving around on a normal day, without any law enforcement present, you may take a fairly lax approach to following certain rules. But if you are taking a behind-the-wheel driving test that you must pass in order to receive or renew your license, you will probably be much more vigilant about following the applicable regulations.

3. Reduce Static Analysis Pain through Process and Workflow

To ensure that an inline, policy-driven static code analysis process is easy to introduce and sustainable to adopt, be sure to consider policy management, workflow management, and workflow optimization.

Policy management lies at the core of such an inline process. A carefully-defined and implemented set of policies establishes a knowledge base that guides developers to start writing safe and reliable code as a matter of habit.

With a policy established, putting it into practice involves workflow management: defining, automating, and monitoring a workflow that improves development productivity and forms the foundation for a sustainable process.

For workflow optimization, tasks to support quality policies must be optimized so they can feasibly become an integral part of the team’s existing workflow, ensuring that the static analysis process is both sustainable and scalable. The lack of automation, repeatability, or consistency will degrade any quality initiative that the organization intends to deploy.

One way to optimize the workflow is by using static analysis in concert with other analysis capabilities, such as metrics analysis and peer code review. This allows you to better optimize the developers’ time by focusing their efforts on more severe or more complex scenarios first. For example, if you are alerted that that a certain piece of code has a high level of Cyclomatic Complexity as well as high severity security issues, you would ultimately want to point developers to that region first. In fact, this is a prime example of how code analysis can help you zero in on items that should be discussed during the peer code review.

Other ways to optimize the workflow include:

• Routing each reported issue directly to the responsible developer—as well as customizing issue prioritization to suit your policy priorities—ensures that your most critical issues are addressed in a timely manner.
• Centralized configuration management ensures that rule sets are applied consistently and can be updated effortlessly as priorities and processes evolve.
• Using automated refactoring whenever feasible helps the team correct rule violations as fast as possible.

***

Image credit: ~Brenda-Starr~