Software quality is the degree to which a software product, service, or development process satisfies stated requirements, user expectations, applicable standards, and relevant stakeholder needs. It is not limited to the absence of defects. A system may contain few coding errors but still be poor quality if it is difficult to use, insecure, slow, unreliable, or unsuitable for its intended purpose.
Quality management in software projects combines three related activities:
Quality planning: deciding which quality objectives, standards, methods, measures, and responsibilities will apply.
Quality assurance: establishing and evaluating processes so that work is performed in a controlled and effective way.
Quality control: examining work products and results to identify nonconformities and determine whether requirements have been met.
A central idea of modern quality management is prevention. Testing is necessary, but testing alone cannot create quality. Quality is improved when defects and failures are prevented through clear requirements, sound architecture, competent development practices, reviews, automation, configuration control, and learning from evidence.
This chapter introduces major quality theories, the cost of quality, continuous improvement, the PDCA cycle, ISO 9001, ISO/IEC 25010, ISO/IEC/IEEE 12207, and maturity models. These topics provide a foundation for planning and controlling quality in software projects.
Learning Objectives
By the end of this chapter, you should be able to:
Explain prevention-based quality and distinguish quality assurance from quality control.
Classify and calculate the main components of the cost of quality.
Describe the contributions and limitations of major quality thinkers.
Apply the PDCA cycle to a software quality problem.
Explain the purpose of ISO 9001, ISO/IEC 25010, and ISO/IEC/IEEE 12207.
Interpret the basic idea of maturity models and their use in improvement planning.
Select suitable quality practices for an introductory software project.
1. What Quality Means in Software
Quality has both conformance and fitness-for-use dimensions. Conformance asks whether the product meets specified requirements. Fitness for use asks whether it actually solves the user’s problem in its operating context. For example, an application may conform to a written response-time requirement but still be unsuitable if users cannot understand its workflow.
Important quality stakeholders include customers, end users, developers, testers, operations staff, regulators, security specialists, business owners, and maintainers. Their expectations can conflict. A highly secure authentication process may reduce convenience; rapid delivery may increase technical debt; extensive logging may improve diagnosability while increasing storage costs. Quality management therefore involves explicit decisions and trade-offs rather than pursuing an abstract idea of “maximum quality.”
Quality attributes and requirements
A functional requirement states what the system must do. A quality requirement or non-functional requirement states a characteristic or constraint under which the system must operate. Examples include:
“The system shall allow a customer to reset a password.”
“Ninety-five percent of password-reset requests shall complete within two seconds under the specified load.”
“Only authorized support staff shall view customer identity data.”
Quality requirements should be measurable where possible. Terms such as “fast,” “secure,” and “easy to use” are useful starting points but are too vague for effective verification unless operationalized through criteria, scenarios, thresholds, or acceptance tests.
2. Prevention-Based Quality
The traditional detection approach attempts to find defects after they have been introduced. The prevention approach asks why defects arise and changes the process or conditions that produce them. Prevention does not eliminate testing; it reduces the number, severity, and recurrence of failures that testing must discover.
Typical prevention practices include:
eliciting and reviewing requirements before implementation;
using coding standards, secure design principles, and architecture reviews;
applying peer review and pair programming;
using automated unit, integration, security, and regression tests;
maintaining reproducible build and deployment pipelines;
training staff in tools, domain knowledge, and quality practices;
performing root-cause analysis on significant defects;
controlling versions, environments, and changes.
A useful distinction is between an error, a defect, and a failure. An error is a human action or decision that is incorrect. A defect is a flaw introduced into a work product. A failure is an observed inability of the system to perform a required function. One requirements interpretation error may create several defects, and one defect may cause failures only under particular conditions.
Quality assurance and quality control
Quality assurance is process-oriented and preventive. It examines whether appropriate methods are defined and followed. Quality control is product-oriented and detective or corrective. It examines whether a deliverable meets specified criteria. For example, an audit of whether code reviews are consistently performed is assurance; executing tests against a completed build is control. In practice, the two activities interact and should not be treated as isolated departments.
3. Quality Theories and Their Relevance
W. Edwards Deming
Deming emphasized systems thinking, variation reduction, leadership responsibility, and continual improvement. His Plan–Do–Check–Act cycle became a widely used improvement structure. Deming argued that most quality problems arise from the system and management decisions rather than from individual carelessness alone. In software, this suggests examining unstable requirements, inadequate environments, unrealistic schedules, and poor communication instead of simply blaming developers for defects.
Joseph Juran
Juran described quality management through the quality trilogy: quality planning, quality control, and quality improvement. Planning identifies customers and their needs; control compares actual performance with targets; improvement addresses chronic causes and raises performance. This model is valuable because it treats quality as a management responsibility throughout the product life cycle.
Philip Crosby
Crosby promoted “conformance to requirements” and the idea that quality should be built into work rather than inspected into a product. His phrase “zero defects” is best understood as a management aspiration to prevent accepted defects, not as a claim that every complex software system can be mathematically guaranteed defect-free. Crosby also emphasized the cost of nonconformance and the importance of doing work correctly the first time.
Kaoru Ishikawa
Ishikawa contributed the cause-and-effect diagram, often called the fishbone diagram, and promoted quality circles and organization-wide involvement. A software team may classify causes of escaped defects under requirements, people, methods, tools, environment, and management. The diagram helps organize investigation, but it does not prove that a listed cause is responsible; evidence is still required.
Walter Shewhart and variation
Shewhart distinguished common-cause variation, inherent in a process, from special-cause variation, arising from unusual events. This distinction is important when interpreting metrics. A single rise in defects may result from a special cause such as a failed test environment. Persistent variation may indicate a process that requires redesign. Teams should avoid reacting to every fluctuation without first understanding the data-generating process.
Integrating the theories
These thinkers differ in emphasis but share several principles: quality is a leadership and system responsibility; prevention is preferable to late correction; decisions should use evidence; and improvement should be continuous. Their ideas are not recipes that guarantee success. Applying them mechanically can create excessive bureaucracy, especially when teams collect measures without using them to make decisions.
4. Cost of Quality
The cost of quality (CoQ) is the investment and loss associated with achieving or failing to achieve required quality. It is commonly divided into four categories:
Support, refunds, outage recovery, legal or reputational loss
The cost of conformance is prevention plus appraisal. The cost of nonconformance is internal failure plus external failure. The total cost of quality can therefore be expressed as:
CoQ = Cₚ + Cₐ + Cᵢf + Cₑf
where Cₚ is prevention cost, Cₐ is appraisal cost, Cᵢf is internal failure cost, and Cₑf is external failure cost. All terms must use the same currency and accounting period. The categories are managerial classifications, so an organization should define consistently where activities such as automation engineering are recorded.
Worked example
A project records the following quarterly amounts:
prevention: $8,000;
appraisal: $12,000;
internal failure: $15,000;
external failure: $25,000.
Therefore:
CoQ = 8,000 + 12,000 + 15,000 + 25,000 = $60,000
Cost of conformance is $20,000, and cost of nonconformance is $40,000. If an additional $5,000 spent on automated regression testing reduces external failures by $15,000, the immediate net reduction in total quality-related cost is $10,000, assuming no other costs change. This simple analysis does not prove causation, and longer-term effects such as maintenance savings should also be considered.
A common mistake is to treat all testing as waste. Appraisal costs can be economically rational when they prevent much larger failures. The management question is not “How can testing be eliminated?” but “What combination of prevention, appraisal, and correction gives acceptable risk at sustainable cost?”
5. Continuous Improvement and the PDCA Cycle
Continuous improvement is the disciplined, repeated effort to improve products, services, and processes. It can involve incremental changes, such as reducing build time, or substantial changes, such as replacing a manual release process with continuous delivery.
The PDCA cycle contains four connected activities:
Plan: define the problem, establish a measurable objective, identify causes, select an intervention, and determine how evidence will be collected.
Do: implement the change, preferably on a controlled or limited basis.
Check: compare results with the baseline and objective; examine unintended effects.
Act: standardize the successful change, adapt it, or abandon it and begin another cycle.
PDCA continuous improvement cycle
Figure: PDCA continuous improvement cycle
Figure: The PDCA cycle used to structure iterative quality improvement.
For example, if failed builds are delaying integration, a team may plan to identify the most frequent causes, do by introducing automated dependency checks, check build-failure and recovery data, and act by standardizing the checks if results improve. Metrics should be interpreted with context. A reduction in reported defects may indicate better quality, weaker testing, or reduced reporting; the team must investigate rather than assume.
6. ISO 9001: Quality Management Systems
ISO 9001 specifies requirements for a quality management system (QMS). It is generic rather than software-specific. Its emphasis includes customer focus, leadership, engagement of people, process approach, improvement, evidence-based decision-making, and relationship management. Organizations may use it to establish controlled processes, responsibilities, documented information, objectives, audits, corrective action, and management review.
ISO 9001 does not prescribe a particular programming language, development method, testing tool, or organizational structure. Certification, where pursued, indicates that an organization’s management system has been assessed against the standard’s requirements; it does not certify that every software product is defect-free.
In a software project, an ISO 9001-aligned QMS might define:
how requirements and changes are approved;
how project risks and quality objectives are recorded;
how versions and releases are controlled;
how nonconformities and corrective actions are handled;
how supplier and subcontractor performance is evaluated;
how internal audits and management reviews are performed.
Documentation should support control and learning. Excessive documents that nobody uses can become process theatre. The appropriate level of formality depends on risk, contractual obligations, regulatory context, team size, and product criticality.
7. ISO/IEC 25010: Product Quality
ISO/IEC 25010 provides a quality model for software products and systems. Its product-quality characteristics are commonly described as:
Characteristic
Introductory interpretation
Functional suitability
Provides appropriate and accurate functions
Performance efficiency
Uses time and resources effectively
Compatibility
Coexists and interoperates with other systems
Usability
Enables users to learn, operate, and achieve goals
Reliability
Performs consistently under stated conditions
Security
Protects confidentiality, integrity, authenticity, and accountability
Maintainability
Can be modified, analyzed, tested, and evolved efficiently
Portability
Can be transferred or adapted across environments
The model is a classification framework, not a score that automatically determines quality. A project must translate characteristics into context-specific quality requirements and measures. For example, “reliability” might be represented by availability targets, recovery objectives, or failure-rate observations. “Maintainability” might be explored through change lead time, complexity indicators, testability, and review findings, although no single metric fully measures it.
Quality characteristics can conflict. Encryption may add computational overhead; portability may limit use of platform-specific capabilities; highly flexible configuration may increase usability complexity. Stakeholders should prioritize characteristics based on mission, risk, and lifecycle cost.
ISO/IEC/IEEE 12207 provides a framework for software life-cycle processes. It describes processes and activities that can be adapted across acquisition, development, operation, maintenance, and disposal contexts. It is not a mandatory project schedule and does not require one development methodology.
A project may use its process concepts to clarify:
stakeholder needs and requirements definition;
system and software requirements analysis;
architecture and design;
implementation and integration;
verification and validation;
transition, operation, maintenance, and disposal;
configuration management, quality assurance, decision management, and risk management.
The standard helps organizations establish a common vocabulary and identify omitted activities. For example, a small agile team can still address requirements, architecture, verification, configuration management, and maintenance; it may perform them iteratively rather than in sequential phases. Tailoring is essential. Applying every process with identical formality to every project can consume resources without reducing meaningful risk.
9. Maturity Models
A maturity model describes progressively more capable or consistent organizational practices. A commonly recognized structure is:
Initial: work is unpredictable and largely dependent on individual effort.
Managed: projects use basic planning, tracking, and control.
Defined: organization-wide processes and guidance are established.
Quantitatively managed: performance is measured and controlled using data.
Optimizing: systematic innovation and continuous improvement are institutionalized.
This staged description resembles the logic of models such as CMMI, although actual models have specific terminology, appraisal rules, and scope. Maturity is not the same as product quality, technical excellence, or business success. A mature organization can produce a poor product if it manages the wrong requirements; an immature team may occasionally succeed through exceptional individual effort but remain unable to reproduce that success reliably.
Maturity assessments should be used for improvement, not punishment. A practical assessment asks: What practices exist? Are they consistently used? Is evidence available? Do they produce useful outcomes? What is the next feasible improvement? Small organizations should avoid treating a maturity level as a badge and should focus on capability appropriate to their risks.
10. Applying the Models Together
The standards address different perspectives:
Framework
Primary perspective
Main use
ISO 9001
Organization and management system
Establish controlled, auditable quality processes
ISO/IEC 25010
Product and system quality
Define and evaluate quality characteristics
ISO/IEC/IEEE 12207
Life-cycle processes
Organize activities across the software life cycle
Maturity models
Organizational capability
Assess consistency and guide improvement
They can be combined. A project may use 12207 concepts to map life-cycle activities, ISO 9001 practices to control and improve those processes, ISO/IEC 25010 to define product quality requirements, and a maturity model to assess whether the organization can perform these practices consistently. None replaces professional judgment, stakeholder engagement, testing, or risk management.
11. Illustrative Case: Improving Quality in a Student-Service Portal
Background. A university releases a student-service portal for registration and fee payments. During the first release, users report duplicate submissions, slow pages during peak registration, and confusing error messages.
Problem. The project team focuses on fixing reported defects after release. Requirements contain broad statements such as “the system must be fast and user-friendly,” but no measurable acceptance criteria. The test environment is smaller than production, and release decisions are based mainly on schedule pressure.
Analysis. A cause-and-effect review identifies several contributing conditions: incomplete performance requirements, insufficient load testing, inconsistent error-handling design, lack of idempotency for payment requests, and no formal release-quality checklist. The team classifies the problems using ISO/IEC 25010: performance efficiency, usability, reliability, and functional suitability are all affected. The absence of defined review and release processes also indicates weaknesses in quality assurance and process management.
Approach. The team applies PDCA. During planning, it establishes measurable targets, including a response-time threshold under a defined workload and a requirement that repeated payment requests not create duplicate transactions. During doing, it introduces design review, automated API tests, representative load tests, and a release checklist. During checking, it compares baseline and post-change failure data and conducts usability sessions. During acting, successful practices are added to the team’s standard workflow, while unresolved risks are assigned owners.
The team also records prevention, appraisal, internal failure, and external failure costs. Although automated tests increase short-term appraisal and engineering effort, the expected reduction in payment incidents and support calls makes the intervention economically justified.
Outcome. The next release has fewer duplicate transactions, clearer error messages, and improved peak-period performance. The team does not claim that the portal is perfect. Instead, it has established measurable quality objectives, evidence-based release decisions, and a repeatable improvement process.
Learning points. Quality models help identify what matters; life-cycle processes help identify when and how work should occur; a QMS helps control and improve the way work is performed. The value comes from integrating the ideas into decisions, not from displaying standard names in project documentation.
12. Challenges, Ethics, and Governance
Quality decisions affect people. A defect in an entertainment application may be inconvenient, while a defect in healthcare, finance, transport, or public services may cause serious harm. Teams should consider safety, privacy, accessibility, security, fairness, and legal obligations when defining quality.
Important governance practices include traceability of significant requirements and decisions, segregation of duties where appropriate, protection of test data, controlled access to production systems, and honest reporting of known limitations. Metrics must not encourage harmful behavior. For example, rewarding developers solely for low defect counts may discourage reporting; rewarding testers solely for high defect counts may encourage low-value findings.
AI-assisted coding and testing can improve productivity, but it does not transfer accountability. Generated code may contain security flaws, licensing concerns, incorrect assumptions, or subtle defects. Teams should review, test, and govern AI-generated outputs as they would any other contribution. Confidential requirements and personal data should not be exposed to tools without appropriate authorization and controls.
13. Best Practices for an Introductory Project
A certificate-level project can implement meaningful quality management without a large bureaucracy:
Define measurable acceptance criteria for important functional and quality requirements.
Identify the most serious failure consequences and prioritize prevention accordingly.
Review requirements and design before substantial implementation.
Use version control, reproducible builds, and an agreed definition of done.
Automate repeatable tests, while retaining appropriate exploratory and usability testing.
Record defects with enough information to reproduce and analyze them.
Perform root-cause analysis on recurring or high-impact problems.
Track a small set of useful measures, such as escaped defects, build success, test completion, and response time.
Use PDCA to improve one process problem at a time.
Tailor standards and documentation to project risk rather than copying templates.
Chapter Summary
Software quality includes conformance to requirements and fitness for intended use. Prevention-based quality reduces the introduction and recurrence of defects through sound requirements, design, reviews, automation, training, and process learning. Quality assurance focuses primarily on confidence in processes, while quality control evaluates work products and results.
The cost of quality consists of prevention, appraisal, internal failure, and external failure costs. Investing in prevention and appropriate appraisal can reduce more expensive failures, but decisions should be based on evidence and context. Deming, Juran, Crosby, Ishikawa, and Shewhart provide complementary foundations involving systems thinking, quality planning and improvement, conformance, cause analysis, and variation management.
PDCA provides a practical structure for continuous improvement. ISO 9001 addresses the organizational quality management system; ISO/IEC 25010 provides a product-quality model; ISO/IEC/IEEE 12207 organizes software life-cycle processes; and maturity models describe increasing organizational capability. These frameworks are complementary, not substitutes for judgment. Effective quality management is proportionate to risk, ethically governed, and connected to real stakeholder outcomes.
Key Terms
Quality: Degree to which a product, service, or process satisfies requirements and stakeholder needs.
Quality assurance: Planned activities that provide confidence that processes are suitable and followed.
Quality control: Activities that examine products or results for conformance.
Prevention: Action taken to avoid introducing defects or failures.
Defect: A flaw in a work product that may cause incorrect behavior.
Failure: An observed inability of a system to perform as required.
Cost of quality: Costs associated with achieving or failing to achieve required quality.
Prevention cost: Cost of activities intended to avoid defects.
Appraisal cost: Cost of evaluating products or processes.
Internal failure cost: Cost of defects discovered before release.
External failure cost: Cost of defects discovered after release.
PDCA: Plan–Do–Check–Act cycle for structured improvement.
ISO 9001: Standard specifying requirements for a quality management system.
ISO/IEC 25010: Standardized model of software and system product-quality characteristics.
ISO/IEC/IEEE 12207: Standard framework for software life-cycle processes.
Maturity model: Framework describing progressive levels of organizational capability.
Traceability: Ability to relate requirements, work products, tests, and decisions.
Nonconformity: Failure to meet a specified requirement or criterion.
Continuous improvement: Repeated effort to improve products, services, or processes.
Review Questions
5 Short Answer Questions
What is the difference between quality assurance and quality control?
Why is prevention generally preferred to late defect detection?
Name the four categories in the cost of quality.
What is the purpose of ISO/IEC 25010?
What are the four stages of the PDCA cycle?
5 Long Answer Questions
Explain how Deming, Juran, Crosby, and Ishikawa contributed to modern software quality management.
Describe how a software organization could use ISO 9001 without requiring a particular development methodology.
Explain the eight product-quality characteristics introduced in ISO/IEC 25010 and give one software example for each.
Compare ISO 9001, ISO/IEC 25010, ISO/IEC/IEEE 12207, and maturity models.
A team has high external failure costs but low prevention spending. Use the cost-of-quality model to recommend an improvement strategy and identify possible risks in your recommendation.
Apply PDCA to a project in which failed builds frequently delay integration. Specify a baseline, an intervention, and evidence that should be checked.
A small healthcare application must protect patient data and remain available during busy periods. Select relevant ISO/IEC 25010 characteristics and explain how the team could translate them into measurable quality requirements.
Multiple Choice Questions with Answers
Question 1
Which activity is primarily prevention-oriented?
A. Reviewing production incident tickets
B. Conducting a requirements review before implementation
C. Refunding customers after an outage
D. Repairing a failed production build
Correct Answer: B. Conducting a requirements review before implementation
Question 2
Which formula correctly represents the cost of quality?
A test of a released application that checks whether it meets specified acceptance criteria is primarily an example of:
A. Quality control
B. Quality planning
C. Organizational maturity
D. Supplier management
Correct Answer: A. Quality control
Question 4
In the PDCA cycle, comparing post-change results with the baseline occurs during which stage?
A. Plan
B. Do
C. Check
D. Act
Correct Answer: C. Check
Question 5
Which standard primarily provides a product-quality model containing characteristics such as usability, reliability, and security?
A. ISO 9001
B. ISO/IEC 25010
C. ISO/IEC/IEEE 12207
D. A maturity appraisal guide
Correct Answer: B. ISO/IEC 25010
Question 6
What is the principal focus of ISO 9001?
A. A programming language standard
B. A quality management system
C. A software user-interface taxonomy only
D. A defect-counting formula
Correct Answer: B. A quality management system
Question 7
Which statement best describes ISO/IEC/IEEE 12207?
A. It defines a single mandatory agile method
B. It provides a framework for software life-cycle processes
C. It guarantees that software contains no defects
D. It replaces all project risk management
Correct Answer: B. It provides a framework for software life-cycle processes
Question 8
An organization whose processes are unpredictable and dependent on individual effort is typically at which introductory maturity level?
A. Initial
B. Defined
C. Quantitatively managed
D. Optimizing
Correct Answer: A. Initial
Question 9
A project spends $6,000 on prevention, $9,000 on appraisal, $10,000 on internal failures, and $15,000 on external failures. What is its total cost of quality?
A. $24,000
B. $30,000
C. $34,000
D. $40,000
Correct Answer: B. $30,000
Question 10
Which statement about software quality models is most accurate?
A. A model automatically proves that a product is high quality
B. A model removes the need for stakeholder priorities
C. A model helps classify and discuss quality but must be tailored to context
D. A model requires every quality characteristic to have equal priority
Correct Answer: C. A model helps classify and discuss quality but must be tailored to context
Software Quality & Risk Management
Chapter 2
of 14