MSDN Magazine - January 2009 - (Page 44)

Figure 5 Expected Value Risk Analysis Risk A B C D Probability 0.70 0.20 0.40 0.10 Loss $1,000 $3,000 $2,000 $9,000 Exposure $700 $600 $800 $900 tion process among several people by assigning different people to different taxonomy questions. On the negative side, using taxonomies for risk identification can be very time consuming. Also, taxonomies are, by their nature, generic and so they cannot identify risks that are specific to your software system unless you put in the effort to discover these specific risks. Compared to taxonomy-based risk identification, an advantage of a scenario-based approach is that it tends to be less generic and forces you from the beginning to be more definite. On the other hand, scenario-based risk identification is somewhat more art than science and you can easily miss a key scenario. Specification-based risk identification is usually the least generic, most specific approach. However, a specification-based approach will yield results only as good as your specification documents. When used together, the three approaches give you a good chance of accurately identifying your software risks. Risk Analysis Risk analysis is the process of combining the probability (or likelihood) of a risk event with the monetary loss (or negative effect) that occurs if the event happens, to produce a value that can be used to compare and prioritize the risk against other risks. In this section, I present two older approaches to risk analysis (the expected value technique and the categorical technique), and one new approach called PERIL. Let’s look at the expected value technique first. Take a look at the example shown in Figure 5. Suppose you have identified four risk events. Let’s call them Risk A, Risk B, Risk C, and Risk D. You assign probabilities to each risk event. A probability is a number between 0.00 (meaning impossible) and 1.00 (meaning certainty) that indicates how likely the event is. Next, you assign a monetary loss value to each risk event, which is the cost to you if the risk event occurs. Now for each risk event you simply multiply the risk’s probability and the risk’s loss to get the risk exposure. Using this method, risk exposure is just a form of expected value. Obviously, there are several major problems with the expected value approach. How can you estimate risk probabilities? How can you estimate a risk loss? In some situations you may have good historical data or experience to base your estimates upon, but this is generally a rare situation when creating software. Based on my experience, the expected value approach to risk analysis is often not feasible in a software development environment. Because it is difficult or even impossible in many software development environments to estimate the probability of a risk event or its associated loss, a common alternative is to use categorical scales for both risk probability and risk loss. This is the categorical technique. An example will make the idea clear. Suppose you have 44 msdn magazine identified four risks, A, B, C, and D. Now instead of guessing at a probability and a loss for each risk, you generate a categorical risk exposure table like the one shown in the top part of Figure 6. As you can see, I have a total of nine categories of risk exposure. There are three categories of risk probability—Low, Medium, and High. There are three categories of loss—also Low, Medium, and High. The cross product of probability category and loss category yields nine risk exposure categories, from Low-Low (low probability of a low loss) through High-High (high probability of high loss). Now I can look at each of my four risk events, assign a Low, Medium, or High probability, and then a Low, Medium, or High loss, to yield a nine-point risk exposure. The idea is that it is often more reasonable to assign a probability value of “Low” instead of an exact numeric value like 0.05 for example. The hypothetical data in the table in the bottom part of Figure 6 suggest that Risk B has the highest exposure and may warrant more attention or resources (including testing) than Risk A, which has the lowest exposure. Although a categorical risk analysis approach somewhat eases the problem of assigning difficult or impossibleto-determine probabilities and loss information, the technique introduces new problems. Notice that I arbitrarily use three categories for both probability and loss. This is a very coarse approach. But suppose I decide to improve my risk analysis by using five categories for both the probability factor and the loss factor: Very Low, Low, Medium, High, and Very High. Now I would end up with a total of 25 risk exposure categories—(Very Low + Very Low) through (Very High + Very High). How would I rank or compare these 25 exposure values? Just how does a (Very Low + High) risk exposure compare to a (High + Medium) exposure? If multiple people are evaluating your categorical risk exposure data, would they interpret the exposure data in the same way? To address the problems with a purely categorical risk analysis approach, several years ago I developed a technique I call Project Exposure using Ranked Impact and Likelihood (PERIL). The essence of the idea is to use categories (as in the categorical approach) but convert them into a quantitative scale so they can be easily combined (as in the expected value approach) to produce numeric exposure metrics. Figure 6 Categorical Risk Analysis Probability High Med Low Risk A B C D Loss High High+High Med+High Low+High Probability Low High Medium Medium Loss Medium High Medium High Med High+Med Med+Med Low+Med Low High+Low Med+Low Low+Low Exposure Low+Medium High+High Medium+Medium Medium+High Test Run

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

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.