Necessary, but inadequate steps toward risk reduction

Acting on the adage to reduce the risks associated with latent problems in software requires introducing a step in the development process to help developers identify and eliminate problems as early as possible - before the costs and risks of eradication escalate.

Common bug eradication practices include manual analysis, debugging, code review, dynamic analysis, and test. While necessary, these steps can be inadequate, time consuming, and expensive.

Manual analysis

The most rudimentary method by which programmers check code for problems is on screen or by printing the code and checking the printout for problems. Debugging by printf might be sufficient for expert programmers working on simple applications, but it forces the organization to rely entirely on the skills of the programmer and might provide an insufficient documentation trail. This leaves the code highly subject to human error and can be difficult for managers to control. The more complex the code, the more programmer-hours it can take to conduct a sufficient manual check, and the less likely the analysis will identify problems that can eventually result in significant expense or risk to the organization.

Debugging

In the quest to kill bugs a typical development team might alternatively build, run, and debug a program hundreds of times during development - returning to coding when a problem is identified. Manual debugging is a time-consuming process that often accounts for more than 50% of overall development time. Part of the reason for this resource-intensive cycle is that typical compilers simply can't recognize literally hundreds of coding problems that can lurk as latent bugs.

Code Review

A code review can be an effective means by which teams can identify whether code meets local standards, and might even result in identifying some problems prior to compiling. However, while important, the value of a code review can be limited by the following reasons:

• It can be an inefficient use of expensive resources.
• Increases possibility for inconsistency of process and result across the team, from project to project, and throughout the organization.
• Provides limited documentation trail for programmers and management.
• Human error passes through the compiler.

Dynamic analysis

Dynamic analysis attempts to find errors while a program is executing. The objective of dynamic analysis is to reduce debugging time by automatically pinpointing and explaining errors as they occur.

The use of dynamic analysis tools can reduce the need for the developer to recreate the precise conditions under which an error occurs. However, a bug that is identified at execution might be far removed from the original programmer and still must be returned to coding for correction.

Test

Test teams attempt to determine whether an executed software application matches its specification and that executes in its intended environment. Common steps in the test phase of development include: modeling the software's environment, selecting test scenarios, running and evaluating test scenarios, and measuring testing progress.

While testing can enhance a development team's ability to identify and eradicate problems, adequately testing today's complex software systems requires enterprise-class test automation tools, with associated infrastructure and trained staff. This translates into more expensive resources to identify problems that are becoming further removed from their source. Also, waiting for the testing stage to identify problems can be a costly mistake because standard test tools typically operate only on runtime units, or executables, and problems usually must be returned to coding for correction.