Software Quality Attributes


Software Quality Attributes

Article Purpose

The purpose of this article is to define the term software quality attributes and to place that term in the context of SQA and software process improvement, SPI.

To consider the function of software quality attributes (also known as software quality factors) lets revisit the overall goal of any quality management, namely Fujitsu’s slogan Quality built-in with cost and performance as prime consideration.
Given the intangible and abstract nature of software, researchers and practitioners have been looking for ways to characterize software in order to make the benefits and costs more visible (for measurement). This quest continues today but there have been two notable models of software quality attributes:-

  • McCall (1977)
  • Boehm (1978)

    There are others (see FURPS) but these two illustrate the general purpose and issues of these quality factor models.
    These two quality models are summarized below and similarities can be seen.
    To begin with there are some common objectives of these models, namely:-

  • The benefits and costs of software are represented in their totality with no overlap between the attributes.
  • The presence, or absence, of these attributes can be measured objectively.
  • The degree to which each of these attributes is present reflects the overall quality of the software product.
  • These attribute facilitate continuous improvement, allowing cause and effect analysis which maps to these attributes, or measure of the attribute.

    Both the measurement (software metrics) of these attributes and the use of the software metrics in software process improvement, SPI, are discussed in other articles.





    • McCall's Quality Model - 1977


    Jim McCall produced this model for the US Air Force and the intention was to bridge the gap between users and developers. He tried to map the user view with the developer's priority.

    McCall identified three main perspectives for characterizing the quality attributes of a software product.

    These perspectives are:-

  • Product revision (ability to change).
  • Product transition (adaptability to new environments).
  • Product operations (basic operational characteristics).

    Product revision
    The product revision perspective identifies quality factors that influence the ability to change the software product, these factors are:-
  • Maintainability, the ability to find and fix a defect.
  • Flexibility, the ability to make changes required as dictated by the business.
  • Testability, the ability to Validate the software requirements.

    Product transition
    The product transition perspective identifies quality factors that influence the ability to adapt the software to new environments:-
  • Portability, the ability to transfer the software from one environment to another.
  • Reusability, the ease of using existing software components in a different context.
  • Interoperability, the extent, or ease, to which software components work together.

    Product operations
    The product operations perspective identifies quality factors that influence the extent to which the software fulfils its specification:-
  • Correctness, the functionality matches the specification.
  • Reliability, the extent to which the system fails.
  • Efficiency, system resource (including cpu, disk, memory, network) usage.
  • Integrity, protection from unauthorized access.
  • Usability, ease of use.

    In total McCall identified the 11 quality factors broken down by the 3 perspectives, as listed above.
    For each quality factor McCall defined one or more quality criteria (a way of measurement), in this way an overall quality assessment could be made of a given software product by evaluating the criteria for each factor.
    For example the Maintainability quality factor would have criteria of simplicity, conciseness and modularity.



    • Boehm's Quality Model - 1978



    Barry W. Boehm also defined a hierarchical model of software quality characteristics, in trying to qualitatively define software quality as a set of attributes and metrics (measurements).

    At the highest level of his model, Boehm defined three primary uses (or basic software requirements), these three primary uses are:-

  • As-is utility, the extent to which the as-is software can be used (i.e. ease of use, reliability and efficiency).
  • Maintainability, ease of identifying what needs to be changed as well as ease of modification and retesting.
  • Portability, ease of changing software to accommodate a new environment.

    These three primary uses had quality factors associated with them , representing the next level of Boehm's hierarchical model.

    Boehm identified seven quality factors, namely:-

  • Portability, the extent to which the software will work under different computer configurations (i.e. operating systems, databases etc.).
  • Reliability, the extent to which the software performs as required, i.e. the absence of defects.
  • Efficiency, optimum use of system resources during correct execution.
  • Usability, ease of use.
  • Testability, ease of validation, that the software meets the requirements.
  • Understandability, the extent to which the software is easily comprehended with regard to purpose and structure.
  • Flexibility, the ease of changing the software to meet revised requirements.

    These quality factors are further broken down into Primitive constructs that can be measured, for example Testability is broken down into:- accessibility, communicativeness, structure and self descriptiveness. As with McCall's Quality Model, the intention is to be able to measure the lowest level of the model.

    • Summary of the two models


    Although only a summary of the two example software factor models has been given, some comparisons and observations can be made that generalize the overall quest to characterize software.

    Both of McCall and Boehm models follow a similar structure, with a similar purpose. They both attempt to breakdown the software artifact into constructs that can be measured. Some quality factors are repeated, for example: usability, portability, efficiency and reliability.

    The presence of more or less factors is not, however, indicative of a better or worse model.

    The value of these, and other models, is purely a pragmatic one and not in the semantics or structural differences.
    The extent to which one model allows for an accurate measurement (cost and benefit) of the software will determine its value.

    It is unlikely that one model will emerge as best and there is always likely to be other models proposed, this reflects the intangible nature of software and the essential difficulties that this brings. The ISO 9126 represents the ISO's recent attempt to define a set of useful quality characteristics.

  • McCall (1977)
  • Boehm (1978)
    A more in depth discussion of these two models can be found here

    • No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-