Risk Analysis and Management - PowerPoint PPT Presentation

Loading...

PPT – Risk Analysis and Management PowerPoint presentation | free to download - id: 6b6385-YWVjM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Risk Analysis and Management

Description:

Risk Analysis and Management Developed by Reneta Barneva, SUNY Fredonia – PowerPoint PPT presentation

Number of Views:103
Avg rating:3.0/5.0
Slides: 33
Provided by: RenetaB3
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Risk Analysis and Management


1
Risk Analysis and Management
2
Risk Analysis and Management
  • Risks are potential problems that might affect
    the successful completion of a software project.
  • Risks involve uncertainty and potential losses.
    Risk analysis and management are intended to help
    a software team understand and manage uncertainty
    during the development process.
  • The important thing is to remember that things
    can go wrong and to make plans to minimize their
    impact when they do.
  • The work product is called a Risk Mitigation,
    Monitoring, and Management Plan (RMMM).

3
Risk Strategies
  • Reactive risk strategies Very common, resources
    are set aside to deal with likely risks, should
    they become a problem. The software team does
    nothing about risks until something goes wrong.
    At that point the team must work quickly to
    resolve the problem.
  • Proactive risk strategies Risk management begins
    before technical work starts. Risks are
    identified, their probability and impact are
    assessed and they are ranked by importance. The
    team builds a plan to avoid risks if they can or
    minimize them if the risks turn into problems.

4
Characteristics of Software Risks
  • Uncertainty the risk may or may not happen that
    is there are no 100 probable risks. (A risk that
    is 100 probable is a constraint on the software
    project.)
  • Loss if the risk becomes a reality, unwanted
    consequences or losses will occur
  • When risks are analyzed it is important to
    quantify the level of uncertainty and the degree
    of loss associated with each risk.

5
Categories of risks
  • Project risks
  • Technical Risks
  • Business Risks
  • Known Risks
  • Predictable/Unpredictable Risks

6
Project Risks
  • Threaten the project plan.
  • Usually result in delays in project schedule and
    increased costs.
  • Identifies potential budgetary, schedule,
    personnel, resource, customer, and requirements
    problems and their impact on a software project.

7
Technical Risks
  • Threaten product quality and timeliness of the
    schedule.
  • Identifies potential design, implementation,
    interface, verification, and maintenance problems.

8
Business Risks
  • Threaten the viability of the software to be
    built.
  • Top 5 business risks
  • Building an excellent product or system that no
    one really wants (market risk).
  • Building a product that no longer fits into the
    overall business strategy for the company
    (strategic risk).
  • Building a product that the sales force doesnt
    understand how to sell
  • Losing the support of senior management due to a
    change in focus or a change in people (management
    risk).
  • Losing budgetary or personnel commitment (budget
    risks)

9
Known Risks
  • Known from careful evaluation of current project
    plan.
  • Examples Unrealistic delivery date, lack of
    documented requirements or software scope, and
    poor development environment.

10
Predictable/Unpredictable Risks
  • Predictable Risks are extrapolated from past
    project experience.
  • Examples staff turnover, poor communication with
    the customer, dilution of staff.
  • Unpredictable risks are extremely difficult to
    identify in advance.

11
Risk Identification
  • Risk identification is a systematic attempt to
    specify threats to the project plan (estimates,
    schedule, resource loading, etc.) By identifying
    known and predictable risks, the project manager
    takes a first step toward avoiding them when
    possible and controlling them when necessary.
  • Generic Risks are a potential threat to every
    software project.
  • Product-specific Risks can be identified only by
    those with a clear understanding of the
    technology, the people, and the environment that
    is specific to the project at hand.
    Product-specific risks require more attention
    than generic risks.

12
Risk Item Checklist
  • Product size risks associated with the overall
    size of the software to be built or modified.
  • Business impact risks associated with
    constraints imposed by management or the
    marketplace.
  • Customer characteristics risks associated with
    the sophistication of the customer and the
    developers ability to communicate with the
    customer in a timely manner.
  • Process definition risks associated with the
    degree to which the software process has been
    defined and is followed by the development
    organization.

13
Risk Item Checklist
  • Development environment risks associated with
    the availability and quality of the tools to be
    used to build the product.
  • Technology to be built risks associated with the
    complexity of the system to be built and the
    newness of the technology that is packaged by
    the system.
  • Staff size and experience risks associated with
    the overall technical and project experience of
    the software engineers who will do the work.

14
Questions in Assessing Overall Project Risk
  • Have top software and customer managers formally
    committed to support the project?
  • Are end-users enthusiastically committed to the
    project and the system/product to be built?
  • Are requirements fully understood by the software
    engineering team and their customers?
  • Have customers been involved in the definition of
    requirements?
  • Do end-users have realistic expectations?
  • Is project scope stable?

15
Questions in Assessing Overall Project Risk
  • Does the software engineering team have the right
    mix of skills?
  • Are project requirements stable?
  • Does the project team have experience with the
    technology to be implemented?
  • Is the number of people on the project team
    adequate to do the job?
  • Do all customer/user constituencies agree on the
    importance of the project and on the requirements
    for the system/product to be built?

16
Assessing Overall Project Risk
  • If any one of the previous questions is answered
    negatively, mitigation, monitoring and management
    steps should be instituted without fail.
  • The degree to which the project is at risk is
    directly proportional to the number of negative
    responses to these questions.

17
Risk Components and Drivers
  • Performance risk the degree of uncertainty that
    the product will meet the requirements and be fit
    for its intended use.
  • Cost risk the degree of uncertainty that the
    project budget will be maintained.
  • Support risk the degree of uncertainty that the
    resultant software will be easy to correct,
    adapt, and enhance.
  • Schedule risk the degree of uncertainty that the
    project schedule will be maintained and that the
    product will be delivered on time.

18
Fig 6.1
19
Risk Projection
  • Also called risk estimation, attempts to rate
    each risk in two ways the likelihood or
    probability that the risk is real and the
    consequences of the problems associated with the
    risk, should they occur.

20
Risk Projection Activities
  • The project planner, along with other managers
    and technical staff, performs four risk
    projection activities
  • 1. Establish a scale that reflects the perceived
    likelihood of a risk
  • 2. Delineate the consequences of the risk
  • 3. Estimate the impact of the risk on the project
    and the product
  • 4. Note the overall accuracy of the risk
    projection so that there will be no
    misunderstandings.

21
Risk Table Construction
  • List all risks in the first column of the table
  • Classify each risk and enter the category label
    in column two
  • Determine a probability for each risk and enter
    it into column three
  • The probability value for each risk can be
    estimated by team members individually.
  • Enter the severity of each risk (negligible,
    marginal, critical, catastrophic) in column four
  • Sort the table by probability and impact value
  • Determine the criteria for deciding where the
    sorted table will be divided into the first
    priority concerns and the second priority
    concerns
  • First priority concerns must be managed (a fifth
    column can be added to contain a pointer into the
    RMMM)

22
Fig 6.2
23
Risk Projection Cutoff Line
  • This line is defined by the project manager on
    the risk table.
  • Implies that only risks that lie above the line
    will be given further attention.
  • Risks that fall below the line are re-evaluated
    to accomplish second-order prioritization.

24
Assessing Risk Impact
  • Three factors affect the consequences that are
    likely if a risk does occur
  • Its nature problems that are likely if it
    occurs
  • Its scope combines the severity with its
    overall distribution
  • Its timing when and how long the impact will be
    felt
  • Risk exposure
  • RE P C, where P is the probability of
    occurrence for a risk, and C is the cost to the
    project should the risk occur

25
Assessing Risk ImpactExample Problem
  • Risk identification.  Only 70 percent of the
    software components scheduled for reuse will, in
    fact, be integrated into the application. The
    remaining functionality will have to be custom
    developed.
  • Risk probability.  80 (likely).
  • Risk impact.  60 reusable software components
    were planned. If only 70 percent can be used, 18
    components would have to be developed from
    scratch (in addition to other custom software
    that has been scheduled for development). Since
    the average component is 100 LOC and local data
    indicate that the software engineering cost for
    each LOC is 14.00, the overall cost (impact) to
    develop the components would be 18 x 100 x 14
    25,200.
  • Risk exposure.  RE 0.80 x 25,200 20,200.

26
Risk Assessment
  • The referent point (break point)
  • the point at which the decision
  • to proceed with the project or
  • terminate it are equally
  • weighed.

Fig 6.4
27
Risk Assessment Steps
  • 1. Define referent levels for each project risk
    that can cause project termination (performance
    degradation, cost overrun, support difficulty,
    schedule slippage).
  • 2. Attempt to develop a relationship between each
    risk triple (risk, probability, impact) and each
    of the reference levels.
  • 3. Predict the set of referent points that define
    a region of termination, bounded by a curve or
    areas of uncertainty.
  • 4. Try to predict how combinations of risks will
    affect a referent level.

28
Risk Refinement
  • Process of restating the risks as a set of more
    detailed risks that will be easier to mitigate,
    monitor, and manage.
  • CTC (condition-transition-consequence) format may
    be a good representation for the detailed risks
    (e.g. given that ltconditiongt then there is a
    concern that (possibly) ltconsequencegt).

29
Risk Mitigation, Monitoring, and Management
  • Risk mitigation (proactive planning for risk
    avoidance)
  • Risk monitoring (assessing whether predicted
    risks occur or not, ensuring risk aversion steps
    are being properly applied, collect information
    for future risk analysis, attempt to determine
    which risks caused which problems)
  • Risk management and contingency planning (actions
    to be taken in the event that mitigation steps
    have failed and the risk has become a live
    problem)

30
Safety Risks and Hazards
  • Risks are also associated with software failures
    that occur in the field after the development
    project has ended.
  • Computers control many mission critical
    applications in modern times (weapons systems,
    flight control, industrial processes, etc.).
  • Software safety and hazard analysis are quality
    assurance activities that are of particular
    concern for these types of applications.

31
Risk Information Sheets
  • Alternative to RMMM in which each risk is
    documented individually.
  • Often risk information sheets (RIS) are
    maintained using a database system.
  • RIS components - risk identification, date,
    probability, impact, description, refinement,
    mitigation/monitoring, management/contingency/
    trigger, status, originator, assigned staff
    member.

32
(No Transcript)
About PowerShow.com