Software Quality Management
The notion of "quality" is not as simple as it may seem. For any engineered product, many desired qualities are relevant to a particular project. The section explains software quality fundamentals, including the main SQM processes: quality assurance, verification, validation, review, and audit. Software quality refers to the delivered product of a software development project, but that quality depends on the quality of the "upstream" products from which it was derived, including requirements, design, construction, and the software quality activities that support it during the development, namely, validation, verification, testing, and measurement. Software quality terminology is numerous, informal, formal, and often ambiguous, with multiple categorizations (internal, external, operational, and feature quality). All of this makes software quality interesting to study.
From a domain perspective, software quality applies to both the problem application domain and the solution domains. It applies to all software development activities and all software products. It is interdisciplinary in that it is a topic in management, software engineering, mathematics, statistics, measurement, and more. It intersects the generic categories of human, software, and hardware and refers to the evolving relationships of these generic types. This last observation hints at the next stage in the evolution of computing technology.
Software quality is a major driving factor for computing technology evolution, which is increasing our capabilities to solve complex problems better, faster, on a larger scale, and with more automation. Generally, the problem domain gets smaller as the solution domain gets larger. The solution domain gets larger as hardware and software support becomes automated. More automation often begins with new abstractions we make in the problem domain, resulting in new relationships between hardware and software, eventually manifesting as automated support tools. We give names to these tools: "cloud computing", big databases, programming languages (front-end, network, back-end, and so on), and AI (natural language translation, image recognition, and machine learning). Indeed, software quality is very interesting.
Practical Considerations
Defect Characterization
SQM processes find defects. Characterizing those defects leads to an understanding of the product, facilitates corrections to the process or the product, and informs project management or the customer of the status of the process or product. Many defect (fault) taxonomies exist, and, while attempts have been made to gain consensus on a fault and failure taxonomy, the literature indicates. Defect (anomaly) characterization is also used in audits and reviews, with the review leader often presenting a list of anomalies provided by team members for consideration at a review meeting.
As new design methods and languages evolve, along with advances in overall software technologies, new classes of defects appear, and a great deal of effort is required to interpret previously defined classes. When tracking defects, the software engineer is interested in not only the number of defects but also the types. Information alone, without some classification, is not really of any use in identifying the underlying causes of the defects, since specific types of problems need to be grouped together in order for determinations to be made about them. The point is to establish a defect taxonomy that is meaningful to the organization and to the software engineers.
SQM discovers information at all stages of software development and maintenance. Typically, where the word "defect" is used, it refers to a "fault" as defined below. However, different cultures and standards may use somewhat different meanings for these terms, which have led to attempts to define them. Partial definitions taken from standard (IEEE610.12-90) are:
- Error: "A difference…between a computed result and the correct result"
- Fault: "An incorrect step, process, or data definition in a computer program"
- Failure: "The [incorrect] result of a fault"
- Mistake: "A human action that produces an incorrect result"
- Failures found in testing as a result of software faults are included as defects in the discussion in this section. Reliability models are built from failure data collected during software testing or from software in service, and thus can be used to predict future failures and to assist in decisions on when to stop testing.
One probable action resulting from SQM findings is to remove the defects from the product under examination. Other actions enable the achievement of full value from the findings of SQM activities. These actions include analyzing and summarizing the findings, and using measurement techniques to improve the product and the process as well as to track the defects and their removal.
Data on the inadequacies and defects found during the implementation of SQM techniques may be lost unless they are recorded. For some techniques (for example, technical reviews, audits, inspections), recorders are present to set down such information, along with issues and decisions. When automated tools are used, the tool output may provide the defect information. Data about defects may be collected and recorded on an SCR (software change request) form and may subsequently be entered into some type of database, either manually or automatically, from an analysis tool. Reports about defects are provided to the management of the organization.