School of Computing and Information Systems
The University of Melbourne
Copyright University of Melbourne 2021-2022
Copyright By PowCoder代写 加微信 powcoder
2022 – Semester 1 Week 3, Module 2
Software Processes & Project Management
Risk Management
Learning Outcomes
Understand the fundamentals of risk management
Understand the Risk Management Process
Understand how to:
plan risk management activities
identify risks
analyze and assess risks respond to risks (risk strategies) monitor and control risks
SWEN90016 Software Processes and Project Management -2- Risk Management
Characteristics of Risk
• Determine which events should be considered as risks by analysing the following:
– Is the probability of the event occurring greater than zero?
– What is the impact of the event on the project?
– Do we have some degree of control over the event or its outcome?
• Generic Risks:
– Threats or opportunities common to every software project (e.g. staff turnover, budget and schedule pressures)
• Product-specific Risks:
– Threats or opportunities specific to the product, and can only be identified by people who have a clear understanding of the product and technology
SWEN90016 Software Processes and Project Management -3- Risk Management
Kinds of Risk
• Project risks
– Affect the planning of the project
e.g. Budget, Schedule, Scope, Personnel, etc.
• Product risks
– Affect the quality or performance of the outcome being
e.g. Design problems, implementation problems, interface problems, maintenance problems, verification problems
• Business risks
– Affect the economic success of the project
e.g. No demand for product, loss of management support, loss of external funding for the project etc.
SWEN90016 Software Processes and Project Management -4- Risk Management
Risk Identification
• Risk identification
– Deals with using a systematic approach for identifying and creating a list of threats and opportunities that may impact the project’s goals
• Risk identification techniques – Pondering
– Interviewing
– Brainstorming
– Checklists
– Delphi Technique – SWOT Analysis
SWEN90016 Software Processes and Project Management -5- Risk Management
Risk Identification Techniques
• Pondering
– This simply involves an individual taking the “pencil and paper” approach of risk identification, which involves sitting and thinking about the possible risks that could occur in the project
– This is one of the initial risk assessment tasks used in many projects
• Interviews/questionnaires
– Interviewing project stake holders, or asking them to fill out questionnaires, to harness their knowledge of a domain
– It is unlikely that a risk manager in a software project will have sufficient knowledge of the methods and tools to be employed to provide a comprehensive view of the risks, so input from stakeholder and domain experts is essential
SWEN90016 Software Processes and Project Management -6- Risk Management
Risk Identification Techniques
• Brainstorming
– The team can use a risk framework or the Work Breakdown Structure (WBS) to identify threats and opportunities
– The key is to encourage contributions from everybody
– The group then discuss and evaluate
• Checklists
– This involves the use of standard checklists of possible risk drivers that are collated from experience
– These checklists are used as triggers for experts to think about the possible types of risks in that area
SWEN90016 Software Processes and Project Management -7- Risk Management
Risk Identification Techniques
• Delphi Technique
– A group of experts are asked to identify risks and their impact
– The responses are them made available to each other anonymously
– The experts are then asked to update their response based on the responses of others – repeated until consensus is reached
• SWOT Analysis (Case study)
– Strengths, Weaknesses, Opportunities and Threats
– This technique allows finding strengths and weaknesses as well
SWEN90016 Software Processes and Project Management -8- Risk Management
Risk Identification – Example
• Example: Risk of a third-party software application
Consider the example of using a third-party software application to provide some functionality of a system that is being developed. The third-party application is developed in parallel with the system:
2. Oncecomplete,thethird-partyapplicationmaynotbereliableenoughtobe used, meaning that a new third-party application providing the functionality will need to be sourced or developed.
3. The third-party application may deliver behaviour that is inconsistent with the expectations of the system developers, meaning that a new third-party application providing the functionality will need to be sourced or developed.
The application could be delivered later than planned, thereby delaying the delivery of the entire system.
SWEN90016 Software Processes and Project Management -9- Risk Management
Identified Risks – example
Risk Source Category
Possible Risk Examples /Risk Factors
Project Size and Complexity
• Effort Hours
• Calendar Time
• Estimated Budget
• Team and Size (Number of Resources)
• Number of Sites
• Number of Business Units
• Number of Dependencies on other Projects
• Degree of Business Change
Requirements
• Volatile Requirements
• Unrealistic Quality Requirements
• Complex Requirements
Change Impact
• Replacement of
• Impact on Business Policies
• Impact on Organisational Structure
• Impact on Systems Operations
SWEN90016 Software Processes and Project Management -10- Risk Management
Identified Risks – example
Risk Source Category
Possible Risk Examples /Risk Factors
Stakeholders
• All key stakeholders have not been identified
• Missing “Buy-In” from a key stakeholder
• Stakeholder needs not completely identified
• Key stakeholders not fully engaged
Organization
• Changes to Project Objectives
• Lack of Priorities
• Lack of Project Management “Buy-In” and Support
• Inadequate Project Funding
• Misallocation and Mismanagement of Resources
• Grope • Leap • Creep
• Estimated Assumptions are Not Holding True
• Scheduled Contingency is Not Adequate
• Inadequate or Poor Estimation
SWEN90016 Software Processes and Project Management -11- Risk Management
Stakeholders
Risk Management – CASE 3 – Bank of America Debit Card Fee
2012 – Bank of America started charging its customers $5 per month to gain access to their funds using their debit cards
No Risk Management Plan – to account for risks stemming from ineffectively managing stakeholder consultations. Consequences far greater than imagined.
5-November-2011 – Bank Transfer Day 8-November-2011 – Dump your Bank Day
1. ThousandsofcustomersdumpedBankofAmericaandmovedaway to other banks and credit unions
2. A Risk Management Plan could have saved Bank of America bad press and the loss of business from lots of old time customers
‘Going full steam’ into a project – without little or no research on
potential consequences as key project risks can turn projects into a
Bank Transfer Day – Wikipedia
Bank dumping day begins – Nov. 4, 2011 (cnn.com)
Bank Transfer Day – Wikipedia
Bank dumping day begins – Nov. 4, 2011 (cnn.com)
Risk Management
SWEN90016 Software Processes and Project Management -13- Risk Management
Learning Outcomes
Understand the fundamentals of risk management
Understand the Risk Management Process
Understand how to:
plan risk management activities identify risks
analyze and assess risks respond to risks (risk strategies) monitor and control risks
SWEN90016 Software Processes and Project Management -14- Risk Management
Risk management Jokes (jokejive.com)
Risks Analysis and Assessment
Risk analysis and assessment provide a systematic approach for evaluating the risks
Risk analysis
– Identify each identified risk’s probability and impact Risk assessment
– Prioritize risks so that an effective risk strategy can be formulated
Two approaches for analysis and assessment:
– Qualitative: subjective assessment based on experience/intuition – Quantitative: mathematical and statistical techniques
SWEN90016 Software Processes and Project Management -16- Risk Management
Risk Analysis – Qualitative
• The important steps of risk analysis are:
Estimating the risk probability (P)
– this is an estimation of the probability that the risk will occur – usually done based on expert judgement
Estimating the risk impact (I)
the impact that the risk will have on the project Usually measured in a scale of 1 – 5 (or 10):
(1)no impact; (2) minimal impact; (3) moderate impact; (4) severe impact; and (5) catastrophic impact
Impact can be expressed as a monitory value
SWEN90016 Software Processes and Project Management -17- Risk Management
Risk Analysis – Qualitative
• The important steps of risk analysis cont..
3. Compute risk exposure (or P *I Score) Risk exposure= 𝑃∗ 𝐼
4. Identifying the root cause
– It is important that one identifies the root causes of all risks
– If this root cause can be identified, then all of these risks can be controlled by addressing the root cause
SWEN90016 Software Processes and Project Management -18- Risk Management
Risk Analysis – Example
• Example: Risk of a third-party software application
Consider the example of using a third-party software application to provide some functionality of a system that is being developed. The third-party application is developed in parallel with the system:
2. Oncecomplete,thethird-partyapplicationmaynotbereliableenoughtobe used, meaning that a new third-party application providing the functionality will need to be sourced or developed.
3. The third-party application may deliver behaviour that is inconsistent with the expectations of the system developers, meaning that a new third-party application providing the functionality will need to be sourced or developed.
The application could be delivered later than planned, thereby delaying the delivery of the entire system.
SWEN90016 Software Processes and Project Management -19- Risk Management
Risk Analysis – Example
Probability
The application could be delivered later than planned, thereby delaying the delivery of the entire system.
Once complete, the third-party application may not be reliable enough to be used, meaning that a new third-party application providing the functionality will need to be sourced or developed
The third-party application may deliver behaviour that is inconsistent with the expectations of the system developers, meaning that a new third-party application providing the functionality will need to be sourced or developed
Risk Impact Analysis Table
SWEN90016 Software Processes and Project Management -20- Risk Management
Risk Analysis – Example
Probability (0 – 100%)
Impact (1-10)
Exposure (1-5)
A key member leaving the project
Client unable to define scope and requirements
Client experiences financial problems
Response time not acceptable to the user/client
Technology does not integrate with existing application
Financial manages deflects resources away from the project
Client unable to obtain license agreement
Risk Impact Analysis Table
SWEN90016 Software Processes and Project Management -21- Risk Management
Risk Assessment – Risk Matrix
• Risk matrix – define the level of risk by considering the probability or likelihood consequence severity.
• A mechanism to increase visibility of risks and assist management decision making.
High Medium
Medium High LIKELIHOOD
SWEN90016 Software Processes and Project Management -22- Risk Management
Risk Matrix – Example
High Medium
Low Medium High LIKELIHOOD
SWEN90016 Software Processes and Project Management -23- Risk Management
Risk Assessment – Quantitative
Quantitative approaches include mathematical and statistical techniques
• They are based on modelling a particular risk situation – probability distributions of risks are the main consideration
• Common Techniques:
– Decision Tree Analysis – Simulation
– SensitivityAnalysis
Quantitative approaches are beyond the scope of this subject
SWEN90016 Software Processes and Project Management -24- Risk Management
Learning Outcomes
Understand the fundamentals of risk management
Understand the Risk Management Process
Understand how to:
plan risk management activities identify risks
analyze and assess risks respond to risks (risk strategies) monitor and control risks
SWEN90016 Software Processes and Project Management -25- Risk Management
References
• Shari L. Pfleeger and Joanne M. Atlee. Software Engineering: Theory and Practice. Prentice–Hall International,
3rd edition, 2006.
• R. S. Pressman. Software Engineering: A Practitioner’s Approach. McGraw Hill, seventh edition, 2009.
• J.T. Marchewka. Information Technology Project Management. & Sons, fourth edition, 2012.
SWEN90016 Software Processes and Project Management -26- Risk Management
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com