Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2015 (3 hours, open book, 8 questions of equal value; the first FIVE as they appear in the answer book are marked — all eight are solved here as a study resource).
Part (a) — contents of the SQA plan. An SQA plan is the project-level document that tells everyone on the team, and every reviewer/auditor, how quality will be built into and checked on this specific project. Per Pressman/IEEE 730, it typically includes:
Purpose and scope — which products, processes and standards the plan covers.
Documentation — which work products (requirements, design, code, test plans) exist and are subject to SQA.
Standards, practices and conventions — coding standards, naming conventions, documentation formats to be followed and audited against.
Reviews and audits — the schedule and procedure for technical reviews, walkthroughs and management/formal audits.
Software configuration management (SCM) — how baselines, versions and change control are handled (links to Q6c).
Problem reporting and corrective action — how defects are logged, tracked and closed out (a defect-tracking procedure).
Tools, methods and metrics — the specific quality metrics that will be collected (defect density, review effectiveness, etc.) and the tools used to collect them.
Records, retention, training and risk management sections rounding out the plan.
Part (b) — software reliability. Software reliability is the probability that the software will perform its required function, without failure, for a specified period of time under specified operating conditions. Unlike hardware, software does not wear out; a reliability failure is always a manifestation of a design/coding defect being triggered by a particular input or execution path. Reliability is commonly measured as mean time between failures (MTBF), failure intensity (failures per unit time), or availability, and is estimated using models such as the Musa execution-time model applied to failure data collected during test.
Part (c) — software safety. Software safety is a software quality activity that focuses specifically on identifying and assessing potential hazards that may affect software negatively and cause an entire system to fail, particularly where the system controls a process with the potential for injury, death or major financial/environmental loss (e.g. medical devices, avionics, industrial control). Safety analysis (hazard analysis, fault-tree analysis) traces hazards back to their software cause and imposes constraints/requirements that eliminate or contain them; it is a stricter, narrower lens than general reliability, because a software element can be highly reliable (rarely fails) yet still unsafe (its rare failure mode is catastrophic).
