Fairley Rook p261

8/2/2019 Fairley Rook p261

1/34

Risk Management for SoftwareDevelopmentRichard FairleyColorado Technical UniversityColorado Springs, Colorado, USA

Paul RookThe Center for Software ReliabilityCity University, Northampton Square, London, UK

Presented by: Ken Waller

EEL 6883 Software EngineeringII


2/34

Presentation Agenda Review and Present the Paper

Give my Thoughts on the Paper Strengths Weaknesses

Suggestions for Improvements

Question and Answer Session But feel free to ask questions during the

presentation, as well


3/34

Paper Overview Introduction

Risk Management vs. Project Management

Risk Types Software Development Processes and their

Relationship to Risk Management

Detailed Discussion of Risk Management

Procedures Organizational Level Risk Management

Conclusions


4/34

Introduction History

1800s: Origins stem from the concept of RiskExposure (Insurance Industry)

1950s: Some related topics being taught inacademia (decision theory, probabilistic modeling)

1980s: Formal Risk Management used inPetrochemical and Construction Industries

1990s: Risk Management becomes an element ofSoftware Engineering

1990s Present: Risk Management appliedthroughout many diverse industries


5/34

Introduction Definitions:

Risk = PotentialProblem

Probability (0.0 1.0) (non-inclusive)

Loss (riskimpact)

Quantify: Money, human lives, etc.

Qualify: Credibility, trust

Problem = MaterializedRisk (reality)

Resources (time, money, personnel) needed tofix


6/34

Introduction When risk can be quantified:

RiskExposure= probability * impact

Example:

Probability that SW glitch will cause explosion:0.3 (30%)

Impact: 5 Human Lives (L)

Exposure: 0.3 * 5L = 1.5L


7/34

Introduction Risks are caused by events:

Single events

Multiple events

Continuous events

Interdependent events

Can be difficult to distinguish cause andeffect


8/34

Introduction Risk Management Overview:

State outcomethat you want to avoid

State courses of actionthat will lead toavoidance

Find root causes

Start withproject targets: cost,schedule, product (functionality,performance, quality, etc.) Risks are associated with targets


9/34

Introduction Risk Management Procedures: Basic Steps

(independent of industry or discipline):

Risk Assessment Identify Risks

Analyze Risks

Rate/Rank/Prioritize Risks

Risk Control Abate Risks

Create Risks Mitigation Plans

Apply Plans


10/34

Introduction Risk Management considerations:

Constraints

External conditions on project targets

Estimates

Ranges

Confidence levels Project Targets (negotiated)

Conditional maximum target


11/34

Conditional Maximum Targets

(expanded) Desire to maximize some project

attribute

Doing so may compromise another

Threshold

(maximum)

Cost Schedule Performance

Threshold

(maximum)

Threshold

(minimum)

Cost Schedule Performance Cost Schedule Performance


12/34

Risk Management vs. Project

Management Project Management (Classical)

Attempts to manage/control risks in

traditionalways: estimating, planning,scheduling

Problem Management

Reactive: Difficult choices and riskmitigation plans are made only afterproblems arise


13/34


Management Risk Management

Attempts to manage/control risks in a more focusedmanner: Risk Assessment

Identify what may go wrong Assign probabilities Assess negative impact severities

Risk Control Create plans to reduce probabilities and/or severities Create plans to resolve risks that surface

Reassess Risks True management of risks Proactive: Difficult choices and risk mitigation plans are

made beforerisks surface


14/34


Management Risk Management Augments Project

Management

Not the same thing Not a replacement

Risk Management not a guarantee

Successful projects: Overcome problems

Do not never encounter problems


15/34

Risk Types Four categories identified:

Contractual/Environmental: Problems with customers orvendors, hindering organizational policies, etc.

Management/Process: Unclear authorities andresponsibilities, weak or inadequate processes, etc.

Personnel: Lack of skills/training, etc.

Technical: Requirements creep, inadequate testing, etc.

Must be correctly typed so appropriate level can

address them


16/34

Risk Types

For Risk Control, two categories Generic

Common to most/all software projects

Methods to abate/control have been developed, over time Errors in products handled by V&V, incremental testing

Communication problems handled by documentation, reviews, andmeetings

Project Specific Associated with a particular project

Covered by the Risk Management Plan, consisting of Action Plans: Decision to engage in a risk reduction activity

without any further consideration (decision has been made)

Contingency Plans: Initiate risk reduction activity at some futuretime, if warranted

S ft D l t P d


17/34

Software Development Processes andtheir Relationship to RiskManagement

The use of a particular softwaredevelopment process is an essential risk

reduction technique To select an appropriate development

process, need to understand: Availablesoftware developmentprocesses

Critical Risk Factorsassociated with theproject under development

S ft D l t P


18/34

Software Development ProcessModels and their Relationship to RiskManagement

Available Software Development Processes: COTS: Overlooked; requirements match

Waterfall: Single Pass

Risk Reduction/Waterfall: RR, then Waterfall Capabilities-to-Requirements: Pick COTS, then adjust reqs

Transform: Tool automates generation of code

Evolutionary: Spiral, several passes

Prototyping: Low fidelity system

Incremental: Add capabilities in each build

Design-to-Cost/Schedule: Prune reqs to meet schedule/cost

S ft D l t P


19/34

Software Development ProcessModels and their Relationship to RiskManagement

Critical Risk Factors: Growth: High growth implies risk if using COTS

Available Technologies:

Ill-Defined Requirements: Feedback essential (usespiral/incremental)

Understanding of Architecture: Low understanding = highrisk of top down approach

Robustness: Require more rigorous process model

Budget/schedule limitations: May be good to use design-to-cost/schedule models

High-risk system nucleus: May indicate spiral/incrementalapproach


20/34

Detailed Discussion of RiskManagement Procedures

Review of Risk Management Procedures:

Risk Assessment

Risk Identification Risk Analysis

Risk Prioritization

Risk Control

Risk Abatement Strategies

Risk Mitigation Planning

Risk Mitigation


21/34


Risk Assessments Main Goal: Establishing a set ofRisksthat potentially threaten a project

Three explicit steps in Risk Assessment: Risk Identification

Find Risks and bring to the attention of management, seniorlevel personnel, and the customer

Risk Analysis Assign quantitative values to risks (impacts, probabilities)

Also perform cost/benefit analysis Risk Prioritization

Rank risks, from 1..n

Higher the rank, more resources invested (time, money)


22/34


More on Risk Identification: Main tool: Expertise and previous experience Organizations attempt to develop various forms of checklists

to capture previous experience and knowledge Other tools:

Scenarios Decompositions Prototyping Modeling and Simulation

Identification process needs to involve all levels of businessand technical staff, along with the customer More/different experience leads to discovery of more risks Must integrate (overcome) different viewpoints


23/34


More on Risk Analysis: Goal: Develop numerical aspects of risks

Analysis Tools & Techniques:

Historical Data Cost estimation tools (automated software; manual

spreadsheets/forms)

Expertise and Past Experiences

Other available Techniques depend upon type of Risk Technical Risks: Modeling and Simulation, prototyping

Cost Risks: Algorithmic cost models, Monte Carlo Simulations

Schedule Risks: Algorithmic schedule models, Monte CarloSimulations

Operational Risks: Performance and Reliability Modeling


24/34


More on Risk Prioritization:

Not all Risks get included on the final list of

Risks to manage Main Factorthat contributes to the

importance of a Risk (and ultimately aformal prioritized list) is Risk Exposure(probability * impact)


25/34


Risk Control relies on a Feedback Loop Feedback upon whether risks are being managed or not If not, redirect, re-plan, and close loop

Initial Action Plans are executed to reduce risk Contingency Plans executed upon trigger to attack risks further Project Manager = Controller Depends upon completion of the Risk Assessment phase Three explicit steps:

Risk Abatement Strategies:

Determine strategies Risk Mitigation Planning:

Produce detailed plans, based upon strategies

Risk Mitigation: Put plans into action and reduce/eliminate risks


26/34


More on Risk Abatement Strategies: Must first know where to start expending

resources Relies upon analysis/results of Risk Assessment phase May also rely upon Simulations, Prototypes,

Data/History, Experts/Experience

Three Basic Strategies Available: Risk Avoidance: May involve deletion of requirements or

functionality Risk Transfer: May involve reallocating requirement or

functionality Risk Acceptance: Involves further risk control

Must consider cost-benefit analysis


27/34


More on Risk Mitigation Planning:

Translate strategies into detailed plans

Action Plans Contingency Plans

Must take project schedule and resourceconsumption into account

Consumption of resources to manage one risk may causeanother risk to occur (must iterate)

Funds/resources can be set aside for risks(reserves)


28/34


More on Risk Mitigation:

Put mitigation plans into effect

Goal is to reach a resolution of the underlyingproblem

Must continually track (monitor and report)the characteristics of risks

Re-assess risks as plans are implemented andimpacts are made (iterate the loop)


29/34

Organizational Level RiskManagement

Companies that deal in advanced technologies now mandateRisk Management Plans Includes senior technical and executive management, as well as

the customer

Goal is to understand the impacts risks may have on financialbottom lines

Characteristics of Organizations that employ Risk Management: Explicit risk management processes defined and followed

Customization for specific project allowed

Communication

Reporting risks to the highest levels of the organization(executives, VPs, etc.) Regular reviews


30/34

Conclusions

Risk Management has been around (invarious forms) for a long time, and is used ina vast array of industries

Experience is perhaps the key tool usedduring the Risk Management process (finding,assessing, etc. risks) Prototyping, simulations can also be used

Explicit steps are defined and well known

Risks must be expected


31/34

My Opinions on the Paper

Strengths:

Use of a wide range of types of Figures to

illustrate various points/ideas Thorough and understandable discussion

Use of many quick for example


32/34


Weaknesses: Formatting Issue: No Numbering System Used

For Example: X. Risk Assessment (Risk Identification, Risk Analysis, ) Risk Identification Risk Analysis

Is less clear than: X. Risk Assessment

X.1 Risk Identification X.2 Risk Analysis X.3

Some content out of place History Lesson in the Risk Management Procedures section Discussion of Development Process relationship to Risk Management in

the Types of Risks section


33/34


Suggestions for Improvement:

Devise and incorporate a formal numbering

systems Makes clear to readers the organization of the

paper

Reformat the content

Suggests already laid out in this presentation


34/34

Questions?

Thank You!!

Fairley Rook p261

Documents

Transcript of Fairley Rook p261