Better Software - June 2008 - (Page 40)

assumption that programmers knew what to do with parity faults caused a parity fault to be ignored, which caused corrupted data.” This two-way verification of the analysis keeps the logic of the analysis on track. Once the analysis is finished we are only about 25 percent done! The next step is identifying potential solutions. These should be in line with the resources pre-allocated by management for problem resolution, although there should be exceptions when a serious problem would require more than the agreed upon resources (in other words, although there may be guidelines, let common sense rule the decision). In the example above, there are four possible solutions: 1. Fix the hardware design error. 2. Do not enable the software trace. 3. Train software programmers on the correct response to the error status. 4. Train the hardware engineer to fully communicate the impact of status errors. In this case, solutions 1 and 2 do not address the root cause. These are problem fixes. If the hardware-design error cause had been traced further, we might get to a root cause (designer oversight, inability to add sufficient hardware to address problem, etc.). To prevent the problem from recurring in other applications with other hardware, solutions 3 and 4 are preventive actions. Adding solutions 3 and 4 to a checklist used at project startup will help the staff “remember” to do this, as well. four to six of ten defects, one action can prevent a large percentage of the errors. This is where the real power of RCA comes into play. Carrying this a step further, there should be a team responsible for coordinating results from multiple RCA teams, as an infrequently identified cause at the team level may have a wider impact across the organization. summary Most software systems have a large number of defects. How can root cause analysis be effective in this situation? Typically, causal analysis waits until multiple defects have been found to allow the RCA team to work through ten to twenty defects in a single meeting. This may seem like a large number, but most software defects can be analyzed fairly quickly. A team of developers would wait until a sufficient number of defects have accumulated, perform the RCA for each defect, and then group the causes to identify common causes, if any. If we are able to identify one cause contributing mulTiPle defecTs The most important factors in the success or failure of root cause analysis are attitude toward the findings of the causes (“fix the problem” or “punish the people”) and follow through with action plans and solutions. If these are done properly, organizations can work through the process. No matter how well the analysis is done, lack of follow through will make the process another make-work task with no value. With the right support and training of participants, root cause analysis can play a significant role in improving product quality and organizational effectiveness. {end} 40 BETTER SOFTWARE JUNE 2008 www.StickyMinds.com http://www.agile2008.org http://www.agile2008.org http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.