Professional Documents
Culture Documents
Presented By: Ken Waller EEL 6883 - Software Engineering II: Richard Fairley Paul Rook
Presented By: Ken Waller EEL 6883 - Software Engineering II: Richard Fairley Paul Rook
Richard Fairley
Colorado Technical University Colorado Springs, Colorado, USA
Paul Rook
The Center for Software Reliability City University, Northampton Square, London, UK
Presentation Agenda
Strengths Weaknesses Suggestions for Improvements But feel free to ask questions during the presentation, as well
Paper Overview
Introduction Risk Management vs. Project Management Risk Types Software Development Processes and their Relationship to Risk Management Detailed Discussion of Risk Management Procedures Organizational Level Risk Management Conclusions
Introduction
History
1800s: Origins stem from the concept of Risk Exposure (Insurance Industry) 1950s: Some related topics being taught in academia (decision theory, probabilistic modeling) 1980s: Formal Risk Management used in Petrochemical and Construction Industries 1990s: Risk Management becomes an element of Software Engineering 1990s Present: Risk Management applied throughout many diverse industries
Introduction
Definitions:
Introduction
Probability that SW glitch will cause explosion: 0.3 (30%) Impact: 5 Human Lives (L) Exposure: 0.3 * 5L = 1.5L
Introduction
Introduction
State outcome that you want to avoid State courses of action that will lead to
Introduction
Risk Assessment
Identify Risks Analyze Risks Rate/Rank/Prioritize Risks Abate Risks Create Risks Mitigation Plans Apply Plans
Risk Control
Introduction
Constraints
Estimates
Threshold (maximum)
Threshold
(maximum)
Threshold
(minimum)
Cost
Schedule Performance
Cost
Schedule Performance
Cost
Schedule Performance
Attempts to manage/control risks in traditional ways: estimating, planning, scheduling Problem Management Reactive: Difficult choices and risk mitigation plans are made only after problems arise
Risk Management
Risk Control
Identify what may go wrong Assign probabilities Assess negative impact severities Create plans to reduce probabilities and/or severities Create plans to resolve risks that surface Reassess Risks
True management of risks Proactive: Difficult choices and risk mitigation plans are made before risks surface
Risk Types
Contractual/Environmental: Problems with customers or vendors, hindering organizational policies, etc. Management/Process: Unclear authorities and responsibilities, weak or inadequate processes, etc. Personnel: Lack of skills/training, etc. Technical: Requirements creep, inadequate testing, etc.
Risk Types
Generic
Common to most/all software projects Methods to abate/control have been developed, over time
Errors in products handled by V&V, incremental testing Communication problems handled by documentation, reviews, and meetings
Project Specific
Associated with a particular project Covered by the Risk Management Plan, consisting of
Action Plans: Decision to engage in a risk reduction activity without any further consideration (decision has been made) Contingency Plans: Initiate risk reduction activity at some future time, if warranted
The use of a particular software development process is an essential risk reduction technique To select an appropriate development process, need to understand:
Available software development processes Critical Risk Factors associated with the
project under development
COTS: Overlooked; requirements match Waterfall: Single Pass Risk Reduction/Waterfall: RR, then Waterfall Capabilities-to-Requirements: Pick COTS, then adjust reqs Transform: Tool automates generation of code Evolutionary: Spiral, several passes Prototyping: Low fidelity system Incremental: Add capabilities in each build Design-to-Cost/Schedule: Prune reqs to meet schedule/cost
Growth: High growth implies risk if using COTS Available Technologies: Ill-Defined Requirements: Feedback essential (use spiral/incremental) Understanding of Architecture: Low understanding = high risk of top down approach Robustness: Require more rigorous process model Budget/schedule limitations: May be good to use design-tocost/schedule models High-risk system nucleus: May indicate spiral/incremental approach
Risk Assessment
Risk Identification Risk Analysis Risk Prioritization Risk Abatement Strategies Risk Mitigation Planning Risk Mitigation
Risk Control
Risk Assessments Main Goal: Establishing a set of Risks that potentially threaten a project Three explicit steps in Risk Assessment:
Risk Identification
Find Risks and bring to the attention of management, senior level personnel, and the customer Assign quantitative values to risks (impacts, probabilities) Also perform cost/benefit analysis
Risk Analysis
Risk Prioritization
Rank risks, from 1..n Higher the rank, more resources invested (time, money)
Main tool: Expertise and previous experience Organizations attempt to develop various forms of checklists to capture previous experience and knowledge Other tools:
Identification process needs to involve all levels of business and technical staff, along with the customer
More/different experience leads to discovery of more risks Must integrate (overcome) different viewpoints
Historical Data Cost estimation tools (automated software; manual spreadsheets/forms) Expertise and Past Experiences Technical Risks: Modeling and Simulation, prototyping Cost Risks: Algorithmic cost models, Monte Carlo Simulations Schedule Risks: Algorithmic schedule models, Monte Carlo Simulations Operational Risks: Performance and Reliability Modeling
Not all Risks get included on the final list of Risks to manage Main Factor that contributes to the importance of a Risk (and ultimately a formal prioritized list) is Risk Exposure (probability * impact)
Initial Action Plans are executed to reduce risk Contingency Plans executed upon trigger to attack risks further Project Manager = Controller Depends upon completion of the Risk Assessment phase Three explicit steps:
Feedback upon whether risks are being managed or not If not, redirect, re-plan, and close loop
Determine strategies
Risk Mitigation:
Relies upon analysis/results of Risk Assessment phase May also rely upon Simulations, Prototypes, Data/History, Experts/Experience Risk Avoidance: May involve deletion of requirements or functionality Risk Transfer: May involve reallocating requirement or functionality Risk Acceptance: Involves further risk control
Consumption of resources to manage one risk may cause another risk to occur (must iterate)
Re-assess risks as plans are implemented and impacts are made (iterate the loop)
Companies that deal in advanced technologies now mandate Risk Management Plans
Includes senior technical and executive management, as well as the customer Goal is to understand the impacts risks may have on financial bottom lines
Communication Reporting risks to the highest levels of the organization (executives, VPs, etc.)
Regular reviews
Conclusions
Risk Management has been around (in various forms) for a long time, and is used in a vast array of industries Experience is perhaps the key tool used during the Risk Management process (finding, assessing, etc. risks)
Explicit steps are defined and well known Risks must be expected
Strengths:
Use of a wide range of types of Figures to illustrate various points/ideas Thorough and understandable discussion Use of many quick for example
Weaknesses:
History Lesson in the Risk Management Procedures section Discussion of Development Process relationship to Risk Management in the Types of Risks section
Makes clear to readers the organization of the paper Suggests already laid out in this presentation
Questions?
Thank You!!