17–8 With the explosion of computer hardware and software during the 1970s and 1980s, companies began developing models to assess the technical risk for the computer hardware and software effort. One such model is discussed in this problem. Although some people contend that there may still exist applicable use for this model, others argue that the model is obsolete and flawed with respect to current thinking. After reading the paragraphs below, explain why the model may have limited use today for technical risk management.

Previously, we showed that risk quantification could be found by use of an expected-value calculation. However, there are more sophisticated approaches that involve templates combined with the expected-value model. Here, we can develop mathematical expressions for failure and risk for specific types of projects.

Risk can be simply modeled as the interaction of two variables: probability of failure (Pf)

and the effect or consequence of the failure (Cf). Consequences may be measured in terms of technical performance, cost, or schedule. A simple model can be used to highlight areas where the probability of failure (Pf) is high (even if there is a low probability of occurrence).

Mathematically, this model can be expressed as the union of two sets, Pf and Cf. Table 17–14 shows a mathematical model for risk assessment on hardware–software projects. In other words, the risk factor (defined as Pf Cf) will be largest where both Pf and Cf are large, and may be high if either factor is large.

In this case, Pf is estimated by looking at hardware and software maturity, complexity, and dependency on interfacing items. The probability of failure, Pf, is then quantified from ratings similar to the factors in Table 17–14. Cf is calculated by looking at the technical, cost, and schedule implications of failure. For example, consider an item with the following characteristics:

● Uses off-the-shelf hardware with minor modifications to software database ● Is based on simply designed hardware ● Requires software of somewhat minor increase in complexity ● Involves a new database to be developed by a subcontractor Using Table 17–14, the probability of failure, Pf, would be calculated as follows:

Assume that the weighting factors for

a, b,

c, d, and e are 20 percent, 10 percent, 40 percent, 10 percent, and 20 percent, respectively.

Then Cf for this item [assuming that the weighting factors in equation (3) of Table 17–14 are as indicated above] would be 0.42.
From equation (1) of Table 17–14, the risk factor would be 0.30 0.42 (0.30)(0.42) 0.594 In other words, the risk associated with this item is medium. Because most of the risk associated with this example arises from software changes, in particular the use of a subcontractor in this area, we can conclude that the risk can be reduced when the computer software developer is held “accountable for work quality and is subject to both incentives and penalties during all phases of the system life cycle.”
Similar risk analyses would be performed for all other items and a risk factor would be obtained for each identified risk area. Risk areas would then be prioritized according to source of the risk (for example, are other items exhibiting excessive risk due to subcontractor software development?)

Transcribed Image Text:

(1) Risk Factor = Pr+ C- Pr Cr (2) P = a PM +bPM +c+Pc+d+Pc +e+PD where: hw SW PM = Probability of failure due to degree of hardware maturity PM = Probability of failure due to degree of software maturity SW Pc Probability of failure due to degree of hardware complexity hw = Pc Probability of failure due to degree of software complexity sw Pp = Probability of failure due to dependency on other items and where: a, b, c, d, and e are weighting factors whose sum equals one. (3) C=f C+g+C+h+C where: C = Consequence of failure due to technical factors C = Consequence of failure due to changes in cost C = Consequence of failure due to changes in schedule and where: f, g, and h are weighting factors whose sum equals one. Maturity Factor (PM) Complexity Factor (Pc) Magnitude Hardware Software Hardware PM PM Software Pc SW Existing Existing Simple Simple 0.1 design design Minor Minor Minor Minor 0.3 redesign redesign increases in increases in complexity complexity Major Major Moderate Moderate 0.5 change change increase increase feasible feasible Technology New software, 0.7 available, complex design similar to existing Significant increase Significant increase/major increase in # of modules 0.9 State of art, some research State of art, never done Extremely complex Extremely complex complete before Dependency Factor (PD) Independent of existing system, facility, or associate contractor Schedule dependent on existing system, facility, or associate contractor Performance dependent on existing system performance, facility, or associate contractor Schedule dependent on new system schedule, facility, or associate contractor Performance dependent on new system schedule, facility, or associate contractor