It’s one thing to find bugs in software code — it’s quite another to actually figure out the importance of one bug relative to another. It’s a problem that code analysis vendor Coverity is aiming to solve
with a new release of its namesake platform.
The big new feature in Coverity 5 is officially called Defect Impact Mapping, and it aims to help developers identify the severity of a given bug in an application. Coverity’s technology does both static
and dynamic code analysis and is used by both commercial and open source projects.
“After you find defects, now we’ve introduced new capabilities that allow you to look at the defects and immediately prioritize based on the severity,” Dave Peterson, chief marketing officer at Coverity, told InternetNews.com.
Mapping bug severity is no easy task, since certain types of bugs can be common. For example, Coverity recently reported that NULL pointer deference bugs are common in open source code. Coverity has been running an open source code scanning project since 2006, originally started with funding from the U.S. Department of Homeland Security.
Coverity CTO Andy Chou explained that the defect impact analysis puts the bugs into subcategories.
“We took all the different defects and split them up into subcategories that represent specific narrow views of different types of defects. We looked at our experience in analyzing open source
software to determine which categories are the ones people will want to address first. ”
Agile development-friendly
Chou added that the Defect Impact Mapping feature is a static mapping of bugs. Coverity is not trying to understand the exact impact that something will have on an application but rather the impact that the category of defect tends to have on applications.
“It’s not an attempt to try and understand the runtime behavior of a program but rather to understand at the code level if it’s something you want to address,” Chou said.
Coverity’s approach is in contrast to recent efforts from IBM to assess the production impact of code defects. IBM Rational developer tools now have integrations for IBM Tivoli operations tools to get a view of code right into operations and back again.
Though the impact analysis from Coverity is a static mapping, the overall Coverity 5 application suite includes a build
analysis tool first introduced earlier this year. With build analysis, errors in the software build process can be identified and corrected before they end up in production usage. Chou noted that Coverity has integrations for IDE’s
“For Agile developers, one common methodology is continuous integration,” Chou said. “That means that as changes are made the source code is continuously rebuilt. Having static analysis in there
as part of a continuous process during development is a very Agile-friendly way of using the technology that Coverity has.”
