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:
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.
Allow approximately 20 minutes.
OpenLearn - Approaches to software development Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.