Monday, December 12, 2011

Chapter 25

Chapter 25
Risk Management

CHAPTER OVERVIEW AND COMMENTS

This chapter defines the process of risk management and explains why it is an important part of the planning process for any software project. The text contains practical advice on how to perform risk analysis and how to build risk mitigation, monitoring, and management (RMMM) plans. Students will have a hard time relating to this material without seeing lots of examples of software risks and techniques for managing them. Having students write RMMM plans or risk information (RSI) sheets for projects of their own design is an important part of their learning process.

25.1     Reactive vs. Proactive Risk Strategies

This section distinguishes between reactive and proactive risk strategies. It is important for students to understand that reactive strategies are usually not successful as a means of avoiding serious project problem. You might use the tragic events of 9/11 or the (considerably less serious, but still important) blackout of Summer, 2003 as examples of reactive as opposed to proactive approaches to risk.

25.2     Software Risks

Risks involve areas of uncertainty in the software development process that have the potential to result in nontrivial losses to the project. Most computing students will need help in recognizing that software risks go beyond technical concerns and also include the economic uncertainties that come with marketing a piece of software. Students also need to be aware that while most software risks can be identified prior to beginning a project, some cannot. The fact remains that even if it is impossible to manage all risks any planning is better than no planning.



25.3     Risk Identification

This section discusses the differences between identifying generic risks and product-specific risks. Generic risks can be listed on a checklist to examine for every software product. Examining the project plan and the software statement of scope identifies product-specific risks. Students may need to be shown examples of software project risk checklists. The risk assessment table shown in this section provides students with a good to begin quantifying the impact of many types of risk.

25.4     Risk Projection

Risk projection (estimation) attempts to associate with each risk the likelihood (probability) of its occurrence and the consequences of the resulting problems if the risk should occur. The students should go though the process of creating risk tables for projects of their own. Determining the probabilities and quantitative impact measures will be very hard for them. It may be wise to give them some heuristics for converting qualitative statements into measures. If it is easier for them to estimate costs to fix problems, then Halstead's risk exposure (RE) might be helpful to use.

25.5     Risk Refinement

Risk refinement is the process of decomposing risks into more detailed risks that will be easier to manage. Using the CTC (condition-transition-consequence) format may be helpful to students as they refine their own risks.

25.6     Risk Mitigation, Monitoring and Management

When teaching this section, it will be helpful to give students examples of several types of risks and have the class discuss detailed strategies for mitigation, monitoring, and management. Contingency plans often benefit from brain storming activities. This section also provides a chance to pitch the importance of metrics as a source of indicators that can assist managers in risk monitoring.
It is important to note that risk monitoring also includes tracing problems back to their points of origin (to do a better job of mitigating this risk in the future).


25.7     Safety Risks and Hazards

This section provides an opportunity to introduce a computing ethics topic. In fact, you might consider assigning Section 32.7 of Chapter 32 at this point in time.
Engineers are often entrusted with ensuring the safety of the public and software engineers are not exempted from this obligation. There are lots of stories in the media that provide examples of critical software systems that failed with dire consequences to people or businesses.

25.8     The RMMM Plan

The template RMMM plan appears on the SEPA Web site. Students should be encouraged to examine its headings.


No comments:

Post a Comment