1Coming up: Project Risks Chapter 28 – Modified by Fleck Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2Coming up: Option 1: Deal with the problem when it occurs Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?

Option 1: Deal with the problem when it occurs 3Coming up: Option 2: Contingency plan: Plan ahead what you will do when the risk occurs Caller: I have a slight problem, I’m trapped in my burning house 911: Fire truck on it’s way

Option 2: Contingency plan: Plan ahead what you will do when the risk occurs 4 Coming up: Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence

Option 3: Risk mitigation: Lessen the probability of the risk occuring. Reduce the impact of occurence 5Coming up: Risk Management Paradigm Lets read about not playing with fire Reduce probabilityReduce impact

6Coming up: How to identify risks RISK Risk Management Paradigm control identify analyze plan track

How to identify risks Common risks - many risks are common to many project. Start with a list of these. (Your book has a list, and the web has many) Some examples: Schedule is optimistic, "best case," rather than realistic, "expected case”. Layoffs and cutbacks reduce team’s capacity Development tools are not in place by the desired time End user ultimately finds product to be unsatisfactory, requiring redesign and rework. Customer insists on new requirements. Vaguely specified areas of the product are more time-consuming than expected. Personnel need extra time to learn unfamiliar software tools or environment 7

8 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Risk Projection Risk projection, also called risk estimation, attempts to rate each risk in two ways the likelihood or probability that the risk will occur the consequences of the problems associated with the risk, should it occur. The are four risk projection steps: establish a scale that reflects the perceived likelihood of a risk occuring (high, medium, low or numeric) delineate the consequences of the risk estimate the impact of the risk on the project and the product if it occurs note the overall accuracy of the risk projection so that there will be no misunderstandings.

9 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Building a Risk Table RiskProbabilityImpactRMMM RiskMitigationMonitoring&Management Text description of the risk Probability of occurance Impact if occurs (Negligible=1…Catestrophic=5) Exposure Coming up in a few slides…

10 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Building the Risk Table Estimate the probability of occurrence Estimate the impact on the project on a scale of 1 to 5, where 1 = low impact on project success 5 = catastrophic impact on project success Determine the exposure: Risk Exposure = Probability x Impact Some use cost to the project rather than impact, but in my experience cost is hard to estimate accurately. - Fleck

11 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Risk Exposure Example Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed. Risk probability. 80% (likely). Risk impact. 60 reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200. Risk exposure. RE = 0.80 x 25,200 ~ $20,200. Personal Opinion: I don’t like this - Fleck

12 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. mitigation—how can we avoid the risk? monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely? management—what contingency plans do we have if the risk becomes a reality? Risk Mitigation, Monitoring, and Management

13 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Risk Management Paradigm RISK control identify analyze plan track Key step: Once you have created your risk spreadsheet… you must track and update it as things change.