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 minutesAfter static analysis tools have been integrated into the everyday workflow of the development team, the next phase is working to reduce the backlog of warnings and technical debt in a project.
In the case of a product under maintenance or in development, there is likely a sizeable backlog to deal with. In the case of a greenfield project (see the first post in my static analysis series to see the discussion of these different project stages: Getting Started with Static Analysis Without Overwhelming the Team), there is less backlog, although the recommendations remain the same for each stage of maturity.
The best starting point for dealing with a backlog of warnings is to prioritize and filter the results based on the desired outcome. Using security as an example, it makes sense to prioritize the backlog in terms of security warnings, ranked by criticality. This is a continuation of the approach used when first introducing static analysis into a project, but now the focus is on the next digestible set of warnings for the team to analyze. This is handled is several ways by Parasoft C/C++test, as we’ll get into below.
Parasoft’s centralized reporting and analytics dashboards provide developers and managers with the ability to see the current state of a project from various viewpoints, and further navigate into more detail where needed to establish a set of warnings for further investigation. Consider the following dashboard showing a project’s current compliance with the CERT C coding standard:
Figure 1: An example of a web portal dashboard. In this case, a summary of CERT C compliance.
Using this web portal, users can dig deeper into the analysis, down to the file and code level if needed, and investigate warnings entirely within the web portal or in an IDE. Warnings can be prioritized, assigned to developers, suppressed, or marked as a false positive at this stage. See the following example from the Parasoft explorer:
Figure 2: The Parasoft violation explorer.
In most cases when analyzing source for coding standard compliance, violations are reported as static analysis warnings. In a large project, there are initially going to be lots of warnings, and managing them quickly and efficiently is critical. Parasoft’s violation explorer is the key tool to navigate, evaluate, prioritize, and assign reported errors for remediation. If a static analysis rule violation turns out to be valid but justifiable, considered harmless, or not applicable, a developer can suppress the error and a deviation can be documented. These deviations are reported up through each level of the project to the dashboard and compliance documentation.
To make coding standard compliance feasible for existing projects, it’s critical that teams focus on the rules that are considered mandatory first. Compliance is often based on meeting the mandatory requirements with violations of recommended rules if they are documented appropriately. Standards allow rules to be re-categorized, if non-mandatory, allowing for violations if justifiable and documented. Without this, trying to correct every violation becomes infeasible.
Parasoft saves its users many extra hours of work by providing management with a navigable interface to explore violations and automatically generate reports for certification evidence, if needed. An example of a MISRA C deviation report is shown below:
Figure 3: An example Parasoft MISRA C Deviation Report.
It’s important for teams adopting static analysis to understand that it isn’t necessary to fix or analyze all warnings. All warnings are not created equal, so the severity level is the best indicator of how much effort should be placed on investigating and fixing a warning. Continuing the “line in the sand” approach discussed in the first post<link>of this series, when digging into the backlog of warnings, we are effectively moving the line in the sand a bit farther each time.
Parasoft Jtest and Parasoft C/C++test enable users to prioritize and filter warnings within the IDE using configurations. For example, severity and category (type of warning, e.g. security-related) can be used to create a set of warnings suitable for analysis. An example new user configuration is shown below:
Figure 4: Custom test configuration settings inside the IDE.
This configuration can be used to filter the warnings in the IDE:
Figure 5: Configurations can be selected in the DTP Findings view in the IDE.
Incrementally moving the “line in the sand” to tackle the next highest priority and category is the best approach for dealing with a large backlog of warnings. Eventually, a cut off point is reached due to time and budget, but software teams should feel comfortable that they have made significant improvement in quality and security despite any remaining backlog of warnings.
In a large project, there are initially going to be lots of warnings, and managing them quickly and efficiently is critical. It’s important for teams adopting static analysis to understand that it isn’t necessary to fix or analyze all warnings, but make sure to select a tool that enables you to navigate, evaluate, prioritize, and assign reported errors for remediation. Incrementally moving the “line in the sand” to tackle the next highest priority and category is the best approach for dealing with a large backlog of warnings.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
As a Solution Architect at Parasoft, Billy helps teams strategize and prioritize as they adopt modern software development and testing practices into their organization.