Making source code analysis part of the software development process
By Andrew Yang, Code Integrity Solutions
Embedded.com (04/26/10, 06:41:00 AM EDT)
Modern source code analysis tools (sometimes called static analysis or SCA tools) analyze software programs at the earliest stage of development. SCA tools analyze a program to calculate metrics and find potential flaws and defects in the code.
Unlike tools of the past, which tended to do simple pattern matching, modern SCA tools (Figure 1, below perform sophisticated path and data flow analysis and can find surprisingly meaningful bugs with good accuracy.
Figure 1: Source code analysis detects problems in the earliest part of development
From a business perspective, SCA tools hold a lot of promise. By uncovering problems in the earliest part of the development process, SCA tools can dramatically lower the cost of quality and security for a product.
The effort required to get to value is relatively low. For most organizations, just a few hours of analysis will uncover hundreds to even thousands of potential defects. No testcases are required, and the reported defects literally point to the line or lines of code where a problem can occur.
While SCA tools are an easy sell for most organizations, in practice, users often struggle with the tool. Unrealistic expectations coupled with underinvestment result in failed or suboptimal deployments.
Instituting any toolchain change in an organization requires more than just installing it and sending out the URL to the developers. Real change requires effective planning and execution. Instituting SCA is no different.
Everyone has opinion and experience with SCM tools and bug tracking systems. Much fewer have experience with SCA tools. Because modern SCA tools are relatively new, the industry does not have a plethora of reference architectures by which to fall back upon.
What I hope in this article is to convey some of the hard lessons we've learned by working with a number of companies instituting SCA tools. We hope you don't make these mistakes when instituting change in your environment.
E-mail This Article | Printer-Friendly Page |
Related Articles
- Five steps to reliable, low-cost, bug-free software with static code analysis
- Dealing with automotive software complexity with virtual prototyping - Part 2: An AUTOSAR use case
- Dealing with automotive software complexity with virtual prototyping - Part 1: Virtual HIL development basics
- Automotive System & Software Development Challenges - Part 2
- Automotive System & Software Development Challenges - Part 1
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)