Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
04-Soft-A6, Software Quality Assurance — National Exams, May 2018 (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).
Prepare the project's SQA plan. The plan (IEEE 730-style) is developed during project planning and reviewed by all affected groups; it identifies evaluations to be performed, audits and reviews to be carried out, standards to be applied, and the procedures for reporting and tracking noncompliance.
Participate in developing the project's software process description. The SQA group reviews the team's chosen process to ensure it complies with organizational policy, internal standards and any externally imposed standards (e.g., an EGBC/regulatory audit standard), catching process gaps before development work starts against a non-compliant process.
Review software engineering activities to verify compliance. SQA identifies deviations from the defined process (e.g., a design review skipped, a coding standard ignored) as work proceeds, rather than waiting to discover the consequence later in testing.
Audit designated software work products to verify compliance. SQA audits selected products (e.g., a requirements document, a test plan) against the standards that apply to them and reports the results of each audit to management.
Ensure deviations are documented and handled per a documented procedure. Any deviation in process or product is recorded, tracked to closure, and escalated if unresolved — deviations are managed, not silently absorbed.
(Any three of the above — or an equivalent list drawn from the project's own SQA plan — satisfy the question; the common thread is that SQA activities are oversight and verification activities layered onto the engineering work, not the engineering work itself.)
Part (b) — the SQA lifecycle mapped onto the SDLC. SQA is an umbrella activity: it does not occupy its own separate phase at the end of development, but runs in parallel with every phase of the software development lifecycle, applying a different set of activities appropriate to that phase's work product.
SDLC phase
SQA activities performed during that phase
Requirements
Requirements reviews/walkthroughs checking the SRS for completeness, consistency and verifiability; confirm acceptance criteria are testable before design starts.
Design
Design reviews checking traceability of the design back to requirements, adherence to architectural/design standards, and early risk/complexity assessment.
Coding/implementation
Code reviews/inspections and static analysis checking conformance to coding standards; unit-test oversight (are unit tests actually being written and passed).
Testing
Test-plan and test-case reviews confirming requirements traceability and coverage; audits of test records and defect logs; verification that exit criteria are actually met before release.
Delivery/maintenance
Software configuration management audits (baselines, change control), post-release defect and field-failure tracking feeding back into process improvement.
Because each phase produces a different work product (SRS, design document, code, test results), the specific SQA technique changes phase to phase, but the underlying purpose — verifying that phase's output against its inputs and against documented standards — is constant across the whole lifecycle.
