12.5 Maintainability

We will need to change a piece of software for one of two reasons. First, our needs may have changed. We will need to implement new features or operations for the users. Alternatively, the operating milieu of the software has changed. New or different hardware may be added to the environment in which the software is running. In this case, the set of user operations will not change but the set of functionalities will change in response to this new operating environment.

The second reason that we will have to change a system is that we have observed it failing. We will know that the system has failed in that it has departed in some measure from its specifications. In the simplest case we could simply insist that the software system merely meet the nonfunctional requirement that it not cease to operate for any reason. That is, if it suffers from a catastrophic collapse (the blue screen of death), then we will know that the system has failed.

The vast majority of software systems currently in operation or under development do not really have a set of specifications that control their development. They have been or are being lovingly crafted by small groups of people who do not really communicate with each other. This makes the failure determination problem significantly more difficult. If we do not have a precise set of software specifications for a given system, then any behavior of the system other than outright failure is really acceptable behavior. This is so in that a software failure of a program will be recognized at the point of its departure from its specified behavior. Absent a set of specifications, any behavior of this system is as good as any other. It might, for example, trash the system password file whenever it is run. If we have not specified exactly what the system should be doing, then trashing the password file is probably as acceptable as any other behavior.