Even the most jaded software developers will agree that high-quality software is an important goal. But how do we define quality? In Chapte...
Even the most jaded software developers will agree that high-quality software is an important goal. But how do we define quality? In Chapter 8, we proposed a number of different ways to look at software quality and introduced a definition that stressed conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.
There is little question that the preceding definition could be modified or extended and debated endlessly. For the purposes of this book, the definition serves to emphasize three important points:
1. Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality.
2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result.
3. There is a set of implicit requirements that often goes unmentioned (e.g., the desire for ease of use). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.
Software quality is a complex mix of factors that will vary across different applications and the customers who request them.
McCall’s Quality Factors
The factors that affect software quality can be categorized in two broad groups:
(1) factors that can be directly measured (e.g., defects per function-point) and
(2) factors that can be measured only indirectly (e.g., usability or maintainability).
In each case measurement must occur. We must compare the software (documents, programs, data) to some datum and arrive at an indication of quality.
McCall, Richards, and Walters propose a useful categorization of factors that affect software quality. These software quality factors, shown in figure, focus on three important aspects of a software product: its operational characteristics, its ability to undergo change, and its adaptability to new environments.
Referring to the factors noted in figure, McCall and his colleagues provide the following descriptions:
Correctness. The extent to which a program satisfies its specification and fulfills the customer's mission objectives.
Reliability. The extent to which a program can be expected to perform its intended function with required precision.
Efficiency. The amount of computing resources and code required by a program to perform its function.
Integrity. Extent to which access to software or data by unauthorized persons can be controlled.
Usability. Effort required to learn, operate, prepare input, and interpret output of a program.
Maintainability. Effort required to locate and fix an error in a program.
Flexibility. Effort required to modify an operational program.
Testability. Effort required to test a program to ensure that it performs its intended function.
Portability. Effort required to transfer the program from one hardware and/or software system environment to another.
Reusability. Extent to which a program [or parts of a program] can be reused in other applications—related to the packaging and scope of the functions that the program performs.
Interoperability. Effort required to couple one system to another.
It is difficult, and in some cases impossible, to develop direct measures of these quality factors. Therefore, a set of metrics are defined and used to develop expressions for each of the factors according to the following relationship:
Fq = c1 x m1 + c2 x m2 + . . . + cn x mn
where Fq is a software quality factor, cn are regression coefficients, mn are the metrics that affect the quality factor. Unfortunately, many of the metrics defined by McCall et al. can be measured only subjectively. The metrics may be in the form of a checklist that is used to "grade" specific attributes of the software . The grading scheme proposed by McCall et al. is a 0 (low) to 10 (high) scale. The following metrics are used in the grading scheme:
Auditability. The ease with which conformance to standards can be checked.
Accuracy. The precision of computations and control.
Communication commonality. The degree to which standard interfaces, protocols, and bandwidth are used.
Completeness. The degree to which full implementation of required function has been achieved.
Conciseness. The compactness of the program in terms of lines of code.
Consistency. The use of uniform design and documentation techniques throughout the software development project.
Data commonality. The use of standard data structures and types throughout the program.
Error tolerance. The damage that occurs when the program encounters an error.
Execution efficiency. The run-time performance of a program.
Expandability. The degree to which architectural, data, or procedural design can be extended.
Generality. The breadth of potential application of program components.
Hardware independence. The degree to which the software is decoupled from the hardware on which it operates.
Instrumentation. The degree to which the program monitors its own operation and identifies errors that do occur.
Modularity. The functional independence of program components.
Operability. The ease of operation of a program.
Security. The availability of mechanisms that control or protect programs and data.
Self-documentation. The degree to which the source code provides meaningful documentation.
Simplicity. The degree to which a program can be understood without difficulty.
Software system independence. The degree to which the program is independent of nonstandard programming language features, operating system characteristics, and other environmental constraints.
Traceability. The ability to trace a design representation or actual program component back to requirements.
Training. The degree to which the software assists in enabling new users to apply the system.
