INTRODUCTION:
Business intelligence (BI) is “the strategies and technologies used by enterprises for the data analysis of business information.” This is a broad definition but in the case of software development the data are the metrics, statistics and various reports that are generated throughout the development lifecycle and the business information is the analysis and interpretation of these various data for making decisions. Software development teams need to look more seriously at BI as a tool for making better decisions and static analysis plays an important role in the data collection and reporting needed. In this post, I’ll take a look at the playing field of BI and the role static analysis plays in that.
Related:
- Sqoring Technologies’ Squore Dashboard Demonstration
- TIOBE TICS Quality Assessment
- Technical Debt: From Metaphor to Theory and Practice
BI for Software Development
The term BI and the use of data-driven management is a not a new concept. However, in the past, much of the data needed for software development decision making was either missing or managers couldn’t use it well. In addition, there might have been less motivation to use BI since “seat-of-the-pants” management styles were still popular. However, high failure rates of software development projects (up to a 70 percent failure rate) has driven projects to change. This is where agile and continuous integration concepts come into play. Software development organizations that realize things need to be done differently, are usually early adopters of automation, analytics, and using modern practices such as agile development.
The challenge with modern approaches such as agile and continuous integration is that you loose sight on what aspects of your code base are changing when. The development teams get more autonomy, and that has proven to be a great motivator and deliver great benefits, but management teams still need to understand what the state of these software is. This is where BI, data collection and analytics come in. It provides the management team the data to steer agile development and continuous integration. A particular important example of this is testing, which is somewhat of a bugbear for iterative processes since it’s difficult to test just enough parts of a system to ensure new functions work and no new bugs are introduced. In most cases, development teams end up testing much more than they need and slowing down the process. BI can help here by showing exactly what has changed build-by-build (where tests are needed) and indicate areas of risk, for example, complexity, bad “code smells”, or static analysis warnings. The collection of data, comparisons, metrics, and static analysis reports on a build basis is a key enabling capability that has made BI useful for modern development processes.
The role of Static Analysis in BI
Data is essential to BI and static analysis tools are a great source of data describing the state of your software. Static analysis tools provide not only detailed reports about bugs and security vulnerabilities but can be configured to collect metrics as well. In addition, they provide an overall quality and security easement based on report density of a project (or smaller scale component). Static analysis tools can analyze code on check-in and during each project build allowing synchronization, on a per-build basis, with all other data collected.
Although static analysis reports are data, many of the high priority reports are actionable errors or security vulnerabilities that should be fixed. It’s important to emphasize that BI and static analysis isn’t about data collection alone, it’s really about providing information that’s used to improve the product and the development process. For example, when viewed at high level, the density of static analysis reports can indicate technical risk in the code. Another example, is adopting legacy or third party code, warnings and errors here are a warning sign that your development team is inheriting more than just pre-built functionality. In fact, most projects rely on third party and legacy code, managing the quality and security of such a large portion of the project’s code base leads to the topic of technical debt.
Technical Debt
The strict definition of technical debt “the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.” (Techpedia) I’d extend this further to include the extra cost that arises from delaying refactoring and fixes to a current codebase and any existing code inherited into the project. The growth of this technical debt is sometimes enough to sink a project completely. In most cases, the scale of the problem is unknown, especially in the case of legacy or third party code. In the long term, technical debt impacts an organization’s ability to spend resources on innovation, roughly illustrated by Figure 1.
Figure 1: The impact on innovation due to technical debt over time.
Managing technical debt is an example of a problem well suited to BI tools and static analysis. Static analysis tools can be used on any source code in the system whether it’s third party or internal. It can also be applied to binary code in libraries and executables. BI tools can collect reports from static analysis tools, metrics, test results and problem tracking databases to provide an overall view of the quality of any part of the project, not just newly developed code. The advantage BI and these collection of tools and techniques bring is the ability to focus on the most critical components of technical debt.
Solutions
Many companies have tackled the problem of providing business intelligence solutions themselves by duck taping together their various configuration management, bug tracking, requirements and testing dashboards. There are several commercial solutions out there that remove the need for sticky tape, that provide flexible integrations of various software tools and elegant interfaces that present the data. GrammaTech CodeSonar comes pre-integrated with both TIOBE TICS Quality Assessment and Squore Technologies’ Squore, in the remainder of this blog I’ll use Squore to present an overview.
Squore and CodeSonar Integration
GrammaTech’s partner company, Squoring Technologies “specializes in the evaluation and monitoring of software and systems development projects.” Their powerful dashboard software provides tools to aid and accelerate software development decision making. One of the data sources available to use is GrammaTech CodeSonar which provides the static analysis results alongside many other project metrics and KPI (key performance indicators.) The following architecture diagram illustrates how CodeSonar fits within the Squore BI system.
Here’s an example of SQUORE dashboard:
Due to CodeSonar’s ability to find real defects and vulnerabilities it extends the capabilities of Squore’s technical debt assessment in reliability, security and portability. The chart below illustrates the increased detection of technical debt factors due to the integration with CodeSonar:
Another key aspect of the CodeSonar integration with Squore’s BI dashboard software is that the workflow is respected in both tools. As developers manage their static analysis results in CodeSonar these changes are reflected in Squore. Within Squore, CodeSonar results and code viewer are available (with critical trace details needed to investigate findings.) The following diagrams shows how status changes in CodeSonar are reflected in the Squore dashboard.
CONCLUSION:
The emergence of powerful BI tools in software development provides better insight into the quality, reliability and security of a project. This insight also provides management with information they need to make the best possible decisions. Static analysis tools aren’t just for detecting bugs and security violations in isolation. They provide much needed insight into project quality and security that can be leveraged by BI tools such Squore. The combination of powerful advanced static analysis increases the effectiveness of the BI data which, in turn, leads to better decision making in software development projects.
