24 January Software Engineering Processes Risk Management.
-
Upload
kelly-barker -
Category
Documents
-
view
212 -
download
0
Transcript of 24 January Software Engineering Processes Risk Management.
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
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
Processes
Software Engineering Fundamental Steps
Requirements Design Implementation Integration Test Deployment Maintenance Sunset
Processes
Differ by how often you do the steps Points on the spectrum Differences in overhead
Three fundamental models Waterfall Spiral Iterative
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
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
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
Risk Management
Life is a risk.Diane Von Furstenberg
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
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
Risk Management
1. Identification2. Mitigation plan3. Prioritization4. Retirement
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
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
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
So what will you do if you’re behind?