Download - CSE300 RISK Lecture - Unit2
-
7/22/2019 CSE300 RISK Lecture - Unit2
1/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 21
Risk In Systems Acquisition
CSE300 - Advanced Software EngineeringUniversity of Sunderland 2005
Material supplied By Helen M Edwards
Professor of Software Engineering
School of Computing and Technology
-
7/22/2019 CSE300 RISK Lecture - Unit2
2/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 22
Overview
What is Risk Risks from the Literature
Dealing with Risk (Risk Management)
The Generic Risk Management Lifecycle Overview of A Risk Method
Riskit: for systems development
Prior Reading - "Software Development Risk:
Opportunity, Not Problem"
by Roger Van Scoy
-
7/22/2019 CSE300 RISK Lecture - Unit2
3/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 23
Risk Definitions
The possibility of incurring misfortune or loss.
"Chance of a loss or other event on which a
claim may be filed.
The possibility of suffering loss, injury,disadvantage or destruction.
-
7/22/2019 CSE300 RISK Lecture - Unit2
4/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 24
Technical Definitions
The possibility of suffering loss: for risk to beunderstandable it must be expressed clearly.
Such a statement must include
A description of the current conditions thatmay lead to the loss
A description of the loss.
FromHiguera, R.P., Gluch, D.P., Dorofee, A.J., Murphy, R.L.,Walker, J.A., & Williams, R.C. An Introduction to Team RiskManagement. (CMU/SEI-94-SR-01) Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pa., May
1994.
-
7/22/2019 CSE300 RISK Lecture - Unit2
5/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 25
Technical Definitions
The possibility of loss, the loss itself or anycharacteristic, object or action that is
associated with that possibility.
A loss is defined as an outcomethat falls short ofwhat was expected.
Expectations are held/defined by stakeholders.
From Kontio,J. The Riskit Method for Software Risk
Management, version 1.00, CS-TR-3782, 1997. ComputerScience Technical Reports. University of Maryland. College Park,
MD.
-
7/22/2019 CSE300 RISK Lecture - Unit2
6/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 26
Risk
Risk is inextricably linked with the future. what is: the likelihood? cost/benefit of the
outcomes of what-if scenarios?
Dealing with: uncertainty and decision-making: based on existing data of past experiences,
expectations and (often) prejudices.
-
7/22/2019 CSE300 RISK Lecture - Unit2
7/27
University of
Sunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 27
Risk Definition
An Aphorism: You cant control what you cantmeasure. (Attributed to Lord Kelvin)
So: in any project each risk needs to be defined and
expressed in terms of: Likelihood of occurrence (probability) Consequence of occurrence (impact).
These measures need to be monitored and evaluated appropriate data needs to be collected at the appropriate
time.
-
7/22/2019 CSE300 RISK Lecture - Unit2
8/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
8
Risk and Time.
Risk= Probabilityx Impact.
But
both the probability and
the impact of an eventhappening can change
over time.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1st Qtr 2nd Qtr 3rd Qtr 4th Qtr
risk probability impact
-
7/22/2019 CSE300 RISK Lecture - Unit2
9/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
9
Typical Risks
The next few slides show typical risks thathave been identified and published in the
literature:
These are often the basis for formal repositorylists.
These are all from a systems development
perspective
-
7/22/2019 CSE300 RISK Lecture - Unit2
10/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
10
Boehms Top 10 risk
items
People Personnel shortfalls
Resources Unrealistic schedules
and budgets Requirements
Developing wrongfunctions
Developing wrong UI Gold plating
Changing requirements
External risks Shortfalls in externally
produced components
Shortfalls in externallyperformed tasks
Technology risks Real-time performance
inadequacies
Straining CS [computing]capabilities
IEEE Software, January 1991.
-
7/22/2019 CSE300 RISK Lecture - Unit2
11/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
11
Common Risks from Keil
et al
1. lack of top management
commitment to the project
2. failure to gain user commitment
3. misunderstanding the
requirements
4. lack of adequate user
involvement
5. failure to manage end user
expectations
6. changing scope/ objections
7. lack of required knowledge or
skills in the project personnel
8. lack of frozen requirements
9. introduction of new technology
10. insufficient or inappropriate staffing
11. conflict between user departments.
Identified by experienced software project managers from the USA,
Hong Kong and Finland.
In order of perceivedimportance, these factors are:
Framework for identifying software project risks
Communications of the ACM, vol 41 (11)
-
7/22/2019 CSE300 RISK Lecture - Unit2
12/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
12
Moynihans risks/concerns
1. Clients understanding of the requirements/problem to be solved (12)
2. Seniority & commitment of the project patron/owner (9)
3. Level of IT competence, experience of the customers (9)
4. Need to integrate/interface with other systems (9)
5. Scale/coordination complexity of the project (need to share
resources, subcontract, etc) (8)
6. Where project control resides (developer v client v third parties) (8)
7. Level of change to be experienced by the client (to procedures,
workflow, structures, etc) (7)
8. The need to satisfy multiple groups of disparate users versus theneed to satisfy one group of similar users (7)
9. Who we will be working through: users versus the IT department,
individuals versus committees (7)
10. Developers familiarity with platform/environment/methods (7)
(From 14 experienced systems developer managers in Ireland:
developing systems for other companies)
-
7/22/2019 CSE300 RISK Lecture - Unit2
13/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
13
Moynihans risks
11. Developers previous experience with the application (6)
12. Level of enthusiasm/support/"energy" for the project in the
clients organization (5)
13. Logical complexity of the application (5)
14. Ease of solution validation (e.g. possibility of prototyping) (4)
15. Clients willingness/capability to handle implementation (3)16. Freedom of choice of platform/development environment (3)
17. Criticality/reversibility of the new system roll-out (2)
18. Maturity of the technology to be used (2)
19. Developers knowledge of country/culture/language (2)
20. Stability of the clients business environment (2)
21. Developers knowledge of clients business sector (2)
IEEE Software 14(3) pp35-41
-
7/22/2019 CSE300 RISK Lecture - Unit2
14/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
14
Risk Assessment & Mgt.
General Framework
Another Aphorism: If you fail to plan, you plan to fail.(Attributed to Tom Gilb)
-
7/22/2019 CSE300 RISK Lecture - Unit2
15/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
15
Example Method
Riskit: a method for systems development.
Reference: Kontio,J. The Riskit Method forSoftware Risk Management, version 1.00, CS-TR-
3782, 1997. Computer Science Technical Reports.
University of Maryland. College Park, MD.Kontio's ref: downloadable from:
http://www.sbl.tkk.fi/jkontio/riskittr.pdf
http://www.sbl.tkk.fi/jkontio/riskittr.pdfhttp://www.sbl.tkk.fi/jkontio/riskittr.pdf -
7/22/2019 CSE300 RISK Lecture - Unit2
16/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
16
Riskit
Aimed at systems development. All stakeholders within a project should
have input.
Difficult to evaluate risks quantitatively:
therefore need to cater for qualitative risk
assessment.
Participant communication is essential.
-
7/22/2019 CSE300 RISK Lecture - Unit2
17/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
17
The Riskit Method and its Life
Cycle
The focus in
typical
risk methods
-
7/22/2019 CSE300 RISK Lecture - Unit2
18/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
18
Components of Each Step
Description:
Entry Criteria
Input:
Output:
Methods and tools:
Responsibility:
Resources:
Exit Criteria:
Th Ri kit M th d d
-
7/22/2019 CSE300 RISK Lecture - Unit2
19/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
19
The Riskit Method and
its Life Cycle
-
7/22/2019 CSE300 RISK Lecture - Unit2
20/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
20
Steps TechniquesRisk management
mandate definition
Risk management mandate template.
Goal review Goal-Question-Metric (GQM), Stakeholder-goalpriority table, goal definition template.
Risk identification Brainstorming techniques
Goal and stakeholder driven identification approachesMeeting aidsInterviews
Risk analysis Riskit analysis graphMultiple criteria decision making tools (such as AHP)Riskit Pareto ranking technique
Risk control planning Riskit element reviewRiskit controlling action taxonomy
Risk control NA
Risk monitoring Organisation measurement program or database
Techniques in Riskit
-
7/22/2019 CSE300 RISK Lecture - Unit2
21/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
21
FeaturesTechniques
strategic detailed Riskit
defined
generic
Goal-Question-Metric (GQM) Brainstorming techniques Goal and stakeholder driven identification Meeting aids * * Interviews Riskit analysis graph Multiple criteria decision making tools * * (e.g. AHP)
Riskit Pareto ranking technique Riskit element review Riskit controlling action taxonomy Organisation measurement program or
Database
Summary of
Techniques
-
7/22/2019 CSE300 RISK Lecture - Unit2
22/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
22
Goal and Stakeholder
Driven Identification
StakeholdersGoals
Sales ManagerPriority: 3
Project ManagerPriority: 2
CustomerPriority: 1
Deliver withintimescale
1 2 1
Deliver all requiredfeatures
2 1 3
Have fully trainedstaff
3 4 4
Deliver withinbudget
4 3 2
A simple technique to rank the identified goals within each
stakeholder. N.B. Comparison cannot be made across rows (or goals)
Different stakeholders may be of different priority/ importance in theproject .
-
7/22/2019 CSE300 RISK Lecture - Unit2
23/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
23
Risk Analysis Graph(example from the Riskit Manual)
-
7/22/2019 CSE300 RISK Lecture - Unit2
24/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
24
Risk Analysis Graph
Each path
through thegraph is a
scenario
Scenario 1
Risk Scenario Ranking
-
7/22/2019 CSE300 RISK Lecture - Unit2
25/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
25
Risk
Scenario probability
Utility lossAlmost
certain. (0.9)
Very likely
(0.75)
Likely (0.6). Almost
impossible (0.1)
Catastrophic Scenario1 Scenario2
Critical Scenario 4 Scenario3
SevereScenario 5 Scenario 6
Minimal Scenario 7
Risk Scenario Ranking:
Using Pareto-efficient sets
Riskit controlling action
-
7/22/2019 CSE300 RISK Lecture - Unit2
26/27
University ofSunderland CSE300 ADVANCED SOFTWARE ENGINEERING Session 2
26
Riskit controlling action
taxonomy.
-
7/22/2019 CSE300 RISK Lecture - Unit2
27/27
University ofCSE300 ADVANCED SOFTWARE ENGINEERING
27
Prior Reading
Prior to the next session,
Session 3Software Measurement,
students MUST read the Notesentitled Measurement Prior
Reading