1. Chapter 28 – Modified by Fleck
Risk Analysis
Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student use.
Coming up: Project Risks

2. Project Risks What can go wrong? What is the likelihood?
What will the damage be?
What can we do about it?
Coming up: Option 1: Deal with the problem when it occurs

3. Option 1: Deal with the problem when it occurs
Caller: I have a slight problem, I’m trapped in my burning house
911: Fire truck on it’s way
Coming up: Option 2: Contingency plan: Plan ahead what you will do when the risk occurs

4. Option 2: Contingency plan: Plan ahead what you will do when the risk occurs
Coming up: Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence

5. Option 3: Risk mitigation: Lessen the probability of the risk occuring
Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence
Lets read about not playing with fire
Reduce probability
Reduce impact
Coming up: Risk Management Paradigm

6. Risk Management Paradigm
control
track
RISK
identify
plan
analyze
Coming up: How to identify risks

7. How to identify risks
Common risks - many risks are common to many project. Start with a list of these. (Your book has a list, and the web has many)
Some examples:
Schedule is optimistic, "best case," rather than realistic, "expected case”.
Layoffs and cutbacks reduce team’s capacity
Development tools are not in place by the desired time
End user ultimately finds product to be unsatisfactory, requiring redesign and rework.
Customer insists on new requirements.
Vaguely specified areas of the product are more time-consuming than expected.
Personnel need extra time to learn unfamiliar software tools or environment

8. Risk Projection
Risk projection, also called risk estimation, attempts to rate each risk in two ways
the likelihood or probability that the risk will occur
the consequences of the problems associated with the risk, should it occur.
The are four risk projection steps:
establish a scale that reflects the perceived likelihood of a risk occuring (high, medium, low or numeric)
delineate the consequences of the risk
estimate the impact of the risk on the project and the product if it occurs
note the overall accuracy of the risk projection so that there will be no misunderstandings.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

9. Building a Risk Table Coming up in a few slides… Risk Probability
Impact
Exposure
RMMM
Text description of the risk
Risk
Mitigation
Monitoring
&
Management
Probability of occurance
Impact if occurs (Negligible=1…Catestrophic=5)
Coming up in a few slides…
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

10. Building the Risk Table
Estimate the probability of occurrence
Estimate the impact on the project on a scale of 1 to 5, where
1 = low impact on project success
5 = catastrophic impact on project success
Determine the exposure:
Risk Exposure = Probability x Impact
Some use cost to the project rather than impact, but in my experience cost is hard to estimate accurately. - Fleck
Got Here April 20, 2010
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

11. Risk Exposure Example Personal Opinion: I don’t like this - Fleck
Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.
Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
Numbers here seem “solid”, but are all guesses. Putting dollar values to it makes it seem like an extra $20K will solve the problem, but that’s truly uncertain. I prefer relative scoring and thinking.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

12. Risk Mitigation, Monitoring, and Management
mitigation—how can we avoid the risk?
monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely?
management—what contingency plans do we have if the risk becomes a reality?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

13. Risk Management Paradigm
control
identify
analyze
plan
track
Key step:
Once you have created your risk spreadsheet… you must track and update it as things change.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.