TSP: Causal Analysis

From the CMMI

Causal analysis and resolution improves quality and productivity by preventing the introduction of defects into a product. Reliance on detecting defects after they have been introduced is not cost effective. It is more effective to prevent defects from being introduced by integrating causal analysis and resolution activities into each phase of the project.

In PSP an TSP we could probably do a better job describing the role of defect prevention. It’s built into the process but not always obvious. Removal is relatively easy to see and involves things like improving review checklists and building more and better tests. Another aspect of process improvement is defect prevention, and it’s also important.

Causal Analysis involves looking at the “root cause” of a defect.

We ask defect logs to include very specifically what had to be changed, because we want to focus on

  • how do I recognize the defect when I see it
  • what phases did it escape (how effective are my removal filters)
  • how did it get there (what am I doing that injects defects of this kind)
  • what might I do to prevent it in the first place

The defect description must include what the defect looks like. The symptom might suggest how to detect it but eventually every defect is found by inspecting the product. For example, in test you find a bug. What was wrong, you have to look at the code to understand if there was a variable error, a logic problem, an incorrectly termindated loop, etc. Checklists help you see the actual defect. Indirectly you may learn to avoid some defects, but that is a secondary and indirect effect.

Now take it to the next level. If you are injecting defects that are escaping some phases, maybe you could prevent them. Causal analysis will what you are doing that is defect prone and change it.

For example, PSP data shows that defect injection rates are lower in design than in code. We also find that we can shift some of our time coding to designing without increasing overall time. Spending comparable amounts of time in code and design will reduce overall injections because we inject fewer defects while designing.

There are other things you could do with process or tools. The fundamentals remain

  • measure it
  • understand it
  • improve it

About Bill Nichols

PhD in Physics from Carnegie Mellon University I'm a software team coach and instructor with the TSP Team at the Software Engineering Institute
This entry was posted in Causal Analysis, TSP, Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s