ST350-1 Fault analysis and diagnosis

Upon completion of this module, you should be able to
1,use an organized total system approach for fault analysis and diagnosis
2,write accurate problem statements
3,describe a system problem in terms of error messages, symptoms, relative comparisons and technical conditions
4,identify and use commonly available resources to solve technical problems
5,generate and test a list of likely causes on a per fault basis
6,communicate and document information gathered during fault analysis
7,use the fault analysis worksheet to gather and document facts

 

fault analysis-identify the problem and organize fact gathering and comparisons
diagnosis-organize the actual discovery, testing, repair, and reporting of the problem

 

Eight steps of fault analysis and diagnosis:
state the problem
describe the problem
identify differences
list relevant changes
generate likely causes
test likely causes
verify the most likely cause
take action to correct the fault
NOTE:most bugs that become a disaster happen because the original problem is not identified correctly

 

Describing the problem
Listing All Observed Facts
Identify the sources of the observed facts you listed
1,Customer complaints-Use the original message from the customer
2,Customer interviews-Use the list of questions shown previously to interview customers about the problem. Expand and customize the question list for your own style and environment
3,Interviews of others involved-Include other colleagues such as administrators, programmers, and technical support staff
4,Diagnostics-Consider changed environments and operating system levels
5,Dumps-Evaluate the results of crash analysis if a core file is generated and available

 

Testing Likely Causes
Verification
Three approaches used to verify the most likely cause of a problem are:
1,Factual and logical-In this approach,your conclusions of likely causes are based on information gathered on the fault analysis worksheet and on past experience. This results in likely causes that make the most sense
2,Realistic-In this approach, the most likely cause must pass an experiment to show conclusively that it is or is not the cause. For example,try a new driver without overwriting the old one. This provides a quick, non-disruptive verification with good, but not complete, conclusiveness
3,Result-oriented-In this approach, you assume, without proof, that the most likely cause you choose is the actual cause, and take the indicated correctie action. This is the least conclusive verification, and can be disruptive, expensive, and time-consuming, especially if your assumptions are not correct.

 

Taking Corrective Action
1,Complete the repair
2,Test and verify the repair
3,Document results
4,Obtain confirmation and acceptance