Risk Management (in Software Engineering)

Risk Management (in Software Engineering)
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Risks/Hazards

Defined:
- An uncertain condition/circumstance that has negative consequences
Categories (in Software Engineering):
- Project Risks - have consequences for the schedule, budget, personnel and other aspects of project planning
- Technical/Product Risks - have consequences for the software product (e.g., its design, implementation, verification, deployment, or maintenance)
- Business Risks - have consequences for the non-technical viability of the product (e.g., marketing, sales, support)

Examples of Risks/Hazards

Project Risks:
- Staff turnover
- Management change
- Changing requirements
Technical/Product Risks:
- Failure of a third-party library
- Poorly performing tool
- Unusually high defect rate
Business Risk:
- Competitive products
- Low demand
- Unprepared sales force

Aspects/Components of Risk Management

Risk Identification

Identification - Describing Risks/Hazards

The Condition-Transition-Consequence (CTC) Format (Gluch, 1994):
- Given that condition, then there is concern that (possibly) consequence
Risk Characterizations (Boehm, 1989):
- Create a table with categories as the columns (e.g., catastrophic, critical, marginal, and negligible) and the risks/hazards as the rows

Identification - Risk Decomposition

Purpose:
- Discover the root cause(s) of risks/hazards
Approaches:
- Checklists
- Fault trees (Leveson and Stolzy, 1987) - nodes correspond to causes (with the risk/hazard at the root) and are decomposed using and/or branches (e.g., x will occur if y or z occur)

Risk Assessment

The Accepted View:
- Estimate the probability of each consequence
- Estimate the cost of each consequence
- Multiply the two to get the risk exposure (i.e., a component of the expected value)
My View:
- This is too simplistic (e.g., distributions matter, correlations matter) but it is a reasonable place to start

Risk Avoidance/Reduction

Risk Resolution

The "Infrastructure" for Risk Management (from SEI's 7 Principles)

Maintain a Global Perspective:
- Think of the software within the context of the business
Be Forward-Looking:
- Be (pro)active not reactive - create contingency plans
Encourage Open Communication:
- Encourage everyone to identify for risks/hazards