1. 24 January Software Engineering Processes Risk Management

2. 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

3. 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 WizardJoel Gonzalez, 1 st Playable Productions Dana Cowley, Epic gamesTim Buie, NCSU School of Design Mark Myth, 3-D Learning SolnsAlex Macris, Themis Group Bruce Shankle, Microsoft

4. Processes

5. Software Engineering Fundamental Steps Requirements Design Implementation Integration Test Deployment Maintenance Sunset

6. Processes Differ by how often you do the steps Points on the spectrum Differences in overhead Three fundamental models Waterfall Spiral Iterative

7. 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

8. 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

9. 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

10. Risk Management Life is a risk. Diane Von Furstenberg

11. 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

12. Risks “80% of software projects fail” Standish Report (1995) Standish Report More recently: Sauer et al claim 67% “delivered close to budget, schedule, and scope expectations”Sauer et al Two types of risk Avoidable Unavoidable

13. Risk Management 1. Identification 2. Mitigation plan 3. Prioritization 4. Retirement

14. Sources of Risk 1. Top management commitment 2. User commitment 3. Misunderstood requirements 4. Inadequate user involvement 5. Mismanaged user expectations 6. Scope creep 7. Lack of knowledge or skill Keil et al, “A Framework for Identifying Software Project Risks,” CACM 41:11, November 1998

15. 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

16. 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

17. So what will you do if you’re behind?