1 / 17

24 January

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.

satin
Télécharger la présentation

24 January

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Wizard Joel Gonzalez, 1st Playable Productions • Dana Cowley, Epic games Tim Buie, NCSU School of Design • Mark Myth, 3-D Learning Solns Alex 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) • More recently: Sauer et al claim 67% “delivered close to budget, schedule, and scope expectations” • Two types of risk • Avoidable • Unavoidable

  13. Risk Management • Identification • Mitigation plan • Prioritization • Retirement

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

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

  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?

More Related