ELEC5618 · Software Quality Engineering
Software Quality Planning, Assurance and Control
Week 3 of University of Sydney ELEC5618 Software Quality Engineering separates the three quality activities — quality planning, quality assurance (QA) and quality control (QC) — and lays out the structure of a Software Quality Plan per IEEE 730-2014, with the ISO/IEC 25010 product-quality model and the SPICE / CMM / CMMI standards landscape as resources. The QA-versus-QC distinction is one of the unit's most-examined ideas, and this is a Week-3 milestone-check week.
What this chapter covers
- 01Software quality management (SQM): quality planning, quality assurance, quality control as three sub-processes, aiming at a 'quality culture'
- 02QA = process-oriented (build quality in, evaluate processes, free of technical/managerial pressure) vs QC = product-oriented (check results conform, leads to V&V/testing)
- 03IEEE 730-2014: requirements for initiating, planning, controlling and executing SQA processes; purpose = justified confidence the product meets its requirements
- 04Structure of a Software Quality Plan: goals, organisation/roles, tasks with entry/exit criteria, defect-source analysis, prevention/detection methods, resources
- 05ISO/IEC 25010 product-quality characteristics with sub-characteristics (reliability, security, maintainability, etc.)
- 06Defect handling: prevention (remove root causes early) → reduction (inspections + testing) → containment (fault tolerance, N-version programming)
- 07Defect resolution: logging (how/where/conditions) and tracking (what changed, whether effective)
- 08Standards landscape: SPICE (ISO/IEC 15504), CMM/CMMI as process-capability resources
Classifying five activities as QA or QC
- +1(a) Defining a code-review checklist/standard is QA — it establishes and improves the process teams will follow, before any specific product is checked.
- +1(b) Running the test suite against build 42 and logging failures is QC — it checks a specific product result for conformance and leads into V&V/testing.
- +1(c) Auditing whether the team followed its documented review process is QA — it evaluates the process itself, independent of any one deliverable.
- +1(d) Inspecting the SRS against IEEE 830 characteristics is QC — it examines a specific work product (the SRS) for conformance. (Note: inspection is a QC-style check that can sit inside the broader QA system.)
- +1(e) Measuring test coverage on the delivered module is QC — it monitors a concrete product metric against a standard.
Key terms
- Quality planning
- The SQM sub-process that identifies which standards and regulations apply to a project and how to satisfy them, selecting or adapting the procedures the team will use.
- Quality Assurance (QA)
- Process-oriented quality work: periodically evaluate overall project performance to ensure it will meet the relevant standards; define and evaluate processes, ideally free from technical, managerial and financial pressure. QA builds quality in.
- Quality Control (QC)
- Product-oriented quality work: systematically monitor specific results for compliance with standards, supporting functional and non-functional requirements. QC leads into verification, validation and testing; its activities can sit inside QA.
- IEEE 730-2014
- The standard for SQA processes. It defines requirements for initiating, planning, controlling and executing SQA, harmonised with the software lifecycle, with the purpose of producing a justified statement of confidence that a product meets its established requirements.
- Defect handling (prevention / reduction / containment)
- Three complementary strategies: prevention removes error sources early (shared architecture view, training, formal methods); reduction detects and removes faults via inspections and testing; containment bounds a failure's effect after it occurs (fail-safe defaults, N-version programming).
- Software Quality Plan
- The document (per IEEE 730) laying out quality goals, the organisation and roles, the quality tasks with entry/exit criteria tied to milestones, defect-source analysis, prevention/detection methods and the resources committed to quality on a project.
Software Quality Planning, Assurance and Control FAQ
What is the difference between QA and QC in ELEC5618?
QA is process-oriented — it defines, evaluates and improves the way the team works so that quality is built in, and it should be free from schedule and budget pressure. QC is product-oriented — it checks specific deliverables and results against standards, and it leads into verification, validation and testing. A neat way to remember it: QA builds quality in, QC checks quality out, and QC activities can operate inside a QA system.
What does IEEE 730 actually require?
IEEE 730-2014 sets requirements for initiating, planning, controlling and executing the SQA processes of a development or maintenance project, harmonised with the software lifecycle. Its purpose is to produce a justified statement of confidence that the product meets its established requirements. It applies to both embedded and standalone software and does not dictate how you implement each activity.
What are the three ways of handling defects?
Prevention (remove the sources of error early — shared architecture, agreed vocabulary, training, formal methods), reduction (detect and remove faults that exist, through inspections and testing), and containment (accept that some failures happen and bound their effect, e.g. fail-safe defaults or N-version programming). They map roughly onto early phases, coding/testing, and release/operation.
Can AI help me with quality planning?
Yes. Sia can sort activities into QA vs QC with reasons, walk you through the sections of a Software Quality Plan, and quiz you on IEEE 730 and the defect-handling strategies. Use it to rehearse the distinctions; it does not do graded work, and the University of Sydney academic-integrity policy applies.
Exam move
The single highest-value skill here is sorting activities into QA (process) versus QC (product) instantly and justifying each in one line — practise on mixed lists until it is automatic, because it appears in both multiple-choice and short-answer form. Memorise the sections of a Software Quality Plan (goals, organisation/roles, tasks with entry/exit criteria, defect-source analysis, prevention/detection, resources) and be able to state IEEE 730's purpose in a sentence. Learn the defect-handling trio (prevention → reduction → containment) with one example each, and keep a compact reference of the ISO/IEC 25010 characteristics for requirements questions. Because Week 3 is a milestone-check week, keep your group-project quality plan current — that also banks the weekly report-check marks. Confirm the exam format on Canvas.
Working through Software Quality Planning, Assurance and Control in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Software Quality Planning, Assurance and Control question and get a clear, step-by-step explanation grounded in how ELEC5618 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
