Software Risk Management Richard H. Thayer Richard E. Fairley 2000 - PowerPoint PPT Presentation

1 / 20
About This Presentation
Title:

Software Risk Management Richard H. Thayer Richard E. Fairley 2000

Description:

Kristen Cannava. 5. Project Risk ... Kristen Cannava. 6. Risk Exposure. The product of probability and potential loss ... Kristen Cannava. 7. Risk Management ... – PowerPoint PPT presentation

Number of Views:224
Avg rating:3.0/5.0
Slides: 21
Provided by: davidaw1
Category:

less

Transcript and Presenter's Notes

Title: Software Risk Management Richard H. Thayer Richard E. Fairley 2000


1
Software Risk ManagementRichard H.
ThayerRichard E. Fairley2000
  • EEL6887 Software Engineering
  • Kristen Cannava
  • Spring 2006

2
Reference Sources
  • Software Risk Management, by Richard H. Thayer
    and Richard E. Fairley, Textbook Software
    Engineering Project Management, 2nd ed., edited
    by Thayer and Yourdon, IEEE Computer Society,
    2000, pp195.
  • Know Your Enemy Software Risk Management, by
    Karl E. Wiegers, Software Development, 1998.
  • Risk Identification Patterns for Software
    Projects, by Jakub Miler, Janusz Gorski, 5th
    National Conference on Software Engineering, 2003.

3
Overview
  • Risk Management
  • Project Risk
  • Risk Exposure
  • Risk Management vs. Project Management
  • Steps of Risk Management
  • Risk Identification
  • Risk Analysis
  • Risk Handling
  • Levels of Risk
  • Risk Monitoring
  • Risk Management Program Plan
  • Summary
  • Conclusions

4
Risk Management
  • An organized way of identifying risk factors,
    developing and selecting risk handling options,
    and mitigating risk when they become a problem
  • The primary goal is to identify and respond to
    potential problems with enough time to avoid a
    crisis
  • A strategy should be established early in a
    project and risks addressed throughout the
    lifecycle
  • Does not guarantee success

5
Project Risk
  • A potential problem that could be detrimental to
    a projects success should it form
  • Present in every Software Engineering Project
  • Characterized by the following
  • Uncertainty is involved
  • 0
  • A loss is associated with it
  • Life
  • Budget
  • Schedule
  • Delivery
  • Reputation
  • It is manageable
  • A human action can be applied to change its form
    and degree

6
Risk Exposure
  • The product of probability and potential loss
  • A problem is a risk that has materialized
  • A problem arises when the undesired event has
    occurred and a potential loss is now real
  • When dealing with risk it is not always easy to
    distinguish between single events, multiple
    events, continuous evens, and interdependent
    events, or between cause and effect
  • Systematic risk management requires that initial
    apprehensions be turned into specific root
    causes, and that the probabilities and potential
    losses be established

7
Risk Management vs. Project Management
  • Project Management deals with controlling risk
    factors generic to all software projects through
    institutionalized tools and techniques
  • Project Planning
  • Configuration Management
  • Verification and Validation
  • Risk Management is concerned with identifying and
    managing unique problems in a specific project
  • Risk Management is not a replacement for Project
    Management but an extension
  • When a project is successful, it is not because
    there were no problems but that the problems were
    overcome.

8
Risk Identification
  • An organized, thorough approach to seeking out
    the real risks associated with a program
  • Areas of risk for software projects
  • Schedule
  • Cost
  • Requirements
  • Quality
  • Operational Risks
  • Methods for identifying risk
  • Lifecycle cost and schedule analysis
  • Requirements documents
  • Prototyping and simulation models
  • Lessons-learned
  • Trade studies and analysis
  • Work breakdown structures (WBSs)
  • Schedule networks

9
Schedule Risks
  • Techniques for identifying schedule risks
  • Algorithmic scheduling models
  • A task with many tasks that must be completed
    before the milestone can be achieved
  • A task that must be completed before many other
    tasks can be initiated
  • Critical path methods
  • A slip in schedule for any activity on the
    critical path will result in a slip of the
    overall schedule
  • PERT analysis
  • Provides ranges of probabilities for achieving
    various project milestones

10
Cost Risks
  • Factors that influence cost risks
  • Creeping requirements
  • Requirements slowly increase without an increase
    in the budget
  • Schedule compression
  • Pressures from marketing, management, and the
    customer, which results in a nonlinear increase
    in software costs
  • Unreasonable budgets
  • Budget estimates based on the price necessary to
    satisfy the market, management, or the customer
    rather than the technical requirements
  • Techniques for identifying cost risks
  • Algorithmic cost models
  • Monte Carlo simulation can provide statistical
    ranges of cost based on probability distributions
    for the cost drivers
  • Aggregating the costs and associated risk factors
    for each element of the WBS can provide a
    detailed cost-risk analysis
  • Analysis of project assumptions
  • Budgets are usually determined using effort
    (people X time) as the primary cost factor but
    people and time are not interchangeable

11
Requirements Risks
  • Incorrect requirements
  • Do not correctly state user needs and customer
    expectations
  • Incomplete requirements
  • Do not state desired product features or
    particular aspects of product features
  • Inconsistent requirements
  • Conflict with other requirements in the same
    specification
  • Unclear requirements
  • Have more than one semantic interpretation
  • Unverifiable requirements
  • No finite process exists to verify that the
    product meets the requirements
  • Untraceable requirements
  • No audit trail from requirements to tested code
    and back
  • Volatile requirements
  • Constantly changed requirements
  • Continual addition of new requirements

12
Quality Risks
  • Risk factors that result in the delivery of
    unexpectedly poor software quality
  • Unreliable
  • Software does not perform its intended functions
    under specified conditions for stated periods of
    time
  • Unusable
  • Unreasonable effort is required to use the
    software or to train software users
  • Unmaintainable
  • Extraordinary effort is required to locate and
    fix errors in the software or to upgrade it for
    future use
  • Nonportable
  • Extreme difficulty is encountered in converting
    the software for use in a different operating
    environment
  • Nonexpandable
  • Software capability or performance cannot be
    increased by enhancing current functions or
    adding new functions

13
Operational Risks
  • The risk that a project may produce a system that
    does not satisfy operational needs
  • Does not possess the functional, performance, or
    quality attributes the customers and users want
    and need
  • Not the risk of hazard from a system in operation
  • Hazard is an intrinsic property or condition of a
    system that has the potential to cause an
    accident
  • Techniques for identifying operational risk
  • Performance modeling
  • Reliability modeling
  • Quality factor analysis

14
Risk Analysis
  • An examination of identified risks to determine
    the probabilities of undesired events and the
    consequences associated with those events
  • The purpose is to discover the causes, effects,
    and magnitude of identified risks, and to develop
    and examine alternative options for managing the
    identified risks.
  • Tools for analysis
  • Schedule network models
  • Lifecycle cost models
  • The results of risk analysis is a watch list
    containing
  • Prioritized risk factors
  • Consequences of the risks
  • Indicators that signal the onset of a problem
  • The event that indicates a potential problem has
    become a real problem

15
Risk Handling
  • Techniques and methods developed to reduce and/or
    control risk
  • Risk avoidance
  • Avoiding a high-risk approach to software
    development by selecting a lower-risk approach
  • Avoiding risk in one area of a project might
    increase risk in another area
  • Risk assumption
  • A conscious decision to accept the consequences
    should an undesired even occur
  • The project manager must determine the level of
    risk that can safely be assumed in each situation
    as it arises
  • Problem control (prevention)
  • The continuous monitoring of project status and
    the development of other solutions if the risk
    becomes a problem
  • Involves development of a risk reduction plan and
    tracking to that plan
  • Risk transfer
  • Transferring potential problems to other areas of
    responsibility
  • Knowledge acquisition
  • Uncertainty can be reduced by obtaining
    additional information to further assess risk and
    to develop new contingency plans.

16
Levels of Risk
  • Risk identification, analysis, and handling are
    not free but they can be cost-effective
  • Calculating cost-effectiveness of Risk management
  • Determine the probability of an undesired event
  • Determine the cost of the loss if the risk
    becomes a problem
  • Compute the maximum amount that should be spent
    by computing risk exposure (RE)
  • RE (probability of loss) X (amount of loss)
    the amount of money that can be spent to mitigate
    the risk
  • Examine the risk leverage (RL) factor that would
    result from mitigating the risk
  • RL (risk exposure before) (risk exposure
    after) / (cost of risk mitigation)
  • Risk exposure before is the risk exposure before
    risk mitigation
  • Risk exposure after is the risk exposure after
    risk mitigation
  • Higher values of RL indicate the better areas for
    investing in risk management
  • Risk mitigation activities may reduce
    probability, potential loss, or both

17
Risk Monitoring
  • Risks identified and accepted in the risk
    identification and analysis phases should be
    monitored constantly
  • Particular attention should be paid to risk
    triggers which are values of indicator metrics
    that have been identified to sound the alarm
    that a potential problem has or has a high
    probability of becoming a real problem
  • A major trap of risk management is refusal to
    acknowledge that a risk has become a problem and
    he resulting need to implement a risk-handling
    plan

18
Risk Management Program Plan
  • Describe risk identification, risk analysis, and
    risk handling
  • Describe the role of risk assessment in design
    reviews, technical performance monitoring, and
    change control process
  • Describe the methods of risk reduction,
    monitoring, and handling to be used for each
    assessed risk
  • Require a separate risk handling plan be prepared
    for each high-risk item, identify the timing for
    its development, citing originator, and review
    responsibilities
  • Require a risk reduction report be prepared for
    each item classified as medium or high risk
  • Contain for each accepted risk
  • Statement and assessment of the risk factor
  • Probability of the risk becoming a problem
  • Consequences and/or cost of the problem
  • Alternatives considered with risk, cost, and
    schedule of each
  • Recommended risk reduction/abatement method

19
Risk Management Program Plan cont.
  • Impact statement for implementation
    (cost/schedule/technical)
  • Responsible organization and personnel
  • Risk indicator metrics to be tracked
  • Risk trigger thresholds
  • Criteria for closure of the problem (should it
    occur)
  • Reviews and decision points
  • Recommended backup developments and tests
    including cost and schedule
  • Planning for the management of risk makes sense
    in order to
  • Eliminate risk wherever possible
  • Isolate and minimize risk
  • Develop alternate courses of action
  • Establish time and money reserves to cover risks
    that are not known

20
Summary
  • Risk factors for every software project should be
    identified, analyzed, and handled
  • Every project should have a risk management plan
  • Every manager should keep an up-to-date list of
    the projects top-10 project risks
  • Risk metrics should be collected, analyzed, and
    heeded
  • Preplanned risk handling activities should be
    implemented when the project metrics indicate
    that a risk has become a problem
Write a Comment
User Comments (0)
About PowerShow.com