Sommerville-Software-Engineering-10ed

22.1 ■ Risk management 651
Figure 22.5 Strategies
to help manage risk
Risk
Organizational
financial problems
Recruitment
problems
Staff illness
Defective
components
Requirements
changes
Organizational
restructuring
Database
performance
Underestimated
development time
Strategy
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business and presenting
reasons why cuts to the project budget would not be
cost-effective.
Alert customer to potential difficulties and the possibility
of delays; investigate buying-in components.
Reorganize team so that there is more overlap of work
and people therefore understand each other’s jobs.
Replace potentially defective components with bought-in
components of known reliability.
Derive traceability information to assess requirements
change impact; maximize information hiding in the design.
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Investigate the possibility of buying a higher-performance
database.
Investigate buying-in components; investigate use of
automated code generation.
cope with the risk if it arises. These should reduce the overall impact of a risk on
the project or product.
22.1.4 Risk monitoring
Risk monitoring is the process of checking that your assumptions about the product,
process, and business risks have not changed. You should regularly assess each of
the identified risks to decide whether or not that risk is becoming more or less probable.
You should also think about whether or not the effects of the risk have changed.
To do this, you have to look at other factors, such as the number of requirements
change requests, which give you clues about the risk probability and its effects.
These factors are obviously dependent on the types of risk. Figure 22.6 gives some
examples of factors that may be helpful in assessing these risk types.
You should monitor risks regularly at all stages in a project. At every management
review, you should consider and discuss each of the key risks separately. You
should decide if the risk is more or less likely to arise and if the seriousness and
consequences of the risk have changed.