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...
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) format . That is, the risk is stated in the following form: 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.
