All risk analysis activities have a single purpose - to assist the project team in establishing a strategy for dealing with risk. An effective strategy must consider three issues:
· Risk avoidance
· Risk monitoring
· Risk management and contingency planning
Avoidance is always the best strategy if the software project team takes a proactive approach to risk. This can be achieved by establishing a risk mitigation plan. For example, frequent staff turnover is marked as a project risk, based on past history and management experience, the probability of staff turnover is 70%, and the impact is predicted to have a serious impact on project cost and schedule. To mitigate this risk, project managers must establish a strategy to reduce turnover. Possible strategies are as follows:
· Discuss with existing staff the reasons for turnover (e.g. poor working conditions, low pay, intense competition)
· Before the project begins, take action to mitigate those causes that are under management control.
· Once the project is launched, assume that personnel turnover will occur and take some technical measures to ensure continuity of work when personnel leave.
· The project is well organized so that information about each development activity can be widely disseminated and exchanged.
· Define documentation standards and establish mechanisms to ensure documentation can be created in a timely manner.
· Conduct a detailed review of all work so that more than one person is familiar with the work.
· Designate a backup for each key technician.
As the project progresses, risk monitoring activities begin. Project managers monitor certain factors that can provide an indication of whether risk is becoming higher or lower. In the above example, the following factors should be monitored:
· The general attitude of project team members to project stress.
· Project team cohesion.
· The relationship between project team members.
· Potential issues related to compensation and benefits.
· Possibility to work both inside and outside the company.
In addition to monitoring the above factors, project managers should monitor the effectiveness of risk mitigation steps. For example: In the above example, the risk mitigation step requires the definition of "documentation standards, and the establishment of corresponding mechanisms to ensure that documentation can be created in a timely manner". This is a mechanism to ensure continuity of work if a key person leaves the project team. Project managers should monitor these documents carefully to ensure that they are correct and provide new employees with the necessary information when they join the project.
Risk management and contingency planning assume that mitigation efforts have failed and risks become reality. Continuing with the previous example, suppose a project is underway and some people announce that they are leaving. If the mitigation strategy is followed, a back-up is available because the information is documented and knowledge is widely exchanged across the project team. In addition, project managers can temporarily redirect resources to where people are needed and adjust project schedules so that new members can "catch up." At the same time, those who are leaving are asked to stop working and enter "knowledge transfer mode".
The RMMM step will result in additional project overhead. Therefore, part of the task of risk management is to assess when the benefits produced by the RMMM steps are less than the costs of implementing them. Essentially, project planners perform a typical cost-benefit analysis to estimate changes in project costs.
For a large project, 30-40 risks may be identified. Risk management itself may become a "project" if three to seven risk management steps are defined for each risk. Experience has shown that 80% of the overall software risk (that is, 80% of the potential factors that may lead to project failure) can be accounted for by only 20% of known risks. The work accomplished in the early risk analysis steps can help planners determine which risks are in the said 20%.
1. Security risks and dangers
Risk is not limited to the software project itself. Risks can still occur after the software has been able to deliver to customers. These risks are generally associated with software failures in the domain.
While the probability of error in a good system is small, undetected errors in computer-based control and supervisory systems can result in huge financial losses, or worse
When software is used as part of a control system, complexity increases by orders of magnitude. Tiny design flaws caused by human error can become difficult to spot when using the software.
Software safety and risk analysis is a software quality assurance activity that is primarily used to identify and evaluate potential hazards that may negatively affect the software and cause the entire system to fail. If hazards can be identified in the early stages of software engineering, software design features can be specified to eliminate or control potential hazards.
2. RMMM plan
The risk management strategy can be included in the software project plan, or the risk management steps can be organized into a separate risk mitigation, monitoring and management plan (RMMM plan). The RMMM plan documents all risk analysis and is used by the project manager as part of the overall project plan. The outline of the RMMM plan is as follows:
I. Introduction
Scope and Purpose of Documentation
Overview of key risks
Responsibility
a. Manager
b. Technician
Ⅱ. Project Risk Table
Description of all risks above the termination line
Factors that affect the probability and influence
Ⅲ. Risk Mitigation, Monitoring and Management
ease
general strategy
Specific steps to mitigate risk
monitor
Factors being monitored
Monitoring methods
manage
Contingency plan
special consideration