Share This Article:
  

How to Evaluate Static Code Analysis Tools

6 Steps to Choosing a Static Code Analysis Tool Your Team Will Actually Use

static_analysis_scr

As applications grow increasingly complex, more and more organizations are turning to static code analysis tools to ensure that code meets uniform expectations around security, reliability, performance, and maintainability.

Many evaluators take a common approach to selecting a static code analysis tool for their group or organization: they run each tool on the same code, compare the results, then choose the static code analysis tool that reports the most violations out-of-the-box.

Beyond Bake-Offs

This isn’t really a static code analysis product evaluation; it’s a bake-off. And the winner is not necessarily the best static code analysis tool for establishing a sustainable, scalable static analysis process within the team or organization. In fact, many of the key factors that make the difference between successful static analysis adoption and yet another failed initiative are commonly overlooked during these bake-offs.

This series of blogs recommends 6 steps for selecting a static code analysis tool that your team will actually use: one that suits your current situation and will grow with you as your needs evolve.

Please note that although Parasoft offers static code analysis tools, these blogs are designed to offer vendor-agnostic evaluation tips. We won't discuss our products in these blogs; if you want details about Parasoft static analysis, see the links at the end of the article.

Step 1. Assess Your Static Analysis Needs

Before you start searching for a static code analysis tool that meets your needs, you need to take a brutally honest look at where your organization stands today and where you hope static code analysis will take it.

Things to consider:

  • Pains: What specific pains are you hoping to address with static code analysis? For example, do you want to eliminate specific performance or stability issues that have been troubling you? Reduce the length and number of QA cycles? Make code more reusable and easier to extend? Satisfy regulatory compliance expectations (FDA, MISRA, JSF, PCI, ISO/IEC, etc.)?
  • Process: Is your development process stable, repeatable, and streamlined enough to provide a strong foundation for static code analysis? Are there weaknesses you should address first (e.g., lack of a fully-automated build process)?
  • Past experiences: If you tried static code analysis before, why did it fail? What can be done to prevent the same obstacle from stopping you this time?
  • Organization structure: How is your development organization structured? Will there be a fixed set of quality policies organization-wide and/or more specific rule sets to suit the needs of specific projects and teams?
  • Project variation: How will static code analysis efforts vary across your current projects? What new projects are anticipated in the foreseeable future and how will static code analysis apply?
  • Future goals: Where do you want your organization to be in terms of static code analysis 2-3 years from now? 10 years from now?

Next week we'll cover tips for compiling a preliminary list of candidates and getting the information you need from vendors.

***

 Image credit: * Beezy *

About Parasoft's Static Code Analysis

For information about Parasoft's static code analysis, see:

Share This Article:
     

Related Posts

Submit a Comment

Stay up to date