Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Static code analysis for low-cost, bug-free software

Posted: 24 Jul 2014     Print Version  Bookmark and Share

Keywords:static analysis  programmer  software code  SA tools 

Many studies have illustrated increases in software code reliability and developer efficiency through the use of static source analysis. There is no dispute that there are large benefits to be gained for most organisations.

One problem is that there are no standards that specify what static source analysis means, or what types of defects it should be detecting. Several government agencies, including Department Of Homeland Security, National Institute of Standards and Technology, and FDA have been trying to develop a set of guidelines and recommendations to specify exactly that, but there has been no clear solution as of yet.

One of the fundamental issues has been the difficulty in defining what defects need to be detected and at what rates. However, that doesn't take away from the fact that static source analysis has been proven as an extremely effective way to solve many issues that software developers are faced with.

With so many choices and no standards, a new problem arises: How do you pick a static analysis tool that is right for your organisation?

Since you will be instituting a new practice for your developers, you also need to make sure you overcome any initial adoption resistance. After all, static analysis (SA) tools are designed to expose programmers' bugs and make them public. No one likes to hear how bad their coding is. Even the most accurate SA tools will get a negative emotional response at first, once a programmer realises that an automated tool was "smarter."

Finally, it is hard to directly measure positive effects of static analysis. Instead, you know it is working by the lack of negative things, and can only be sure of it in retrospect. Because of this delayed response, programmers don't get the instant gratification that will motivate them to use the tool all the time, even though to get the greatest benefit of SA tools, they should do so. A certain amount of discipline will be required to make sure your SA tools are used all the time by everyone.

These issues are the essential questions we will try to answer in the rest of this paper.

Steps to success
The process of adopting static source analysis in an organisation is not easy. Static source analysis will offer different benefits to different organisations, depending on their needs. For instance, a company that consists of only a few developers and is looking to really crack down on the security of their software will have very different needs than a company that has dozens of developers and is looking to boost their release cycle efficiency.

The process to adopting static source analysis can be broken down into five distinct steps:
Step 1: Ask yourself: Do I need static source analysis
Step 2: Develop evaluation criteria
Step 3: Evaluate Trial Versions
Step 4: Overcome Growing Pains
Step 5: Gain Continued Adoption

Step 1: Ask yourself—Do I need static source analysis
The whole point of this step is to answer that question, and prepare for possible Step 2. If you realise that there will be very little to gain from any type of SA tool simply because the problems you have are unrelated to what static analysis can do, you should spend your time and energy on things that are more important. However, keep an open mind in finding out what your problems truly are.

For some of the questions it may seem that you need to do extensive statistics studies, instituting all sorts of bureaucracy. This is not so – you can get most of the information just by sampling a few things. Remember, what you are looking for is large obvious problems. Sampling a dozen or so data points should reveal those big problems pretty quickly. Otherwise, it is not worth your time.

These are the questions you should ask yourself:

Are any of the following problems of great concern: software reliability, security, slow release cycles, buggy software in the hands of customers?
An eager salesperson might look for an obvious "yes" to profoundly exclaim "you need static source analysis!" However, you really should figure out how much of a problem these things are, and what is causing them. For instance, if slow release cycles are a problem, is that because quality assurance (QA) and developers spend a lot more time finding and fixing software bugs than you originally predicted, or is something else a problem (e.g. server that all of the tests run on keeps crashing)? If it's the former, your static analysis (SA) tools may help you. If it's the latter, you might want to have a heart to heart talk with your system administrator and order some new servers.

1 • 2 • 3 • 4 • 5 Next Page Last Page



Comment on "Static code analysis for low-cost, b..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top