The document discusses static analysis as an automated method for evaluating source code to identify coding defects without execution, highlighting tools like FindBugs that classify issues such as null pointer dereferences and incorrect comparisons. It also outlines evaluation metrics used in assessing software systems, the costs associated with defect detection and rework, and the potential for static analysis to reduce these costs while improving maintenance efficiency and risk management. Additionally, it presents various return on investment models for different static analysis techniques.

1. ************ [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

2. 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

3. 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.

4. Return on Investment models for different static analysis techniques
1. EXAMPLE: Automated Defect Detection

5. 2. EXAMPLE: Improving Maintenance Efficiency

6. 3. EXAMPLE : Risk Assessment

7. 4. EXAMPLE: Higher Reuse