CS615 –
Software Engineering I |
Lecture 11 |
Risk always involves two
characteristics:
Must quantify:
Kinds of Risks:
Project risks threaten the project plan.
Identify potential
budgetary, schedule, personnel (staffing and organization), resource, customer,
and requirements problems and their impact on a software project
Technical risks threaten the quality and timeliness of the software
to be produced
Business risks threaten the viability of the software to be built.
Top five business risks :
(1) building an excellent product or system that no one
really wants (market risk)
(2) building a product that no longer fits into the
overall business strategy for the company (strategic risk)
(3) building a product that the sales force doesn't
understand how to sell
(4) losing the support of senior management due to a
change in focus or a change in people (management risk)
(5) losing budgetary or personnel commitment (budget
risks).
Known risks - uncovered after evaluation:
Predictable risks - extrapolated from past project experience
e.g.,
·
staff turnover
·
poor communication with
the customer
·
dilution of staff
effort as ongoing maintenance requests are serviced
Unpredictable risks - occur, but difficult to identify in advance.
·
Attempt to specify
threats to the project plan (estimates, schedule, resource loading, etc.)
·
Two types of risks:
o
Generic risks - potential threat to every software project.
o
Product-specific
risks - identified by: those with a
clear understanding of the technology, the people, and the environment that is
specific to the project at hand.
§
Identify by looking at
the project plan and the software statement of scope
§
Ask question -
"What special characteristics of this product may threaten our project
plan?"
1. Have top software and customer managers formally
committed to support the project?
2.
Are end-users
enthusiastically committed to the project and the system/product to be built?
3.
Are requirements fully
understood by the software engineering team and their customers?
4.
Have customers been
involved fully in the definition of requirements?
5.
Do end-users have
realistic expectations?
6.
Is project scope
stable?
7.
Does the software
engineering team have the right mix of skills?
8.
Are project
requirements stable?
9.
Does the project team
have experience with the technology to be implemented?
10. Is the number of people on the project team adequate
to do the job?
11. Do all customer/user constituencies agree on the
importance of the project and on the requirements for the system/product to be
built?
Sample Risk Checklist (Long)
·
U.S. Air Force pamphlet
contains guidelines for software risk identification and abatement.
·
Air Force approach
requires that the project manager identify the risk drivers that affect
software risk components—performance, cost, support, and schedule.
·
Risk components:
(1)
Performance risk—the degree of uncertainty that the product will meet
its requirements and be fit for its intended use.
(2)
Cost risk—the degree of uncertainty that the project budget
will be maintained.
(3)
Support risk—the degree of uncertainty that the resultant software
will be easy to correct, adapt, and enhance.
(4)
Schedule risk—the degree of uncertainty that the project schedule
will be maintained and that the product will be delivered on time.
·
Impact of each risk
driver on the risk component is divided into one of four impact
categories—negligible, marginal, critical, or catastrophic
Attempts to rate each risk
in two ways
·
The probability that
the risk is real
·
The consequences of the
problems associated with the risk, should it occur.
Project planner, along with
other managers and technical staff, performs four risk projection activities:
(1) establish a measure that reflects the perceived
likelihood of a risk
(2) delineate the consequences of the risk
(3) estimate the impact of the risk on the project and
the product
(4) note the overall accuracy of the risk projection so
that there will be no misunderstandings.
Risk table provides a
project manager with a simple technique for risk projection
(1) Project team begins by listing all risks in the first
column of the table.
Accomplished with the help of the risk item checklists.
(2) Each risk is categorized in the second column
(e.g., PS implies a project size risk, BU implies a business risk).
(3) The probability of occurrence of each risk is entered
in the next column of the table.
The probability value for each risk can be estimated by team members
individually.
(4) Individual team members are polled in round-robin
fashion until their assessment of risk probability begins to converge.
(1) Each risk component is assessed using the Risk
Charcterization Table (Figure 1) and impact category is determined.
(2) Categories for each of the four risk
components—performance, support, cost, and schedule—are averaged to determine
an overall impact value.
1. A risk that is 100 percent probable
is a constraint on the software project.
2.
The
risk table should be implemented as a spreadsheet model. This enables easy
manipulation and sorting of the entries.
3.
A
weighted average can be used if one risk component has more significance for
the project.
(3) Once the first four columns of the risk table have
been completed, the table is sorted by probability and by impact.
·
High-probability,
high-impact risks percolate to the top of the table, and low-probability risks
drop to the bottom.
(4) Project manager studies the resultant sorted table
and defines a cutoff line.
·
cutoff line (drawn
horizontally at some point in the table) implies that only risks that lie above
the line will be given further attention.
·
Risks below the line
are re-evaluated to accomplish second-order prioritization.
·
Risk impact and
probability have a distinct influence on management concern.
o
Risk factor with a high
impact but a very low probability of occurrence should not absorb a significant
amount of management time.
o
High-impact risks with
moderate to high probability and low-impact risks with high probability should
be carried forward into the risk analysis steps that follow.
·
All risks that lie
above the cutoff line must be managed.
·
The column labeled RMMM
contains a pointer into a Risk Mitigation, Monitoring and Management Plan
·
Three factors determine
the consequences if a risk occurs:
o
Nature of the
risk - the problems that are likely if it occurs.
o
e.g., a poorly defined
external interface to customer hardware (a technical risk) will preclude early
design and testing and will likely lead to system integration problems late in
a project.
o
Scope of a risk
- combines the severity with its overall distribution (how much of the project
will be affected or how many customers are harmed?).
o
Timing of a risk
- when and how long the impact will be felt.
·
Steps recommended to
determine the overall consequences of a risk:
Overall risk exposure,
RE, determined using:
RE
= P x C
P is the
probability of occurrence for a risk
C is the
the cost to the project should the risk occur.
Example
Assume the software team
defines a project risk in the following manner:
Risk identification.
·
Only 70 percent of the
software components scheduled for reuse will 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.
·
Have established a set
of triplets of the form:
[ri, li, xi]
where
ri is
risk
li is the likelihood (probability) of the risk
xi is
the impact of the risk.
·
During risk
assessment :
o
further examine the
accuracy of the estimates that were made during risk projection
o
attempt to rank the
risks that have been uncovered
o
begin thinking about
ways to control and/or avert risks that are likely to occur.
·
Must Define a risk
referent level
o
performance, cost,
support, and schedule represent risk
referent levels.
o
There is a level for
performance degradation, cost overrun, support difficulty, or schedule slippage
(or any combination of the four) that will cause the project to be terminated.
o
A risk referent level
has a single point, called the referent point or break
point, at which the decision to proceed with the project or
terminate it are equally weighted.
·
Referent level rarely
represented as a smooth line on a graph.
·
Most cases - a region
in which there are areas of uncertainty
·
Therefore, during risk
assessment, perform the following steps:
1.
Define the risk referent
levels for the project.
2.
Attempt to develop a
relationship between each (ri, li, xi)
and each of the referent levels.
3.
Predict the set of
referent points that define a region of termination, bounded by a curve or
areas of uncertainty.
4.
Try to predict how
compound combinations of risks will affect a referent level.
·
A risk may be stated
generally during early stages of project planning.
·
With time, more is
learned about the project and the risk
o may be possible to refine the risk into a set of more
detailed risks
·
Represent risk in condition-transition-consequence
(CTC) format.
o
Stated in the following
form:
·
Using CTC format for
the reuse we can write:
Given that all
reusable software components must conform to specific design standards and that
some do not conform, then there is concern that (possibly) only 70 percent of
the planned reusable modules may actually be integrated into the as-built
system, resulting in the need to custom engineer the remaining 30 percent of
components.
·
This general condition
can be refined in the following manner:
Subcondition 1. Certain
reusable components were developed by a third party with no knowledge of
internal design standards.
Subcondition 2. The design
standard for component interfaces has not been solidified and may not conform
to certain existing reusable components.
Subcondition 3. Certain
reusable components have been implemented in a language that is not supported
on the target environment.
Effective strategy must
consider three issues:
·
Proactive approach to
risk - avoidance strategy.
·
Develop risk
mitigation plan.
·
e.g. assume high staff
turnover is noted as a project risk, r1.
·
Based on past history
o the likelihood, l1, of
high turnover is estimated to be 0.70
o the impact, x1, is
projected at level 2.
o So… high turnover will have a critical impact on
project cost and schedule.
·
Develop a strategy to
mitigate this risk for reducing turnover.
·
Possible steps to be
taken
·
Project manager
monitors for likelihood of risk
·
For high staff
turnover, the following factors can be monitored:
·
Project manager should
monitor the effectiveness of risk mitigation steps.
·
Risk management and
contingency planning assumes that
mitigation efforts have failed and that the risk has become a reality.
e.g., the project is
underway and a number of people announce that they will be leaving.
·
Mitigation strategy
makes sure:
§
backup is available
§
information is
documented
§
knowledge has been
dispersed across the team.
·
RMMM steps incur
additional project cost
e.g. spending time
to "backup" every critical technologist costs money.
·
Large project - 30 or
40 risks.
·
80 percent of the
overall project risk (i.e., 80 percent of the potential for project failure)
can be accounted for by only 20 percent of the identified risks.
·
Work performed during
earlier risk analysis steps will help the planner to determine which of the
risks reside in that 20 percent (e.g., risks that lead to the highest risk
exposure).
·
Risk Mitigation,
Monitoring and Management Plan
(RMMM) - documents all work performed as part of risk analysis and is used by
the project manager as part of the overall project plan.
·
Alternative to RMMM
- risk information sheet
(RIS)
RIS is maintained
using a database system, so that creation and information entry, priority
ordering, searches, and other analysis may be accomplished easily.