Risk management is one of the main activities of project managers. It involves anticipating risks that might affect the project schedule or the quality of the software being developed and taking action to avoid these risks. The results of the risk analysis should be documented in the project plan along with an analysis of the consequences of a risk occurring. There are three categories of risk:
1. Project risks. These risks affect the entire project schedule.
2. Product risks. Product risks have influence on the quality and performance of the software.
3. Business risks. These risks affect the organization developing or procuring the software.
Project manager has to get ready for risks, understand the impact of these risks on the project, the product and the business, and take steps to avoid these risks. Project manager should prepare contingency plans so that, if the risks occur, he can take immediate actions.
The risk management process is shown in Figure 11.2. It has four stages:
1. Risk identification. Possible project, product and business risks are identified.
2. Risk analysis. Using risk analysis the probability and consequences of risks are analyzed.
3. Risk planning. The objective of risk planning is to avoid the risks or minimize its effects.
4. Risk monitoring. The identified risk is continuously assessed and the avoidance strategies are revised as more information becomes available about the risk.
Figure 11.2. The risk management process.
The risk management process is an iterative process which continues throughout the project. As more information about the risks becomes available, the risks have to be reanalyzed and the avoidance and contingency plans has to be also modified. The outcomes of the risk management process should be documented in a risk management plan.
11.4.1 Risk identification
The first stage of risk management is the identification of risks. It is concerned with discovering possible risks to the project. Risk identification may be carried out as a team work based on the experience of team members. Helping the process risks are usually classified into separate groups:
1. Technology risks. These risks are related to the software or hardware technologies that are used to develop the system.
2. People risks. Risk that are associated with the people in the development team.
3. Organizational risks. Risk that derive from the changes in organizational environment.
4. Tools risks. Risk that derive from the CASE tools and other support software used in the development process.
5. Requirements risks. Risk that derive from changes to the customer requirements and the process of managing the requirements change.
6. Estimation risks. Risk that derive from the management estimates of the system characteristics and the resources required to build the system.
Table 11.1. gives some examples of possible risks in each of these categories.
Table 11.1. Risks and risk types.
Risk type Possible risks
Technology Purchased software component is defective.
People Development manager regularly gets ill.
Organizational The management of software company is restructured and other project management is responsible for the project.
Tools The class skeleton generated by UML editor inefficient.
Requirements Changes to software requirements which require development of additional increments.
Estimation The time required to develop a software components is underestimated.
11.4.2 Risk analysis
During the risk analysis process, the probability and the effects of identified risks are determined. This process is mainly based on the experience of project managers. The risk estimates are generally assigned to different bands:
1. The probability of the risk might be assessed as very low (<10%), low (10–25%), moderate (25-50%), high (50–75%) or very high (>75%).
2. The effects of the risk might be assessed as catastrophic, serious, tolerable or insignificant.
Table 11.2. illustrates results of risk analysis.
Table 11.2. Risk analysis.
Risk Probability Effects
It is not possible to recruit developers with appropriate skills
High Catastrophic
One of the software developers who regularly gets a flu in every years gets a flu again in this year
High Serious
The database used has a lower performance as expected.
Moderate Serious
Development time for a software component is underestimated.
High Serious
Once the risks have been analyzed and ranked, it is necessary to decide which risks are most significant. In general, the catastrophic risks and the serious risks having more than a moderate probability of occurrence should always be considered.
11.4.3 Risk planning
The risk planning process identifies strategies to manage the identified risks. There is no general procedure to establish risk management plans. It is mostly based on the judgement and experience of the project manager. Table 11.3. shows possible strategies that have been identified for the key risks from Table 11.2.
The risk management strategies have three categories:
1. Avoidance strategies. Following these strategies means that the probability that the risk will arise will be reduced.
2. Minimization strategies. The objective of these strategies is to reduce the effect of risk.
An example of a risk minimization strategy is that for staff illness shown in Table 11.3.
3. Contingency plans. These are the strategies used when risk arises.
Table 11.3. Risk management strategies.
Risk Strategy
Recruitment problems
Notify customer of potential difficulties, search for software components to purchase, looking for a sub-contractor company Staff illness Reorganize the development team so that more people can have the
same competence Database
performance
Purchase of a higher performance database management system
Underestimated development time
Purchase of software components
11.4.4 Risk monitoring
The purpose of risk monitoring risk is to constantly assess each of the identified risks to decide whether its probability and effects have changed. Usually this cannot be observed directly and other factors should be monitored to detect the changes. Table 11.4. gives some examples of factors that may be helpful in assessing different types of risks.
Table 11.4. Risk factors.
Risk type Potential indicators
Technology One of the hardware supplier companies becomes bankrupt People Software engineer, who gets a flu in every year complains about
weakness
Organizational Poor managerial activity is seen
Tools Using a CASE tool the first error occurs
Requirements Customer complains about the performance of current version of software
Estimation The status of the approved project schedule is very poor
11.5 Exercises
1. What are the main differences between a software engineering and an industrial manufacturing project?
2. List the main activities of a software project manager!
3. List the parts of a project plan!
4. Explain the project scheduling process!
5. Explain the steps of risk management!
6. What are the objectives for risk analysis?
7. What strategies can be applied in risk planning?
12 Software quality management
The quality of software has improved significantly over the past two decades. One reason for this is that companies have used new technologies in their software development process such as object-oriented development, CASE tools, etc. In addition, a growing importance of software quality management and the adoption of quality management techniques from manufacturing can be observed. However, software quality significantly differs from the concept of quality generally used in manufacturing mainly for the next reasons [1]:
1. The software specification should reflect the characteristics of the product that the customer wants. However, the development organization may also have requirements such as maintainability that are not included in the specification.
2. Certain software quality attributes such as maintainability, usability, reliability cannot be exactly specified and measured.
3. At the early stages of software process it is very difficult to define a complete software specification. Therefore, although software may conform to its specification, users don’t meet their quality expectations.
Software quality management is split into three main activities:
1. Quality assurance. The development of a framework of organizational procedures and standards that lead to high quality software.
2. Quality planning. The selection of appropriate procedures and standards from this framework and adapt for a specific software project.
3. Quality control. Definition of processes ensuring that software development follows the quality procedures and standards.
Quality management provides an independent check on the software and software development process. It ensures that project deliverables are consistent with organizational standards and goals.