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).
Part (a) — a general definition of quality, and how it relates to software. In general terms, quality is the degree to which a product, service or system conforms to its specified requirements and meets the needs of the customer who pays for it. Pressman sharpens this into three levels a software product must satisfy simultaneously: (1) conformance to explicitly stated functional and performance requirements, (2) conformance to explicitly documented development standards (coding standards, review procedures, naming conventions), and (3) conformance to implicit characteristics that are expected of professionally developed software even though nobody wrote them down (ease of use, maintainability, reasonable performance). Software quality is harder to judge than the quality of a physical product because software is intangible — there is nothing to inspect visually — so an organization must build measurement and review activities into the process itself (rather than final inspection alone) to confirm all three levels of conformance are actually being met.
Fig. Q1(b) — failure rate vs. time. Hardware follows the classic reliability "bathtub": a decreasing infant-mortality region, a flat useful-life region, then a rising wear-out region as parts physically degrade. Software has no wear-out phase at all, because code does not physically degrade with use — with no upgrades, its curve decays through infant mortality (latent design/coding defects being found and fixed) and then stays flat indefinitely. With upgrades, each new release re-introduces a burst of latent defects (new/changed code), so the curve re-spikes at every release boundary (dashed vertical lines) before decaying again — and if regression discipline is weak, the post-release floor drifts upward release over release.
Part (c) — software metrics and measures, and the role of measurement. A measure provides a quantitative indication of the extent, amount, dimension or capacity of some attribute of a product or process — e.g., the number of errors found in a code review, or the number of lines of code written. A metric is a quantitative measure of the degree to which a system, component or process possesses a given attribute, typically derived by relating one or more measures to each other (e.g., defects per KLOC relates a defect-count measure to a size measure). Software measurement's role in development is to turn otherwise-subjective judgments ("the design looks complex," "testing seems to be going well") into objective, trackable numbers that support: (1) planning and estimation (size/effort measures feed cost and schedule models), (2) early problem identification (a rising complexity or defect-density metric flags a module before it fails in the field), (3) process control (comparing measured outcomes against targets lets management adjust resources mid-project rather than only post-mortem), and (4) process improvement (historical metrics baselines show whether changes to the process actually reduced defects or effort on later projects).
