Page 188 -

CHAPTER 6 RISK ANALYSIS AND MANAGEMENT 159

computer-based control and monitoring far outweigh the risk. Today, computer hard-
ware and software are used regularly to control safety critical systems.
When software is used as part of a control system, complexity can increase by an
order of magnitude or more. Subtle design faults induced by human error—some-
WebRef thing that can be uncovered and eliminated in hardware-based conventional con-
A voluminous database trol—become much more difficult to uncover when software is used.
containing all entries from Software safety and hazard analysis [LEV95] are software quality assurance activ-
the ACM’s Forum on Risks
to the Public can be found ities (Chapter 8) that focus on the identification and assessment of potential hazards
at that may affect software negatively and cause an entire system to fail. If hazards can
catless.ncl.ac.uk/ be identified early in the software engineering process, software design features can
Risks/search.html
be specified that will either eliminate or control potential hazards.

6.8 THE RMMM PLAN
A risk management strategy can be included in the software project plan or the risk
management steps can be organized into a separate Risk Mitigation, Monitoring and
Management Plan. The RMMM plan documents all work performed as part of risk
analysis and is used by the project manager as part of the overall project plan.
Some software teams do not develop a formal RMMM document. Rather, each risk
is documented individually using a risk information sheet (RIS) [WIL97]. In most cases,
the RIS is maintained using a database system, so that creation and information entry,
priority ordering, searches, and other analysis may be accomplished easily. The for-
RMMM Plan mat of the RIS is illustrated in Figure 6.5.
Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence. As we have already discussed, risk mitigation is a prob-
lem avoidance activity. Risk monitoring is a project tracking activity with three pri-
mary objectives: (1) to assess whether predicted risks do, in fact, occur; (2) to ensure
that risk aversion steps defined for the risk are being properly applied; and (3) to col-
lect information that can be used for future risk analysis. In many cases, the prob-
lems that occur during a project can be traced to more than one risk. Another job of
risk monitoring is to attempt to allocate origin (what risk(s) caused which problems
throughout the project).

6.9 SUMMARY

Whenever a lot is riding on a software project, common sense dictates risk analy-
sis. And yet, most software project managers do it informally and superficially, if
they do it at all. The time spent identifying, analyzing, and managing risk pays itself
back in many ways: less upheaval during the project, a greater ability to track and
control a project, and the confidence that comes with planning for problems before
they occur.