Software Quality Models

Software quality models provide structured frameworks for understanding what "quality" means in the context of software systems. Quality is not a single attribute—a system can be reliable but unusable, efficient but unmaintainable, or secure but inflexible. Quality models decompose this complex concept into measurable dimensions, helping teams set meaningful quality targets, assess current quality levels, and make informed tradeoff decisions. Without such models, "build a high-quality system" is a meaningless requirement because everyone interprets quality differently.

McCall's Quality Model (1977)

Jim McCall developed one of the earliest software quality models, organizing quality into three perspectives with eleven factors:

Product Operations (using it):

• Correctness: Does the software do what it is supposed to do? Does it meet its specifications and satisfy user objectives?
• Reliability: Does it perform consistently without failure? Can users depend on it to function correctly under stated conditions?
• Efficiency: Does it use computing resources (memory, CPU, network) economically? Does it provide adequate response times?
• Integrity: Can it resist unauthorized access or modification? Does it protect data and code from tampering?
• Usability: Can users learn and operate the software easily? Is the effort required to use it proportional to its benefit?

Product Revision (changing it):

• Maintainability: How easy is it to locate and fix defects? Can developers understand the code well enough to modify it safely?
• Flexibility: How easy is it to modify the software to accommodate new requirements or changed environments?
• Testability: How easy is it to verify that the software works correctly? Can tests be designed and executed efficiently?

Product Transition (moving it):

• Portability: How easy is it to move the software to a different platform or environment?
• Reusability: Can components of the software be used in other systems or contexts?
• Interoperability: How easily does it interface with other systems?

McCall's model also defines metrics for each factor—specific measurements that quantify each quality attribute. For example, correctness might be measured by defect density, reliability by mean time between failures, and maintainability by mean time to repair.

Boehm's Quality Model (1978)

Barry Boehm proposed an alternative hierarchy that adds the perspective of different stakeholders:

High-Level Characteristics:

• As-is utility: How well does the system serve users today? (Reliability, efficiency, human engineering)
• Maintainability: How easy is it to modify the system? (Testability, understandability, modifiability)
• Portability: How easy is it to change the system's environment? (Device independence, self-containedness)

Boehm's contribution was recognizing that quality characteristics form a hierarchy—higher-level concerns (like utility) are composed of lower-level measurable properties. He also introduced the concept of quality being relative to stakeholder perspective: users care about utility, maintainers care about modifiability, and managers care about cost-effectiveness.

ISO/IEC 9126 Quality Model

The ISO 9126 standard (later superseded by ISO 25010) defined six quality characteristics:

Functionality: The capability of software to provide functions that meet stated and implied needs. Sub-characteristics include suitability, accuracy, interoperability, security, and compliance.

Reliability: The capability to maintain a specified level of performance under stated conditions. Sub-characteristics include maturity (frequency of failure), fault tolerance (ability to maintain performance despite faults), and recoverability (ability to restore after failure).

Usability: The effort needed for use and the individual assessment of such use. Sub-characteristics include understandability, learnability, operability, and attractiveness.

Efficiency: The relationship between performance level and resources used. Sub-characteristics include time behavior (response and processing times) and resource utilization (amounts of resources used).

Maintainability: The effort needed to make modifications. Sub-characteristics include analyzability (ease of diagnosing deficiencies), changeability (ease of implementing changes), stability (risk of unintended effects), and testability (ease of validating changes).

Portability: The ability to transfer from one environment to another. Sub-characteristics include adaptability, installability, co-existence, and replaceability.

ISO/IEC 25010 (SQuaRE) - Current Standard

The successor to ISO 9126, ISO 25010 defines eight quality characteristics:

1. Functional Suitability - completeness, correctness, appropriateness
2. Performance Efficiency - time behavior, resource utilization, capacity
3. Compatibility - co-existence, interoperability
4. Usability - recognizability, learnability, operability, error protection, aesthetics, accessibility
5. Reliability - maturity, availability, fault tolerance, recoverability
6. Security - confidentiality, integrity, non-repudiation, accountability, authenticity
7. Maintainability - modularity, reusability, analyzability, modifiability, testability
8. Portability - adaptability, installability, replaceability

Real-World Application: Evaluating CRM Software

A company evaluating CRM (Customer Relationship Management) software uses ISO 25010 characteristics to structure their assessment:

Weighted scores reveal which vendor best matches the organization's quality priorities. Different organizations would assign different weights—a hospital might weight security and reliability highest, while a startup might prioritize usability and performance.

Quality Tradeoffs

Quality models reveal that maximizing all quality attributes simultaneously is impossible. Design decisions that improve one attribute often degrade others:

• Security vs. Usability: Strong security (complex passwords, multi-factor authentication) makes systems harder to use
• Performance vs. Maintainability: Highly optimized code is often harder to understand and modify
• Flexibility vs. Simplicity: Systems designed to accommodate every possible future requirement become complex and difficult to use for common cases
• Reliability vs. Cost: Achieving 99.999% availability costs vastly more than 99.9%

Quality models help teams make these tradeoffs explicitly—documenting which attributes are most important for their specific context and accepting conscious compromises on less critical attributes.

Practical Value of Quality Models

Quality models provide shared vocabulary for discussing quality (everyone agrees on what "maintainability" means), structured requirements for quality attributes (not just "make it good" but specific targets for specific dimensions), evaluation criteria for comparing alternatives, and improvement guidance (measuring where you fall short on which dimensions directs improvement efforts). They transform quality from a vague aspiration into an engineering discipline with concrete goals and measurable outcomes.