11.5 Cause-and-event charting

11.5 Cause-and-event charting

The first part of this chapter explained how to record root-cause information, with much of the chapter devoted to a taxonomy of root causes for software defects. This is what most software-development organizations mean when they say that they do root-cause analysis. It is not, however, root-cause analysis according to the definition commonly used by safety experts. All we have done so far from the perspective of the safety expert is to provide a method for categorizing and recording the final results of root-cause analysis.

Cause-and-event charting produces a graphic display of the relationship between events, conditions, changes, and causal factors. Standard symbols borrowed from the ancient method of flowcharting are used to draw the diagram. We present here a simplified version of the method as described in The Root Cause Analysis Handbook by Max Ammerman [Am98].

The following symbols are used to construct the cause-and-event chart:

  • Event: An action or circumstance that was observed to occur. Events are represented by rectangles drawn with a solid line.

  • Presumed event: An action or circumstance that was not observed to occur, but that is presumed by logical deduction to have happened. Presumed events are represented by rectangles drawn with a dashed line.

  • Critical event: An undesirable event that was critical to the problem you’re analyzing. Critical events are represented by diamonds drawn with a solid line. Critical events should occur only on the primary event line; otherwise they aren’t critical events.

  • Terminal event: The starting and ending events of the analysis. Terminal events are represented by circles drawn with a solid line. Terminal events should occur at the beginning and end of the primary event line.

  • Condition: Circumstances that may have influenced the events in the diagram. Conditions are represented by ellipses drawn with a solid line. Circumstances should be connected to the related event with a dashed line.

Describe all events with a simple sentence. The subject should refer to an entity in the program or the real world. Events should be described by action verbs, not being verbs. If you can’t describe an event with an action verb, it probably isn’t an event. Put dates and times on events wherever possible.

Describe all conditions with a simple sentence. The subject should refer to an entity in the program or the real world. The verb should generally be a being verb, normally with a predicate adjective. If you can’t describe a condition with a being verb and an adjective, or equivalent grammatical construct, it probably isn’t a condition.

To make the charts readable, label each symbol with a number or letter. Create a legend at the bottom of the chart that spells out what the contents of that symbol are.

You can construct a cause-and-event chart by performing the following steps:

  1. Draw the primary event line with the terminal events.

  2. Review the defect report to identify the critical events. Add them to the chart on the primary event line, chronologically from left to right.

  3. Place all primary events on the primary event line.

  4. Add secondary events and conditions to the chart. They will be off the primary event line.

  5. Review the critical events and determine what conditions or causes allowed or forced the critical event to occur. Add the conditions to the chart.

  6. For each condition on the chart, determine why it occurred. Recursively analyze each condition as if it were a critical event until the original critical event is fully explained.

  7. Make a list of actions to take to remedy the root cause and prevent it from occurring again.

Debugging by Thinking. A Multidisciplinary Approach
Debugging by Thinking: A Multidisciplinary Approach (HP Technologies)
ISBN: 1555583075
EAN: 2147483647
Year: 2002
Pages: 172

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net