Software Quality

Note: Much of this is based upon writings of Bertrand Meyer.

In assessing a product such as an automobile, we judge it according to whether or not (or to what degree) it possesses certain properties that are deemed to be important. Among the properties in which most people are interested are reliability, safety, fuel efficiency, ease of handling, smoothness of ride, passenger space, storage space, etc. Of course, people differ in which properties they value and how much they value them. Also, different vehicles are intended to be used for different purposes. As a result, each kind of automobile is designed to possess certain desirable qualities at the expense of lacking others. For example, an SUV has more storage space than a typical sedan but less fuel efficiency.

Similarly, we assess a software "artifact" according to the degree to which it possesses those properties deemed to be important in the realm of software. What are some of these properties? They include the following:

• Correctness: the property of conforming to specifications (i.e., behaving as intended in all foreseen situations).

  It is worth noting that specifications for large software systems are hard to develop and can themselves be "wrong". Also, correctness spans several layers, in that an executing program can behave "incorrectly" due to an error that exists elsewhere, such as in hardware, the operating system, or the compiler that translated the program's source code into machine language.

  How do we determine whether software is correct? In general, this is not possible. However, software testing (executing software on various sets of input) is a useful way to detect incorrectness. Proving correctness mathematically (using concepts such as that of loop invariant) is theoretically possible, but so far it has not been accepted as practical, except in certain cases where errors could have disastrous consequences.
  
  

• Robustness: the property of reacting "gracefully" (as opposed to "crashing") when abnormal conditions (i.e., ones not covered by the specifications) arise. (E.g., an invalid input is entered, a method is called when its precondition is not satisfied.)
  
  
• Efficiency: the property of placing (close to) as few demands as possible upon system resources (time/space)
  
  
• Ease of use: E.g., beginners can learn it without excessive frustration; experienced users are not hindered.
  
  
• Extendibility/maintainability: the property of being easy to change. Maintenance activities can be classified according to the reason for making changes:
  • corrective: to correct errors
  • adaptive: to adapt the software to changes in specification (e.g., added features)
  • perfective: to improve its quality in some way (e.g., make more efficient by taking advantage of a newly-discovered algorithm)
  
  
  
• Reusability: the property of being useful as a software component in many different applications/software systems. (E.g. ADT's such as stacks, queues, and lists are widely used)
  
  
• Compatability: the property of being usable in conjunction with other software (e.g., MS Excel spreadsheets can be "imported" into MS Word documents).
  
  
• Portability: The property of being able to be installed on various hardware/software "platforms" without excessive difficulty. One of the keys here is to isolate platform-dependent code in as few places as possible.

Correctness and robustness together yield reliability. Extendability and reusability together yield modularity.

Note that the relative importance of these qualities differs according to the intended purpose of the software. For example, robustness is of extreme importance in "safety-critical" software (such as that controlling a nuclear reactor or a space shuttle in flight), but not so important in a computer game.