 |
Quality Characteristics |
|
Quality Characteristics |
The definition given by the ISO/IEC 8402 standard is:
"The totality of features and characteristics of a product or a service that bear on its ability to satisfy stated or implied needs". Software quality can not be specified only as software without error. The software quality specification must be more accurate and detailed. The formalisation of the software quality can be done using a quality model.
In 1977, McCALL and his colleagues proposed a quality model to specify software quality. This model is based on three uses of a software product:
The McCall quality model: one of the first quality models widely recognized
The McCall quality model is organized around three types of Quality Characteristics:
Since then, various quality models have been defined, adopted and enhanced over the years for example those proposed by Boehm or Forse.
The need for one recognized standard quality model became more and more urgent. The ISO/IEC 9126 standard is the result of a consensus for a software quality model. As with McCall's this is also based on three levels:
Each characteristic is refined to a set of sub-characteristics and each sub-characteristic is evaluated by a set of metrics. Some metrics are common to several sub-characteristics.
Examples of selected characteristics for two software profiles
It is not easy to translate a user need (informal quality requirements) into a selection of quality characteristics (formal specification of the software quality as defined in ISO/IEC 9126). A European ESPRIT project, SPACE-UFO, has the objective to provide an enhanced user-oriented method for IT product quality requirements specification, which can be used as the "Quality Target" for both IT product evaluation processes and IT development processes.
There is not a single formal method or technique to specify the metrics. The standardization process is ongoing by the ISO project "Evaluation and Metrics". The specification of metrics is not an easy task. Two problems have to be resolved. The first is to choose the right metric from amongst the large amount of existing ones. The second is to implement the data collection. The efficiency of a metric, i.e. the relevance of the results to cost, is an important parameter in the choice.
The quantification of metrics reduces the subjectivity in the software evaluation, even if the analysis of results is still dependant on the skill and the experience of experts. The results of measurement are values on the scales of metrics (a range 1 to10, a binary response Yes/No, a rate...). For a measurement value, a rating level is required. The ISO/IEC 9126 proposes four rating levels: Excellent, Good, Fair and Poor. The first three are considered as satisfactory, the last is considered as unsatisfactory.
It can be useful to consult the metrics guides proposed by the ISO project "Evaluation and Metrics" or the IEEE standard 1061-1992.
To illustrate the relationship between the metrics and quality characteristics, we will present some metrics that could be used to evaluate the maintainability. The great advantage is the possible automation by market tools (Logiscope from Verilog, Hindsight from Integry Soft, Audit from Sema...).
The maintainability characteristic is divided in four sub-characteristics:
Halstead and McCabe have worked a lot on software measurement, and many of the metrics for code analysis comes from their studies. Measuring maintainability uses various code analysis metrics. These metrics are of various types to measure the software textual complexity, the data flow complexity, the control flow complexity, the architectural complexity and for specific programming languages the inheritance complexity.
The metrics used to evaluate the maintainability could be the following:
Analyzability:
Changeability:
Stability:
Testability:
The actual implementation of each metric depends on the programming language.
