SOFTWARE QUALITY is conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. (Pressman) THE DEFINITION HAS THREE PARTS, and each failure mode is distinct: · fails the STATED REQUIREMENTS → a functional defect · fails the DOCUMENTED STANDARDS → a process failure; the code works but is unmaintainable · fails the IMPLICIT EXPECTATIONS → the most dangerous, because nobody wrote them down. Ease of use, maintainability, not corrupting data on a crash. THE QUALITY DILEMMA: if you produce a software system with terrible quality you lose because no-one will buy it. If you spend infinite time and effort achieving perfect quality you lose because it will never ship. Somewhere between is a "good enough" level, and identifying it is a judgement, not a formula. SQA is an UMBRELLA ACTIVITY applied throughout the software process. It encompasses: · a quality management approach · effective software engineering technology (methods and tools) · formal technical reviews applied throughout the process · a multi-tiered testing strategy · control of software documentation and the changes made to it · a procedure to ensure compliance with software development standards · measurement and reporting mechanisms QUALITY CONTROL vs QUALITY ASSURANCE — the distinction examiners ask for: QUALITY CONTROL the series of inspections, reviews and tests used throughout the process to ensure each work product meets its requirements. Includes a FEEDBACK LOOP to the process that created the work product. → PRODUCT-oriented, DETECTS defects QUALITY ASSURANCE consists of the auditing and reporting functions of management. Provides management with the data necessary to be informed about product quality. → PROCESS-oriented, PREVENTS defects COST OF QUALITY — the standard breakdown, and the argument for prevention: PREVENTION COSTS quality planning, formal technical reviews, test equipment, training APPRAISAL COSTS in-process and inter-process inspection, equipment calibration and maintenance, testing FAILURE COSTS INTERNAL FAILURE rework, repair, failure mode analysis — found before shipping EXTERNAL FAILURE complaint resolution, product return and replacement, help-line support, warranty work — found by the customer THE ARITHMETIC OF PREVENTION: recall the Boehm ratios — a defect found in review costs ~1 unit and after release ~100. So spending 10 units on prevention to avoid one released defect is a 10× return, and prevention is where the money belongs.

SQA GROUP ACTIVITIES (Pressman's list): 1. PREPARES AN SQA PLAN for the project, identifying evaluations, audits and reviews, standards applicable, error reporting procedures, and the documents produced. 2. PARTICIPATES IN THE DEVELOPMENT of the project's software process description, reviewing it for compliance with organisational policy and standards. 3. REVIEWS ENGINEERING ACTIVITIES to verify compliance with the defined process. 4. AUDITS DESIGNATED WORK PRODUCTS to verify compliance with those defined as part of the process. 5. ENSURES DEVIATIONS are documented and handled according to a documented procedure. 6. RECORDS ANY NON-COMPLIANCE and reports to senior management. SQA is deliberately given a reporting line INDEPENDENT of the project manager, because otherwise schedule pressure would always win over quality reporting. WORKED — the economics of a review programme, computed. A 40 KLOC project. Historical data: defects introduced ≈ 20 per KLOC → 800 defects review finds ≈ 60% of defects present cost to fix in review ≈ 1.5 person-hours cost to fix in system test≈ 9 person-hours cost to fix after release ≈ 45 person-hours review effort ≈ 3 person-hours per KLOC WITHOUT REVIEWS — assume testing catches 80% of the 800: found in test = 640 × 9 = 5,760 person-hours escaped to field = 160 × 45 = 7,200 person-hours review cost = 0 TOTAL = 12,960 person-hours WITH REVIEWS: review effort = 40 × 3 = 120 person-hours found in review = 800 × 0.60 = 480 defects 480 × 1.5 = 720 person-hours remaining = 320 defects found in test = 320 × 0.8 = 256 → 256 × 9 = 2,304 person-hours escaped = 64 × 45 = 2,880 person-hours TOTAL = 6,024 person-hours SAVING = 12,960 − 6,024 = 6,936 person-hours, a 53.5% reduction, for an investment of 120 hours of review effort. RETURN ON THE REVIEW INVESTMENT = 6,936 / 120 = 57.8× AND NOTE WHERE THE SAVING COMES FROM: escaped defects fell from 160 to 64, so the biggest single component is field failures avoided — the most expensive category. That is the quantitative case for reviews, and it is why they are the first SQA activity any organisation should adopt.

SOFTWARE STANDARDS are important because they: · encapsulate best practice, avoiding repetition of past mistakes · provide a framework for defining what quality means in a particular setting — a definition of "done" · assist CONTINUITY when work is passed between people, and reduce the learning effort for new staff PRODUCT STANDARDS apply to the software product being developed. Examples: a document standard such as the structure of a requirements document; a documentation standard such as a comment header for a class definition; a coding standard defining how a programming language is to be used. PROCESS STANDARDS define the processes to be followed during development. Examples: definitions of specification, design and validation processes; a description of the documents to be written at each stage; how a review is to be conducted. THE PROBLEM WITH STANDARDS, stated honestly: software engineers often regard standards as bureaucratic and irrelevant, particularly when they are not updated. To avoid this: · INVOLVE PRACTITIONERS in developing product standards — they must understand the rationale · REVIEW AND MODIFY standards regularly to reflect changing technologies · PROVIDE TOOL SUPPORT — a standard enforced by a linter or a formatter costs nothing to follow; a standard enforced by a document nobody reads costs arguments in every review QUALITY PLANS — a project-specific plan setting out the desired product qualities and how they are assessed, selecting those organisational standards that are appropriate. Its structure: product introduction · product plans · process descriptions · quality goals · risks and risk management A quality plan should be SHORT. If it is not read, it has no effect.