Page 185 -

156 PART TWO MANAGING SOFTWARE PROJECTS

6.5 RISK REFINEMENT
During early stages of project planning, a risk may be stated quite generally. As time
passes and more is learned about the project and the risk, it may be possible to refine
the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor,
and manage.
One way to do this is to represent the risk in condition-transition-consequence (CTC)
? What is a format [GLU94]. That is, the risk is stated in the following form:
good way to
describe a risk?
Given that <condition> then there is concern that (possibly) <consequence>.
Using the CTC format for the reuse risk noted in Section 6.4.2, we can write:

Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of the
planned reusable modules may actually be integrated into the as-built system, resulting in
the need to custom engineer the remaining 30 percent of components.
This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that
is not supported on the target environment.
The consequences associated with these refined subconditions remains the same (i.e.,
30 percent of software components must be customer engineered), but the refinement
helps to isolate the underlying risks and might lead to easier analysis and response.

6.6 RISK MITIGATION, MONITORING, AND MANAGEMENT

All of the risk analysis activities presented to this point have a single goal—to assist
the project team in developing a strategy for dealing with risk. An effective strategy
must consider three issues:
“If I take so many • risk avoidance
precautions, it is
because I leave • risk monitoring
nothing to chance.” • risk management and contingency planning
Napolean
If a software team adopts a proactive approach to risk, avoidance is always the best
strategy. This is achieved by developing a plan for risk mitigation. For example, assume
that high staff turnover is noted as a project risk, r . Based on past history and man-
1