1Coming up: Project Risks

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.

2Coming up: Option 1: Deal with the problem when it occurs

Project Risks

What can go wrong?What can go wrong?What is the likelihood?What is the likelihood?What will the damage be?What will the damage be?What can we do about it?What can we do about it?

Option 1: Deal with the problem when it occurs

3Coming up: Option 2: Contingency plan: Plan ahead what you will do when the risk occurs

Caller: I have a slight problem, I’m trapped in my burning house911: Fire truck on it’s way

Option 2: Contingency plan: Plan ahead what you will do when the risk occurs

4Coming up: Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence

Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence

5Coming up: Risk Management Paradigm

Lets read about not playing with fire

Reduce probability Reduce impact

6Coming up: How to identify risks

RISK

Risk Management Paradigm

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack

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

7

8These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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.

9These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Building a Risk Table

RiskRisk ProbabilityProbability ImpactImpact RMMMRMMM

RiskRiskMitigationMitigationMonitoringMonitoring

& & ManagementManagement

Text description of the risk

Probability of occurance

Impact if occurs (Negligible=1…Catestrophic=5)

ExposureExposure

Coming up in a few slides…

10These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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

11These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Risk Exposure Example 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.

Personal Opinion: I

don’t like this - Fleck

12These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

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?

Risk Mitigation, Monitoring,and Management

13These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Risk Management Paradigm

RISK

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack

Key step:Once you have created your risk spreadsheet… you must track and update it as things change.