Sie sind auf Seite 1von 31

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 –

International Journal of Industrial Engineering Research

IJIERD

© I A E M E

IJIERD © I A E M E

6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

and Development (IJIERD), ISSN 0976 – 6979(Print) ISSN 0976 – 6987(Online) Volume 2 Issue 1, May – October (2011), pp. 15-45 © IAEME, http://www.iaeme.com/ijierd.html

DEVELOPMENT AND APPLICATION OF SQFD MODEL FOR AN INNOVATIVE EMBEDDED SOFTWARE PRODUCT – A CASE STUDY

Dillibabu,R. Department of Industrial Engineering, Anna University, India, Chennai. Telephone No: +914422357680 prdillibabu@rediffmail.com

Krishnaiah,K. Department of Industrial Engineering, Anna University, India, Chennai. Telephone No: +914422357673

Baskaran,R. Department of Industrial Engineering, Anna University, India, Chennai. Telephone No: +914422357683

ABSTRACT

This paper discusses the development and application of Software Quality Function Deployment (SQFD) Model for a new embedded software product. A detailed Literature study has been carried out on the applications of QFD model for software development. An integrated SQFD model with House of Quality (HOQ), Subsystem/Module Deployment Matrix and Technology Deployment Matrix is developed. The proposed SQFD model has been implemented for developing a new embedded software product. From the HOQ matrix reveals that the ‘image capture button’ and ‘imaging’ has been identified as the most important technical requirement for this product. The “Procedure Recording” Subsystem has been identified as the most critical subsystem that affects the design. The most suitable technology that meets the design is the ‘Prism+, pSOS’. Accordingly, recommendations are made to the company. The study demonstrates that the SQFD technique is suitably applied using SQFD Model in an embedded software product, and it is appropriate for the design and development of new software products.

KEYWORDS: Software Quality Function Deployment, House of Quality, Embedded Software, Technology deployment matrix, Subsystem Deployment Matrix and New Product Deployment.

1.0

INTRODUCTION

Software quality has traditionally been defined in terms of fitness for use based on Juran’s definition of quality. A software product is deemed fit for use if it performs to some level of

15

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

satisfaction, in terms of functionality and continuous operation (William and Raja 1995) and (Yoji 1997). An important element of software quality is the reduction of management risk. Late delivery, cost overruns, inadequate product performance, and a short product life are management

risks that must be controlled along with fitness for use to obtain software quality. These management risks relate to the process of developing software and not the software product itself. Quality Function Deployment (QFD) is a useful quality analysis and improvement tool with many advantages. The following are the advantages of QFD

(i)

Fewer and earlier design changes

(ii)

Reduced Product Development cycle time

(iii)

Fewer startup problems

(iv)

Easier documentation

(v)

Fewer field problems

(vi)

Warranty claim reduction

(vii)

Development of cross-functional team work

(viii)

Improved design reliability

(ix) Customer Satisfaction

QFD is also employed for designing IT-related products (software industry). When using QFD, it is important to understand the needs of the customers, and then we can design or modify the product to meet their needs (Ronald 1996). The manufacturing QFD (Taeho and Kim 1998) was developed in Japan in the mid 60’s by Yoji Akao and Shigreu Mizuno. QFD is a method to transfer customer needs into product and process requirements. The idea is to develop a product by focusing the effort and limited resources of a project team on what delivers the best value to the most important stakeholders. Adaptation of the classic QFD applicable to manufacturing industries to software products is termed as SQFD. The unique characteristics of software development necessitate the modification of conventional QFD for use in deploying software design. The first characteristic is that software development is not a repetitive production process that must be designed for each product. QFD has been originally conceived as a way of deploying customer requirements throughout the production process of a product, from design to manufacturing. Software elements are developed to a set of design specifications. In QFD this would equate to a part of product deployment.

The second major difference between manufacturing and software development is that the customer requirements are not directly met by specific technical specifications. Unlike manufactured goods, software or information systems are typically intended to provide support infrastructure or to act as an enabling mechanism for an organizational process. In QFD, customer requirements are translated into technical specifications for a particular product. In the case of software or information systems development, customer needs are met by providing certain system functions. These system functions may require the development of one or more software systems. For example; the customer needing “accurate inventory information” would be require the construction of inventory tracking software, purchasing and receiving software, and cost management software. These individual program elements would require finally an integration structure to meet the stated customer requirements. SQFD model with GQM (Goal Question Metric) is also studied and is shown in Fig 1.

2.0 LITERATURE

Several Researchers have developed or applied QFD models for engineering/manufacturing products (Georg et al. 1995; Glenn 1993; Tan, Xie and Chia 1998; Taeho and Kim 1998; Yoji 1997; Yoji and Mazur 2003). SQFD model is based on assessment of impact of technical attributes on satisfaction of customer requirements (Liu et al. 2006). Software requirements

16

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

validation uses SQFD tools (Joao, Pedro and Ana 2005). SQFD is used also to evaluate software quality (Pedro, Marcos, Jose and Luis 2005). But only a very few researchers have contributed to Software Quality Function Depolyment (Georg and Schockert 2003; Georg, Schockert and Werner 1995), (Ohmori 1993), existing SQFD models reveals some of the drawbacks which are presented in Fig 2. From the literature review it is found that very few researchers have developed and applied SQFD models to practical cases. Also the existing models have several drawbacks as listed in Fig 2. In this study it is proposed to develop SQFD model for a new embedded software product and implement it in a leading software company.

3.0 DEVELOPMENT OF THE PROPOSED SQFD MODEL

Great Success has been derived from the use of SQFD by a number of companies. The previous models have been implemented either for a new product development or as an intensifier or enabler of the key process of the customer organization. Most of the existing SQFD models have the components of competitor and technical analysis and as such these cannot be applied to embedded products. The previous SQFD model had the weakness of not employing the “house of quality” form and hence the developers cannot explicitly examine the relationships between technical requirements or the “hows” listed along the x-axis of the matrix (William and Raja

1995). The effects due to product or process characteristics remain unknown, and therefore cannot be improved. Therefore, the following three matrices are proposed to be included in the Proposed SQFD Model.

(i)

Software House of Quality (S-HOQ) Matrix

(ii)

Subsystem or Module Deployment Matrix

(iii)

Technology Deployment Matrix

3.1

Software House of Quality (S-HOQ) Matrix

The utility of QFD is that it requires a company to clearly articulate the means by which it will achieve customer requirements. It relates customer or market needs to be high-level internal technical design requirements using a planning matrix called the house of quality. The basic structure of the house of quality is shown in fig 4. Listed on the left side of the matrix is what the customer needs or requires. Listed along the top of the matrix are the design attributes or technical requirements of the product; these are how the product can meet customer requirements shown in additional sections on the top, right, and bottom sides are correlations among the requirements, comparisons to competitors, technical assessments, and target values.

The procedure suggested by Ronald (Ronald 1996) and (Yoji 1997) has been followed in developing the S-HOQ matrix (Fig 6). The details of the S-HOQ matrix are presented below.

(i) Whats and Customer Importance: The voice of the customer or the customer requirements are gathered through brainstorming (Fig 8, step 1) comprising the representatives of the client company who produces the product. These requirements are grouped into related categories using affinity diagram and presented as whats in the S-HOQ (He, Staples, Ross and Court 1996). Using Analytic Hierarchy Process (Taeho and Kim 1998) and Paired Comparisons, ratings for the whats are identified in a scale 1 to 10 by brainstorming (Fig 8, step 1). One implies low importance or priority and 10 imply high importance or priority.

(ii) Hows: The hows (technical requirements) are obtained by conducting a brainstorming. Although the process is often more technical at this point, the team shall still include representatives of all functions in the organization. The Hows are recorded in the voice of the engineer. Hows usually represent the product features, design requirements, product characteristics, product criteria, substitutes of quality characteristics and technical requirements. The hows represent the means by which a company responds to the user wants and needs. These

17

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

technical requirements are listed along the top of the software House of Quality. Each technical requirement may affect one or more of the customer voices.

(iii) Target Values: The potential Hows are quantified by fixing target values by conducting

another brainstorming. If any technical requirement is not quantifiable then at least a qualitative statement to measure that technical requirement has to be given. These target values are recorded

in the voice of the engineer table itself.

(iv) Relationship Matrix and Validation of Relations: The relationship matrix (John 1999; Tan et al. 1998; Ohmori 1993) is the most important part of the HOQ. As most of the data are collected through brainstorming, there is a need to validate the important outcomes of the brainstorming using any quantitative technique. One way is to design a questionnaire and obtain responses from the developers and validate using statistical testing of hypothesis.

The relationships between customer requirements and technical requirements are established through brainstorming together with the customer representatives. These relationships are related between every what and every how. All relationships are categorized as either strong, medium or weak. Different symbols are used to signify different relationship strengths (circle with dot in the center signifies a strong relationship, blank circle signifies a medium relationship and triangle signifies a weak relationship). The allocation and categorization of the relationships are carried out through careful consideration and double-checked a number of times.

(v) Correlation “Roof” Matrix: This matrix assists the software engineers to specify the various engineering features that have to be improved collaterally. The roof contains the most critical information which is used to balance the trade-offs when addressing the customer benefits. These relations are obtained through brainstorming with the members of the QFD team. Different symbols are used to indicate the strength of the relationships. The correlations are categorized as strong positive relationship, positive relationship, negative relationship and strong negative relationship. A blank cell represents no relationships. The positive symbols show which Hows support each other and the negative symbols show which Hows are in conflict.

(vi) Organizational Difficulty: The organization difficulties are assessed by conducting a

brainstorming and are represented in a scale of 1 to 10. One imples low difficulty in satisfying the

particular technical requirement and 10 implies high difficulty in satisfying the particular technical requirement.

(vii) Weightage Factor: The weightage scheme is selected by conducting a brainstorming session.

In this meeting usually only the members (developers) of the QFD team are present. This selection was based on the gap between the relations categorized as strong, medium and low. These weightage factors are then recorded in the data template.

(viii) Absolute Importance: A cell (i,J) in the relationship matrix of HOQ represents a strong, medium or weak relationship between i th customer requirement (CR) and j th Technical requirement (TR). The absolute and relative importance of TRs is computed using the Customer Importance of CRs and the relationship ratings (Taeho and Kim 1998).

For each TR, the absolute importance rating is computed as

AI j =

m

CI i * R ij

i=1

……………………(1)

18

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

where

AI j is Absolute Importance of TR j , j = 1,

,n

CI i

is

Customer

Importance

i.e.,

importance

rating

of

CR i ,

i = 1,

,m

R ij is Relationship rating representing the strength of the relationship between CR i and TR j .

(ix) Relative Importance: The absolute importance rating can then be transformed into the Relative Importance rating, RI j , as

RI j =

AI j

AI k

k=1

………………………………… (2)

n

The larger the RI j , the more important is TR j . Thus, without consideration of any other constraints such as cost and time, TRs should be incorporated into the product of interest in the order of their relative importance rating to achieve more customer satisfaction. The qualitative relationship viz strong, medium and weak are generally assigned a value of 9, 3 and 1 respectively for obtaining the ratings (Ronald 1996) and (Yoji 1997). However these values can be arrived at by conducting a brainstorming session for specific cases in practice. After computing the absolute and relative importance of the Technical requirements they are normalized to a scale of 1 to 10. 1 implies low importance and 10 implies high importance or priority.

3.2 Subsystem or Module Deployment Matrix

The Subsystem or module deployment matrix is prepared in a manner very similar to the S-HOQ matrix which is shown in Fig 6 (Mekki and Sherif 1997; Ronald 1996; Yoji 1997). Each critical subsystem or module requires the incorporation of all the technical requirements into the product and is designed by conducting brainstorming with the engineers. The technical requirements defined in the S-HOQ matrix become whats that are listed down on the left side of the subsystem or module deployment matrix along with priorities (based on the normalization of S-HOQ matrix relative importance ratings) and target values.

Relationship Matrix: Relationships are established between technical requirements and the critical subsystem or module. These relationships are then categorized as strong, medium, or weak and are validated using a questionnaire (brainstorming) and hypothesis testing.

Importance Rating of Subsystem: Importance rating of each subsystem or module are calculated using equation (1) with slight modification. In Subsystem or Module deployment matrix, a cell (i, j) in the relationship matrix represent a strong, medium, or weak relationship respectively between i th Technical requirement (TR) and j th Subsystem (SS). The importance rating of Subsystem is computed using the normalized importance of TRs and the relationship ratings (Taeho and Kim 1998). For each SS, the importance rating is computed as

19

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

where

IR j =

m

NI i * R ij

I=1

…………………. (3)

IR j is Importance Rating of SS j , j = 1,

,n

NI i is Normalized Importance of TR i , i = 1,

,m

R ij is Relationship rating representing the strength of the relationship between TR i and

SS j

3.3

Technology Deployment Matrix

The technical requirements defined in the S-HOQ Matrix shall become the whats listed on the left side of the Technology deployment matrix along with priorities and target values. This matrix is developed similar to that of subsystem/module matrix (Fig 6). The only change here is that the subsystem/module is replaced by the term technologies is shown in Fig 7.

4.0 PROPOSED SQFD MODEL

The proposed SQFD Model is shown in Fig 8. It is an integrated model of S-HOQ Subsystem/Module Deployment Matrix and the Technology Deployment Matrix. This model is validated through a case study.

5.0 IMPLEMENTATION OF THE SQFD MODEL

The proposed model has been implemented in one of the leading software companies in India. The company is a world leader for medical products and has a large global market share in the Endoscope tools. The endoscope uses a combination of fiber optics and electronics for performing its function. All the endoscope used today is reusable and need 8-10 hours of sterilization and disinfection process before they can be reused.

Some of the functions affecting the performance of the products due to the existing software are presented below:

(i)

Printing

(ii)

Motor start and Stop Motion Command

(iii)

Jet wash on/off status and flow rate setting

(iv)

Joystick of speed command

20

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

(v)

Brightness and contrast adjustment

(vi)

Image capture button and imaging

(vii)

Recording of Image frame and camera video functions

(viii)

GUI navigation commands and SUD connector functions

(ix)

Alert Message and Power supply adjustment

(x)

Record Camera video data to the DVD

(xi)

Database for patients, physicians and procedures

(xii)

Directions for use.

Some of the problems in the present endoscope procedure are listed below:

(i)

Reusable scope calls for strict sterilization and disinfection process.

(ii)

High capital cost for the probes and the allied peripherals and sterilization equipment.

(iii)

High frictional force felt by the patient, necessitating patients to be sedated, increasing the complexity of the procedure as well as patient recovery time.

(iv)

Less number of cases possible by the physician due to long sterilization and dis-infection process.

(v)

Risk of secondary infection due to improper sterilization.

In-spite of sterilization the risk of secondary infection has been reported. This risk has resulted in reluctance among the patients to undergo colonoscopy procedures. This status is in existence for the last 25 years, despite progress in the colonoscopy form a simple bare eye viewed system to a sophisticated CCD camera based system with digital imaging functions. But the system of reuse has never changed. The client is capitalizing the opportunity of an infection free safe procedure as their unique selling proposition of their product. Coppelius Console System is the base unit to which the single use probe is attached and the endoscopy procedure is carried out. The case company is going to develop embedded software for the endoscope probe. SQFD model has employed to overcome the problems stated above and improve customer satisfaction. The steps in its implementation are listed and discussed below.

5.1 Pre-Planning

Pre-planning includes setting the project goals, determining the time schedule, cost planning and forming the SQFD team. Apart from these activities, the planning phase of a SQFD implementation includes defining the project’s content (product definition), identification of the customer groups and their importance for the development ahead as well as selecting customer representatives. This phase is called as Pre-Planning and consists of normal meetings and brainstorming sessions of the persons in charge of the project.

21

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

5.2 Building the Software House of Quality (S-HOQ)

The entire SQFD process has been carried out by a QFD team with members from all departments (development, quality management, marketing, sales, service, etc.), and the client company representatives. Usually formal market research process is applied using focus groups and in-depth qualitative interview techniques to assess the customer requirements. For the embedded software development the end user requirements have been obtained from the client organization, which in turn got them from the actual user of the hardware equipment in which the embedded software is an integral part.

(i) Whats and Customer Importance: Customer requirements are structured using affinity and tree diagrams are shown as whats of the software-HOQ (Fig 7). The Whats are ranked in order of importance using the Analytic Hierarchy Process (Yoji Akao and Mazur 2003) and pair-wise comparison (Georg, Schockert and Werner 1995). The priority of customer importance displayed in the HOQ next to each customer voice has been obtained from the QFD team in a scale of 1 to 10. This gives the customer importance or priority rating for the whats of the software-HOQ. One implies low importance of priority and ten implies high importance of priority.

(ii) Hows : The technical requirements obtained similar to that of customer requirements are

shown as hows of the Software-HOQ carried out similar to the identification of customer requirements, using a Voice of the Engineer (Fig 8), and is shown in Fig 9. The difference is that

the members of the QFD team consist of the developers during the brainstorming session.

(iii) Target Values: The target values are obtained by converting technical requirements into

measurable quality elements. For the product in case these have been arrived at during the internal QFD meeting.

(iv) Relationship Matrix and Validation of Relations: The relationships between customer

requirements and technical requirements have been established through brainstorming involving the customer representatives also. The allocation and categorization of the relationships are carried out through careful consideration and are double-checked a number of times.

Referring to Fig 9, there is a strong relationship between the customer requirement ‘store image’ and the technical requirement ‘recording of image frame’. Similarly there exist a medium relationship between the customer requirement ‘responsive tip control’ and the ‘technical requirement ‘speed oscillation’, and a weak relationship between customer requirement ‘electronic documentation’ and the technical requirement ‘GUI navigation command’. The customer importance and organization difficulty ratings were obtained through brainstorming are validated using a questionnaire and hypothesis testing. A Questionnaire (Fig 12-21) has been developed in MS Excel and sent through E-mail to get response from the developers.

(v) Correlation “Roof” Matrix: The correlation “roof” matrix has been constructed next. This

matrix assists the software engineers to specify the various engineering features that have to be improved collaterally. The roof contains the most critical information which is used to balance the trade-offs when addressing customer benefits. These relationships are obtained through brainstorming with the members of the QFD team. The correlation matrix is constructed using the relationship keys such as:

An inclined hash symbol for strong negative correlation, a multiplication symbol for negative correlation, a blank circle for positive correlation and circle with dot in the center for strong positive correlation. In Figure 9, blank cell represents no relation and others shown are only positive correlations.

22

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

(vi) Organizational Difficulty: These measures provide the software development organization

with a quantitative assessment of their ability to support embedded software development processes. Such an analysis provides the development organization with:

Quantitative indicators of changes in organizational priorities;

Indicators of the effectiveness of software development processes.

The latter point supports continuous improvement efforts on the part of the organizational software development function. The organization difficulty is represented on a scale of 1 to 10. One implies low difficulty in satisfying the particular technical requirement and ten implies high difficulty in satisfying the particular technical requirement. Referring to Figure 9, the company has a low difficulty of one in satisfying the technical requirement ‘database for patients and physicians’ and a high difficulty of six in satisfying the technical requirement ‘general requirement for standards’.

(vii) Weightage Factor: A weightage factor is also attached to each relationship. The weightage

scheme is selected by conducting a brainstorming with the members of the QFD team which include the developers. The weightage scheme of 9-3-1 is used (Ronald 1996) and (Yoji 1997). “9” for a strong relationship, “3” for a medium relationship and “1” for a weak relationship.

(viii) Absolute Importance: The absolute importance AI j for each technical requirement is

calculated using the equation (1). In Fig 9, a sample value for one absolute importance is shown. In the first column the technical requirement “Printing” has a strong relationship with the customer requirement ‘printing of images by printer’, weak relationship with ‘must be versatile’

Thus the column

and strong relationship with ‘printing images during and after procedures’ weight for the first column is computed as (9X9) + (7X1) + (9X9) = 169.

(ix) Relative Importance: The Relative Importance (RI j ) for each technical requirement is calculated using the equation (2). In Fig 5, it is represented graphically as histogram. The column weights are used to identify the technical requirements for quality improvement.

Normalization of Importance: The relative importances of the technical requirements are normalized on 1 to 10 scale. One implies low importance and 10 implies high importance. The normalized rating will be used as the priority ratings in the subsequent phases of Subsystem or module deployment matrix and Technology deployment matrix. The column weights in the matrix indicate which technical requirement has to be addressed first to improve quality. Then in Fig 9, the technical requirement “image capture button & imaging” carrying a highest weightage of 220 needs to be taken up first.

5.3 Subsystem or Module Deployment Matrix

The technical requirements defined in the Software-HOQ matrix shall become the whats for the Subsystem or Module deployment matrix (Fig 10). The target values are also same as that of HOQ matrix. The priority ratings are obtained by normalizing the relative importance ratings of the HOQ. Some of the technical requirements with low priority ratings are not found in the Module deployment matrix. The critical Subsystems/Modules (Fig 10) required incorporating all the technical requirements into the product are obtained through brainstorming. Other aspects of the matrix viz relationships and their validation, wightages and importance ratings are arrived at similar to that of HOQ. These matrix priorities the critical subsystems based on relative importance ratings for quality improvement strategy.

5.4 Technology Deployment Matrix

23

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

This matrix is also constructed similar to that of subsystem/module deployment matrix by replacing the subsystem or module block by the Technology block (Fig 11). This contains alternative technologies suitable to attain the technical requirements. This matrix facilitates the selection of the technology based on the absolute/relative importance ratings. From Fig 11 it is seen that the technology “Prism+, pSOS” is most suitable one for the embedded system software.

5.5 Validation of SQFD Model

A survey has been conducted to assess the impact of SQFD before and after its implementation.

Before implementing SQFD, company has been practicing the traditional quality improvement practices. A questionnaire (Fig 22) has been designed and sets to developers and quality professionals in the software companies before and after the implementation of SQFD. The questionnaire contains a set of question on design goals, success factors (Georg et al. 1998) and results achieved (http://sern.ucalgary.ca/course/seng/613/F97/grp2/report.htm).

The factors are assigned a five point Likert scale: 1-Results not achieved at all, 2-Results not achieved slightly, 3-Can’t say, 4-Result achieved slightly and 5-Result achieved very well. The data from the respondents are analysed and shown in Figure 3. The figures in the table are the mean values of the responses obtained. From Figure 3 it is seen that the implementation of SQFD produced better results in three areas. A paired ‘t’ test indicates that the overall impact of implementation of SQFD is significant.

6.0 FINDINGS AND DISCUSSIONS

The development and implementation of SQFD model for a new embedded system software product has been demonstrated through a case study. This approach can easily be generalized for many other software development products. It can be concluded that this method is feasible for defining, measuring, and improving the quality of software. QFD is a powerful tool in TQM and has, until recently, only been used in manufacturing and other engineering related industries. Currently all the quality tools including QFD are being applied to software development processes also. The following observations are made from the case study:

(i) From Fig 9, it is found that the most important technical requirement that affects customers’

quality is ‘image capture button & imaging’ and the second most important technical requirement

is ‘recording of image frame’. Sine these two have highest absolute importance rating of 220 and

178 respectively.

(ii) Similarly the most critical subsystem that affects design is ‘Procedure Recording subsystem’

and the second most critical subsystem is ‘User Interface subsystem’ (Fig 10).

(iii) The most suitable technology that affects design is ‘Prism+, pSOS’ and the second most

suitable technology is ‘Code Warrior’ (Fig 11).

(iv) The least important technical requirements are ‘Bolus wash variable on the doctors’ monitors

and the ‘Alarm Tones’ (Fig 9).

(v) The least critical subsystem is the ‘User Help Subsystem’ and the next least critical subsystem

is ‘Graphics subsystem’ (Fig 10).

(vi) The least suitable technology is the ‘SECSIMPro’ and the next least suitable technology is

‘Rational suite’ (Fig 11). Based on these findings it is recommended that the company should direct its efforts and resources to improve the quality of performance of the Images Capture button and the Imaging and Recording of Image Frames. Care should be taken in developing the ‘Procedure Recording’ and the ‘User Interface’ subsystems, as these are the most critical subsystems and a minor bug or defect may result in a

24

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

major quality loss. It is also clear that the developers can use the technologies such as ‘Prism+, pSOS’ and ‘Code Warrior’ for developing this particular embedded software product. It is suggested that the company fan afford to compromise on the technical requirements such as the ‘Bolus wash variable on the doctors’ monitor’ and the ‘Alarm Tones’ which have least importance. Further study is required to determine is this progression does indeed support the development of software to support business processes. Specific issues include;

(i)

Refinements to the deployment scheme use for SQFD

(ii)

The development of meaningful quantitative measures to evaluate the priority of requirements

(iii)

The development of quantitative measures to support trade-offs between implementation deployments

(iv)

Formal feedback mechanism to evaluate the level of improvement attained in meeting the support requirements of business processes.

(v)

Formal feedback mechanism to evaluate the benefits obtained by the organization after implementing the proposed SQFD model.

REFERENCES

1. Ammar H.H., Nikzadeh T. and Dugan J.B. (1997), ‘Petrinets: A methodology for risk assessment of function specification of software systems using colored’, Proceedings fourth international software metrics, pp. 108-117.

2. Georg Herzwurm, Gabriele Ahlemeier, Sixten Schockert and Werner Mellis (1998), ‘Success Factors of QFD Projects’, Proceedings of the World Innovation and Strategy Conference, Sydney, Australia, pp. 27-41.

3. Georg Herzwurm and Sixten Schockert. (2003), ‘The leading edge in QFD for software and electronic business’, International Journal of Quality and Reliability Management, Vol. 20, No. 1, pp. 36-55.

4. Georg Herzwurm, Sixten Schockert and M.Werner. 1995. Higher Customer Satisfactin with Prioritizing and Focused Software Quality Function Deployment. Transaction of the 7 th Symposium on QFD, QFD Institute, Novi, MI.

5. Glenn, H.M. 1983. Quality Function Deployment for a Medical Device. Sixth Annual IEEE Computer based Medical Systems Symposium.

6. He Z., Staples G., Ross M. and Court I. (1996), ‘Japanese quality tools in software process improvement’, The TQM Magazine, vol.8, No.4, pp. 40-44.

7. Joao, R., A. Perdro, and R. Ana. 2005. Software Requirements Negotiation using the software quality function deployment. Springer-Verlag, Vol 3706, pp.308-324.

8. John, M.N.2001. Competitive Manufacturing Management. Tata Mcgraw Hil.

9. John, K. 1999, Using Quality Function Deployment in Software Requirements Specification. Andersen Consulting and IDI.

10. Liu, F., K.Noguchi, A. Dhugana, and P.Inuganti. 2006. A quantitative approach for setting technical targets based on Impact Analysis in Software Quality Function Deployment (SQFD), Software Quaity Journal, Vol 14, No 2, June 2006, pp.113-134 (22).

11. Mekki I. Elboushi and Joseph S. Sherif (1997), ‘Object-Oriented Software design utilizing quality function deployment’, Journal of Systems Software, Vol.38, pp. 133-143.

12. Ohmori Akira (1993), ‘Software quality deployment approach: framework design, methodology and example’, Software Quality Journal. No. 3, pp. 209-240.

13. Pai, W.C.(2002). Quality-enhancing software function deployment model. Information Systems Management, pp.20-4.

14. Pedro, A., R.S.B.Macros, A.P.Jose, C.Luis. (2005). Analyzing Groupware Design by means of usability results. 9 th International Conference on Computer Supported Cooperative Work in Design (CSCWD 2005). Coventry, England, IEEE, Computer Society Press, May 2005.

25

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

15. Ronald G. Day (1996), ‘Quality Function Deployment: Linking a company with its customers’, Tata Mcgraw Hill.

16. Tan K.C., Xie M. and Chia E. (1998), ‘Quality function deployment and its use in designing information technology systems’, International Journal of Quality and Reliability Management, Vol. 15 No. 6, pp. 634-645.

17. Taeho Park and Kwang-Jac Kim (1998), ‘Determination of an optimal set of design requirements using house of quality’, Journal of Operations Management, Vol.16, pp. 569-581.

18. William D. Barnett and Raja M.K. (1995), ‘Application of QFD to the software development process’, International Journal of Quality and Reliability Management, Vol. 12, No. 6, pp. 24-42.

19. Yoji Akao (1997), ‘Quality function deployment: Integrating customer requirement into product design’, Productivity Press, pp. 329-339.

20. Yoji Akao and Glenn H. Mazur (2003), ‘The leading edge in QFD: Past, Present and Future’, International Journal of Quality and Reliability Management, Vol. 20 No.

FIG 1: SQFD AND GQM (Pai 2002)

S.No

 

SQFD PROCESS

 

SQFD WITH GQM

1.

Customer

requirements

are

solicited

and

Record

customer

recorded

requirements in report form.

2.

Requirements are converted to a measurable technical specification

Identify goals of the project

for user,

developer and

 

manager perspective

3.

Requirements are mapped to product specifications (with customer feedbacks) to create a correlation matrix

Ask questions derived from goals and measure against requirements reports

4

Requirements are prioritized by customer

 

Modify and reconfirm the improper requirements, then complete matrix.

5.

Priorities are determined by multiplying customer priorities with matrix

Priorities are determined by multiplying customer priorities with matrix.

26

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

FIG 2: Drawbacks about the existing SQFD Models

S.No

The Model

   

Drawbacks

 

1

The Erikkson and McFadden’s SQFD Model (William and Raja 1995)

Does

not

employ

the

House

of

Quality

(HOQ)

 

Developers are not able to explicitly examine the relationships between implementation deployments or the hows listed along the x- axis of the matrix

There is no statement of how the customer needs will be met

2.

Zultner’s SQFD Model (William and Raja 1995)

Does not use the conventional HOQ for its QFD matrices

Does not draw the connection between customer segments and the organizational processes

3.

Shindo’s SQFD Model (Georg and Schokert 2003)

Decomposes the customer requirements directly into functions and data and then into modules. Does not have any formal mechanism for determining the importance of the function.

4.

Ohmori’s

matrix-of-matrices

A total of 14 matrices are to be implemented which is very tedious and complex

SQFD

Model

(Georg

and

Schockert 2003)

 

5.

The Herzwurm & Schockert’s PriFo SQFD Model (Georg and Schockert 2003)

Covers only the first phase i.e product planning in the classic QFD and designing part is not dealt with.

 

27

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Fig 3: Impact of Implementation of SQFD

S.

Success Factors, Design Goals or Results Achieved

Before

After

no

Implementation

Implementation

1.

The technical specification appropriate products

3.85

3.9

2.

Development

several

product

3.625

3.5

components in parallel

3.

Reusability to other similar projects

 

3.825

4.15

4.

Systematic structured proceeding

 

3.5

4.25

5.

Constantness up to the delivery into production

3.6

3.575

6.

Objective product decisions

 

3.475

3.5

7.

Comprehensibleness

3.825

4.3

8.

Authentication for product decisions

3.3

3.475

9.

Adaptability at customer expectation changes

3.525

3.725

10.

Collection of the real customer requirements

 

3.8

4.275

11.

Prioritization of the customer requirements

 

3.3

4.125

12.

Adherence to planned development times

3.8

4.3

13.

Foresighted acting

3.5

3.625

14.

Function to co-operation

 

3.225

4.125

15.

Tuning of the department goals and decisions

 

3.55

3.6

16.

Communication satisfactory with technical personnel

3.925

4.125

17.

Communication satisfactory with users

 

3.725

4.325

18.

User requirements met

3.675

3.7

19.

Communication satisfactory with management

 

3.95

3.65

20.

Documentation consistent and complete

3.85

3.525

28

Importance

Customer

Importance

Customer

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Correlation Matrix Design or Technical Attributes
Volume 2, Issue 1, May - October (2011), © IAEME Correlation Matrix Design or Technical Attributes

Correlation Matrix

Design or Technical Attributes (Hows)

Target Values (How Much)

Technical Evaluation

Customer Needs

(What)

Relationships between Customer Needs and Design Attributes

Customer Perceptions Competitive
Customer
Perceptions
Competitive

Assessment

Attributes Customer Perceptions Competitive Assessment Importance Weighting Fig 4: Structure of House of Quality

Importance Weighting

Fig 4: Structure of House of Quality

Importance Weighting Fig 4: Structure of House of Quality Correlation Matrix Technical Requirements (Hows)
Importance Weighting Fig 4: Structure of House of Quality Correlation Matrix Technical Requirements (Hows)

Correlation Matrix

Technical Requirements

(Hows)

Organizational Difficulty

Absolute Importance

Relative Importance

Customer

Requirements

(Whats)

Relationship Matrix

Target Value

Fig 5: Proposed Software House of Quality (S-HOQ) Matrix

29

Priority Rating

Target Values

Priority Rating

Target Values

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Subsystems or Modules

Technical

Requirements

(Whats)

Relationship Matrix

Importance Rating

FIG 6: Proposed Subsystem or Module Deployment Matrix

Technologies

Technical

Requirements

(Whats)

Relationship Matrix

Importance Rating

FIG 7: Proposed Technology Deployment Matrix

30

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Brainstorming-3 Brainstorming-1 Voice of Customer Voice of Engineer table Brainstorming-4 Affinity Diagramming
Brainstorming-3
Brainstorming-1
Voice of Customer
Voice of Engineer
table
Brainstorming-4
Affinity
Diagramming
Customer
Requirements
Brainstorming -2
Technical
Requirements with
target value and
organizational
Brainstorming -6
Brainstorming -5
Customer importance
Relationship matrix
Correlation matrix
Validate , Weightage
Correlation matrix
Technical Requirements
Absolute and
relative importance
Customer
Requirements
Relationship Matrix
(Whats)
HOUSE OF
Target Value
Organizational Difficulty
QUALITY
MATRIX
Absolute Importance
Relative Importance
Brainstorming-8
Brainstorming-10
Normalization rating
Technical
requirement table
after deleting least
Subsystem or
module table
Technology table
Brainstorming -9
Brainstorming-11
Relationship matrix
Relationship matrix
Validate
Validate
Subsystem or Module
Technologies
Technical
Relationship Matrix
Technical
Requirements
Requirements
Relationship Matrix
SUBSYSTEM OR MODULE
DEPLOYMENT MATRIX
Importance Rating
TECHNOLOGY DEPLOYMENT
MATRIX
Importance Rating
Customer
Priority Rating
Importance
Target Values
Priority Rating
Target Values

FIG 8: Proposed SQFD Model

31

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME FIG 9:

FIG 9: HOQ for embedded Software

32

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME FIG 10: Subsystem

FIG 10: Subsystem or Module Deployment Matrix

33

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME FIG 11:

FIG 11: Technology Deployment Matrix

34

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

A B C D E F G 1 2 General Details 3 Name 4 Designation
A
B
C
D
E
F
G
1
2
General Details
3
Name
4
Designation
5
Years of Experience
6
E-Mail
7
8
Instructions
9
10
1. The actual outcome of the brainstorming is given in the work sheet "actual relation".
2. Give your response in the worksheet "agreement", whether you are agreeing with the
11
actual relations
12
3.
Also give your choice of the realtions in the third worksheet "choice"
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

FIG 12: S-HOQ Questionnaire - General

35

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

(IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October

36

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Figure 13: S-HOQ Questionnaire – Actual Relations

October (2011), © IAEME Figure 13: S-HOQ Questionnaire – Actual Relations Figure 14: S-HOQ Questionnaire- Agreement

Figure 14: S-HOQ Questionnaire- Agreement

37

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME Figure 15

Figure 15 : S-HOQ Questionnaire- Choice

38

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Figure 16 Subsystem or Module Deployment

Figure 16 Subsystem or Module Deployment Questionnaire- Actual Relations

39

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Figure 17: Subsystem or Module Deployment

Figure 17: Subsystem or Module Deployment Questionnaire- Agreement

40

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Figure 20: Subsystem or Module Deployment

Figure 20: Subsystem or Module Deployment Questionnaire - Choice

41

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Figure 19: Technology Deployment Questionnaire- Actual

Figure 19: Technology Deployment Questionnaire- Actual Relations

42

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

Volume 2, Issue 1, May - October (2011), © IAEME Figure 20: Technology Deployment Questionnaire- Agreement

Figure 20: Technology Deployment Questionnaire- Agreement

43

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME Figure 21: Technology Deployment Questionnaire

Figure 21: Technology Deployment Questionnaire - Choice

44

International Journal of Industrial Engineering Research and Development (IJIERD), ISSN 0976 – 6979(Print), ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME

ISSN 0976 – 6987(Online) Volume 2, Issue 1, May - October (2011), © IAEME Figure 22

Figure 22 : Success Factors Questionnaire

45