Applying Quality Function Deployment to Software Development

Document Sample
Applying Quality Function Deployment to Software Development Powered By Docstoc
					APPLYING QUALITY FUNCTION DEPLOYMENT TO SOFTWARE DEVELOPMENT
Hisakazu Shindo Yamanashi University Department of Computer Science 4-3-11 Takeda, Kofu 400-8511, Japan TEL&FAX: +81-55-220-8499 shindo@kki.yamanashi.ac.jp Keywords: QFD, Design-oriented approach, Software development, Software structure analysis,
Problem solving, Engineering drawing

Abstract:
Quality Function Deployment (QFD) has been regarded as a quality assurance methodology in developing a new product or a new service. In such a way of understanding, we have applied QFD to various problems and shown its effectiveness. However, it is considered that behind the success of QFD, the significance of a design-oriented aspect of QFD has been relatively overlooked. It was already pointed out in the first book on QFD [1] that the QFD was one of design-oriented approaches. Later, Shindo [2] , and Xiong and Shindo [3] examined an analogy between a quality table and engineering drawing, and reported that a quality table could be considered as a general description of an object to be designed. In this paper we focus our attention on the design-oriented aspect of QFD in order to apply QFD to software development. First, two aspects or approaches of QFD are explained. Second, the design-oriented approach of QFD is introduced. Then, relevant topics and the application of QFD to software development will be explained.

1. Introduction
Since Dr. Akao [4] proposed Quality Function Deployment (QFD) in the end of the 1960’s, an enormous amount of case studies have been reported all over the world. Most of them seem to have aimed at improving quality assurance or customer satisfaction. This results from the fact that QFD was originally proposed as a methodology of quality assurance in developing a new product. It follows that most of case studies have usually begun from grasping requirements for quality or demanded quality, while listening to the voice of customers. As a result, some people unfortunately seem to misunderstand that QFD is just making a quality table consists of requirements for quality and quality elements. However, in order to more develop QFD itself, we should re-recognize another aspect of QFD, that is, a design-oriented approach. It is no exaggeration to say that most methodologies used in TQM activities other than QFD and FMEA have been established based on analytic approaches. For example, “QC story” can be applied to problem solving provided that an undesirable result has been observed. This means that the QC story can never play an important role in problem solving without actually observing the result. It follows that the QC story cannot show its power in developing a new product. Because in the course of design, there exists just one problem to be solved, that is, the most important problem is what to realize and how to realize a new product or a new service. This paper will focus our attention on the aspect of the design-oriented approach of QFD. If one can recognize this aspect, QFD would provide more powerful applications of problem solving. First, an analytic approach and a design-oriented approach are explained. Second, the design-oriented approach of QFD is introduced. Then, relevant topics and the application of QFD to software development are explained.

2. Two approaches to problem solving
There have been various methodologies for problem solving. They can be classified into two approaches. One is analytic; the other is design-oriented. Many methodologies employed in TQM activities other than QFD can be basically said to be analytic. This tendency naturally came from the principle of “management by result”. Therefore, many methodologies used in TQM cannot be applicable unless the

Analytic approaches

past

present

future

Design-oriented approaches Fig. 1 Analytic and design-oriented approaches result has been observed. For example, a typical problem solving methodology in TQM field, QC story, is used together with the process of asking “why?” many times. In this case, a question “why?” implies “Why can it have become so?” Namely, the questions are asked against the past facts that might have caused the undesirable result. In other words, after the result has been observed, the QC story does work well to solve the problem. Because it is guaranteed that the QC story certainly finds out the real cause on the basis of causality. However, there exist problems of other type which will not have completed or produced the result. For example, in a process of design, the finished product has not yet been realized. Needless to say, the most important purpose of the design work is to realize something to be expected. Therefore, we cannot successfully apply the “QC story” to most of problems involved in design processes. Figure 1 illustrates the difference between two approaches. We are now at the present time. Once we recognize a problem to be solved, we must trace back to the past facts that have already occurred and seem to be suspicious for bringing about the problem. In this case, the QC story is very effective as well known. The QC story can be said to be scientific because it is based on the causality. It is of theoretical and practical importance that the process of problem solving by utilizing the QC story is sure to converge as long as we make necessary efforts to solve the problem. In contrast, if we would like to realize a product in the near future, we must pay attention to what to and how to realize it, that is, a series of design work itself. In the 1960’s, Japanese quality control confronted with a change from the statistical to the company-wide, or the total quality control. It is important that “Policy management (Hoshin Kanri in Japanese)” and QFD were proposed in the change. In those times, the major aim of quality control activities was shifting from the down-stream to the up-stream of a product development process. Figure 2 is so-called a waterfall model of a product development process. At the down-stream phase of the model, the statistical quality control played an important role to analytically solve various problems. From those experiences, a set of formulated procedures for problem solving is now called the QC story. As the major aim of the quality control was going up towards the up-stream of the model, necessity of a new method instead of QC story was growing while being required especially by designers. Thus, it was not until QFD was proposed that designers’ needs were satisfied. Because designers were interested not in solving problems but in realizing a product or a service. That is why QFD is called a design-oriented approach. Plan Analytic approaches

Design Design-oriented approaches Manufacture Inspect Fig. 2 A waterfall model of a product development and two approaches

Table 1 Description of a cone in the form of a table

20cm

front-view-like description

15cm

an i soscel tri e es angl ○ 20 cm i hei n ght ○ 15 cm i base n ○ ○ lne sym m etri i cal ○ three di ensi m onal ○ ○

Fig. 3 A drawing of a cone

3. Engineering drawing and a two-dimensional table
Shindo [2,5] examined the analogy between an engineering drawing and a two dimensional table. Design is a drawing or an outline from which something may be made. In the course of design work, an engineering drawing is usually used for representing an object or a scene. Since an object is three dimensional, it is projected from orthogonal three directions and described by a set of three projected shapes, each of which is called a top view, a front view and a side view. It is of theoretical and practical significance that every object can be described in such a way as long as it is shaped. For example, Fig. 3 is a drawing of a circular cone. The top view is a circle with 15 centimeters in diameter; the front and side views are both triangles with a base of 15 centimeters and 20 centimeters in height. This example is so simple that we can sometimes neglect or abbreviate the side view. Then if we focus on the top view and the front view, we can describe the cone in the form of a table as shown in Table 1. This table contains information concerning the shape of the cone from different two angles, each of which gives the top view and the front view respectively, together with their relationship between each piece of information. Therefore, it can be considered that Table 1 and Fig. 3 are equivalent to each other. If the object is a solid body, we can map it into an engineering drawing necessarily and sufficiently. In contrast, Table 1 provides us with a more general means of description even if the object is not a solid body. From the above viewpoint, a quality table can be considered as a certain kind of drawing of an object, which is described from the point of views of requirements for quality and quality elements. It is natural to make a quality table from these two viewpoints because the purpose of QFD is usually a quality assurance. However, if we treat a table as a kind of drawing, it is not always necessary to start with making a table from these two viewpoints. In such a case, it is of practical importance to determine at least two viewpoints from which we describe the object with respect to the purpose. It is noticed that if the significance of various tables composed in QFD is recognized as mentioned above, QFD can be widely applied not only to quality assurance but also to other problems to be solved from the point of view of design. When we try to apply QFD to problem solving from the design-oriented viewpoint, it is most important to find out key factors that constitute the problem and determine how to describe the problem with a combination of two dimensional tables.

15 cm in diameter three dimensional

a circle a center exists

top-view-like description

?
(A) (B) Fig. 4 Examples of a product to be improved (A) and a product to be developed or realized (B)

4. Relevant Topics 4.1 Why do we start QFD with grasping requirements for quality?
When we use a term “a new product development”, there seems to be various implications. Even if it is an improved product, some people call it a new product. In the case of Fig.4 (A), users can easily express their needs or desires for the product to be improved because users understand what an automobile is. Therefore, we can carry out QFD by grasping users’ requirements for quality. It is important that a product to be improved is already existing. To the contrary, as shown in Fig.4 (B), if users do not know what a product to be developed is, they cannot express their needs for the product. Nevertheless, most of QFD applications carried out so far started with grasping requirements for quality. This implies that the objects to which QFD has been applied were almost improved ones. If so, how can we apply QFD to the case of Fig. 4 (B), that is, an unknown product or service? The answer is clarifying what it would be by defining its functions. Because defining the function of a product or the purpose of a service is equivalent to expressing what it is. This suggests that we must start QFD with defining or specifying the function of the product when it is epoch-making or it has never existed. It is of practical importance that the QFD starting with defining and specifying functions meets engineers’ work.

4.2 What is the key factor in developing a new product?
About ten years after the original QFD concept was proposed, Akao et al. [6,7] proposed a comprehensive QFD in which engineering, cost and reliability are incorporated. It is significant that the comprehensive QFD has been accepted to be effective not only by quality staff but also by designers and engineers. The reason is that the “function deployment” plays an important role. In most cases, quality staff makes efforts how to assure the quality of the product. However, designers are always interested in how to realize the function required by users. In spite of its significance, the function deployment has not been always adopted positively. Here we consider a certain kind of product. Quality control (QC) or Quality management (QM) in narrow sense is interested in how well the function is realized. Value engineering (VE) contributes to how to improve the value of the product, where the value is defined by the ratio of function and cost. Reliability engineering (RE) is closely related to function itself. Figure 4 illustrates these three activities share the concept of “function”. Therefore, we can take a balance among quality, cost and reliability in spite of their different dimensions. Thus, we must re-recognize the significance of the function and its deployment.

4.3 Why do we need such a large quality table?
Usually a quality table becomes so large that we cannot easily handle it. This is why some people abandon the merit of QFD or a large amount of effort to make a table prevents engineers from QFD. In general, a finished product consists of a set of functions. Therefore, if we want to make a quality table, it is ready to become large. In order to overcome this difficulty, some people apply QFD restrictedly to a subsystem or a part of a product. However, it is noticed that a subsystem or a part of a product is determined after the design process has considerably progressed. Such an application, therefore, cannot draw a whole power of QFD. Instead, starting with deploying function of a product can be recommended. Then, from a technological viewpoint, we can understand the specific problem to which QFD should be applied.

Quality

Quality Control, Quality Management

Function

Value Engineering

Reliability Engineering

Cost

Reliability

Fig. 4 Relationship among factors to be considered in a design process

There is another method to obtain smaller tables. Shindo [2] and Anang et al.[8] proposed a decomposition method of a table by utilizing so-called the quantification method of type three (QM3). This enables one to decompose or nearly decompose a table that describes a system. Usually in designing a hardware product, it is natural for designers to consider how to realize it by combining various subsystems and parts. It is very important to make a necessary and sufficient table for solving a problem related to a new product development. Although quality staff may be able to inspect the necessity of a quality table, it is skilled engineers that should examine the sufficiency of the table from their experiences and knowledge. Thus, QFD should reflect the way of thinking of engineers. Their experiences, skills and knowledge help us adequately apply QFD to a product development. As a result, we can solve the problem through a comparatively small table. Such a way of designing has been established by a large amount of experiences having been accumulated for several thousand years. This means that nothing will be realized without expertise. Therefore, designers are requested to have profound expertise.

4.4 A new paradigm of QFD application
We can propose a new paradigm of QFD application as shown in Fig. 5. It can be characterized by starting with deploying not requirements for quality but function. This enables us to easily examine not only quality problems but also cost, reliability and engineering problems together with engineers. Moreover, it extends the range of QFD application to various problems such as software development, service planning, systems planning and management system design. By starting with deploying function, most problems to be solved in the course of a design process can be examined as early as possible. For example, although cost planning is already introduced into QFD, engineers have not been always satisfied with it. Because cost deployment in QFD up to this time is carried out after the design is considerably progressed. The new paradigm gives a chance to examine cost at an early phase of design process from the functional viewpoint. Therefore, we can naturally introduce the value engineering into QFD. Moreover, the new paradigm can be also applied to problem solving together with effectively employing other methods and tools. This paradigm has been partly introduced into QFD by experts. However, it can be emphasized that conventional QFD should be extended in order to effectively apply to problems required from technological viewpoint as well as ones related to quality assurance. It is possible because the QFD has been proposed as one of method of design-oriented approaches.

Function Marketing Value Engineering Price FxP

Quality

FxQ

Quality Management

Reliability

FxR

Reliability Engineering

Basic concept of the product Major problems to be solved

A

Function B

C

D

Quality

Cost

Balancing

Reliability

Balancing Technological viewpoint, Experiences, Knowledge, Other tools

Fig. 5 A new paradigm of QFD based on a design-oriented approach

5. Application of QFD to Software Development

In the early nineteen eighties QFD was applied to software development in Japan. Since then many applications of QFD to software development have been reported. In the US Zultner [9] first introduced QFD to software development using a combination of various tables. Recently Kawane [10] also reported case studies carried out in NTT Data Company. Until now, many other applications of QFD to software and its development have been also reported in ISQFD. However these applications of QFD to software or software development were basically applied to by referring to examples performed in the field of manufacturing industry. The software development environment is now dramatically changing. The latest technology of software development is symbolized by the concept of the object-oriented approach and visual programming tools. Even if we try to apply the technology to developing software, it remains difficult how to recognize objects that are existing latently in the system. This is similar to how to determine the subsystems that may constitute the whole system. Xiong and Shindo [3] reported a method of determining subsystems by applying the quantification method of type three (QM3) [2] to a two dimensional table consists of function and data. Recently, Anang et al. [8] reported a useful software tool for QFD with the QM3. Since software does not have a shape, it is very difficult for users to specifically express requirements for quality. Therefore, it is indispensable to clarify the software by defining every function and relevant data. After that, we may as well decompose the software into subsystems and extract respective requirements for quality in more specific terms. Defining the function of the software brings about a merit to consider cost or effort required in developing. Specifically, it can be realized by combining the function deployment and the function point method [11] that was originally proposed as an estimation method of software development cost. As both are directly treating function, they are considered to be congenial. However, it is necessary to accumulate more data concerning cost through the function point. As for the reliability of the software, it seems natural to introduce FMEA and FTA by way of the function deployment. In this case, we must apply FMEA and FTA in order to derive test cases as much as possible. From the above viewpoint, we try to apply QFD to software development, the concept of which is shown in Fig. 6. The procedures are as follows:

(1) Extract requirements for function and relevant data from various kinds of requirements required by users Although requirements include various meanings, we focus attention on the requirements for function and then extract data necessary to realize the function. “Data dictionaries” are used, if necessary, to define the complex data. “Mini specifications” are also made for references and used in the following algorithm design. (2) Make a two dimensional table of functions and data together with their relationships This table can be regarded as a description of the system from the design-oriented viewpoint. Traditionally a software system has been designed based on dividing functions. However, such a method becomes old-fashioned because it largely depends on skills and experiences of designers. Instead, a data-centered design approach is widely employed in the software engineering. It is important that recognizing the significance of functions, data and their relationships, we describe the system simultaneously based on these factors, that is, functions and data. (3) Apply the quantification method of type three (QM3) to the table to nearly decompose the system Here, QM3 is used to decompose or nearly decompose the system. If the system is perfectly decomposed, it means that the system consists of subsystems that are independent of each other; otherwise the system is made up of mutually interacted subsystems. Although with respect to the former we have only to make some tables independently. Since subsystems of a software system usually have interfaces between them, it is important to get information of interfaces through this process. (4) Specify the function and data of each subsystem or module with their interfaces

The purpose of this step is to determine what to realize as a software system. The function point method [11] is recommended to briefly introduce into this step, which yields a rough estimation of the development efforts. Although it is difficult to transform the “function points” into cost, if the cost seems to be beyond the budget, some functions may be neglected to meet the budget. (5) Extract requirements for quality with respect to each subsystem and compose necessary quality tables After making users understood the subsystem, extract their requirement for quality to determine the level of quality to attain in the following step. Judging from the technological viewpoint, it is not always necessary to make all the quality tables. It is noticed that a quality table of software mentioned here consists of a set of functions and performances. So far as software is concerned, performance is easier to understand than quality for software engineers. Besides, software designers do not seem to design a software system so that it directly reflects the quality. The performance of software largely depends on that of hardware. (6) Compose a quality table and determine the quality level of each function Two-dimensional tables of quality and function are helpful to determine the level of quality. From the technological viewpoint, bottleneck engineering can be drawn from the tables. In some cases, the performance of hardware should be also taken into consideration to overcome the bottleneck engineering. It is natural that users require the final performance of the system that consists of software and hardware. (7) Design database while taking functions into consideration Referring to the structure of data items obtained by the application of QM3 to a function-data table, database is designed with considering how the database is used by the relevant function. It is emphasized that the application of QM3 to the table makes the table well structured simultaneously both function and data. Therefor, the result is useful to design the database by referring to functions. (8) Design algorithms necessary to realize function of subsystem to the satisfactory degree It is important to design necessary algorithms which provide the performance to the satisfactory degree. In this process “mini specifications” previously made are utilized. Introducing recent technologies of graphical user interface is indispensable to make the software more friendly to users. Although this important work is usually left to skilled designers, design review is indispensable from the standpoint of users. (9) Extract test cases considering actual operating environment With respect to the bottleneck engineering, FMEA and FTA are used to extract effective test cases. As logic base tests are already finished, the test cases for a system integration test are mainly concerned. Recently, Kihara et al. [12] reported an effective method of extracting test cases using QFD.

Gather Requirements

Extract software function and data

Compose a two-dimensional table consists of function and data

Nearly decompose the table by QM3

Define modules and interfaces between them

Collect requirements for quality with respect to each module

Compose two-dimensional tables consist of function and quality

Determine the level of quality to be realized and extract bottle-neck engineering

Select modules to be difficult to realize

Consider how to realize the modules

Determine the implementation of each module

Review the specification and implementation from logical and users’ viewpoints

Extract test cases to confirm logic and performance

Fig. 6 A general flow of applying QFD to software development

References

[1] Mizuno, S. and Akao, Y. ed. (1978): “Quality Function Deployment--- An approach to the company-wide quality control, JUSE Publishing Company, pp. 8 - 10, (in Japanese). [2] Shindo, H. (1993): “ Generalization of a quality table concept as a method of system description and its structuralization based on near decomposability”, Hinshitsu (Journal of JSQC), Vol.23, No.3, pp. 95 –104, (in Japanese). [3] Xiong, W. and Shindo, H. (1995): “ An application of the quality table concept to the analysis of software structure”, Proceedings of ISQFD’95-Tokyo. [4] Akao, Y. (1972): “New product development and quality assurance--- a system of quality deployment”, Standardization and Quality Control, Japanese Standardization Association (JSA), Vol. 25, April, pp. 9 14, (in Japanese). [5] Shindo, H. ed. (1998): “Practical applications of QFD”, JUSE publishing Company, Tokyo (in Japanese). [6] Akao, Y. et al. (1983): “Quality Deployment in which cost, reliability and engineering are incorporated (1)”, Hinshitsu (Journal of JSQC), Vol.13, No.3, pp. 61 – 70, (in Japanese). [7] Akao, Y. et al. (1983): “Quality Deployment in which cost, reliability and engineering are incorporated (2)”, Hinshitsu (Journal of JSQC), Vol.13, No.3, pp. 71 – 78, (in Japanese). [8] Anang, Y., Yamashita, S., Watanabe, Y., and Shindo, H.(1998):A software tool for quality function deployment incorporating the quantification method of type 3, 4th ISQFD'98-Sydney, pp.77-84, Sydney. [9] Zultner, R. E. (1987): “Software Quality Deployment – Adapting QFD to Software”, Proceeedings of 13th Rocky Mountain Quality Conference. [10] Kawane, Y. (1997): “Applying QFD method to Software Development”, Proceedings of ISQFD’97, Vol.2, pp. 51 – 60. [11] IFPUG ed. (1994): “Function Point Counting Practice Manual (Release 4.0)”, trans. by JFPUG. [12] Kihara, T., Hutchinson, E. C., Dimancescu, D., Shindo, H. and Yoshizawa, T. (1998): Innovation of effective system integration test with QFD, 4th ISQFD'98-Sydney, pp.96-106, Australia