Unsuccessful software systems
Unfortunately, successful software systems rarely make the news. Example 6 illustrates the kind of failure that does break through into the public domain (in this case, the failure became a series of headline stories).
Example 6
In 1992, the London ambulance service commissioned a computer-aided dispatch (CAD) system for getting ambulances and their crews to reported incidents. It was intended to replace an existing paper-based system. There were two notable failures of the new system in November 1992 that resulted in severe delays in ambulances reaching certain incidents.
The final report on the system failures (South West Thames Regional Health Authority, 1993) identified a number of major management problems with the project. A technical audit revealed that the CAD system was incomplete and not fully tested. Its ability to deal with heavy loads had not been tested and nor had a backup service been tested. There were also outstanding problems with the accuracy of the information needed to initiate each dispatch (South West Thames Regional Health Authority, 1993).
The London ambulance service had a software system that was lacking in usefulness, usability, reliability and availability.
This discussion of software problems has probably given you a rather pessimistic view of software development. You must not forget that many software systems work, and work well, given the fact that they are used in every aspect of modern life. However, the rate at which the role of software is evolving is so fast that there must be practices involved in developing software that can cope effectively with this expansion.
Activity 4 Maintainability
- a.Suggest a means of measuring the maintainability of a software system.
- b.What can we learn from legacy systems about developing a good software system?
- c.Suggest a reason why legacy systems will always be a problem.
Answer
- a.We could measure the effort required by a developer to locate and implement a given change to a software system. That effort can be classified in two components – the effort needed to locate and fix errors (bugs), and the effort needed to adapt the software system to meet its users’ needs.
- b.A legacy system may have started out with all the characteristics of a good software system, yet those characteristics may have changed over time, resulting in a less flexible and maintainable product. As change is inevitable, the right processes should be in place to make change happen in a more controlled way. This requires the adoption of standards and documentation conventions that help decision making on changes and how to introduce them. Any changes need to be well documented so that software is still understandable and less dependent on the people initially involved with developing and maintaining the software.
- c.The inherent malleability of software makes it easy to change. You have already seen that a legacy system is lacking in flexibility as a result of the number of changes made to it during its operational lifetime. (The analogy with metalworking through malleability is useful. Once a blacksmith forms some component, usually in iron, there is a limit to the number of times that it can be heated, formed and cooled before that component becomes brittle and hence liable to failure.)
This explains why our ability to bolt features and fixes onto a legacy system means that it will eventually become too fragile, and it will become precarious to go any further. The staff issues mentioned in (b) compound these problems.