Chapter 06wht

1
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Chapter 6
Risk Management

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

3
Reactive Risk Management
 project team reacts to risks when they occur
 mitigation—plan for additional resources in anticipation
of fire fighting
 fix on failure—resource are found and applied when the
risk strikes
 crisis management—failure does not respond to applied
resources and project is in jeopardy

4
Proactive Risk Management
formal risk analysis is performed
organization corrects the root causes of
risk
TQM concepts and statistical SQA
examining risk sources that lie beyond the bounds of
the software
developing the skill to manage change

5
RISK
Risk Management Paradigm
control
identify
analyze
plan
track

6
Risk Due to Product Size
• estimated size of the product in LOC or FP?
• estimated size of product in number of programs,
files, transactions?
• percentage deviation in size of product from
average for previous products?
• size of database created or used by the product?
• number of users of the product?
• number of projected changes to the requirements
for the product? before delivery? after delivery?
• amount of reused software?
Attributes that affect risk:

7
Risk Due to Business Impact
• affect of this product on company revenue?
• visibility of this product by senior management?
• reasonableness of delivery deadline?
• number of customers who will use this product
• interoperability constraints
• sophistication of end users?
• amount and quality of product documentation that
must be produced and delivered to the customer?
• governmental constraints
• costs associated with late delivery?
• costs associated with a defective product?
Attributes that affect risk:

8
Risks Due to the Customer
• Have you worked with the customer in the past?
• Does the customer have a solid idea of requirements?
• Has the customer agreed to spend time with you?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated?
• Is the customer willing to let your people do their
job—that is, will the customer resist looking over your
shoulder during technically detailed work?
• Does the customer understand the software
engineering process?
Questions that must be answered:

9
Risks Due to Process Maturity
• Have you established a common process framework?
• Is it followed by project teams?
• Do you have management support for
software engineering
• Do you have a proactive approach to SQA?
• Do you conduct formal technical reviews?
• Are CASE tools used for analysis, design and
testing?
• Are the tools integrated with one another?
• Have document formats been established?

10
Technology Risks
• Is the technology new to your organization?
• Are new algorithms, I/O technology required?
• Is new or unproven hardware involved?
• Does the application interface with new software?
• Is a specialized user interface required?
• Is the application radically different?
• Are you using new software engineering methods?
• Are you using unconventional software development
methods, such as formal methods, AI-based approaches,
artificial neural networks?
• Are there significant performance constraints?
• Is there doubt the functionality requested is "do-able?"

11
Staff/People Risks
• Are the best people available?
• Does staff have the right skills?
• Are enough people available?
• Are staff committed for entire duration?
• Will some people work part time?
• Do staff have the right expectations?
• Have staff received necessary training?
• Will turnover among staff be low?

12
Impact Assessment
See Figure 6.1 – impact assessment table

13
Building a Risk Table
Risk Probability Impact RMMM
Risk
Mitigation
Monitoring
&
Management

14
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
 sort the table by probability and impact

15
Risk Referent Level
Triplet
[ri, li, xi]
Ri = risk
Li = likelihood
Xi = impact
Then chart like in Figure 6.4 to decide where
project termination point is

16
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

17
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which require
hardware component under development. Hardware component
delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay using
software simulation
Estimated resources: 6 additional person months beginning 7-1-96
Recording Risk Information

Chapter 06wht

More Related Content

What's hot (20)

Similar to Chapter 06wht (20)

Recently uploaded (20)

Chapter 06wht