(Last modified Thu Apr 24 10:24 2008)
Boehm and Ross's "Top Ten Software Risk Items"
(SRIs)
The items most likely to cause your project to fail to come to completion
with a satisfactory result,
or to fail to come to completion at all.
- Personnel shortfalls
- Not enough qualified, settled-in people when you need them
- Turnover too high
- Unrealistic schedules and budgets
- Developing the wrong software functions
- Developing the wrong user interface
- Got the right functions but can't find them or they are too hard to use
- Gold plating
- adding 'bells and whistles' until the requirements
(and the system)
are weighed down by unnecessary complications
that aren't worth the cost
- Continuing stream of requirements changes
- Because requirements weren't settled early enough and effectively
- Shortfalls in externally furnished components
- Shortfalls in externally performed tasks
- Real-time performance shortfalls
- This usually becomes evident too late to fix
- Straining computer science capabilities
Overall risk management actions
- (1,2,5) Analyze (examine consequences of) requirements, schedules, costs
- (1) Personnel
- Staff with top talent
- Match skills and interests to jobs
- Enough appropriately-trained people efficiently organized
- Teambuilding
- Cross-training
- Arranging for replacements for turnover and overloads
- (1,7, 8) Periodically check that project will have the specialists and
resources it needs soon
- (2-8) Prepare and review contracts
- (2-8) Keep communication going
- (2-8) Negotiate changes if necessary
- (2-10) Intensive SQA measures (inspections, reviews, benchmarking)
- (3,4) User and stakeholder involvement, from start to finish
- (3-6,9,10) Use scenarios to examine high-risk modules concretely
- (3,4,9,10) Prototype high-risk modules
- (3-5) "Scrub" the requirements periodically
- (6) Set a high change threshold; screen the change requests
- (9) Simulate high-risk modules
- (*) Arrange for experts in particular SRIs to help out
- (*) Schedule SRI activities as early as possible
- (*) Bring in outside expertise
Quantitatively ranking specific risks,
in order to focus effort for minimizing risk
The idea behind ranking risks
(whether quantitatively or qualitatively)
is that you then concentrate first
on the activities that will have the best effect,
keeping in mind that likelihood and damage are two separate issues:
the most likely risk may result in minor damage,
while the most serious damage may be associated with
low-probability risks.
How do you balance those two dimensions?
For specific risks associated with a specific project:
- Estimate probability of occurrence for each risk
- Estimate damage resulting from occurrence for each risk
- Sort by probability × damage
- Concentrate first on risks whose probability-damage products are highest.
- The probabilities and damages have to be comparable.
For example,
- all damage figures are for
total damages to the organization for that risk;
or all damage figures are for damages per customer;
but not a mixture.
- all probabilities are for
that risk occurring at all over the product's lifetime;
or all are probabilities that the risk will occur during a single year;
but not a mixture.
Qualitative rankings of seriousness and cost
Often you will not have enough information
to make an effective numerical estimate of probability and damage.
These qualitative categories of seriousness and cost
can help you decide which risks need attention first.
Note that there are no qualitative rankings of probability of occurrence.
| Levels of seriousness | Examples
|
|---|
| 1. Human life endangered, injury possible
| a medical treatment system
|
| 2. Essential organizational function blocked, no alternative
| e-business online sales system
|
| 3. Larger system prevented from functioning
| embedded automotive system
|
| 4. Essential organizational function impacted, alternative exists
| dentist office scheduling
|
| 5. Function blocked for many users
| point-of-sale terminal
|
| 6. Function blocked for single user
| word processor
|
| 7. Non-essential function impacted
| elevator display blank
|
| 8. User(s) inconvenienced but not blocked
| elevator display distorted
|
Levels of cost:
- Lawsuit for loss of life
- Damages for business losses
- Cost of repairing bug
- Software purchase cost refunded
- Future sales of software reduced
- Current sales reduced
References
Boehm+Ross1989-twsp
B. W. Boehm and R. Ross.
"Theory-W Software Project Management Principles and Examples."
IEEE Transactions on Software Engineering, 15(7):902-916, 1989.
doi
