IntroductionIntroductionSight is a faculty; seeing, an art.
— George Perkins Marsh
In this book we set as our goal to learn how to judge the quality of software code. Having mastered this art, we'll then be able to apply our new-found sense to the code we write ourselves and to the code written by others, aiming to assess its quality aspects and improve what we find lacking. We can also use our acquired knowledge of code quality when we discuss implementation alternatives with our colleagues, hopefully nudging our project toward the most appropriate direction.
We can view software quality from the point of its specifications, and define it as the degree to which it meets the specified requirements, or we can also take people into account, and define quality as the degree to which the software meets the customer or user needs or expectations. No matter how we look at quality, it is important. Quality, time, and cost are the three central factors determining the success or failure of any software project, and quality is the only one of those factors that can not be changed on the spot by management fiat. In addition, the effects of poor software quality can be dramatic and difficult to undo: if our space probe's software miscalculates a variable and crashes onto a planet, we are back to square one (minus the probe).
[...]
Figure 1.2: Book map: elements of software quality
A good way to treat an elusive concept, such as the quality of software, is to decompose it into finer-grained attributes, and decompose them again, until we get tired of the process, or, preferably, we reach a level at which we can base our discussion on meaningful examples that share common characteristics. The ISO/IEC 9126 standard, which defines the quality model we will use in our discussion, categorizes internal and external software quality characteristics into six major areas: functionality, reliability, usability, efficiency, maintainability, and portability. You can see these elements decomposed in Figure 1.2; all six major elements include a compliance sub-characteristic, which refers to the extend to which the software adheres to the corresponding standards, conventions, style guides, and regulations. (Remember, the classification comes from an international standard, so you'd expect it to reference other standards.)
The functionality of software is the quality characteristic associated primarily with what the software does, rather than how it does it. The elements of the software's functionality are: the suitability of the functions for the specified tasks and the user's objectives, the accuracy of its results or operation, the interoperability of the software with other systems, and the security the software affords to its data. The suitability and interoperability characteristics are difficult to discern from code; we discuss security in Chapter 3, go through many elements of accuracy in Chapter 8, where we examine floating point arithmetic.
The reliability of software refers to its capability to maintain its specified level of performance under the specified conditions. The three elements of reliability mirror the prevention, mitigation, and recovery concepts we use for dealing with crises and natural disasters. Maturity refers to the absence of faults in the software, while fault tolerance is associated with the capacity of the software to continue functioning despite some faults, and recoverability deals with functions in the software that allow it to get back the data and continue operation after a failure. We deal with all three aspects in Chapter 2.
The usability of the software is primarily an external quality characteristic. Three of its elements roughly correspond to a typical timeline of software use: understandability, how easily we can understand whether the software is suitable for our needs, and how to use it to accomplish a particular task; learnability, the effort required to learn it, and operability, the effort required to use it. In addition, attractiveness deals with the feeling the software leaves on us. Although usability is a very important quality element, it is quite difficult to determine it by examining the software's code. One could for example look for the use of appropriate APIs to select a file, a color, or a font, but in the end, usability is judged by the interaction of the user with the software. For this reason we will not examine it any more in this book.
Software efficiency deals with the ying and yang elements of computation: space and time. These two primal opposing but complementary concepts are what make practical computation possible. Disable all your computer's caches (gaining space), and your machine will grind to a halt (loosing time). Distribute your SETI calculation over the internet (occupying more space), and your processing will fly (gaining time). In true ying/yang style, in some rare cases it is even possible to for a program to gain in both directions: squeeze a tight loop's instructions to fit a cache, and the smaller code will also run faster. Trying to separate the two concepts, we talk about the software's time behavior, which deals with response, processing times, and throughput rates, and resource utilization, which refers to the material resources (memory, CPUs, network connections) used by the software. We examine the performance of software in time in Chapter 4, and its performance in space in Chapter 5.
The maintainability of software is probably the element that can best be approached at the level of the software's design and actual code. When talking about the software's maintainability we are interested about analyzability, how easy it is for us to locate the elements we want to improve or fix; changeability, how much work we need to do to implement a modification; stability, how few things break after our changes; and testability, our ability to validate our modifications. We deal with all these elements, and more, in Chapter 7.
Finally, portability refers to how easy it is to take the software from one environment (for example Windows) and transfer it to another (for example Mac OS X). Our main goal here is adaptability, the capability of the software's code to function in different environments, and this is the focus of Chapter 6. Other sub-characteristics of portability are mainly operational in nature: installability deals with the software's installation in different environments, co-existence examines how well the software plays in a crowded playground, and replaceability denotes the extend to which a software can be used as a drop-in replacement for another.
[...]
Book homepage | Author homepage
Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.