Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but...

RISK MANAGEMENT IN

SOFTWARE DEVELOPMENT

Dillon Hasselmann

“When a project is successful, it is not because there are no problems, but

that the problems were overcome”

Roadmap

What is a Risk? Elements of Risk Management

Risk IdentificationRisk AnalysisRisk Treatment

Responsible Risk Analysis

What is Risk?

What is a Risk?

A risk is “The likelihood of an event, hazard, threat, or situation occurring and its undesirable consequences”IEEE Standard 1540-2001

Characteristics

UncertaintyProbability of occurrence

Associated LossWhat happens when it materializes?

ManageableHuman intervention can have an influence

What is Risk Management?

Main Goal: Identify and respond to potential problems with enough time to avoid a crisis

How is it Done?

Identify risk factors

Analyze factors to estimate probability and possible impact(s)

Develop treatment options to deal with risks if they should become problems

Monitor risks on an ongoing basis

Issues in Managing Risk

Process is complexNot everyone knows probability

Limited insight“Crystal balls rarely found on sale”

Projects are just trying to get completedDevelopers don’t want to deal with problems

which haven’t materialized“Pay to fix” problems mentality

Issues in Managing Risk

Culture of OrganizationFocus on optimization over dealing with

issuesRisk denialTroublemakers

Common Risks and Preventions

Costly late fix to a productEarly verification and design work

Tons of bugs and defectsCode reviews and testing

Poor communication among the developersStatus reports and group meetings

Risk vs. Project Management

Project management deals with common risks found over the years which are present on nearly every project

Risk management deals with risks which are unique to a specific project

Elements of Risk Management

Elements of Risk Management

Risk IdentificationWhat are the risks and impacts?

Risk AnalysisPlans for dealing with risks

Risk Mitigation/TreatmentActually dealing with the problem

Risk Identification

Risk Identification Organized approach to determine actual risks

to a project

NOT: Dreaming up crazy schemes which will almost never occurWhat if the sun blows up tomorrow?

At the same time, do not ignore severe risks just because they’re too severe and no one would know what to doWhat if a runaway truck hits our senior engineer?

How do we go About Finding Risks?

2 paradigmsDirect: find root cause and then work

towards impacted areas

Indirect: Look at areas of impact and work backwards to possible root causes

Another Approach

Where do we look for risks?Traditional or folk knowledgeLearn from othersCommon senseResults of tests

Common Risk Factors

Organization Estimation Monitoring Development Methodology Tools Reliability Personnel

Types of Risks

Cost

Schedule

Requirements

Quality

Operational

Schedule Risks

Make an activity network

From http://syque.com/improvement/Activity%20Network.htm

Cost Risks

Bad estimates

Requirements creep

Uncertain requirements

Unreasonable budgets

Requirements Risks

Incorrect requirements

Inconsistent requirements

Very difficult requirements

Unverifiable requirements

Unclear requirements

Quality Risks Unreliable: Frequently breaks

Unusable: Too much effort to use

Unmaintainable: Hard to find and fix errors

Non-Portable: Only works in 1 environment

Non-Expandable: Can’t add new functionality

Operational Risks

Main cause: Development environment different from operating environmentProduct satisfies requirements, but doesn’t

satisfy customer

Many risks belong to more than one category!

What if we have to add more developers half-way through the project?

Cost? Salary and benefits

Schedule?Training

Quality? Unfamiliar with requirements

Risk Analysis

Risk Analysis

Primary goal is to uncover the cause and effects of risks and develop possible means to mitigate the problem should the risk become one

Subset of Risk Identification- sometimes you do both steps at the same time

Risk Exposure RE = probability * cost

Note that these are estimates!

Attempt to assign a monetary value to a risk

Generally, do not spend more than the calculated exposure to prevent the risk

From Hasker: Prioritize the risks that have high probability, high cost, then

high probability low cost. These are much more likely to have an impact on your

project

How is Risk Analysis Carried Out? One way- A risk list

Easy way to keep track of problems that might creep up

But does not list any possible solutionsBetter than nothing

Better Option- Risk Action ListSame as risk list, but with possible solutions

How is Risk Analysis Carried Out?

A more ideal alternative: watch list or risk registryTrigger eventActions taken to avoid a problemPerson(s) responsible for taking action

Goal: Assess the impacts of risks

Watch ListTrigger Event Action Taken Responsible

Person(s)

Code does not compile

Conduct code reviews to find the errors

Bob

Engineers unfamiliar with implementation language

Training by a certain date

Team leader

Budget overrun Talk with executive board to receive additional funding

Jack, Jill

Note that these can be sorted in order of priority

Treatment

Risk Treatment

Risks which have become (or about to become) problems are dealt with

This separates the men from the boys - does the team crumble when things go wrong? Or work together to solve the problem?

How is it different from risk analysis?Analysis: Brainstorming possible solutionsTreatment: Carrying out a solution

Five Techniques

Risk Avoidance

Risk Acceptance

Problem Control and Prevention

Risk Transfer

Refinement of Knowledge

Risk Avoidance

Select lower risk requirement over one with higher risk

Advantages?Easy to doIn some cases, eliminates the risk completely

Disadvantage?May not satisfy what the customer wants

Risk Acceptance Accept the consequences of the risk/problem

Hoping that the problem won’t destroy the project Advantage?

Don’t have to change requirementsThere could be other benefits from doing the project

a specific way Disadvantage?

What if the problem is much worse than anticipated

“I am aware of the risk yet I choose to accept it because of potential benefits”

Problem Control and Prevention

Aware of the risk, but measures are taken to reduce the chances of it surfacing as a problem and its impact

Essentially alternate solutions to problems

Disadvantage?Requires the development of a plan and the

effort to track its progress

Risk Transfer

Transfer responsibilities of one task over to someone (or something) else

Advantages?Give the job to someone who can do it

Disadvantages?You may lose control over a portion of your

project

Refinement of Knowledge Ongoing activity to reduce uncertainty

Not a “true” risk handling method

TechniquesPrototypingModelingBenchmarkingStudying

Treatment ExamplesRisk Avoidance Acceptance Control Transfer Knowledge

Refinement

Getting shot by someone with a gun

Don’t live in states without gun control laws

Assume someone else will get shot instead

Wear a bulletproof vest

Health Insurance

Learn self defense

Memory Leaks

Use Java Hope that the memory leaks don’t destroy the program

Use leakwatcher.h to search for memory leaks

Have someone else code portion of project

Learn about pointer management

Take CS 263

Other Issues

How do you know if your project was a failure?Not as easy as “we didn’t finish”

What if our product isn’t used?Satisfies requirements, but…

Possible solution?Responsible risk analysis

Responsible Risk Analysis

Responsible Risk Analysis The focus is on the stake holders

Anyone who interacts or is otherwise involved with the product

Think in terms of user interaction instead of “does it work”?

What type of software is being developed?Business?Commercial?Medical?

Example: Traffic Controller Direct traffic approaching a bridge to

least crowded lanes

How is it judged to be successful?Does it cause accidents?Did it speed up traffic flow?Was it done on time?Did it stay within the budget?

Example: Traffic Controller Despite being judged “successful”, the

project ended up being a failure

During periods under excessive load, the system would get out of synch and crashRequired a reboot periodically

Acknowledged by developerBut never fixed to satisfy time/budget

constraints

Quantitative vs. Qualitative

Most developers focus on quantitativeMost are universal among projectsEngineers are taught to recognize theseMost of us are very mathematically inclined

Professor at Carnegie Mellon Institute of Software Engineering defines good software as “usable, reliable, defect free, cost effective, and maintainable”

“Tunnel vision” of only seeing quantitative

But What About Qualitative? These may or may not affect if your project gets

finished

May have much more severe consequences if overlookedCan cause death!

Example: Aegis Radar SystemSuccessful in terms of budget, schedule, requirementsTerrible user interface blamed for a missile hitting a

commercial aircraft

References Barki, H., Rivard, S., & Talbot, J. (1993). Toward an Assessment of

Software Development Risk. Journal Of Management Information Systems, 10(2), 203-225.

  Christensen, M. (2001). The Project Manager's Guide to Software

Engineering's Best Practices. Washington: IEEE.

  Gotterbarn, D., & Rogerson, S. (2005). RESPONSIBLE RISK ANALYSIS

FOR SOFTWARE DEVELOPMENT: CREATING THE SOFTWARE DEVELOPMENT IMPACT STATEMENT. Communications Of AIS, 2005(15), 730-750.

Karolak, D. (1998). Software Engineering Risk Management. Washington: IEEE.

Pennington, R., & Tuttle, B. (2007). The Effects of Information Overload on Software Project Risk Assessment. Decision Sciences, 38(3), 489-526.

Do You Have Any Questions?

Of course you do!