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


2/27

University of


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


3/27

University of


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.


4/27

University of


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.


5/27

University of


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.


6/27

University of


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/27

University of


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.


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


9/27


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


10/27


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.


11/27


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)


12/27


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)


13/27


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


14/27


14

Risk Assessment & Mgt.

General Framework

Another Aphorism: If you fail to plan, you plan to fail.(Attributed to Tom Gilb)


15/27


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


16/27


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.


17/27


17

The Riskit Method and its Life

Cycle

The focus in

typical

risk methods


18/27


18

Components of Each Step

Description:

Entry Criteria

Input:

Output:

Methods and tools:

Responsibility:

Resources:

Exit Criteria:

Th Ri kit M th d d


19/27


19

The Riskit Method and

its Life Cycle


20/27


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


21/27


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


22/27


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 .


23/27


23

Risk Analysis Graph(example from the Riskit Manual)


24/27


24

Risk Analysis Graph

Each path

through thegraph is a

scenario

Scenario 1

Risk Scenario Ranking


25/27


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


26/27


26

Riskit controlling action

taxonomy.


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

cse300 risk lecture - unit2

Documents