Dealing with risk

A software solution to a problem needs to be considered in the broad context of the domain to allow you to manage the risks associated with a development project. For example, if delays cause the team in Example 11 to miss the market ‘window’, it does not matter how much software has been developed, because it is no longer of benefit to the customer and users. Assessing risks and taking steps to reduce them are important activities in software development – this is known as risk management.

In a typical project, the major risks are around the requirements. Do you understand them? Have you got them all? Are they changing too frequently? Anything that you can do to increase your confidence that the requirements you have are both necessary and sufficient can reduce the risk of project failure. In general, for every decision you make there is a risk that your decision is wrong, or at least inappropriate, and you should consider identifying and reviewing major decisions. If the risks cannot be overcome, the project is unlikely to succeed.

An agile approach takes the view that requirements will change during development, and therefore they should be under continuous review. By involving customers throughout development it is easier to address changes in requirements and reduce the risk of making the wrong decision.

In any project there is likely to be a trade-off between what can be delivered in a given time to a specified budget and the functionality of the software system. Often the number of desirable features of a solution exceeds those that can be delivered for a given price and within a given timescale, so choices have to be made. One way to make such choices is to estimate the risk of not delivering each feature. That is, if a feature were not to appear in the final product, what effect would this have on such things as the usability, usefulness, reliability and flexibility of the product?

Figure 8 illustrates a simple spiral process that deals with risk explicitly and can be used in the development of a software system. (There are many interpretations and variations upon Barry Boehm’s original spiral (Boehm, 1986).) There are four steps that are repeated with each iteration of the spiral:

• determine the objectives, the alternatives and the constraints
• evaluate the objectives and identify and resolve the associated risks
• develop and verify a (partial) solution or product
• review that solution, and plan the activities for the next iteration.

Maximise

Figure 8 Spiral process to deal with risk

Show description|Hide description

This figure represents a spiral whose centre is the intersection of two lines, one horizontal and one vertical, which divide the figure in four parts. In the top left part there is a text with ‘determine the objectives, the alternatives and the constraints’. In the top right part, ‘evaluate the objectives and identify and resolve the associated risks’. In the bottom right part, ‘develop and verify a (partial) solution or product’; and in the bottom left part, ‘review that solution and plan the activities for the next iteration’. The spiral goes from the inner side of the ‘determine the objectives, the alternatives and the constraints’, and moves clockwise and outwards through evaluate …, develop and verify …, review and back to determine… It comprises several revolutions.

Figure 8 Spiral process to deal with risk

The spiral process starts when it is recognised that a particular organisational process can be improved or supported with the aid of a software system. The distance from the origin is intended to show how many resources have been used, the cumulative cost of a project.

There is no need for a complete solution to be produced by the end of the first iteration of the spiral. For example, the first iteration could focus on the question ‘Can we build an acceptable software system with the resources that can be brought to bear?’ After each iteration of the spiral, new risks come to light and plans are made for the next iteration in order to resolve those risks. With successive progressions, you should reach a point where your review indicates that you have an acceptable solution – a software system that meets the needs of its users.

Agile development follows, loosely speaking, a spiral approach and has mitigation of risks as an important concern. There are however some indicators that would distinguish an agile process from the generic spiral model. In agile development the short timeboxed iterations, for example, result in partially working systems, and an iteration would, typically, be no longer than 1 month.

Such a risk-driven model is also helpful when developing large software systems or systems where the developers have little experience of the problem domain. In both cases there is a high risk of failure. For example, if you have never built a real-time system, you need to gain some understanding of the scheduled execution of tasks.