1. “If You Don’t Actively Attack the Risks,
Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.
“If You Don’t Actively Attack the Risks,

2. The Risks Will Actively Attack You.”
-Tom Gilb

3. Importance of Risk Management
Addresses Complex Software Systems
Focuses Projects on Critical Risk Items
Provides Techniques for Handling Risk Items
Reduces Software Costs by Reducing Rework
Usually 40-50% of software costs

4. Rework Costs Concentrated in a Few High-Risk Items

5. If Risk Management is so important, why don’t people do it?
Unwillingness to admit risks exist
Leaves impression that you don’t know exactly what you’re doing
Leaves impression that your bosses, customers don’t know exactly what they’re doing
“Success-orientation”
Tendency to postpone the hard parts
Maybe they’ll go away
Maybe they’ll get easier, once we do the easy parts
Costs money and time up front

6. When do people do Risk Management?
After they’ve been burned in similar situation
Pain-avoidance
Convincing evidence of consequences
When everybody involved is convinced that risks exist, but that it’s still worth going forward
Everyone is a winner  Realistic expectations
When they’ve learned how to do it well
Techniques not well-known, but can be learned

7. Defining Risk “Risk”: Possibility of loss or injury -Webster
Risk Exposure =
(Probability of unsatisfactory outcome) X
(Loss if unsatisfactory outcome)

8. Components of “Satisfactory Outcome:” Stakeholder Win Condition Satisfaction
Customer, Developer: Budget, Schedule
User: Functionality, Performance, Reliability, Usability
Maintainer: Modifiability, Portability
Product Line Manager: Reusability
Many Counterexamples:
Lee, “The Day the Phones Stopped,” 1991
Gibbs, “Software’s Chronic Crisis,” 1994
Neumann, “Computer Related Risks,” 1995

9. A Typical Software Risk Situation
Software Controls Spaceborne Experiment
PROB (Software has critical error) = 0.4
Loss from Critical Error Occurring = $20M
If Do Independent V&V:
PROB (Critical Error Remains) = 0.05
Added Cost to Software Project = $1M
If No Independent V&V:
PROB (Critical Error Remains) = 0.2
Added Cost to Software Project = $0

10. Prioritizing Risks: Risk Exposure Risk Exposure - (Probability) (Loss of Utility)
High
Check
Utility -
Loss Estimate
Major
Risk
Risk Probability
Check
Probability
Estimate
Little
Risk
Low
Low
High
Loss of Utility

11. Risk Exposure Factors (Satellite Experiment Software)
Unsatisfactory Outcome (UO)
Prob (UO)
Loss (UO) 10 8 7 9 3 4 1 5 2
Risk Exposure
3 - 5
4 - 8 5 6 8 1 2 45 15 24 8 30 7 4
A. S/ W error kills experiment
B. S/ W error loses key data
C. Fault tolerance features cause unacceptable
performance
D. Monitoring software reports unsafe condition
as safe
E. Monitoring software reports safe condition
as unsafe
F. Hardware delay causes schedule overrun
G. Data reduction software errors cause extra
work
H. Poor user interface causes inefficient
operation
I. Processor memory insufficient
J. DBMS software loses derived data

12. Risk Exposure Factors and Contours: Satellite Experiment Software

13. Top 10 Risk Items: 1989 and 1995 1989 1995 1. Personnel shortfalls
2. Schedules and budgets
3. Wrong software functions
4. Wrong user interface
5. Gold plating
6. Requirements changes
7. Externally-furnished components
8. Externally-performed tasks
9. Real-time performance
10. Straining computer science
1995
1. Personnel shortfalls
2. Schedules, budgets, process
3. COTS, external components
4. Requirements mismatch
5. User interface mismatch
6. Architecture, performance, quality
7. Requirements changes
8. Legacy software
9. Externally-performed tasks
10. Straining computer science

14. Candidate 3156/4156 Risk Items
Personnel: commitment; compatibility; ease of communication; skills (management, Web/Java, Perl, CGI, data compression, …)
Schedule: project scope; IOC content; critical-path items (COTS, platforms, reviews, …)
COTS: to be discussed further in recitation
Rqts, UI: mismatch to Library user needs
Performance: #bits; #bits/sec; overhead sources

15. General Cause of Risk “Model Clashes” Goal:
Underlying assumptions made by stakeholders models may conflict
Often “unconscious”
Examples?
We’ll see how to use MBASE to address this pervasive problem
Goal:
Know risks
“no risks” - impossible
risks are a natural part of a project, just know how to approach
balance tradeoff’s - greater risk = higher reward = greater pot. loss
Mitigation and risk reduction
reduces total risk exposure, planned mitigation allows for risk taking

16. Model Clashes and MBASE

17. Where Are We Now? Overview of MBASE
Operation Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description (SSAD)
Life Cycle Plan (LCP)
Feasibility Rationale Description (FRD)

18. “No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits.
Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it.”
Fred Brooks, 1975

19. “Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it.
But we must try to understand it if we are to solve it.”
Fred Brooks, 1975

20. Understanding the Tar Pit: Model Clashes
Model (Webster): A description or analogy used to help visualize or analyze something; a pattern of something to be made
Includes product models, process models, property models, success models
Model Clash: An incompatibility among the underlying assumptions of a set of models
Produces conflicts, confusion, mistrust, frustration, rework, throwaway systems
Model Integration: Choosing and/or reengineering models to reconcile their underlying assumptions.

21. Examples of Model Clashes
Product Model Clashes: structure clashes, traceability clashes, architectural style clashes
COTS-driven product and Waterfall process
Risk-based process and spec-based progress payments
Design-to-cost process and tightly-coupled architecture
Incremental process and Rayleigh-curve staffing model
Evolutionary development without life-cycle architecture
Golden Rule and stakeholder win-win
Spec-based process and IKIWISI success model
I’ll know it when I see it

22. Classic Model Clashes In Practice
Model Clashes and Tar Pits:
Bank of America Master Net Example
Master Net Stakeholders
Master Net Contract
Initial Progress
The Tar Pit
The Bottom Line
Contributing Model Clashes
R.Glass, Software Runaways, Prentice Hall, 1998, PP

23. Reconciling Model Clashes
Use stakeholders’ success models, domain models to drive choices of other models
MBASE conceptual framework
Example: Process model decision table
Reconcile underlying assumptions
Example model clash patterns
Pre-package domain-integrated models
Successful examples

24. Where’s It All Going? Win-Win • Business Case Analysis
Software Warranties • QFD
10X • Six Sigma
Award Fees
JAD • RAD
UML
CORBA • COM
Architectures
Product Lines
OO Analysis & Design
Domain Ontologies
COTS • GOTS
Spiral
Waterfall
Risk Management
Business Process Reengineering
CMM’s • Peopleware
IPT’s • Objectory
Groupware
COCOMO
COCOTS • Checkpoint
System Dynamics
Metrics • - ilities
Simulation and Modeling

25. One View: Models Needing Integration
Win-Win • Business Case Analysis
Software Warranties • QFD
10X • Six Sigma
Award Fees
JAD • RAD
Success Models
Product
Models
Spiral
Waterfall
Risk Management
Business Process Reengineering
CMM’s • Peopleware
IPT’s • Objectory
Groupware
UML
CORBA • COM
Architectures
Product Lines
OO Analysis & Design
Domain Ontologies
COTS • GOTS
MBASE
COCOMO
COCOTS • Checkpoint
System Dynamics
Metrics • - ilities
Simulation and Modeling
Process
Models
Property Models