************ [Using Static Analysis to Find Bugs – Pugh, Hovemeyer, Morgenthaler & Penix]********************

A static analysis involves the automated evaluation of a system’s source code or design without actually executing it. Rather than trying to prove that the code fulfills its specification, such tools look for violations of recommended programming practice, places in which code might deference a null pointer or overflow an array. They also flag an issue such as a comparison that can’t possibly be true. FindBugs is an example of static-analysis tool that looks for coding defects.

Type of issues that FIndBugs identifies.

Infinite recursive loop

When software invokes a method but ignores its return value

When developer creates an exception but forgets to throw it

Using the wrong relational or Boolean operation

Situations in which the code checks a value for null in some places and unconditionally dereferences it in others.

Find places in which two objects guaranteed to be of unrelated types are compared for equality

Checking whether a double value is equal to a Double.

Rather than worry about whether particular paths are feasible, FindBugs looks for branches or statements that, if executed, guarantee that a null pointer exception will occur. FindBugs Detectors can access information about types, constant values, and special flags, as well as values stored on the stack or in local variables. Detectors can also traverse the control-flow graph, using the results of data-flow analysis such as type information, constant values, and nullness. FindBugs groups each bug pattern into a category (such as correctness, bad practice, performance, and internationalization) and assigns each bug pattern report either high, medium, or low priority. FindBugs determines priorities via heuristics unique to each detector or pattern that aren’t necessarily comparable across bug patterns. In normal operation, FindBugs doesn’t report low-priority warnings. ************ [Return on Investment Models for static analysis tools – Khaled El Emam / 2003]*******************

Types of Evaluations

Metrics are collected from the code or design. These metrics quantitatively characterize the size of the system, the coupling among the system’s components, inheritance relationships among classes in an object-oriented system, and cohesion within functions and classes.

Potential defects in the code are identified. For example, the use of uninitialized variables or NULL pointers, functions returning references to local objects, array bound violations, and incorrect memory deallocation are all likely to lead to a failure in the software

Visualization capabilities. For large systems, the visualization can give a concise picture of which parts of the system communicate with each other, where the bottlenecks are, which parts are more complex than others.

Types of actions based on information provided by evaluation

Automatic detection of defects

Risk Management

Efficient changes

Discovery of structured code

Every project has a fixed and overhead costs. These include things like rent, furniture, and electricity bills. Construction costs consist of the effort associated with the actual software development activities, such as requirements analysis, design and coding. Defect detection costs are the effort to look for defects introduced during construction. Defect detection includes activities such as inspections (peer reviews), testing, and root cause analysis. Rework costs are all costs to fix defects.

There are rework costs pre-release (before

general availability), and rework costs post-release. Pre-release rework is due to fixing defects found during inspections and testing, as well as other defect detection activities before the product is released. Post-release rework is due to fixing defects that were detected largely by customers. Although, a minority of defects will be found through internal testing even after a product is released. After a product is released, further effort is spent adding new features and porting the application. This breakdown covers the total life cycle of a software product.

An isolation effort when making a change refers to the effort to recreate the problem and the trace from

observed failure to the defect.

Static Analysis can reduce costs by

1. Reductions in the construction costs and new feature costs. This can be achieved through increased reuse. 2. Reductions in rework costs.

Payoff from reuse

Payoff from better defect detection techniques

Automatic defect detection essentially eliminates the defect detection costs. Benefits are automatic:

1. Benefits compared to not having any inspections

2. Benefits compared to having design and code inspections

Risk assessment techniques would allow the project to inspect only the high risk modules or components. It allows

focused or targeted design and code inspections.

1. Benefits of inspecting everything rather than focusing

on the higher risk modules

2. Not performing any inspections

Static analysis can reduce isolation effort when making

changes to fix defects.

Post release costs should be taken into account is that these

costs have a direct impact on time-to-profit.

Return on Investment models for different static analysis techniques

1. EXAMPLE: Automated Defect Detection

2. EXAMPLE: Improving Maintenance Efficiency

3. EXAMPLE : Risk Assessment

4. EXAMPLE: Higher Reuse