Download software testing and quality assurance chap 1 and more Study notes Software Engineering in PDF only on Docsity!
I l@ve RuBoard
Chapter 1. What Is Software Quality?
Quality must be defined and measured if improvement is to be achieved. Yet, a major problem in quality engineering and management is that the term quality is ambiguous, such that it is commonly misunderstood. The confusion may be attributed to several reasons. First, quality is not a single idea, but rather a multidimensional concept. The dimensions of quality include the entity of interest, the viewpoint on that entity, and the quality attributes of that entity. Second, for any concept there are levels of abstraction; when people talk about quality, one party could be referring to it in its broadest sense, whereas another might be referring to its specific meaning. Third, the term quality is a part of our daily language and the popular and professional uses of it may be very different. In this chapter we discuss the popular views of quality, its formal definitions by quality experts and their implications, the meaning and specific uses of quality in software, and the approach and key elements of total quality management. I l@ve RuBoard I l@ve RuBoard
1.1 Quality: Popular Views
A popular view of quality is that it is an intangible trait—it can be discussed, felt, and judged, but cannot be weighed or measured. To many people, quality is similar to what a federal judge once commented about obscenity: "I know it when I see it." Terms such as good quality, bad quality, and quality of life exemplify how people talk about something vague, which they don't intend to define. This view reflects the fact that people perceive and interpret quality in different ways. The implication is that quality cannot be controlled and managed, nor can it be quantified. This view is in vivid contrast to the professional view held in the discipline of quality engineering that quality can, and should, be operationally defined, measured, monitored, managed, and improved. Another popular view is that quality connotes luxury, class, and taste. Expensive, elaborate, and more complex products are regarded as offering a higher level of quality than their humbler counterparts. Therefore, a Cadillac is a quality car, but a Chevrolet is not, regardless of reliability and repair records; or, a surround-sound hi-fi system is a quality system, but a single-speaker radio is not. According to this view, quality is restricted to a limited class of expensive products with sophisticated functionality and items that have a touch of class. Simple, inexpensive products can hardly be classified as quality products. I l@ve RuBoard I l@ve RuBoard
1.2 Quality: Professional Views
The misconceptions and vagueness of the popular views do not help the quality improvement effort in the industries. To that end, quality must be described in a workable definition. Crosby (1979) defines quality as "conformance to requirements" and Juran and Gryna (1970) define it as "fitness for use." These two definitions are related and consistent, as we will see later. These definitions of quality have been adopted and used by many quality professionals. "Conformance to requirements" implies that requirements must be clearly stated such that they cannot be misunderstood. Then, in the development and production process, measurements are taken regularly
to determine conformance to those requirements. The nonconformances are regarded as defects—the absence of quality. For example, one requirement (specification) for a certain radio may be that it must be able to receive certain frequencies more than 30 miles away from the source of broadcast. If the radio fails to do so, then it does not meet the quality requirements and should be rejected. By the same token, if a Cadillac conforms to all the requirements of a Cadillac, then it is a quality car. If a Chevrolet conforms to all the requirements of a Chevrolet, then it is also a quality car. The two cars may be very different in style, performance, and economy. But if both measure up to the standards set for them, then both are quality cars. The "fitness for use" definition takes customers' requirements and expectations into account, which involve whether the products or services fit their uses. Since different customers may use the products in different ways, it means that products must possess multiple elements of fitness for use. According to Juran, each of these elements is a quality characteristic and all of them can be classified into categories known as parameters for fitness for use. The two most important parameters are quality of design and quality of conformance. Quality of design in popular terminology is known as grades or models, which are related to the spectrum of purchasing power. The differences between grades are the result of intended or designed differences. Using the example of cars again, all automobiles provide to the user the service of transportation. However, models differ in size, comfort, performance, style, economy, and status. In contrast, quality of conformance is the extent to which the product conforms to the intent of the design. In other words, quality of design can be regarded as the determination of requirements and specifications and quality of conformance is conformance to requirements. The two definitions of quality (conformance to requirements and fitness for use), therefore, are essentially similar. The difference is that the fitness for use concept implies a more significant role for customers' requirements and expectations. 1.2.1 The Role of the Customer The role of the customer, as it relates to quality, can never be overstated. From a customer's standpoint, quality is the customer's perceived value of the product he or she purchased, based on a variety of variables such as price, performance, reliability, and satisfaction. In Guaspari's book I Know It When I See It (1985 p.77), he discusses quality in the customers' context as follows: Your customers are in a perfect position to tell you about quality, because that's all they're really buying. They're not buying a product. They're buying your assurances that their expectations for that product will be met. And you haven't really got anything else to sell them but those assurances. You haven't really got anything else to sell but quality. From a concept's high-level definition to a product's operational definition, many steps are involved, each of which may be vulnerable to shortcomings. For example, to achieve the state of conformance to requirements, the customers' requirements must be first gathered and analyzed, specifications to meet those requirements must be produced, and the product must be developed and manufactured accordingly. In each phase of the process, errors can occur that will affect the quality of the finished product. The requirements may be erroneous (this is especially the case for software development), the development and manufacturing process may be subject to variables that induce defects, and so forth. From the customer's perspective, satisfaction after the purchase of the product is the ultimate validation that the product conforms to requirements and is fit to use. From the producer's perspective, once
software and customers, different weighting factors are needed for different quality attributes. For large customers with sophisticated networks and real-time processing, performance and reliability may be the most important attributes. For customers with standalone systems and simple operations, on the other hand, ease of use, installability, and documentation may be more important. Figure 1.1 shows the possible relationships of some quality attributes. Some relationships are mutually supportive, some are negative, and yet others are not clear, depending on the types of customers and applications. For software with a diverse customer set, therefore, setting goals for various quality attributes and to meet customers' requirements is not easy. Figure 1.1. Interrelationships of Software Attributes—A CUPRIMDA Example In view of these discussions, the updated definition of quality (i.e., conformance to customers' requirements) is especially relevant to the software industry. It is not surprising that requirements errors constitute one of the major problem categories in software development. According to Jones (1992), 15% or more of all software defects are requirements errors. A development process that does not address requirements quality is bound to produce poor-quality software. Yet another view of software quality is that of process quality versus end-product quality. From customer requirements to the delivery of software products, the development process is complex and often involves a series of stages, each with feedback paths. In each stage, an intermediate deliverable is produced for an intermediate user—the next stage. Each stage also receives an intermediate deliverable from the preceding stage. Each intermediate deliverable has certain quality attributes that affect the quality of the end product. For instance, Figure 1.2 shows a simplified representation of the most common software development process, the waterfall process. Figure 1.2. Simplified Representation of the Waterfall Development Process graphics/01fig01.gif
Intriguingly, if we extend the concept of customer in the definition of quality to include both external and internal customers, the definition also applies to process quality. If each stage of the development process meets the requirements of its intermediate user (the next stage), the end product thus developed and produced will meet the specified requirements. This statement, of course, is an oversimplification of reality, because in each stage numerous factors exist that will affect that stage's ability to fulfill its requirements. To improve quality during development, we need models of the development process, and within the process we need to select and deploy specific methods and approaches, and employ proper tools and technologies. We need measures of the characteristics and quality parameters of the development process and its stages, as well as metrics and models to ensure that the development process is under control and moving toward the product's quality objectives. Quality metrics and models are the focus of this book. graphics/01fig02.gif I l@ve RuBoard I l@ve RuBoard
1.4 Total Quality Management
The term Total quality management (TQM) was originally coined in 1985 by the Naval Air Systems Command to describe its Japanese-style management approach to quality improvement. The term has taken on a number of meanings, depending on who is interpreting it and how they are applying it. In general, however, it represents a style of management aimed at achieving long-term success by linking quality and customer satisfaction. Basic to the approach is the creation of a culture in which all members of the organization participate in the improvement of processes, products, and services. Various specific methods for implementing the TQM philosophy are found in the works of Crosby (1979), Deming (1986), Feigenbaum (1961, 1991), Ishikawa (1985), and Juran and Gryna (1970). Since the 1980s, many U.S. companies have adopted the TQM approach to quality. The Malcolm Baldrige National Quality Award (MBNQA), established by the U.S. government in 1988, highlights the embracing of such a philosophy and management style. The adoption of ISO 9000 as the quality management standard by the European Community and the acceptance of such standards by the U.S. private sector in recent years further illustrates the importance of the quality philosophy in today's business environments. In the computer and electronic industry, examples of successful TQM
Various organizational frameworks have been proposed to improve quality that can be used to substantiate the TQM philosophy. Specific examples include Plan-Do-Check-Act (Deming, 1986; Shewhart, 1931), Quality Improvement Paradigm/ Experience Factory Organization (Basili, 1985, 1989; Basili and Rombach, 1987, 1988; Basili et al., 1992), Software Engineering Institute (SEI) Capability Maturity Model (Humphrey, 1989; Radice et al., 1985), and Lean Enterprise Management (Womack et al., 1990). Plan-Do-Check-Act is based on a feedback cycle for optimizing a single process or production line. It uses techniques, such as feedback loops and statistical quality control, to experiment with methods for improvement and to build predictive models of the product. Basic to the assumption is that a process is repeated multiple times, so that data models can be built that allow one to predict results of the process. The Quality Improvement Paradigm/Experience Factory Organization aims at building a continually improving organization, based on its evolving goals and an assessment of its status relative to those goals. The approach uses internal assessments against the organization's own goals and status (rather than process areas) and such techniques as Goal/Question/Metric (GQM), model building, and qualitative/ quantitative analysis to improve the product through the process. The six fundamental steps of the Quality Improvement Paradigm are (1) characterize the project and its environment, (2) set the goals, (3) choose the appropriate processes, (4) execute the processes, (5) analyze the data, and (6) package the experience for reuse. The Experience Factory Organization separates the product development from the experience packaging activities. Basic to this approach is the need to learn across multiple project developments. The SEI Capability Maturity Model is a staged process improvement, based on assessment of key process areas, until you reach level 5, which represents a continuous process improvement. The approach is based on organizational and quality management maturity models developed by Likert (1967) and Crosby (1979), respectively. The goal of the approach is to achieve continuous process improvement via defect prevention, technology innovation, and process change management. As part of the approach, a five-level process maturity model is defined based on repeated assessments of an organization's capability in key process areas. Improvement is achieved by action plans for poor process areas. Basic to this approach is the idea that there are key process areas and attending to them will improve your software development. graphics/01fig03.gif
Lean Enterprise Management is based on the principle of concentration of production on "value-added" activities and the elimination or reduction of "not-value-added" activities. The approach has been used to improve factory output. The goal is to build software with the minimum necessary set of activities and then to tailor the process to the product's requirements. The approach uses such concepts as technology management, human-centered management, decentralized organization, quality management, supplier and customer integration, and internationalization/ regionalization. Basic to this approach is the assumption that the process can be tailored to classes of problems. I l@ve RuBoard I l@ve RuBoard
1.5 Summary
This chapter discusses the definition of quality from both popular and professional views, and describes total quality management (TQM) as it relates to software quality. From the popular view, quality is some type of thing that cannot be quantified: I know it when I see it. Quality and grade (or class) are often confused. From the professional view, quality must be defined and measured for improvement and is best defined as "conformance to customers' requirements." In software as well as other industries, the de facto operational definition of quality consists of two levels: the intrinsic product quality (small q) and customer satisfaction (big Q). The TQM philosophy aims at long-term success by linking quality and customer satisfaction. Despite variations in its implementation, a TQM system comprises four key common elements: (1) customer focus, (2) process improvement, (3) human side of quality, and (4) measurement and analysis. It is not surprising that the professional definition of quality fits perfectly in the TQM context. That definition correlates closely with the first two of the TQM elements (customer focus and process improvement). To achieve good quality, all TQM elements must definitely be addressed, with the aid of some organizational frameworks. In this book, our key focus is on metrics, measurements, and quality models as they relate to software engineering. In the next chapter we discuss various software development models and the process maturity framework. I l@ve RuBoard I l@ve RuBoard
References
- Basili, V. R., "Quantitative Evaluation of Software Engineering Methodology," Proceedings First Pan Pacific Computer Conference, Melbourne, Australia, September 1985 (also available as Technical Report, TR-1519, Department of Computer Science, University of Maryland, College Park, July 1985).
- Basili, V. R., "Software Development: A Paradigm for the Future," Proceedings 13th International Computer Software and Applications Conference (COMPSAC), Keynote Address, Orlando, Fl., September 1989.
- Basili, V. R., and H. D. Rombach, "Tailoring the Software Process to Project Goals and Environments," Proceedings Ninth International Conference on Software Engineering, Monterey, Calif.: IEEE Computer Society, March 30–April 2, 1987, pp. 345–357.
- Likert, R., The Human Organization: Its Management and Value, New York: McGraw-Hill, 1967.
- Radice, R. A., J. T. Harding, P. E. Munnis, and R. W. Phillips, "A Programming Process Study," IBM Systems Journal, Vol. 24, No. 2, 1985, pp. 91–101.
- Shewhart, W. A., Economic Control of Quality of Manufactured Product, New York: D. Van Nostrand Company, 1931.
- Shores, D., "TQC: Science, Not Witchcraft," Quality Progress, April 1989, pp. 42–45.
- Smith, W. B., "Six Sigma: TQC, American Style," presented at the National Technological University television series on October 31, 1989.
- Womack, J. P., D. T. Jones, and D. Ross, The Machine That Changed the World: Based on the Massachusetts Institute of Technology 5-Million-Dollar, 5-Year Study of the Future of the Automobile, New York: Rawson Associates, 1990.
- Zimmer, B., "Software Quality and Productivity at Hewlett-Packard," Proceedings of the IEEE Computer Software and Applications Conference, 1989, pp. 628–632. I l@ve RuBoard
