Thanks:  0
Likes:  0
Dislikes:  0

1. ## Risk Analysis

Hi,
Can some one help me understand how to calculate the 'probability of occurence' of a risk in a software project?
regards
Swathy

------------------

2. ## Re: Risk Analysis

There are many ways to do this so it sort of depends on what you are doing. I will just cover a few things. In its most simple formulation, just frame the statement of risk as a question: "How likely is this risk to occur?" Then use a scale of something like high, medium, low. It does nothing for quantification, of course, but it is possible to do it this way. You can, if you want, assign values, such as: high=1, medium=2, low=3. Then use those as the basis for a calculated scheme.

Beyond that, there are different things you can do. One is called risk exposure. You are asking, in other words, how much the risk is exposed such that it is likely to occur. A strict formula for this:

Risk exposure is RE = (P * C)

Here P is the probability of the occurrence of a given risk and C is the cost to the project should the risk actually occur in some form. Usually this only makes sense when you then do a prioritization scheme of some sort, such as:

RL = (RE<sub>before</sub> - RE<sub>after</sub>) / (Cost of Risk Control)

What they call this is Risk Leverage (RL). A high value means certain areas that are better for risk management activities - i.e., more risk is possible in those areas than in others. (Usually that is based on how "exposed" the risk actually is or is assumed to be.) The problem is that it relies entirely on the risk exposure, which means you have to be good at figuring that out and which means you have a little circularity.

Another way is potential loss values for risk as such:

R = C * P<sub>ps</sub> * P<sub>o</sub>

R is obviously the risk. C is the consequence value and this is something you have to work out. (Think of it in terms of a severity value, which usually has a ranking of between 1 to 8 in most risk analyses.) P<sub>ps</sub> is the probability of the risk manifesting. Usually this is a value, ranging between 0 and 1, representing the potential for the risk to occur, assuming that area of the product is utilized. P<sub>o</sub> is the actual probability of occurrence. Again, this will usually be a value, between 0 and 1, representing the estimate by the risk analyst (or whomever) of the user attempting to use the application in such a fashion where the risk can possibly manifest. Ideally, this value should be based on a review of past trends of user behavior or estimates of future trends of user behavior.

Also, some people do a technique known as impact estimation tables. The idea here is to analyze any risk directly in relation to requirements and costs. One of the nice things about this is that it includes a "Credibility Rating of the Impact Assertion" so that you can determine not only the risk, but how credible the statement of risk actually is. Impact Estimation tables require a lot more detail than you probably want here so I will just leave you with the terminology for now.

Hopefully some of this helps. Just remember ot try to adhere to a quantifiable measurement of risk. When you realize that risk is basically derived from probability of occurrence and from an associated cost, you can then relate this into loss by taking: cost of failure = (cost * probability). That helps you show impact on the bottom-line.

------------------

3. ## Re: Risk Analysis

JeffNyMan
Thanks for the wonderful explanation .It did clear some of my doubts.I would also like to know if Influence Diagrams could help in a proper , calculated risk analysis.
regards
Swathy

------------------

4. ## Re: Risk Analysis

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by amulu:
I would also like to know if Influence Diagrams could help in a proper , calculated risk analysis.<HR></BLOCKQUOTE>

They definitely can help. Whether they actually do or not depends upon how they are implemented. Keep in mind that a strict influence diagram should be used to see the relationships among components of a given product and the risks of that product. If you are doing a formal risk management effort that can adequately use these things, youu can then further that analysis by using decision trees. These take the information from influence diagrams to help model a certain sequence of events.

The idea, though, if you are going to go with influence diagrams is to remember they are a deductive tool in the sense that you take identitifed risk nodes (events) and attempt to see, from those events, the immediate (localized) cause(s) of the risk and also its systemic cause. So note that for large systems, you should break risk analysis down into discrete components because otherwise the risk models get much too large to deal with.

------------------

5. ## Re: Risk Analysis

can you imagine qaforums without JeffNyman, this is guy is a bank of information

------------------

6. ## Re: Risk Analysis

qa_tester,
You are right.Thank you JeffyNyMan, you have been quite informative and your explanations certainly helped me.
regards
Swathy

------------------

7. ## Re: Risk Analysis

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by amulu:
Thank you JeffyNyMan, you have been quite informative and your explanations certainly helped me.<HR></BLOCKQUOTE>

I am glad the information helped and you are very welcome. Risk analysis is one of those things that is very often left off in many quality efforts so it is always refreshing to talk about it a little bit.

------------------

8. ## Re: Risk Analysis

Jeff,
Have you written any white papers on this subject?
Or on any of the subjects you discuss?

I do enjoy following you around these forums and trying to soak up some of your knowledge.

------------------
Jean James, CSTE
J.James Consulting, Inc.

9. ## Re: Risk Analysis

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Jeanj:
Jeff,
Have you written any white papers on this subject?
Or on any of the subjects you discuss?
<HR></BLOCKQUOTE>

I have written white papers for companies. None of those have been published. I am working on a few things now based on threads that have started on these forums. However, I was also thinking it might be interesting for us to do TUTORIAL posts. I tried THEMATIC posts to see how that worked and TOOLBOX posts as well. I think that might be helpful for people.

I am just trying to think of formats that would be the most helpful so that the posts themselves do not get so filled with other material that they become only a lackluster reference and one that you have to sift through. One way is we can post a TUTORIAL thread and then close it. Then have other threads discuss it. That way the main thread says static but still open to discussion. Alternatively, with the TOOLBOX thread format, we could have each person who wants to contribute to that thread use their post to spell out their idea for how they do whatever activity is covered. The thread would not be so much a discussion thread but rather a presentation thread (thematic in nature), each post being one person's discussion of how they use the "tool".

The idea here would be to keep the main thread that expounds the point static but have discussion threads that could spawn off from that. We could use a standard naming nomenclature for the thread title so that searching would be easier. It think that would be easier said than done, however. I am just not sure.

------------------

10. ## Re: Risk Analysis

Sounds like a great idea to me.

We all are proponents of processes, procedures and standards. It ought to be workable. Have you mentioned this to AJ?

And should you publish your papers, please make sure you let us all know.

------------------
Jean James, CSTE
J.James Consulting, Inc.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.