Software is judged by its quality. But quality means different things to different people, causing no single measure of software quality to be acceptable for everyone. Defining quality in a measurable way eases a specific viewpoint to be understood by other people and relates specific notions to the notions of these people. Often, the aim in software development is to relate these quality notions to the business goals as effective as possible.
The importance of mapping quality characteristics of a particular software product onto metrics that can be used during development of this same product has been recognized widely. Many different quality models have been suggested in literature, which support the importance of this mapping. These models should make it possible to evaluate the (eventual) quality of the product to be developed. User quality characteristics are subdivided into sub-characteristics, where each of them is defined by several relevant metrics.
Many approaches have been proposed since the beginning of software engineering era. Early attempts dealing with structural programming languages were focusing on the quality of the constructed code, through metrics like lines of code, comments percentage, nested complexity, number of functions etc. in order to derive conclusions about the overall quality of the system. Later developments, introduced the Function Points methodology. Function Points proposed a more integrated approach on the software evaluation, by including stakeholders view and providing high assessment. But the lack of objective measurements on metrics held the wide adoption of this method.
The object oriented paradigm demanded new methods and metrics to cope with software quality. Again software quality was related to code quality with metrics like depth of inheritance, documented classes, coupling between objects etc. These metrics are accompanied with thresholds indicating the boundaries of good object oriented application. Indeed, due to strong dependency between applicable design Object Oriented techniques (i.e. UML) and the actual code, this approach found a wide acceptance in the O-O community. There are many freeware software assessment tools (like JDepent and SourceMonitor) able to perform code analysis and provide valuable results.
It became apparent that software quality is not solely depended on code quality, but on a plethora of associated factors as architecture quality, requirements completion, stakeholders’ evolvement just to name few. Thus a framework that could address software quality by taking into account most of the software engineering processes (requirements elicitation, design, coding, testing etc) and mapped these to quality characteristics as Usability, Performance, Maintainability, Efficiency, Reliability etc. was needed.
ISO/IEC 9126 Quality Model and ISO/IEC 14598 Software Product Evaluation, are international standards for software engineering product quality and came to rescue the situation.
ISO/IEC 14598 series of standards give methods for measurement, assessment and evaluation of software product quality. They describe neither methods for evaluating software production processes nor methods for cost prediction (software product quality measurements may, of course, be used for both these purposes). ISO/IEC 14598 series gives an overview of software product evaluation processes and provides guidance and requirements for evaluation. The scope and aim of these ISO/IEC 14598 series of is to provide guidance and requirements for the evaluation process in three different situations:
- Development (Enhancement) (ISO/IEC 14598-3)
- Acquisition (ISO/IEC 14598-4)
- Independent evaluation (including third-party evaluation) (ISO/IEC 14598-5)
The actual measurement and evaluation is performed by applying ISO/IEC 9126 Quality Model. It defines six characteristics which determine the quality in use for the actual user of the software.
These are general characteristics that cannot be measured directly. In order to fill up the gap between these characteristics and the possible measurements, each characteristic has been assigned several subcharacteristics which can be measured by internal and external metrics. The subcharacteristics serve to detail a viewpoint when analyzing software. The subcharacteristics cannot directly be measured.
Therefore, they are divided into attributes – software ‘facts’ or ‘things’ - that can be identified and measured to a certain degree of precision. For each sub-characteristic these attributes should be identified according to the purpose of the evaluation.
The quality model uses a specified framework for reasoning about approaches to quality. It argues that the actual quality in use depends on the external quality attributes. External quality is defined as the extend to which a product satisfies stated and implied needs when used under specified conditions; it is the quality when the software is executed. On their turn, these attributes depend on internal quality attributes. Here, internal quality is defined as the totality of attributes of a product that determine its ability to satisfy stated and implied needs when used under specified conditions; it is the totality of characteristics of the software product from an internal view.
The other way around, improving internal quality improves external quality, which again improves quality in use. The quality model seems to be a good reference tool for defining the quality of a software product. But there are some limitations worth mentioning. For instance, the proposed framework does not seem to provide an answer when a product is way above expectations for one characteristic and falls short on another quality characteristic. Another pitfall is the lack of a rationale for which factors should be included in the specific quality definition of a certain software product, and the lack of a rationale for the division of characteristics and sub-characteristics. Therefore, the selection of quality characteristics and sub-characteristics can seem subjective.
Back to top
GAZETTE 
