- Forward


Risk Management (in Software Engineering)
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Risks/Hazards
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • Risk Identification
  • Risk Assessment (and Monitoring)
  • Risk Mitigation/Avoidance/Reduction
  • Risk Resolution
Risk Identification
Back SMYC Forward
  • Purpose:
    • Identify risks/hazards
  • Common Approaches:
    • Brainstorming
    • Checklist (based on past experience)
Identification - Describing Risks/Hazards
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • Reduce the Probability:
    • Change the environment
  • Reduce the Cost:
    • Develop contingency plans
    • Change the environment
Risk Resolution
Back SMYC Forward
  • Risk Reporting:
    • Report on occurrence of conditions/circumstances
  • Risk Reassessment:
    • Account for changes in probabilities and/or costs
The "Infrastructure" for Risk Management (from SEI's 7 Principles)
Back SMYC Forward
  • 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
There's Always More to Learn
Back -