Page 183 -

154 PART TWO MANAGING SOFTWARE PROJECTS

where P is the probability of occurrence for a risk, and C is the the cost to the project
should the risk occur.
For example, assume that the software team defines a project risk in the follow-
ing manner:
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 cus-
tom 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.
Compare RE for all
risks to the cost Risk exposure can be computed for each risk in the risk table, once an estimate of
estimate for the the cost of the risk is made. The total risk exposure for all risks (above the cutoff in
project. If RE is greater the risk table) can provide a means for adjusting the final cost estimate for a project.
than 50 percent of
project cost, the It can also be used to predict the probable increase in staff resources required at var-
viability of the project ious points during the project schedule.
must be evaluated. The risk projection and analysis techniques described in Sections 6.4.1 and 6.4.2
are applied iteratively as the software project proceeds. The project team should revisit
the risk table at regular intervals, re-evaluating each risk to determine when new cir-
cumstances cause its probability and impact to change. As a consequence of this
activity, it may be necessary to add new risks to the table, remove some risks that are
no longer relevant, and change the relative positions of still others.

6.4.3 Risk Assessment
At this point in the risk management process, we have established a set of triplets of
the form [CHA89]:
[r , l , x ]
i
i
i
where r is risk, l is the likelihood (probability) of the risk, and x is the impact of the
i
i
i
risk. During risk assessment, we further examine the accuracy of the estimates that
were made during risk projection, attempt to rank the risks that have been uncov-
ered, and begin thinking about ways to control and/or avert risks that are likely to
occur.
For assessment to be useful, a risk referent level [CHA89] must be defined. For most
software projects, the risk components discussed earlier—performance, cost, sup-
port, and schedule—also represent risk referent levels. That is, there is a level for per-