Chapter 1: The Elements of a Complete Software Quality System

Starting a software quality program from scratch is time consuming and a task often doomed to failure before it is begun. Inadequate preparation, misused terms, lack of planning, and failure to recognize the roles of all individuals in the organization are only a few of the pitfalls waiting for the overanxious practitioner.

As stated in the Introduction, this is a what-to book. It is intended to serve as an introduction to the concepts involved in software quality systems and to suggest how the system's parts may be implemented. This chapter introduces some software quality terms, the basic elements of the software quality system, and a few important additional concerns. The balance of the book elaborates on each of the elements and concerns and discusses implementation of the overall software quality system.

1.1 Definitions

This text uses several terms that are granted many meanings throughout the computing and, in particular, the software industry. In this text, certain of these variably defined terms are used as defined in this section. Where available and appropriate, previously published definitions are used and their sources identified.

Activity: A task or body of effort directed at the accomplishment of an objective or the production of all or part of a product.
Anomaly: Any deviation from expected results or behavior.
Arithmetic defect: A software flaw in a mathematical computation.
Audit: "An activity to determine through investigation the adequacy of, and adherence to, established procedures, instructions, specifications, codes, and standards or other applicable contractual and licensing requirements, and the effectiveness of implementation" (ANSI N45.2.10-1973).
Client: That person or organization that causes the product to be developed or maintained. The client is often the customer.
Component: A general term for a portion of a product. A component could be a chapter of a document or a unit or module of software. A component may include the entire product.
Consumer: That person or organization that acquires a software product. The consumer may be either the customer or the user.
Control Defect: A software flaw in a decision process.
Customer: That person or organization that pays for the product.
Defect: A flaw in the product resulting from the commission of an error.
Element: See Unit.
Entity: Part of the overall company organization (e.g., software quality group, development group).
Error: A mistake made by a person resulting in a defect in the product.
Failure: The experienced manifestation of a defect being encountered in the product.
Fault: See Defect.
Guideline: A preferred practice or procedure that is encouraged, but not enforced, throughout the organization.
Input/Output defect: A software flaw in the process of passing information into or out of the software element.
Inspection: "A formal evaluation technique in which software requirements, design, or code is examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems" (IEEE Standard 100-1996).
ISO 9000, et al: International quality system standards published by the International Organization for Standardization (ISO). Intended to be used as the international definition of quality systems to be applied by producers or suppliers. Certification of an organization to ISO 9001 attests that the organization has a documented quality system and has evidence of its application.
Item: See Component.
Module: A group of units that together perform some convenient individual function or subfunction within the software system.
One-on-one review: The most informal examination, by a coworker of the producer, usually of a small portion of a product.
Peer review: A review of a product by peers of the producer. In some literature, the term peer review is used to mean any of the informal reviews.
Phase: Any of several convenient divisions of the software life cycle. These may typically include: concept development, requirements, design, coding, test, installation and acceptance, operation and maintenance, and retirement. Phases may or may not be sequential.
Process: The group of activities and procedures by which a producer develops or maintains a product.
Producer: The person or organization that, following a process, develops or maintains a product.
Product(s): The final, or intermediate, output(s) from any given phase of the software life cycle. These usually include specifications, code, test results, and so on.
Program: "A schedule or plan that specifies actions to be taken" (IEEE Standard 100-1992).
Quality: Compliance of a product with the expectations of the user, based on the product's requirements.
Quality assurance: The set of activities intended to detect, document, analyze, and correct process defects and to manage process changes.
Quality assurance practitioner: A person whose task is to perform one or more of the quality assurance functions or activities comprising the quality system.
Quality control: The set of activities intended to detect, document, analyze, and correct product defects and to manage product changes.
Quality control practitioner: A person whose task is to perform one or more of the quality control functions or activities comprising the quality system.
(Software) quality groups: The organizational entity responsible for monitoring and reporting the performance of the (software) product development functions and activities.
Quality management: The empowering, and encouraging, of the producer to identify and submit improvements to the product development process.
Quality practitioner: A person whose task is to perform one or more of the functions or activities comprising the quality system. The quality practitioner may or may not be assigned to a (software) quality group. This includes both quality assurance and quality control practitioners.
(Software) quality systems: The total set of quality control, quality assurance, and quality management activities dedicated to the provision of quality products.
Requirement: "A condition of capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents" (IEEE Standard 100-1996).
Review: A formal or informal meeting at which an output (product or component) of the software development life cycle is presented to the customer, user, or other interested parties for examination, evaluation, and approval.
SEI CMM: A five-level model of an organization's software process maturity, called the Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI).
Software: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.
Software development life cycle: The portion of the software life cycle devoted to the actual creation of the software system, generally beginning with the requirements generation and ending with the installation of the software system into active production.
Software life cycle: The entire period during which a software system is active, beginning with its initial conceptual development and ending with its removal from active use and its archiving.
Software system: A total, integrated aggregation of software components that performs the set of specific functions as defined by its approved requirements.
Standard: A practice or procedure that is imposed and enforced throughout the organization.
Subsystem: A group of modules that together perform one of the major functions of the software system.
Supplier: The person or organization that provides the product.
Total quality: The culture that maximizes the likelihood that a product conforms to its requirements on an ongoing basis.
Total quality system: The set of activities required to provide decision-making, action-capable management with the information it needs to affect the product development process beneficially.
Unit: "A software component that is not subdivided into other components" (IEEE Standard 610.12-1990). This is also known as the "smallest replaceable component" and sometimes called an element.
Unit development folder: The "diary" of the development of a software component. It usually contains the portion of the approved requirements being addressed by the component, the design and test information that applies, and any additional information applicable to the understanding of the development approach used for the component.
User: That person who actually performs his or her job functions with the assistance of the product.
Vendor: A person or organization that sells part or all of a product, usually for inclusion in a larger product being developed by a producer.
Walk-through: A review method in which a producer leads one or more other members of the development team through a product, or portion thereof, that he or she has developed, while the other members ask questions and make comments about technique, style, possible errors, violations of development standards, and other problems.

1.1 Definitions

A-I

M-R

S-W