Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 4 minutesIf you haven’t read last week’s blog about getting started with static analysis, I recommend you do so, to understand how to interpret your first reports from static analysis tools and deal with the initial analyses without overwhelming the team.
The second part in this little getting-started series is all about how to integrate static analysis tools into your daily workflows. How do you incorporate static analysis every day?
As it turns out, this is key. Making sure that your static analysis adoption is a success in your project revolves around making sure the tools are easy to use and easily accessible by developers, providing useful, actionable information upfront. This is best achieved within the environment the developer is working in (IDE), like Eclipse or Visual Studio. Static analysis warnings are delivered in the same manner as compiler errors in the IDE, and these warnings are highlighted in the code to make analysis and fixing much easier. For example, see this screenshot of Parasoft Jtest’s static analysis warnings integrated in Eclipse:
As you can see in the above example of a Java application in Eclipse, the static analysis results from Parasoft Jtest are delivered in a warnings/error view (1) and can be interacted with as any other error message. Selecting an error brings the editor pane (2) to the line of code in question, which also brings up the control flow trace in the code that can be used to track down root causes of the warning. If remediation is needed, code can be submitted, as usual, through the project navigation view (3).
So what does a developer do when analyzing each warning? This is best described in a process diagram, shown below:
It starts with aggregating and filtering the static analysis results, a critical first step to prioritize and focus on key warnings. Usually, QA and team leaders decide on the quality goal in mind, and structure the configuration of the analysis around this goal. To improve security, for example, checkers related to security would be enabled along with a secure coding standard such as CERT C.
Developers then investigate and fix the warnings they find, based on the policies the team has in place and the maturity of the product. As explained in my last post, in a greenfield project, most warnings would be investigated and prioritized since the amount of code would be relatively small, while at later stages of maturity the filtering and prioritization would be stricter so developers would only address truly critical warnings. In either case, the process is the same.
After changes are made in response to a static analysis warning, code is checked into version control and analyzed again during the next build. This short and tight feedback loop greatly improves the quality and security of the code right at the time it’s being written and modified.
The main integration point for static analysis tools and build systems is through a command-line interface. Static analysis used in this fashion acts somewhat like a compiler would in the build structure. Files are processed in the same manner, although the output isn’t an executable but rather results that are stored in a repository, indexed by file and build number.
With Parasoft C/C++test, for example, this is handled by Parasoft’s reporting and analytics system (Parasoft DTP), which is both a repository and an intelligence engine that analyzes the results. This analysis and accompanying information is fed back to each developer to their IDE and made available through Parasoft’s web portal for managers and team leads.
In the above diagram, you see how we integrate Parasoft static analysis tools into a continuous integration pipeline. Parasoft DTP is the central repository and analysis engine for warnings.
Integrating static analysis into daily workflows requires both the developer to access static analysis directly in the IDE, as well as the ability to perform project-wide analysis, reporting, and management. Supporting developers directly where they work with code, as well as team leads and managers with access to the same information with their own trending information and reports is critical to leverage static analysis completely in a project.
Hungry for more? Come back soon for the next part in this little series. I’ll explain how to deal with static analysis warning backlogs and technical debt.
As a Solution Architect at Parasoft, Billy helps teams strategize and prioritize as they adopt modern software development and testing practices into their organization.