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 1

 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 2

 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 3
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 4
 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 5
 Risk Management Paradigm
control

track

RISK identify

plan
analyze

Coming up: How to identify risks 6

 Reactive versus proactive risk strategies

 A reactive strategy monitors a project for likely

risks. Resources are set aside to deal with
them .the team flies into action in an attempt to
correct the problem rapidly.
 A proactive strategy begins long before
technical work is initiated potential risks are
identified , their probability and impact are
assessed and they are ranked by
importance .Then the software team
establishes a plan for managing risk.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7
 Software risks
 Project risks –threaten project plan
 Technical risks threaten the quality and
timeliness of the software to be built.
 Business risks threaten the viability of the
software to be built
 Another risk categorization categorizes risk into
three
 Known risks –can be uncovered after careful
evaluation of the project plan

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8
  Predictable risk are got from past project
experience
 Unpredictable risks are extremely difficult to
identify in advance.

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

 Risk management is an attempt to minimize

the chances of failure caused by unplanned
events. The aim of risk management is not to
avoid getting into projects that have risks but to
minimize the impact of risks in the project that
are undertaken.
 Risk management concepts
 Risk is defined as an exposure to the chance of
injury or loss.risk management is the area that
tries to ensure that the impact of risks on cost ,
quality and schedule is minimal.
 The two main elements in risk management
are
 Risk assessment
 Risk control
 Risk assessment
 Risk assessment is an activity that must be
undertaken during project planning.This
involves identifying the risks , analyzing them
and prioritizing them on the basis of the
analysis.
 Since uncertainities are more at the
starting time of the project, risk
assessment is most needed in the
starting phases of a project.
 The goal of risk assessment is to
prioritize the risks so that attention and
resources can be focused on the more
risky items.
 Risk identification is the first step in
risk assessment which identifies all
different risks for a particular project.
 Checklist of frequently occurring risks are
probably the most common tool for risk
identification. Based on surveys of experienced
project mangers ,
 top ranked risk item is personnel shortfalls.
 This involves having fewer people than
necessary or not having people with specific
skills that a project might require.
 One way to manage this is risk is to get the top
talent possible and to match the needs of the
project with the skills of the available personnel
 Adequate training along with having some
key personnel for critical areas of the project
will also reduce this risk.
 second item is unrealistic schedules and
budget
 It is very common that the high-level
management imposes a schedule for a
software project that is not based on the
characteristics of the project and is unrealistic.
 Projects may run the risk of developing
the wrong software if the requirements
analysis is not done properly and if the
development begins too early.
 Improper user interface may be
developed
 This might require extensive rework of
user interface later or the software
benefits are not obtained because users
are reluctant to use it.
 Gold plating refers to adding features in
the software that are only marginally
useful.
 This adds unnecessary risk to the
project because gold plating consumes
resources and time with little return.
continuous change in requirements is
another risk element because it is a
reflection that the client has not yet
understood or settled on its own
requirements.
 Performance short falls are critical in real
time systems and poor performance can mean
the failure of the project.
 If a project depends on externally available
components either to be provided by the client
or to be procured as an off the shelf
component , the project runs some risks as it
may be delayed if the external component is
not available on time.
 If a project relies on technology tat is not well
developed , it may fail. This is the risk due to
straining the computer science capabilities.
 Using the above check list of risk items is one
way to identify risks
 Other methods are
Decision driver analysis
Assumption analysis
Decomposition


 Decision driver analysis involves questioning
and analyzing all major decisions taken for the
project.
 Optimistic assumptions made about the
project are also a source of risk
 Decomposition implies breaking a large project
into clearly defined parts and then analyzing
them.
 Next tasks that comes after risk identification
are
 Risk analysis
 Prioritization
 In risk analysis the probability of occurrence of
a risk has to be estimated along with the loss
that will occur if the risk does materialize
 The other approaches for risk analysis include
studying the probability and the outcome of
possible decisions.
 Once the probabilities of risk materializing and
losses due to materialization of different risks
have been analyzed they can be prioritized.
 One approach to prioritization is risk exposure
or risk impact
 RE = prob(uo) * loss(uo)
 Prob(uo) - probability or risk materializing
 Loss(uo) -total loss incurred due to
unsatisfactory outcome.
 Higher the RE , higher the priority of risk
 Risk control
 The main objective of risk management is to
identify the top few risk items and then focus
on them. once the risks have been identified
and prioritized the question is how to resolve
them.
 One obvious strategy is risk avoidance which
entails taking actions that will avoid the risk
altogether.
 For most risks the strategy is to perform the
actions that will either reduce the probability of
the risk materializing or reduce the loss due to
the risk materializing .
 These are called risk mitigation steps.
 To decide what mitigation steps to take , alist of
commonly used risk mitigation steps for various
risks is useful here. Risk monitoring is the
activity of monitoring the status of various risks
and their control activities.
A practical risk management
approach
 In this approach the probability of a risk is
categorized as low , medium or high.
 The risk impact can also be classified as low ,
medium or high.
 With these ratings the following simple method
for risk identification can be specified.
 1.for each risk , rate the probability of its
happening as low, medium , high
 2.for each risk asses its impact on the project
as low, medium .high
 3.rank the risks based on the probability and
effects on the project.
 4. select the top few risk items for mitigation
and tracking
 risk prob impact exp mitigation
plan
1. Failure to meet high high high white papers
the high performance training

2.Lack of people med med med train resources

with right skills review prototype
3. Complexity of med med med deploy persons
with application prior exp

4. Man power attrition med med med training, rotate

assignments
5.Unclear req med med med review a prototype
mid stage review
Risk Refinement
 One way to this is to represent the risk in condition
transition consequence format(CTC)
 <Condition> then there is a concern that
(possibly)<consequence>
 The general condition can be refined in the following
manner
 Subcondition1:certain reusable components were
developed by a third party with no knowledge of internal
design standards
 Subcondition2: The design standard for component
interfaces has not been solidified and may not conform
to certain existing components
 Subcondition3: Certain reusable components have been
implemented in a language that is not supported on the
target environment
Risk projection

 Also called risk estimation attempts to rate each risk in

two ways
 1.the likelihood of the risk
 2.consequences of the risk
 The are 4 steps in risk projection
 1.establish a scale that reflects the perceived likelihood
of a risk
 2.Delineate the consequences of the risk
 3.estimate the impact of the risk on then project and the
product
 4.Assess the overall accuracy of the risk projection so
that there will be no misunderstandings.
Possible steps for risk
mitigation

 1.Meet with the staff to determine the causes

for turn over
 Mitigate those causes that are under your
control before project starts
 Once the project commences assume turn over
will occur and develop techniques to ensure
continuity when people leave
 Organize project teams so that information
about each development activity is widely
dispersed
 Define work product standard and establish
mechanisms to be sure that all documents are
developed in timely manner
 Conduct peer reviews of all work
 Assign a backup staff member for every critical
technologist
 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
34
 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. 35
 Building a Risk Table
Risk Probability Impact Exposure RMMM

Text description of the

risk Risk
Mitigation
Probability of Monitoring
occurance &
Impact if occurs (Negligible=1… Management
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. 36
 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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 37
 Per
s
don onal O
’t lik p
e th inion:
is - I
Risk Exposure Example Fle
ck

 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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 38
 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. 39
 Risk Management Paradigm

Key step: control

Once you have
created your risk track
spreadsheet… you
must track and
update it as things
change.
RISK identify

plan
analyze

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