Software Quality Engineering

A Practitioner's Approach

Witold Suryn

• Publisher: Wiley-IEEE Computer Society Pr
• Year: 2013
• Print ISBN: 9781118592496
• eBook ISBN: 9781118830185
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

A concise, engineering-oriented resource that provides practical support to IT professionals and those responsible for the quality of the software or systems they develop

Software quality stems from two distinctive, but associated, topics in software engineering: software functional quality and software structural quality. This book studies the tenets of both of these notions, which focus on the efficiency and value of a design, respectively. It addresses engineering quality on both the application and system levels with attention to information systems (IS) and embedded systems (ES) as well as recent developments.

Software Quality Engineering introduces the basic concepts of quality engineering like the nature of the engineering process, quality models and measurements, and evaluation quality, and provides a step-by-step overview of the application of software quality engineering in commonly recognized phases of the software development process. It also discusses management of software quality engineering processes, with special attention to budget, planning, conflict resolution, and traceability of quality requirements.

Targeted at graduate engineering students and software quality specialists, Software Quality Engineering:

• Provides an analysis of interdependence between software functionality and its quality
• Includes a list of software quality engineering "to-dos" and models of software quality requirements traceability
• Covers the practical use of related ISO/IEC JTCI/SC7 standards

Chapter 1

Why Software Quality Engineering?

Quality has become a critical attribute of software products as its absence produces financial, health, and sometimes life losses. At the same time the definition, or scope, of the domain of software quality has evolved continuously from a somewhat technical perspective to a perspective that embraces human aspects such as usability and satisfaction.

An increasing business-related recognition of the importance of software quality has also made software engineering's “center of gravity” shift from creating an engineering solution toward satisfying the stakeholders. Such a shift very clearly reflects the trend within the community of stakeholders who more and more often say: “I do not want to know about bits and bytes. I want a solution that satisfies my needs.” The critical word here is “satisfaction,” for it covers both functional and quality perception of the software solution being used.

Development organizations confronted with such an approach are, in general, not entirely prepared to deal with it even if their engineers are adequately educated. Moreover, if the education is there, it is quite often acquired through experience rather than a regular educational process, as the software engineering curricula being offered, with few exceptions [1], do not emphasize the importance of teaching software quality engineering.

One of practical responses to such a situation was the development of Software Engineering Body of Knowledge (SWEBOK) [2]. SWEBOK seeks to provide the knowledge that allows universities to build such educational programs that will allow producing professionals able to stay abreast of the fast-moving industry, but it also adds a scientific and innovative component to best practices. The continuation of this approach is this book.

So let's ask the question, “why software quality engineering?” as three partial questions:

• Why software? Because in contemporary social life software, systems and services rendered by software are omnipresent, beginning with the watches we wear, ending with nuclear electricity plants or spaceships.
• Why quality? Because if these instances of software work without the required quality we may be late, dead, or lost in space.
• Why engineering? As in every technical domain, it is engineering that transforms ideas into products, it is the verified and validated set of “to-dos” that help develop the product that not only has required functionalities but also executes them correctly.

To make this picture complete, another question should be asked: why at all? There is in fact only one reason: the user. Despite decades of evolution of information technology and its tools, the user still faces risky, unreliable, and quite often unintelligent products that far too often waste his or her time or money, and wear off his or her patience. So quality engineering applied to software, systems, and related services is intended to assist developers in building good, intelligent, and reliable products; to help users request and verify their quality needs; and for those who want to use software as easily as they use a dishwasher, to shield against faulty products and unprofessional suppliers.

1.1 Software Quality in the Real World

For the users, a software product more and more often corresponds to a black box that must effectively support their business processes. As a consequence of this natural approach, business needs become a driving force of quality software product development and a stakeholder moves to the position of a car buyer and user rather than an involuntary expert in software engineering. And what he or she perceives at the end corresponds to expressed satisfaction at using a software product that possesses both required functionalities and required quality. When one of them is missing, a painful process of improvements and negotiations takes place to often end by changing the supplier and replacing the product with one that is mature enough do its job well on both accounts.

What exactly constitutes the quality of a product is often the subject of hot debate. The reason the concept of quality is so controversial is that there is no common agreement on what it means. For some it is “degree to which a set of inherent characteristics fulfills requirements” [3], whereas for others it can be synonymous with “customer value,” or even “defect levels” [4]. A possible explanation as to why any of these definitions could not win a consensus is that they generally do not recognize different perspectives of quality, such as for instance the five proposed by Kitchenham and Pfleeger [5]:

• The transcendental perspective deals with the metaphysical aspect of quality. In this view of quality, it is “something toward which we strive as an ideal, but may never implement completely.”
• The user perspective is concerned with the appropriateness of the product for a given context of use.
• The manufacturing perspective represents quality as conformance to requirements. This aspect of quality is stressed by standards such as ISO 9001 [6] or models such as the Capability Maturity Model [7].
• The product perspective implies that quality can be appreciated by measuring the inherent characteristics of the product.
• The final perspective of quality is value-based. This perspective recognizes that the different perspectives of quality may have a different importance, or value, to various stakeholders.

One could argue that in a world where conformance to ISO and IEEE standards is increasingly present in contractual agreements and used as a marketing tool, all the perspectives of quality are subordinate to the manufacturing view. This predominance of the manufacturing view in software engineering can be traced back to the 1960s, when the U.S. Department of Defense and IBM gave birth to Software Quality Assurance [8]. This has led to the belief that adherence to a development process, as in manufacturing, will lead to a quality product. The corollary to this belief is that process improvement will lead to improved product quality.

This opinion is not shared unanimously, as some parts of both industry and academia find it inaccurate or at least flawed. For example, G. Dromey states:

The flaw in this approach [that you need a quality process to produce a quality product] is that the emphasis on process usually comes at the expense of constructing, refining, and using adequate product quality models [9].

Kitchenham and Pfleeger reinforce this opinion by stating:

There is little evidence that conformance to process standards guarantees good products. In fact, the critics of this view suggest that process standards guarantee only uniformity of output [5].

Furthermore, data available from Agile [4] projects show that high quality is attainable without following a manufacturing-like approach.

However, some studies conducted at Raytheon [10] and Motorola [11] showed that there is indeed a correlation between the maturity level of an organization as measured by the Capability Maturity Model (CMM) and the quality of the resulting product. These studies provide data on how a higher maturity level (as measured by the CMM) can lead to:

• Improved error/defect density (i.e., the error/defect density lowers as maturity improves)
• Lower error rate
• Lower cycle time (time to complete parts of the lifecycle)
• Better estimation capability.

From these results, one could conclude the quality can be improved by following a mature process. Studies of the development of lifecycle models presented by Georgiadou [12] indicate that the maturity of the development process is reflected by the emphasis and allocation of testing and other quality assurance activities. The study demonstrated that the more mature the process and its underlying life cycle model, the earlier the identification of errors in the deliverables. However, these measured improvements are directly related to the manufacturing perspective of quality. Therefore, such quality improvement efforts fail to address the other perspectives of quality. This might be one of the reasons for the perception of the “quality problem” as one of the main failings of the software engineering industry. Furthermore, studies show that improvement efforts rooted in the manufacturing perspective of quality are difficult to scale down to smaller projects and/or smaller teams [13, 14]. Indeed, rather than being scaled down in smaller projects, these practices tend to be not performed at all.

Over recent years, researchers have proposed new approaches and models that try to encompass more perspectives of quality than just the manufacturing view. Geoff Dromey [9, 15] proposed such a model in which the quality of the end product is directly related to the quality of the artifacts that are a by-product of the process being followed. The reasoning is that if quality artifacts are correctly designed and produced throughout the life cycle, then the end product shall manifest attributes of good quality. This approach can clearly be linked to the product perspective of quality with elements from the manufacturing view. This is certainly a step from the manufacturing-only approach, but it fails to view the engineering of quality as a process that covers all the perspectives of quality. In Pfleeger and Atlee [16], the reader can find valid arguments against approaches that focus only on the product perspective of quality:

This view [the product view] is the one often advocated by software metrics experts; they assume that good internal quality indicators will lead to good external ones, such as reliability and maintainability. However, more research is needed to verify these assumptions and to determine which aspects of quality affect the actual product's use.

All of this may be true to a certain extent, but what ultimately counts is a customer's yes said after the delivery is finalized.

Another absolutely natural trend observable within the “population of IT customers” is the desire to be properly served without having to become proficient in information technology. A customer just wants to buy, learn how to use, and then simply use a software product, just as he or she does with a car or a TV. This boils down to an extended (or shall we just say “professional and mature”) responsibility of a software supplier, who now has to know not only what the customer is able to express, but also what the customer does not know that he or she knows. And then, when all questions are asked and answered, the supplier must continue on his or her way until the product is built and delivered to the customer's satisfaction.

Similarly to mathematics, the most important part of software and software quality engineering is to understand the problem. Whatever comes after is the result of knowledge applied to this understanding and, if we make an assumption that such knowledge exists, the final outcome makes the “executable form” of what was understood. The graveness of this statement is expressed by different kinds of statistics showing billion-dollar losses resulting from bad or incomplete understanding of the problem called a software product (a simple search on Google brings up thousands of hits on this subject). In case of software quality, the situation is even more dire, as the primary source of information, a customer, is usually able to at least signal his or her “functional” needs, but in the majority of situations is not knowledgeable enough to identify or discuss in precise terms the quality requested from the product under discussion. When it comes then to analyzing why something bad happened, customers blame suppliers (which is understandable) but the suppliers do not stay behind. From a purely professional point of view, one might ask: “Is that fair?” Who, between the user and the supplier, is supposed to be an expert, especially in a subject so difficult to define as quality? Should not...

Table of contents

• Cover
• Title page
• Copyright page
• Dedication
• Preface
• Chapter 1: Why Software Quality Engineering?
• Chapter 2: Software Quality Engineering: Making It Happen
• Chapter 3: System and Software Quality Engineering: Some Application Contexts
• Chapter 4: Trustworthiness of IT Systems and Services
• Appendix: Cost of Missing Quality: Case Studies
• Index