24 January Software Engineering Processes Risk Management.

17
24 January Software Engineering Processes Risk Management

Transcript of 24 January Software Engineering Processes Risk Management.

Page 1: 24 January Software Engineering Processes Risk Management.

24 January

Software Engineering Processes

Risk Management

Page 2: 24 January Software Engineering Processes Risk Management.

Web site content project description contact information schedule of weekly meetings project plan functional spec contract design document all user manuals test plan journal of meetings and decisions related links

Page 3: 24 January Software Engineering Processes Risk Management.

What’s Happening: Games Tonight: IGDA meeting 7-9

Emergent Technologies 54 and I-40 (exit 273)

http://www.igda.org/nctriangle/ Going Online with Emergent's Shared Entity and Simulator Framework Next-Gen Narrative Design

Saturday: Carolina Games Summit 10-9 Wayne Community College, Goldsboro http://www.carolinagamessummit.com/index.php

David Sipple, Piano Wizard Joel Gonzalez, 1st Playable Productions Dana Cowley, Epic games Tim Buie, NCSU School of Design Mark Myth, 3-D Learning SolnsAlex Macris, Themis Group Bruce Shankle, Microsoft

Page 4: 24 January Software Engineering Processes Risk Management.

Processes

Page 5: 24 January Software Engineering Processes Risk Management.

Software Engineering Fundamental Steps

Requirements Design Implementation Integration Test Deployment Maintenance Sunset

Page 6: 24 January Software Engineering Processes Risk Management.

Processes

Differ by how often you do the steps Points on the spectrum Differences in overhead

Three fundamental models Waterfall Spiral Iterative

Page 7: 24 January Software Engineering Processes Risk Management.

Waterfall Do it once Traditional model Used for large next version releases,

especially when tightly coupled changes Pros

Simple documentation management Clean design phase

Cons Least flexibility No early feedback

Page 8: 24 January Software Engineering Processes Risk Management.

Spiral Few iterations Each iteration adds new requirements Used often for projects with less well

defined requirements Pros

Adaptation to changes based on risks Good customer interaction Early version Limited iterations provide phase structure

Cons Document maintenance

Page 9: 24 January Software Engineering Processes Risk Management.

Iterative Many iterations Each iteration is on a fixed cycle

Typically weekly Used for projects with lots of small independent,

but well understood, changes Pros

Fast feedback on problems Very adaptable to any changes Lots of versions to work with

Cons Document maintenance Code maintenance Requires good automation

Page 10: 24 January Software Engineering Processes Risk Management.

Risk Management

Life is a risk.Diane Von Furstenberg

Page 11: 24 January Software Engineering Processes Risk Management.

Should we eliminate risk?

Take calculated risks. That is quite different from being rash. (Patton)

Great deeds are usually wrought at great risks. (Herodotus)

Great deeds are usually wrought at great risks. (Nehru)

No risk => no challenge

Page 12: 24 January Software Engineering Processes Risk Management.

Risks

“80% of software projects fail” Standish Report (1995) More recently: Sauer et al claim 67%

“delivered close to budget, schedule, and scope expectations”

Two types of risk Avoidable Unavoidable

Page 13: 24 January Software Engineering Processes Risk Management.

Risk Management

1. Identification2. Mitigation plan3. Prioritization4. Retirement

Page 14: 24 January Software Engineering Processes Risk Management.

Sources of Risk

1. Top management commitment2. User commitment3. Misunderstood requirements4. Inadequate user involvement5. Mismanaged user expectations6. Scope creep7. Lack of knowledge or skill

Keil et al, “A Framework for Identifying Software Project Risks,” CACM 41:11, November 1998

Page 15: 24 January Software Engineering Processes Risk Management.

Technical Risks

New features New technology Developer

learning curve Changes that may

affect old code Dependencies Complexity

Bug history Late changes Rushed work Tired

programmers Slipped in “pet”

features Unbudgeted items

Page 16: 24 January Software Engineering Processes Risk Management.

What can be controlled? Cost

Number of people Hours worked Hardware and software used

Capability Function that you ship

Quality Procedures that increase cost and quality Testing

Delivery Dates

Page 17: 24 January Software Engineering Processes Risk Management.

So what will you do if you’re behind?