Quality management in software engineering covers quality planning, quality assurance, quality control, and continuous improvement, and published sources name ISO 9000, ISO 9001, and CMMI as the standards most often cited.
The exact-match query "quality management in software engineering" is the subject of this page, and the term appears in the heading below and throughout the body. The four working parts are not a sequence of gates but a set of overlapping activities that attach to different points in the software development lifecycle. Quality planning decides what "good" means before work starts. Quality assurance builds the process that makes defects less likely. Quality control inspects the output and finds what slipped through. Continuous improvement feeds what was learned back into the plan.
Quality Management In Software Engineering: The Working Parts
Published treatments of quality management in software engineering converge on four components. Wikipedia's software quality management article organises its quality management activities under quality assurance, quality planning, and quality control, and treats improvement as an ongoing thread. Zymr's guide lists the same four as core components: quality assurance, quality planning, quality control, and continuous improvement. The four-part split is the closest thing to a consensus structure across the analysed pages.
- Quality planning — defines the quality attributes the product must carry, the standards the team will follow, and the checks that will be run. It happens before and during requirements work.
- Quality assurance — builds process, review, and definition-of-done discipline so that defects are prevented rather than discovered. It runs across the whole lifecycle.
- Quality control — tests, inspects, and measures the actual product against the plan. It runs on built artefacts.
- Continuous improvement — takes defect data, review findings, and incident records and changes the plan and the process. It runs after each cycle and never really stops.
The order matters less than the coverage. A team that plans quality attributes but never inspects output has a plan and no evidence. A team that tests heavily but never changes its process keeps rediscovering the same class of defect.
Quality Assurance, Quality Planning, and Quality Control
These three terms are frequently used interchangeably in casual conversation and are not interchangeable. The table below separates them by purpose and by when the work happens, using only the categories that appear across the analysed sources.
| Activity | Purpose | Timing |
|---|---|---|
| Quality planning | Define the quality attributes, standards, and checks the product must satisfy | Before and during requirements and design |
| Quality assurance | Build process, review, and definition-of-done discipline that prevents defects | Across the whole software development lifecycle |
| Quality control | Test and inspect built artefacts against the plan and record what fails | On completed or partially completed work |
Quality assurance is process-facing and quality control is product-facing. That distinction is the one most often blurred. A code review is assurance when its purpose is to change how the team writes code, and control when its purpose is to catch a specific defect in a specific change. The same meeting can serve both, which is why the labels drift.
Quality planning is the part teams skip most often, because it produces no visible artefact until something goes wrong. Its output is a decision. which quality attributes matter for this product, and which do not. A payments feature and a marketing microsite do not need the same attributes, and treating them as if they do wastes effort in one place and under-invests in the other.
Where continuous improvement fits
Continuous improvement is the loop that connects control back to planning. Defect records, review findings, and production incidents are the inputs. The output is a change to the plan, the process, or the checks. Without that loop, quality management becomes a fixed set of rituals that stops matching the product.
Standards and Frameworks Named Across Published Sources
The analysed pages name a consistent set of standards and frameworks. ISO 9000 and ISO 9001 appear across multiple sources, including the Wikipedia article, the CCSU software engineering class notes, and the cmrtpoint unit on quality management. CMMI appears in the Wikipedia article and in the IEEE Computer Society's software quality resource. ISO/IEC 9126 and ISO 25010 appear as software product quality models. PRINCE2, PMBOK, RUP, MSF, COBIT, and ITIL appear in the Wikipedia article as linked IT and project methods rather than as quality standards in their own right.
Two cautions apply to this list. First, naming a standard is not the same as holding it. Second, the analysed sources describe what these standards cover in general terms; none of them establishes which standard a particular team is required to follow. That determination depends on the client, the sector, and the contract, and no supplied source settles it for Malaysian software teams.
Process standards and product standards
The CCSU class notes draw a useful line between product standards and process standards. Product standards describe what the finished software must be. Process standards describe how the team works. ISO 9001 is a process standard. ISO 25010 is a product quality model. A team can adopt one without the other, and the choice changes what evidence the team can produce at the end.
How Quality Work Maps to the Software Lifecycle
Quality activities attach to lifecycle stages rather than sitting in a separate phase at the end. The mapping below follows the stages named across the analysed sources.
- Requirements — quality planning defines the attributes; reviews check that requirements are testable and complete.
- Design — assurance activities such as design review and inspection check the structure before code exists.
- Implementation — assurance continues through code review and pair programming; static analysis tools run against the code.
- Testing — control activities verify the built product against the plan; defects are recorded, not just fixed.
- Release and operation — control continues through production monitoring and incident review; improvement feeds findings back into planning.
The Wikipedia article notes that software quality work links to IT methods such as PRINCE2, PMBOK, RUP, MSF, CMMI, COBIT, and ITIL, and to agile testing practice. The practical effect is that quality activities are distributed across whatever delivery method the team already uses, rather than bolted on as a separate stage.
Agile delivery changes the rhythm rather than the content. The CCSU notes describe quality management in agile development as relying on practices such as pair programming and continuous review, with the same planning, assurance, control, and improvement functions present but compressed into shorter cycles.
Measurements Teams Track and What They Miss
Metrics are where quality management most often goes wrong, because a metric that is easy to collect is not always the metric that matters. The analysed sources name several measurement families without agreeing on thresholds.
Defect-related measures appear across the sources: defect counts, defect density by module, defect leakage rate, and the split between user-reported and internally found defects. Test-related measures include test coverage and code coverage, which the Zymr guide explicitly distinguishes. Time-related measures include mean time to detect and mean time to repair. Process measures include review and inspection findings, and the IEEE Computer Society resource discusses software quality measurement and process improvement as connected activities.
What the sources do not supply is a verified benchmark. No supplied source establishes a target defect rate, a target coverage percentage, or a cost figure for poor quality. Any specific number presented as a standard would be unsupported. The honest position is that these measures are useful for tracking direction within one team over time, and unreliable for comparing one team against another.
The measurement trap
Coverage is the clearest example. A team can raise coverage without reducing defects, because coverage measures which lines ran, not whether the assertions were meaningful. The Zymr guide flags the test coverage versus code coverage distinction for exactly this reason. The same caution applies to defect counts: a falling count can mean fewer defects or a quieter reporting channel.
What Published Sources Do Not Settle
The analysed pages are consistent on structure and silent on specifics. Several questions a Malaysian software team would reasonably ask are not answered by any supplied source.
No supplied source verifies defect-rate, cost, or productivity figures for quality management in software engineering. No supplied source verifies Malaysian regulatory requirements, certification costs, or audit timelines for software quality management. No supplied source verifies tool pricing, licence terms, or vendor performance claims for quality management platforms. No supplied source verifies which standards a Malaysian software team is legally required to hold. No supplied source verifies current adoption rates of quality management practices among Malaysian software firms.
That gap is worth naming rather than papering over. A team evaluating a quality approach should ask for the specific evidence behind any claim about cost savings, defect reduction, or compliance obligation, and should treat a general reference to ISO 9001 or CMMI as a starting point for its own verification rather than as an answer.
What to ask before committing
Three questions separate a real quality approach from a set of rituals. Which quality attributes does this product actually need, and which has the team decided to trade away? What evidence will exist at the end that the process worked, beyond a passing test suite? And who owns the improvement loop when a defect class keeps recurring?
A team that can answer those three questions has the working parts in place. A team that cannot has a plan, or a test suite, or a standard, but not quality management in software engineering.