sqfd-model

Document Sample
sqfd-model Powered By Docstoc
					 International Journal of of Industrial Engineering and Development (IJIERD), ISSN 0976
International Journal Industrial Engineering Research Research                                 –
and Development (IJIERD), ISSN 0976 Issue 1, May - October (2011), © IAEME
 6979(Print), ISSN 0976 – 6987(Online) Volume 2,
                                                 – 6979(Print)               IJIERD
ISSN 0976 – 6987(Online) Volume 2
Issue 1, May – October (2011), pp. 15-45
                                                                    ©IAEME
© 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 ith customer requirement (CR) and jth 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

                        m

                AIj =   ∑ CIi * Rij              ……………………(1)

                        i=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

           AIj is Absolute Importance of TRj, j = 1,...,n
           CIi    is     Customer       Importance     i.e.,   importance     rating    of    CRi,
                  i = 1,...,m
           Rij is Relationship rating representing the strength of the relationship between CRi and
           TRj.
(ix) Relative Importance: The absolute importance rating can then be transformed into the
Relative Importance rating, RIj, as
                                 AIj

                        RIj =             ………………………………… (2)

                                         n

                                ∑ AIk

                                k=1

            The larger the RIj, the more important is TRj. 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 ith Technical requirement (TR) and jth 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




                            m

                    IRj = ∑ NIi * Rij         …………………. (3)

                            I=1

where

               IRj is Importance Rating of SSj, j = 1,...,n

               NIi is Normalized Importance of TRi, i = 1,...,m

              Rij is Relationship rating representing the strength of the relationship between TRi and
SSj

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 AIj 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’
and strong relationship with ‘printing images during and after procedures’.. Thus the column
weight for the first column is computed as (9X9) + (7X1) + (9X9) = 169.

(ix) Relative Importance: The Relative Importance (RIj) 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 7th
          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. 9th 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 Identify goals of the project
           technical specification                                   for     user,    developer      and
                                                                     manager perspective

3.         Requirements        are     mapped       to    product Ask questions derived from
           specifications (with customer feedbacks) to goals and measure against
           create a correlation matrix                               requirements reports

4          Requirements are prioritized by customer                  Modify and reconfirm the
                                                                     improper requirements, then
                                                                     complete matrix.

5.         Priorities are determined by multiplying Priorities are determined by
           customer priorities with matrix                           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         •    Does not employ the House of Quality
         SQFD Model (William and                  (HOQ)
         Raja 1995)
                                             •    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      •    Does not use the conventional HOQ for its
         (William and Raja 1995)                  QFD matrices

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

3.       Shindo’s SQFD Model (Georg          •    Decomposes      the    customer    requirements
         and Schokert 2003)                       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
         SQFD    Model      (Georg   and          which is very tedious and complex
         Schockert 2003)

5.       The Herzwurm & Schockert’s          •    Covers only the first phase i.e product
         PriFo SQFD Model (Georg                  planning in the classic QFD and designing
         and Schockert 2003)                      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          Before                After
 no                    Achieved                       Implementation       Implementation
 1.    The technical specification appropriate               3.85                 3.9
       products
 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                  3.6                 3.575
       production
 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                 3.525                3.725
       changes
 10. Collection of the real customer                         3.8                 4.275
     requirements
 11. Prioritization of the customer                          3.3                 4.125
     requirements
 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                      3.55                 3.6
     decisions
 16.   Communication satisfactory with technical            3.925                4.125
       personnel
 17.   Communication satisfactory with users                3.725                4.325


 18.   User requirements met                                3.675                 3.7
 19.   Communication satisfactory with                       3.95                3.65
       management
 20.   Documentation consistent and complete                 3.85                3.525

                                               28
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




                                                        Correlation Matrix
                                                       Design or Technical
                                                            Attributes (Hows)

                                                                                         Customer




                                  Importance
                                   Customer
                                                                                         Perceptions
               Customer Needs                     Relationships between
                   (What)                       Customer Needs and Design
                                                        Attributes
                                                     Importance Weighting
                                                 Target Values (How Much)                    Competitive
                                                      Technical Evaluation                   Assessment
                                                          Importance




                           Fig 4: Structure of House of Quality




                                                                   Correlation Matrix
                                                                 Technical Requirements

                                                                         (Hows)
                                               Importance
                                                Customer




                        Customer
                      Requirements
                                                                   Relationship Matrix
                         (Whats)
                                                                      Target Value
                                                                 Organizational Difficulty
                                                                  Absolute Importance
                                                                   Relative Importance



            Fig 5: Proposed Software House of Quality (S-HOQ) Matrix
                                                            29
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




                                      Priority Rating
                                                                      Target Values
                       Technical
                     Requirements
                        (Whats)                                                                    Relationship Matrix

                                                                                                    Importance Rating



          FIG 6: Proposed Subsystem or Module Deployment Matrix


                                                                                                        Technologies
                                                    Priority Rating
                                                                                  Target Values




                         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 Engineer
         Voice of Customer                                                                                      table
                                                                                                                                                 Brainstorming-4
                      Affinity
                   Diagramming
             Customer                                                                                         Technical
           Requirements                                                                                  Requirements with
                     Brainstorming -2                                                                     target value and
                                                                                                           organizational
                                                                                Brainstorming -5              difficulty                          Brainstorming -6

         Customer importance
                                                                                         Relationship matrix

                                                                                             Validate , Weightage                                Correlation matrix



                                                                    Correlation matrix
                                                                 Technical Requirements
                                                                                                    Absolute and
                                                                                                    relative importance
                                                                                                    calculation
                        Importance
                         Customer




           Customer
         Requirements
            (Whats)                                                Relationship Matrix

                 HOUSE OF                                             Target Value
                  QUALITY                                        Organizational Difficulty
                  MATRIX                                          Absolute Importance
                                                                  Relative Importance                  Brainstorming-8                                              Brainstorming-10
       Normalization rating


                   Technical                                                                            Subsystem or
              requirement table                                                                         module table
                                                                                                                                                                      Technology table
              after deleting least                                              Brainstorming -9
                                                                                                                           Brainstorming-11
                important ones


                                                                              Relationship matrix
                                                                                                                          Relationship matrix

                                                                         Validate                                                                                  Validate

                                                                    Subsystem or Module                                                                                Technologies
                               Priority Rating

                                                 Target Values




                                                                                                                               Priority Rating

                                                                                                                                                   Target Values




              Technical                                              Relationship Matrix                         Technical
            Requirements                                                                                       Requirements
                                                                                                                                                                    Relationship Matrix
          SUBSYSTEM OR MODULE                                        Importance Rating                     TECHNOLOGY DEPLOYMENT                                    Importance Rating
           DEPLOYMENT MATRIX                                                                                      MATRIX


                                                                     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




                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




                 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




                      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
   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




                                             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




                    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




                       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




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




   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




      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




       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




          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




            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




                      Figure 22 : Success Factors Questionnaire




                                             45

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:14
posted:11/16/2012
language:
pages:31