Software Quality – Lecture 1 Comprehensive Notes

Definition of Software

  • IEEE (Institute of Electrical and Electronics Engineers)
    • “Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.”
  • ISO (International Organization for Standardization)
    • Includes four inseparable elements:
    • Computer program (the actual “code”)
    • Procedures
    • Documentation
    • Data necessary for operating the software system
  • Key take-away: Standards bodies emphasize not only code but everything required to make that code usable and maintainable.

Definition of Software Quality (SQ)

  • Crosby (1979): “Conformance to requirements.”
  • Juran (1988): “Product features meet the needs of customers’ and product’s satisfaction.”
  • General technical view: Accuracy & completeness of software specifications — the product must be free from deficiencies.
  • IEEE: “The degree to which a system, component, or process meets specified requirements and customer or user needs and expectations.”
  • Practical implication: Quality exists at the intersection of written requirements and real-world user expectations; if either is missed, quality suffers.

Software Quality Assurance (SQA)

  • IEEE definition
    • “A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.”
    • “A set of activities designed to evaluate the process by which the products are developed or manufactured.”
  • Core idea: SQA is process-oriented (not only product-oriented) and must be planned; it is woven through every stage of the development lifecycle.
  • Process integration: All SQA actions are embedded into each development stage — from requirements through maintenance.

Objectives of SQA Activities

  1. Functional / Technical Conformance
    • Provide acceptable confidence that the delivered software meets all functional requirements.
  2. Managerial Conformance
    • Provide acceptable confidence that schedules and budgets are honored.
  3. Continuous Improvement
    • Initiate & manage activities that improve both software development efficiency and the SQA process itself.

Quality Assurance (QA) vs. Quality Control (QC)

  • Definition & Focus
    • QA: Set of activities focused on the processes used to build a product — proactive & preventive.
    • QC: Set of activities focused on the product itself — reactive & detective/corrective.
  • Goal
    • QA: Ensure that defects never arise.
    • QC: Find & eliminate defects that slipped through.
  • Method (“How”)
    • QA: Establish, document, and audit the quality management system (e.g., process standards, templates, SPC).
    • QC: Execute inspections, testing, and validations on finished work products (e.g., SQC, system testing).
  • Responsibility
    • QA: Everyone involved in developing the product (holistic responsibility).
    • QC: A designated testing/inspection team.
  • Typical Examples
    • QA → Verification, process audits, Statistical Process Control (SPC).
    • QC → Validation / software testing, Statistical Quality Control (SQC).
  • Managerial vs. Corrective Tools
    • QA is managerial (design the shield); QC is corrective (detect punctures in the shield).

Errors, Faults, and Failures

  • Error
    • A human action that produces an incorrect result (e.g., coding a multiplication instead of an addition).
    • Can be syntactic, logical, computational, or definitional.
  • Fault
    • A manifestation of an error in the software; may remain dormant if the faulty code path is never executed.
  • Failure
    • The external behavior of the software deviates from requirements because a fault is activated.
    • Error→Fault→Failure\text{Error} \rightarrow \text{Fault} \rightarrow \text{Failure} (activation chain)
  • Key distinction: Not every error leads to a fault, and not every fault leads to a user-visible failure.

Classification of Causes of Software Errors ("Nine Causes")

  1. Faulty Requirements Definition
    • Wrong, incomplete, unclear, missing, or unnecessary requirements inflate cost & complexity.
  2. Client-Developer Communication Failures
    • Misinterpretations of written, graphical, or oral requirements; “different planets” mind-set.
  3. Deliberate Deviations from Requirements
    • Re-used code with extraneous pieces, omitted features due to pressure, or unapproved “enhancements.”
  4. Logical Design Errors
    • Erroneous algorithms, wrong formulas, mis-specified boundary conditions, or missing system states.
  5. Coding Errors
    • Syntax, logic, or run-time errors; classic “bugs.”
  6. Non-Compliance with Documentation & Coding Instructions
    • Ignoring templates, naming conventions, or mandated manuals; impacts maintainability & integration.
  7. Shortcomings of the Testing Process
    • Incomplete test plans, poor coverage (path, branch, boundary), slow defect correction, inadequate reporting.
  8. User Interface & Procedure Errors
    • Poor learnability/usability, missing feedback, misleading error messages; to users, the UI is the system.
  9. Documentation Errors
    • Out-of-sync design docs, incorrect user manuals, obsolete feature lists, or faulty on-line help.

Visual Chain of Defect Propagation

  • Software Development Process
    • Error→Fault→Failure\text{Error} \rightarrow \text{Fault} \rightarrow \text{Failure}
    • Each transition often occurs in a different lifecycle phase (e.g., requirement error → coding fault → production failure).

Practical / Ethical Implications Mentioned

  • Skipping SQA steps (especially testing) leads to elevated risk and stakeholder distrust.
  • Omitting features or adding unapproved “enhancements” can be ethically dubious and invariably surfaces during system tests, causing schedule slippage and reputational harm.
  • Usability flaws propagate a negative perception “up the management chain,” even if the underlying logic is sound.
  • Standards (documentation, coding) are not bureaucratic overhead; they ensure maintainability, reuse, and correct integration in larger ecosystems.

Connections & Context

  • SQA is an integral subset of Software Engineering (SE); without rigorous SQA, SE cannot claim systematic, disciplined, and quantifiable practice.
  • Early life-cycle quality activities (requirements QA, design QA) are significantly cheaper than late defect removal, echoing Boehm’s cost-of-change curve.
  • Statistical methods (SPC for processes, SQC for products) come from manufacturing but map well onto software when metrics (defect density, escape rate) are defined.

Quick Self-Check / Study Prompts

  • Define each of the nine error causes and sketch a real project example.
  • Distinguish QA vs. QC in one sentence each; provide a real-world tool used for both.
  • Explain the error-fault-failure chain and why a dormant fault may never fail in production.
  • List the three formal objectives of SQA and link each to a corresponding lifecycle artifact (e.g., schedules → Gantt, functional conformance → requirement traceability matrix).