Extending AbstractRiskAnalyzerDataSource Implement RiskAnalyzerDataSource

FAQTroubleshooting 23-3 ■ a problem is getting out of control ■ a problem has potential for getting out of control

23.1.4 Process Flow of Analysis

The process flow of analysis is presented below: 1. State the problem. 2. Specify the problem. Develop possible causes from: a. Knowledge and experience b. Distinctions and changes 3. Test possible causes against the specification. 4. Determine most probable cause. 5. Verify the solution.

23.1.4.1 State the Problem

Stating the problem is the most important step to solving the issue.

23.1.4.2 Specify the Problem

Describe problems in detail and ask focused questions to gather pertinent information. Step Description Ensure a clear and concise problem statement Stating the problem is the most important step. It is the most commonly ignored or at least the problem statement is assumed. It is pointless trying to solve a problem until the problem statement is stated. Otherwise what are you actually trying to fix? If you do not know what it is you are fixing how can you fix it? Consider if the problem stated can be explained If so, then it is not the problem statement --If the problem statement can be explained then back up and try and get a more correct problem statement. This is a case to start communicating if you are helping someone solve his problem. Either ask some direct questions to narrow down the issue or just pick up the telephone and talk to the person to clarify the real issue. If there are lots of issues then start noting them down as separate issues. Do not settle for a vague statement Vague problem statements, like bad performance, something crashes are of no use and commonly are the cause for issues to be long running and out of control. Never combine problems in a single statement Ensure there is only one problem being dealt with. Do not accept combined problems. The combined problem is either multiple distinct problems or some of the problems are actually symptoms. Step Description Specify the problem These are symptoms of the problem. Start by asking questions Ask questions such as What, Where, When, and to what Extent? What? What tends to be the obvious question and is mostly a list of facts and symptoms; what deviated from the expectation? Where? Where may or may not be relevant, but is worth asking as it is often significant and often overlooked. 23-4 Oracle Fusion Middleware Developers Guide for Oracle Adaptive Access Manager

23.1.4.3 What It Never Worked

If the component did not work before, performing these steps:

23.1.4.4 IS and IS NOT but COULD BE

Consider what the problem is, what it isnt, and what it could be. When When is very important as time lines helps identify patterns and establish what change triggered the problem. Extent Extent or how many is particularly useful in establishing probable causes. If it is all the systems for example then check if it affects all systems or try a testcase. How often is also important. Once a week is quite different from many times every second and tells us much about the type of issue to look for. List the symptoms and facts List the symptoms and facts and how they are significant What changed? Something changed that is certain unless the problem has always been there. This is a special case. Assumptions Verify the data provided and check for conflicts and contradictions. Always check for any assumptions. Be careful to identify any information that is not verified and thus is only assumed. In fact this is particularly a mistake made by analysts that have more technical experience. Though also occurs a lot when inexperienced analysts are given details from people they perceive as having more knowledge. However trivial an assumption seems, always look for proof and confirmation. Considerations Description Consider behavior and expectation if performance issue For cases when the issue is about something that never worked correctly the first issue is to establish what correct behavior really is and if it is reasonable? This also allows us to set proper expectations from the outset. This is especially true for performance issues. Confirm that there is no misunderstanding Establish that the requirement is reasonable. Do not compare Apples with Oranges Agree on a specific goal. Focus on that issue only. Consider all components involved Consider all components involved: ■ Not just the software ■ Hardware is fast enough? Consider if the solutions is just to change perception What can you see that causes you to think theres a problem? ■ Human factors ■ Perception Step Description IS and IS NOT but COULD BE For every fact or symptom ask this question: IS and IS NOT but COULD BE Step Description