11.7 Review

General information to keep with a root-cause-analysis record includes the type of person who reported the problem, the method or tool used to identify the problem, the scope of the defect, and the order of magnitude of the time required to diagnose the defect. Symptom descriptions can be categorized as runtime problems, link-time problems, and compile-time problems.

We don’t consider problem reports that originated in erroneous requirement specifications. Our view of software defects is that a defect occurs when there is a difference between requirements and actual behavior.

Design errors can be categorized as data-structure problems, algorithm problems, and problems with user-interface specifications, software-interface specifications, and hardware-interface specifications.

Coding errors can be categorized as initialization and finalization errors, binding and reference errors, data-structure problems and violations, memory problems, missing operations, control-flow problems, value-corruption problems, invalid expressions, typographical errors, and other people’s problems.

Cause-and-event charting is a method for analyzing complex software defects. While it can be quite valuable for dealing with complex problems, it’s more method than is necessary for analyzing many common software defects.

Fault-tree analysis is another method for analyzing complex software defects. As with cause-and-event charting, it can be quite valuable for dealing with complex problems, but is more method than is necessary for analyzing many common software defects.

Cause-and-event charting is a diachronic (through time) method, in which the chronological order of events is made explicit. Cause-and-event charting is concerned with the dynamic view of a situation.

Fault-tree analysis is a synchronic (with time) method, in which the logical relationship of events is made explicit. Fault-tree analysis is concerned with the static view of a situation.