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.
Software Quality Fundamentals
Models and Quality Characteristics
Terminology for software quality characteristics differs from one taxonomy (or model of software quality) to another, each model perhaps having a different number of hierarchical levels and a different total number of characteristics. Various authors have produced models of software quality characteristics or attributes which can be useful for discussing, planning, and rating the quality of software products. ISO/IEC has defined three related models of software product quality (internal quality, external quality, and quality in use) (ISO9126-01) and a set of related parts (ISO14598-98).
Software engineering process quality
Software quality management and software engineering process quality have a direct bearing on the quality of the software product.
Models and criteria which evaluate the capabilities of software organizations are primarily project organization and management considerations, and, as such, are covered in the Software Engineering Management and Software Engineering Process.
Of course, it is not possible to completely distinguish the quality of the process from the quality of the product.
Process quality influences the quality characteristics of software products, which in turn affect quality-in-use as perceived by the customer.
Two important quality standards are TickIT and one which has an impact on software quality, the ISO9001-00 standard, along with its guidelines for application to software.
Another industry standard on software quality is CMMI. CMMI intends to provide guidance for improving processes. Specific process areas related to quality management are process and product quality assurance, process verification, and process validation. CMMI classifies reviews and audits as methods of verification, and not as specific processes like.
There was initially some debate over whether ISO9001 or CMMI should be used by software engineers to ensure quality. This debate is widely published, and, as a result, the position has been taken that the two are complementary and that having ISO9001 certification can help greatly in achieving the higher maturity levels of the CMMI.
Software product quality
The software engineer needs, first of all, to determine the real purpose of the software. In this regard, it is of prime importance to keep in mind that the customer's requirements come first and that they include quality requirements, not just functional requirements. Thus, the software engineer has a responsibility to elicit quality requirements which may not be explicit at the outset and to discuss their importance as well as the level of difficulty in attaining them. All processes associated with software quality (for example, building, checking, and improving quality) will be designed with these requirements in mind, and they carry additional costs.
Standard ISO9126-01 defines, for two of its three models of quality, the related quality characteristics and sub-characteristics, and measures which are useful for assessing software product quality.
The meaning of the term "product" is extended to include any artifact which is the output of any process used to build the final software product. Examples of a product include, but are not limited to, an entire system requirements specification, a software requirements specification for a software component of a system, a design module, code, test documentation, or reports produced as a result of quality analysis tasks. While most treatments of quality are described in terms of the final software and system performance, sound engineering practice requires that intermediate products relevant to quality be evaluated throughout the software engineering process.