Your SlideShare is downloading. ×
  • Like
Customer oriented planning of case-tools using quality function deployment (qfd)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Customer oriented planning of case-tools using quality function deployment (qfd)

  • 1,579 views
Published

Customer-Oriented Planning of CASE-Tools …

Customer-Oriented Planning of CASE-Tools
Using Quality Function Deployment (QFD)*
Georg Herzwurm, Werner Mellis, Dirk Stelzer
Chair of Business Computing, University of Cologne, Prof. Dr. Mellis
Albertus-Magnus-Platz, 50923 Cologne, Germany

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,579
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Customer-Oriented Planning of CASE-ToolsUsing Quality Function Deployment (QFD)*Georg Herzwurm, Werner Mellis, Dirk StelzerChair of Business Computing, University of Cologne, Prof. Dr. MellisAlbertus-Magnus-Platz, 50923 Cologne, GermanyAbstractSoftware products often do not satisfy customer expectations. This is espe-cially true for CASE tools. Much of the success of Japanese companies par-ticularly in meeting customer expectations is commonly attributed to theiremployment of simultaneous engineering. Simultaneous engineering uses asynchronous definition of product-design and production-processes based oncustomer’s requests and interdisciplinary team work in the company. QFD isthe backbone of simultaneous product-planning. OFD was originally devel-oped for industrial production. This paper describes a case study of applyingQFD to the planning of a CASE-Tool and demonstrates how to use andadapt the QFD method for application to software products.* veröffentlicht in: Software Quality Management III: Vol. 1 Quality Management, Hrsg.: M. Ross, C.A. Brebbia, G. Staples, J. Stapleton, 1995, Southampton-Boston, Seiten 429-440
  • 2. 430 Software Quality Management1. Customer-Orientation of CASE Tool ProducersAccording to Gartner-Group only ten European companies are among theworld’s hundred largest software-houses. The CASE-Tool market is domi-nated by American producers, too. There has not been much research aboutthe reasons for this dominance. The Irish Software Department for examplementions the following reasons: insufficient marketing and a lack of cus-tomer-orientation in Europe.Research at the University of Cologne proves, that CASE tool providers areoften more technology oriented than customer-oriented. They strive to offernewest technology and elaborate functionality, while customers give highestpriority to non functional requirements like user friendliness and adaptabil-ity. [1] Frequently CASE tool providers seem to be engaged in missionaryactivities as in the following example. The client demanded the capability toprint out an entity relation ship diagram distributed on several sheets of pa-per. This request was rejected by the CASE tool producer with the argu-ment, that a „good“ entity relation ship diagram should fit onto one sheet ofpaper. This and similar examples demonstrate that the discrepancies be-tween customer expectations and product characteristics rely in a lack ofcustomer-orientation. Often the tool is a laboratory invention, which wasnever confronted with a systematic analysis of customer needs and wants orthe known customer requirements have not been properly deployed.2. Basic Principles of CASE Tool PlanningIn the end it is up to the customer to decide about success or failure of aproduct. Where the determining factor is the customer’s perception of thevalue the product creates in his application. For a CASE tool this means thatit is relevant whether the tool is useful in the customer’s environment notwhether it is useful in a fictitious software process under fictitious condi-tions. Figure 1 illustrates the value as perceived by the customer.
  • 3. Software Quality Management 431 value (%) functional requirements functional requirements of a small company of a large-scale company 150 poor return for outstanding performance100 punishment for poor performance 50 CASE- CASE- Tool A Tool B functionalityFigure 1: Value of a CASE tool’s quality element [2]The x-axis represents different quantities of a product characteristic (in ourexample: a CASE tool’s functionality). The y-axis represents the normalizedvalue a potential customer assigns to different quantities of the productcharacteristic. Curve A shows the dependency of the value as perceived bythe customer from the amount of functionality offered by a classical PC-CASE tool, supporting the early phases of the software life cycle (upperCASE tool). Curve B shows the dependency for a Client-Server CASE tooloffering various generation tools and supporting a wide range of phase inde-pendent activities. The value 100 is reached for both products at a ratherdifferent functionality. A lack of functionality in respect to this requiredfunctionality in both cases means little value for the customer. An incrementof functionality in respect to the required functionality does not increase theperceived value proportionally. Therefore the different levels of functional-ity characterize different kinds of CASE tools not different qualities in thesense of „goodness“. The value of a CASE tool for a certain customer de-pends on his specific requirements. The CASE tool evaluation study of theUniversity of Cologne therefor carefully avoided any hint to a ranking of thetools. This also points out that customer-orientation is a critical successfactor for a CASE tool producer.If a customer’s requirements are not met, he will not buy the product or hewill demand a substantially lower price (severe punishment of un-derachievement). The curves have a steep slope on the lower side of the re-
  • 4. 432 Software Quality Managementquired functionality. On the other hand overachievement does not mean aproportional increment of value for the customer: A small or mediums sizeenterprise would not be willing to pay a higher prize for a complex CASEtool offering a lot of functionality the small enterprise would not take advan-tage of. At least it is unclear whether the excess cost of overachievementwill reach amortization. Misunderstood „positive“ quality at best means anincreased risk. Overachieving customer requirements makes sense only inexceptional cases for example if all customer requirements are met. The goalof product planning should be to meet customer expectations as close aspossible. This is what QFD supports.[3]Product planning of a CASE tool in contrast to planning of other softwareproducts like text processing for example has some particularities, whichhave to be considered in the application of QFD:• product complexity Because of a CASE tool’s complexity many customers cannot be ex- pected to formulate true needs and to distinguish reliably requirements of major and minor importance.• application complexity of the product Applying a CASE tool is a very complex task, since it means automation of the very complex and not well understood process of software devel- opment. There are many factors and unknown conditions influencing the successful application of a case tool. As a consequence the customer re- quirements are sometimes conjecture or mere guesswork and software engineering specialist claim to know better.• external factors Technology trends (for example object-orientation, client-server architec- tures) and management trends (for example total quality management) usually cause novel requirements upon CASE tools. Unfortunately these trends have effects on the product that are neither foreseeable nor control- lable by neither the customers nor providers.• quality versus innovation Another typical obstacle to customer-orientation of CASE tool producers is the different evaluation of quality requirements and innovation by de-
  • 5. Software Quality Management 433 velopers and clients. While clients and near-to-client-departments of the producer give high priority to quality, developers tend to give higher pri- ority to innovations. Software engineers usually tend to see themselves as inventors of fundamentally novel ideas and not primarily as developers of useful products. Therefore we frequently find a hidden competition be- tween quality and innovation, in which the looser is quality. Often quality lacks a promoter in the development department.Therefore QFD is an instrument with a twofold effect:• it supports product planning on the basis of the customer’s voice by a stepwise analysis and deployment of customer requirements and• it supports an improvement of communication between all people in- volved in a product development.However, there are two other effects it will not exhibit: the control and pre-diction of customer requirements and trends.3. QFD as an Instrument for Improving Customer-OrientationMuch of the success of Japanese companies is commonly attributed to theiremployment of simultaneous engineering. Simultaneous engineering uses asynchronous definition of product-design and production-processes based oncustomer’s requests and interdisciplinary team work in the company. QFD isthe backbone of simultaneous product-planning. [4] From pronounced, pro-vided or latent customer wants and needs relating to the projected product orimprovement the product’s features are successively developed. During thefirst phase „quality-planning“ customer-requirements are mapped to techni-cal characteristics of the product. In the following multistage phase „part-deployment“ the characteristics of the product-parts (modules for example)are derived from the product’s features. During the „process-planning“phase the part characteristics and eventually specific process requirementsare used as important criteria for the definition of key process operations(object or time of testing for example).Any important technical and economic data as well as the fundamental datafor defining the market strategy are fixed by an interdepartmental team ofexperts in marketing, product-planning, product-development and quality
  • 6. 434 Software Quality Managementmanagement, etc. Every step of planning is recorded in a QFD planning-matrix, which consequently represents a kind of project summary.Applying QFD in the development of new and improved software productscould yield several advantages:• it gives development a clear focus an customer requirements• it supplies management with an early and clear survey of the critical is- sues and conflicting goals• it provides a rational and transparent basis for development decisions• it supports developers with clear guidelines for software process organi- zationTherefore it is of great interest to adapt QFD for use in software develop-ment either. There have been some attempts to do so [5], but there is not yeta stable mehtodology.4. Potential and limits of QFD in the development of CASE toolsWe shall discuss the potential of QFD for planning software developmentemploying a short example of the planning of a CASE tool.During the first phase of QFD, quality planning, quality requirements aredetermined from the voice of the customer. Traditionally two types of re-quirements can be distinguished: functional and non functional require-ments, where usually the non functional requirements attract only little at-tention. Among the non functional requirements particularly quality re-quirements are virtually neglected. This is in sharp contrast to the fact that inempirical studies CASE tool users give priority to quality requirements. [6]QFD can be used for deployment of functional as well as non functionalrequirements. In surveys unsatisfied functional requirements are of minorimportance in the explanation of customers’ dissatisfaction. Therefore wegive priority to the improvement of the process of deploying quality re-quirements. Customer requirements need to be sufficiently precise and de-tailed in order to form a solid base for decisions about technical characteris-tics of the product. As has been pointed out in chapter 2, especially for usersof CASE tools demanding precise and detailed quality requirements means
  • 7. Software Quality Management 435expecting too much. This can also be demonstrated in the process of select-ing a CASE tool, where a product assessment catalogue is needed. In orderto save the effort of systematizing their requirements many companies find itvery helpful to base their own assessment on a standard CASE tool assess-ment catalogue [7] containing potential requirements in a systematic andprecise form. In a first step customer requirements have to be transformedinto a system of precise and detailed requirements. To prevent bias thisshould be done with the customer, who also has to attach his weights to thefinal requirements. In planning the first release of a product the dominatingdirection of development of the customer requirements will be from abstractto specific. In planning further releases the customer will express very spe-cific requirements from his past experience of the product that need to beorganized, aggregated and abstracted.In the planning of a new release of a simple information system we usedmoderated sessions with customers. The sessions were based on some sim-ple rules. The „producers“ were allowed to ask customers for information,explanation or detail. They were not allowed to comment on requirements,wishes or complaints of customers. The customers were encouraged to de-tail, interpret, explain and discuss their requirements. They were further en-couraged to describe their use of the product and to comment on the product,its strengths and deficiencies. The results of the group sessions were consis-tent with an independent survey, that has been conducted before. But themoderated sessions yield additional surprising requirements. Because of thegreat amount of requirements priorization is difficult. It seems to be helpfullto use a pairwise comparison. Of course this judgement needs to be consid-ered carefully. The priorization of the requirements can only be used as basisfor development decisions, if the selection of customers participating in thesessions was sufficiently representative.In detailing requirements one can proceed similarly as in a traditional devel-opment of a quality model. Quality requirements like for example userfriendliness are separated into aspects (secondary requirements) like ease ofuse, short period of training, individual adaptability (figure 2).
  • 8. 436 Software Quality Management Primary Secondary Tertiary Quartiary ... Notation Support ... Method Support Computer Aided Development ... Software Automation Engineering Ease of Use ... User Friendliness Short Period Training ... Individual Adaptation ... ... ... ...Figure 2: Typical customer requirements for a CASE toolIf necessary the secondary requirements can be further broken down intotertiary requirements and so on. For example ease of use can be separatedinto ease of determination of the appropriate work context, ease of selectionof the needed function, ease of input of the necessary data for the selectedfunction, etc. Here it is important, that the detailing is solution independentand strictly from a customer’s point of view. The degree of detail (grainsize) has to be determined pragmatically. It is adjusted appropriately, if thesystem of requirements 1. can be handled appropriately within the typicalQFD diagrams, 2. allows for a detailed comparison with the quality of com-peting products and 3. maps easily to the components of the product.The customer’s satisfaction with the product respectively the comparativeevaluation of competing products on the right hand side of the diagram isanother important information of the first QFD diagram.During the next step the developer has to deduce product quality elementsfrom the customer’s requirements. In this step requirements are mappedonto the product and gain precision. Quality elements should have a preciseand ideally operational meaning. Usually there is no simple relation betweencustomer requirements and quality elements. Therefore it is appropriate todescribe the relation in form of a typical QFD diagram. In case there is agreat number of quality elements it is advised to aggregate them into higher
  • 9. quality elements identified in the first step. For software applications amine which product component (figure 4) contributes to the most importantIn component planning the same diagram technique is employed to deter-a particular quality element.cific type of user or the average number of steps needed for a typical task asThe focus of further analysis in our example may be the beginner as a spe-grams are related to the product’s components and improvement measures.This first QFD diagram is related to the CASE product. The further dia- QFD quality planning of a CASE tool [8] Figure 3:      § P F § Q B R  ¦ ¦ • • §  ) ¦ @  2  ) 4  A B C E F G F G B H ©  D   ) I E P F 1 T © • • ¦                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ )                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ for a typical task £ S §                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 3 9 3 3 <2                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 63                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ number of steps                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ •                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ +                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ user errors per day                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 9 1                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 2                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 47                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ + number of                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ •                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ +                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ for beginner                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 3 9                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 3                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ time to learn                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 51                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ •                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ U V professional                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 1 9 ...                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 2                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ time to learn for                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ 41 ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢                   ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ <16h <80h <3 ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ • ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¥ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢  ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¦5 5 4 2 ... %   $ & %  $  # "  ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¥¦ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ © 2  ¦  © ¥ !       ¤ ¦5 @ 4  § ) 1 7 6 8§ 2 © )  ¦ © ¦ © ¨3 §  0 ¨3  9 £ () § §  ¦ ¦ © ¥ ¨ 3 ¦ £  § © ¨ ¨©   © ¥¦§ ¤ £¤  easy to use short training period individual adaptability ... © Competitor A • Comeptitor Btween the various quality elements (figure 3).of the „House of Quality“ positive and negative correlations are given be-elements at the bottom of the diagram are subjective estimations. In the roofcomplexity (from 1 = easy to 3 = difficult) and the importance of the qualitythe same time development goals. The target values as well as the expectedThe quality element’s target values in figure 3 are average values and are atsteps for a typical task, time to learn for professional etc.the operational quality elements number of user errors per day, number ofabstractions. In the example the requirements „easy to use“ are mapped onto437 Software Quality Management
  • 10. 438 Software Quality Managementstronger modularization is necessary as for typical industry products. Fur-thermore software products need not be hierarchically structured into com-ponents the same way typical industry products are. Help Utilities ... ... Editors User Interface Dialogs Parameters SA Method Dependent ERM ... OMTSoftware Tools Project Management Method Independent Configuration Management Quality Management Repository ... Documentation ...Figure 4: Components of a CASE toolAs a component of a CASE tool we can for example focus on the entity re-lationship diagram editor and its functions create, delete, modify diagram orwe can consider the menu system and options to reach the quality elements’target values.In the following steps specific design decisions are prepared concerning forexample the menu structure or the amount of mouse operations.5. Avoidable Problems in the Introduction of QFDQFD has been developed in Japan by Akao. The first application was carproduction at Toyota [9] and manufacturing is still the most important do-main of application. However, meanwhile QFD is also increasingly appliedin the Japanese software industry.[10]Capers Jones claims that US leading edge companies in information tech-nology (Motorola, HP, AT&T) employ measurement and techniques likeformal inspections and QFD as critical factors of their success. [11]
  • 11. Software Quality Management 439However, many attempts to introduce QFD have failed. [12] In most casesthis can be attributed to the lack of necessary prerequisites particularly achange of the corporate culture towards improved customer-orientation(TQM) and the availability of useful date (about customer needs, customersatisfaction, quantified quality characteristics, target values for quality char-acteristics, etc.). Important reasons of failure for European users of QFDturned out to be deficiencies in cross functional cooperation. Because of thecomplexity of QFD, which is often underestimated, introducing QFD shouldstart with an appropriately small pilot project. From practical experience wesee that sessions for developing the matrices take two to three days for fiveto seven people. Collection and preparation of the necessary input informa-tion can mean a multiple of this effort depending on the availability of datain the enterprise.6. Conclusions for QFD Application in Software DevelopmentThe above proves the applicability of QFD for the planning of softwareproducts in principle. It also demonstrates peculiarities of the application ofQFD to software. The software we are interested in is used to support somebusiness process and in case of CASE software there are very different waysto use the tool. Therefore it is important to start the analysis of customerrequirements with the customer’s requirements on the business process. [13]There is also evidence for the usefulness of a QFD in the development ofindividual software and the customization of standard software. In such de-velopment QFD introduction may even profit from the usually closer contactand cooperation with the customer. For development of individual softwareproducts employment of QFD will also have the software process as an ob-ject. Typical customer requirements in this case are reliable estimation ofeffort, early availability, to have a say in development or ISO 9000 con-formity of the development process.However, in sharp contrast to the situation in the manufacturing industryquantification of process parameters, quality elements and product character-istics lack far behind in software industry. Therefore an essential contribu-tion to the success of QFD can be expected from research and practical ex-perience of measurement in software development.
  • 12. 440 Software Quality ManagementLiterature[1] Georg Herzwurm (Ed.): CASE-Technologie in Deutschland. Orien- tierungshilfe und Marktüberblick für Anbieter und Anwender. Köln 1994[2] Walter Masing: Handbuch Qualitätsmanagement, 3. Auflage, München- Wien 1994[3] Yoji Akao: History of Quality Function Deployment in Japan. In: H. J. Zeller (Ed.): The Best of Quality. Targets, Improvements, Systems. Volume 3. Munich-Vienna-New York 1990, pp. 184-196[4] Lawrence R. Guinta, Nancy C. Praizler: The QFD Book - The Team Approach to Solving Problems and Satisfying Customers Through Quality Function Deployment. New York 1993[5] e. g. Akira Ohmori: Software quality deployment approach: framework design, methodology and example. In: Software Quality Journal. No. 3, 1993, pp. 209-240; Gerd Streckfuss: Quality improvement in software development using Quality Function Deployment (QFD). In: SAQ, EOQ-SC (Ed.): Software Quality Concern for People. Proceedings of the Fourth European Conference on Software Quality. October 17-20, 1994, Basel, Switzerland. Zürich 1994, pp. 120-128; Richard E. Zult- ner: Quality Function Deployment (QFD): Structured Requirements Exploration. In: G. Gordon Schulmeyer, James I. McManus (Ed.): Total Quality Management for Software. New York-London, 1992, pp. 297- 319[6] U. Bittner, J. Schnath, W. Hesse: Werkzeugeinsatz bei der Entwicklung von Software-Systemen. In: Softwaretechnik-Trends. No 1, 1993, pp. 14-23[7] Georg Herzwurm, Uwe Müller: Kriterienkatalog zur Unterstützung der Auswahl von CASE-Tools. Köln 1994[8] The layout of the QFD-matrices is adapted from Tilo Pfeifer: Qualitätsmanagement. München-Wien 1993[9] Yoji Akao: QFD - Quality Function Deployment - Integrating Customer Requirements into Product Design. Productivity 1990
  • 13. Software Quality Management 441[10] Tadashi Yoshizawa, Yoji Akao, Michiteru Ono, Hisakazu Shindo: Re- cent Aspects of QFD in the Japanese Software Industry. In: Quality Egineering, No. 3, 1993, S. 495-504[11] Capers Jones: Software quality tools, methods used by industry leaders. In: Computer. April, 1994, p. 12[12] Berthold Curtius, Ümit Ertürk: QFD-Einsatz in Deutschland - Status und Praxisbericht. In: QZ - Qualität und Zuverlässigkeit. Zeitschrift für industrielles Qualitätsmanagement. No. 4, 1994, pp. 394-402[13] Akira Ohmori: Software quality deployment approach: framework de- sign, methodology and example. In: Software Quality Journal. No. 3, 1993, pp. 209-240