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

50
RISK MANAGEMENT IN SOFTWARE DEVELOPMENT Dillon Hasselmann

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

Page 1: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

RISK MANAGEMENT IN

SOFTWARE DEVELOPMENT

Dillon Hasselmann

Page 2: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

that the problems were overcome”

Page 3: 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

Page 4: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

What is Risk?

Page 5: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 6: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Characteristics

UncertaintyProbability of occurrence

Associated LossWhat happens when it materializes?

ManageableHuman intervention can have an influence

Page 7: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

What is Risk Management?

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

Page 8: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 9: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 10: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Issues in Managing Risk

Culture of OrganizationFocus on optimization over dealing with

issuesRisk denialTroublemakers

Page 11: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 12: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 13: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Elements of Risk Management

Page 14: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Elements of Risk Management

Risk IdentificationWhat are the risks and impacts?

Risk AnalysisPlans for dealing with risks

Risk Mitigation/TreatmentActually dealing with the problem

Page 15: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Risk Identification

Page 16: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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?

Page 17: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 18: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Another Approach

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

Page 19: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Common Risk Factors

Organization Estimation Monitoring Development Methodology Tools Reliability Personnel

Page 20: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Types of Risks

Cost

Schedule

Requirements

Quality

Operational

Page 21: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Schedule Risks

Make an activity network

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

Page 22: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Cost Risks

Bad estimates

Requirements creep

Uncertain requirements

Unreasonable budgets

Page 23: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Requirements Risks

Incorrect requirements

Inconsistent requirements

Very difficult requirements

Unverifiable requirements

Unclear requirements

Page 24: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 25: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Operational Risks

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

satisfy customer

Page 26: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 27: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Risk Analysis

Page 28: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 29: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 30: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 31: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 32: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 33: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Treatment

Page 34: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 35: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Five Techniques

Risk Avoidance

Risk Acceptance

Problem Control and Prevention

Risk Transfer

Refinement of Knowledge

Page 36: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 37: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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”

Page 38: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 39: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 40: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Refinement of Knowledge Ongoing activity to reduce uncertainty

Not a “true” risk handling method

TechniquesPrototypingModelingBenchmarkingStudying

Page 41: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 42: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 43: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Responsible Risk Analysis

Page 44: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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?

Page 45: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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?

Page 46: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 47: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 48: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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

Page 49: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

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.

Page 50: Dillon Hasselmann. “When a project is successful, it is not because there are no problems, but that the problems were overcome”

Do You Have Any Questions?

Of course you do!