Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2016 (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) — why the SQA plan matters inside the project plan. The overall software project plan lays out schedule, resources, budget and risk for building the product; the SQA plan is the section (or companion document) that says HOW quality will actually be built in and checked, rather than assumed. Without it, quality activities (reviews, testing, standards enforcement, configuration control) have no owner, no schedule slot, and no budget line, so they are the first things dropped under deadline pressure. The SQA plan matters because it:
Makes quality activities visible and scheduled — reviews and test milestones appear on the project schedule as real tasks with owners and dates, not an afterthought.
Defines what "acceptable quality" means for this project — the standards, conventions and quality metrics that work products will be measured against.
Assigns responsibility — who conducts reviews, who signs off a baseline, who tracks defects — so quality is not everyone's job and therefore no one's.
Feeds risk management — the project plan's risk section can only account for quality-related risk (late defect discovery, unreliable releases) if the SQA plan states what checks exist and when they run.
Gives management a basis for tracking progress — SQA metrics (defect density, review effectiveness) let managers see whether the project is converging on a releasable product, not just whether tasks are being checked off.
Part (b) — software maintainability. Maintainability is the ease with which software can be understood, corrected, adapted to a changed environment, and enhanced with new capability after it has been delivered. ISO/IEC 25010 splits it into sub-characteristics — modularity, reusability, analysability, modifiability, and testability — because "easy to maintain" really means the code is easy to read, easy to isolate a change in, and easy to re-verify after the change. High maintainability keeps the dominant cost of most software (the maintenance phase, typically the majority of total lifecycle cost) under control.
Part (c) — software usability. Usability is the degree to which specified users can use the software to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use (ISO 9241 / ISO 25010). Practically it covers how easy the software is to learn, how efficiently an experienced user can operate it, how well it prevents and recovers from user error, and how satisfying the interaction feels — it is a quality characteristic aimed at the human operator rather than at the code's internal structure (contrast with maintainability in part (b), which is aimed at the maintainer).
