9.3. O ne of the risk factors listed by Boehm in [Boehm91] is straining computer science capabilities; that is, attempting to implement software for which the algorithms are not known. Give three examples not mentioned in this text of areas where a customer might request features that would strain computer science capabilities. Briefl y explain each
9.5 Excessive overtime is an unacceptable method for overcoming problems in a software project.
- Briefl y explain how much overtime is excessive, in your opinion.
- Briefl y explain three risk factors for project success that are created by excessive overtime.
9.6. Software projects often have risk factors that are not apparent during initial planning of a software project. Give three examples of risk factors not mentioned in this text that might not be apparent during initial planning of a software project. Briefl y explain each.
9.7. Select one risk management technique (avoid, transfer, accept, act, defer, reject) for each of the risk factors listed in Table 9.2 (10 total). Briefl y explain how each of the risk management techniques you selected can be used to manage risk factors for software projects. Select each of the six techniques at least once
9.9 Prepare a spreadsheet to implement a risk register using the format in Table 9 .13. Populate the spreadsheet with some risk factors from Exercises 9.7 and 9.8, and/or some hypothetical risk factors. Hand in your spreadsheet program and a printed listing of the output from it.
FIGURE 9.2 A Monte Carlo estimate of project completion date
- what estimation methods and tools were used?
- what was the basis of estimation for each method and tool used (industry averages, expert judgment, local historical data, etc.)?
- how were differences in the estimates reconciled?
- what assumptions were made for each method or tool used?
- what constraints were observed in making the estimates?
- what inputs were used for each method or tool used (e.g., size, PI, MBI, adjustment factors)?
- what are the probability levels for effort, schedule, resources, cost, and quality attributes for each method or tool used?
- what other estimation data was provided by the estimation methods and tools (e.g., project milestones, effort for various project activities, estimated pre r elease and post- r elease defects, estimated reliability at product delivery, total life cycle costs)
- what risk factors were identifi ed for the project?
- what is the estimator ’ s (estimators ’ ) level of confi dence in the accuracy of the estimate (0 to 10; low, medium, high)?
- what information, resources, and time do the estimators need to make an improved estimate?
Table 9.13 KEY POINTS OF CHAPTER 9
- A risk factor is a potential problem that becomes a real problem when an objectively measured risk indicator crosses a predetermined threshold.
- Risk factors are characterized by probability of occurrence and potential loss.
- Project risk is the set of risk factors that have the potential to negatively impact a software project.
- Most standards and guidelines for software project management include risk management as a key process.
- Conventional project management techniques for planning and estimating, measuring and controlling, and leading and directing software projects are institutionalized techniques used to manage generic risk factors.
EXERCISES
- Risk management techniques are used to identify, analyze, prioritize, and mitigate project -s pecifi c risk factors.
- Risk mitigation strategies include avoidance, transfer, acceptance, immediate action, and contingent action.
- Successful risk mitigation reduces the probability and/or the loss of a potential problem to acceptable levels.
- Managing risk factors in your software projects will be easier, and more likely succeed, if risk management is supported at the organizational level of the organization in which your project is conducted.
- You and your customer, and you and your subcontractors (if any), should engage in joint risk management.
TABLE 9.7 Ratio – scale equivalents of ordinal symbols
| Ordinal Value | Approximate
Ratio – scale Value |
|
| Probability | Very low | 0.10 |
| Low | 0.25 | |
| Medium | 0.50 | |
| High | 0.75 | |
| Very high | 0.90 | |
| Impact | Very low | 10 |
| Low | 25 | |
| Medium | 50 | |
| High | 75 | |
| Very high | 90 |
- I n addition to the assessment of probability and impact, the time frame in which the risk factor might become a problem must be assessed. The risk of having insuffi cient personnel for work activities scheduled three months hence, for example, provides suffi cient time to make arrangements. As the time for the work to commence draws nearer, the probability that a staffi ng risk will become a staffi ng problem becomes higher
TABLE 9.8 Risk mitigation Strategies
| Strategy | Approach |
| Avoidance | Change the project or the product |
| Transfer | Reallocate the requirement(s) |
| Acceptance | Watch list |
| Immediate action | Reduce probability and/or impact |
| Contingent action | Delayed action, if warranted |
faster hardware processor can be used; if there is insuffi cient time to complete the project, perhaps the schedule can be extended, thus avoiding the risk of late delivery.
As mentioned above, risk factors are often created by project constraints and can sometimes be avoided by modifying the constraints. Process constraints (schedule, budget, resources), product constraints (features and quality attributes), and technology constraints (processor speed, available memory) should be examined. Some constraints may be essential to a successful outcome. Others, on closer examination, may be relaxed or removed.
.
