1 / 16

Software Engineering

Software Engineering. Lecture 6 Risk Management. Reactive vs. Proactive Risk Strategies. Reactive: The software team does nothing about risks until something goes wrong. Proactive: The software team establishes a plan for managing risk. The primary objective is to avoid risk.

harmon
Télécharger la présentation

Software Engineering

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. Software Engineering Lecture 6 Risk Management

  2. Reactive vs. Proactive Risk Strategies • Reactive: • The software team does nothing about risks until something goes wrong. • Proactive: • The software team establishes a plan for managing risk. • The primary objective is to avoid risk. • The team develop a contingency plan as a respond in case a risk can not be avoided.

  3. Risk Characteristics • Uncertainty: The risk may or may not happen; that is, there are no 100% probable risks. • Loss: If the risk becomes a reality, unwanted consequences or losses will occur. A risk that is 100 percent probable is a constraint on the software project

  4. Categories of risks • Project Risks: threatens project plan e.g. overdue schedule, increased budget. • Technical Risks: threatens software qualitye.g. difficult / impossible implementation. • Business Risks: threatens software viabilitye.g. market risk, strategic risk, management risk, budget risk.

  5. Another categorization of risks (Charette. 1989) • Known risks: uncovered after careful evaluation of the software project (unrealistic delivery date, lack of documented requirements or software scope). • Predictable risks: extrapolated from past project experience (staff turnover, poor customer communication). • Unpredictable risks: risks that are extremely difficult to identify in advance, but they can and do occur.

  6. Stages of Risk Management • Risk Identification • Risk Impact Assessment • Risk Projection • Building a Risk Table • Determine Cutoff Line • Develop RMMM Plan

  7. Risk Identification • Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). • There are two distinct types of risks for each of the categories previously presented: • Generic risks: a potential threat to every software project • Product-specific risks: depends on the technology, people, and the environment specific to the project

  8. Risk Item Checklist • Risk Item Checklist is one method for identifying risks. • Generic risk subcategories: • Product Size (PS) • Business Impact (BU) • Customer Characteristics (CU) • Process Definition (PR) • Development Environment (DE) • Technology to be built (TE) • Staff Size and Experience (ST)

  9. Risk Impact Assessment • The impact of risks is divided into one of four impact categories: • Catastrophic: schedule delay, cost increase, project failure. • Critical: schedule delay, cost increase, but not as high as the first one. • Marginal: possible cost increase and schedule delay, but recoverable. • Negligible: no effect to cost and schedule.

  10. Risk Projection • Risk Projection (Risk estimation) attempts to rate each risk in two ways: • The probability that risk is real. • The consequences of the problems associated with the risk, should it occur.

  11. Risk Table Risks Category Probability Impact RMMM Staff turnover ST 60% 2 Lack of training tools DE 80% 3 End-users resist system PS 40% 3 Tightened deadline BU 50% 2 …..

  12. RMMM Plan • Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. • High probability, high impact risks are located at the top of the table. • The project manager then defines a cutoff line, indicating that only risks that lie above the line will be given further attention. • All risks that lie above the cutoff line must be managed, by developing the RMMM plan.

  13. Risk Mitigation, Monitoring, and Management • Risk Mitigation / Risk Avoidance • The software team adopts a proactive approach to risk. • Avoidance is always the best strategy. • Risk Monitoring • The project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely. • Risk Management and contingency planning • Assumes that mitigation efforts have failed and that the risk has become reality

  14. An Example of RMMM • Project Risk: High staff turnover • Probability: 70% • Impact: 2 (Critical) • Mitigation: improve working environment, increase salary. • Monitoring: monitor the team member general attitude, member interpersonal relationships. • Management: assign backup team member.

  15. Summary • When a lot is riding on a software project, common sense dictates risk analysis. • Risk Analysis can absorb a significant amount of project planning effort. But the effort is worth it. • Sun Tzu (500 BC) said, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” For the project manager, the enemy is risk.

  16. References • Pressman, Chapter 6

More Related