CHAPTER 6 QUALITY ASSURANCE MODELING FOR COMPONENT BASED SOFTWARE USING QFD

Transcription

1 81 CHAPTER 6 QUALITY ASSURANCE MODELING FOR COMPONENT BASED SOFTWARE USING QFD 6.1 INTRODUCTION Software quality is becoming increasingly important. Software is now used in many demanding application and also in safety critical systems. Software quality may be affected due to various reasons. However, software is ideally suited for many industrial applications because it does not wear out or deteriorate. Software based systems are so versatile, economical and reliable that they are now the common choice for almost all real time systems (Henry et al 2003). Hence, a proper software management system is needed and also it is very essential to assure the software quality in any software development for practical applications. In Component based software engineering, the total software system reliability depends on its component reliability. Reliable functioning of software system is paramount concern to the millions of users who depend on the software system everyday. Unfortunately most of the systems still fall short of user expectation of reliability (Horgan and Mathur 1996). So, software reliability is the end user view of software quality. If software reliability is poor, the total system performance will result serious injury to the system or significant property damage. The role of quality assurance is to ensure that the quality of procedures and processes resulting in a product that fully meets the user s requirements. Quality Function Deployment (QFD) is a

2 82 well-known planning methodology for translating user needs into relevant design requirements. To minimize the bugs in the software and also to manage the software development process, it is planned to apply the Software Quality Function Deployment (SQFD) technique in a systematic manner to manage the software development process. 6.2 FRAMEWORK FOR COMPONENT BASED SOFTWARE RELIABILITY ESTIMATION Various approaches are available for assessing the reliability of CBS. According to the past literature, most of the researchers are concentrating mainly on the individual component reliability. Only less numbers of models available to estimate the reliability of component based software system through component reliability which is explained in chapter 3. Actually, the CBS systems must satisfy not only logical functional requirements but also pare functional properties such as timeliness, quality of service and reliability. From literature survey, Dolbec s model is chosen to make a framework to identify the reliability of system Why Dolbec s Model? In the literature, Dolbec s model has considered the parameters of usage ratio and severity of the component. The component usage ratio represents the ratio of total component execution time over the total software system execution time. So this factor should be considered when the prediction of reliability of component based software system. Severity represents the impact of a single component in the whole software system. This factor is also very important in reliability prediction of component based systems. So, it is planned to include usage ratio and severity in the component based software system reliability assessment. As these parameters are considered in Dolbec s model and also comparing the factors of

3 83 simplicity, generality and applicability, amongst all the models given in literature review, this model is considered as favorable for this work Dolbec s Model for Reliability Estimation According to this model, it is assumed that the software system has m components and that the reliability of the individual components is known. A new definition of system unreliability (Q s ) is derived as Q s m m where m represents the number of components that are used during system execution, µ represents the usage ratio of component; β represents the failure of component. Q s m k 1 Q s is simplified to k k (6.1) Q s m k k 1 1 C k (6.2) where C k represents the component reliability and 1-C k is the unreliability of the component. Software system reliability R s is equal to R s = 1 - Q s R s m 1 k 1 k k (6.3) Equation (6.3) expresses software reliability in terms of the failure of the components and the usage ratio of each component.

4 Component Usage Ratio The component usage ratio weights the severity of the components reliabilities on the overall software system reliability. As a general rule the reliability of the component frequently executed is expected to have more severity on the overall system reliability than a component rarely executed. The component usage ratio is equal to t k k (6.4) T s t k - Total component execution time. T s - Total system execution time The system execution time can be easily obtained. The total component execution time describes the time spent executing instructions inside by a component. The value of the component usage ratio is 0 < µ k < 1. The total of all components usage ratios must be equal to 1 as indicated below. m k 1 1 k Component Severity Analysis The aim of the component severity analysis is to suggest where to allocate resources most effectively to improve the reliability of the software system. The following presents a severity analysis for the software system. The severity of each component on the overall system unreliability is determined by the following equation

5 85 S / Q (6.5) k k k s The severity of each component S k represents the impact of each component on the overall system unreliability. From equation (6.1) it can be seen that the addition of all µ k β k s produces the software system unreliability. Therefore dividing each µ k β k by the software system unreliability Q s gives the contribution or severity of each component on the software system unreliability. The greater the severity number, the greater the effect, the component has on the system unreliability. According to this Dolbec s model, improving the reliability of components with high severity values translate into the best improvement of software system reliability. The severity calculations can be verified by ensuring that the sum of all component severities is equal to 1. m S k k 1 1 This model is applied in ERP software which is explained in the following section. 6.3 RELIABILITY ANALYSIS OF ERP SOFTWARE In this section the proposed technique is applied to the case study of ERP software. It has six software components. They are Manufacturing Component (MC), Supply Chain Management (SCM) component, Financial Component (FC), Project Management Component (PMC),Human Resources Management (HRM) component, Customer Relationship Management (CRM) component. The following assumptions are made in the application of Dolbec s model. i) The component reliability for individual components is predicted using testing/inspection methods.

6 86 ii) iii) The components and also systems execution time are predicted using software testing techniques. Equation (6.4) is applied to compute the usage ratio for each component by measuring the component s execution time and total system execution time. Table 6.1 represents the reliability and usage ratio of the components of ERP. Table 6.1 Reliability and usage ratio of ERP software components Components (k) Component reliability (C k ) Probability of failure (β k ) Usage ratio (µ k ) Manufacturing component Supply chain management Financial component Project management component Human resources management Customer relationship management calculated a Using equation 6.1 the unreliability of the software system can be Q s = (0.28* * * * * *0.09) Q s =

7 87 Using equation (6.2) the reliability of ERP software is: R s = 1-Qs = R s = The severity of each component of ERP is presented in Table 6.2. Table 6.2 Severity of components Component (K) Severity of component (S k ) The severity of fourth component (Project management) is greater than other component severity values. Project management Component s severity gets 32% of the overall system. So the software system reliability will increase by improving the reliability of project management component. It is assumed that if the reliability of project management component is increased by 0.5%, the component unreliability is then and the system reliability is improved to as indicated below. R s = 1-Q s R s = = i.e %

8 88 From equation (6.5), the severity of project management component on over all system reliability is: S 4 = (0.385*0.28)/(0.3337) = The severity of project management component is diminished by the value which is obtained by subtracting the previous severity from the present severity value as given below: = ie 0.28% and there is an increase in system reliability which is obtained by subtracting the previous system reliability from the present system reliability as given below: = Component reliability for project management component is increased by 0.5% continuously and the effect of system reliability and severity of the component is analyzed. Table 6.3 shows the increase of system reliability and Table 6.4 shows the severity decrease of project management component.

9 89 Table 6.3 System reliability analysis Project management Component Reliability System Reliability Percentage of improvement Table 6.4 Severity analysis of project management component Project management Component Reliability Severity Percentage of severity decrease The project management component serves as the main routine for the working of ERP which performs the main activity management. This organizes and manages the resources to bring about the successful completion of the project. This component s usage is high compared to other components, since this component is used for accessing all the facilities available in ERP. Thus project management component plays an important role in ERP system. Increase in reliability of this component has changed the overall system reliability, as depicted in Figure 6.1.

10 90 Figure 6.1 Improvement of system reliability Figure 6.2 Severity analysis of project management component

11 91 The reliability of the project management component is increased by 0.5% continuously and the effect of system reliability and severity is analyzed. If the component reliability increases, the system reliability gets increased and severity gets decreased which is shown in Figures 6.1 and 6.2 respectively. A change in project management component reliability from 0.61 to increases the system reliability from 66% to 67% and decrease in severity of project management component from 32% to 31%. The result of Dolbec s model shows the reliability of total software system is increased to 67%. If high severity components reliability is improved the total system reliability will be improved significantly. Still to improve the system reliability to a very high level, it is needed for continuous improvement of the high severity components. To improve the components reliability the total design of the system itself should be redesigned to reduce the defects by giving importance to user requirements. So, it is decided to start the development process by changing the design by taking an analysis on the other quality attributes. This requires implementation of all activities in a systematic manner to fulfill the requirements for quality which is called as quality assurance in quality engineering field. 6.4 SOFTWARE QUALITY ASSURANCE - AN OVERVIEW The purpose of quality assurance is to fulfill the quality requirements of an entity, i.e. product or service, with adequate confidence by the supplier (Ramasamy 2006). In manufacturing, the difference between actual and observed defect values is usually very small because the measurement system is automated. In software, the measurement is usually done by a person. This leads to a large number of escaped defects. In a competitive and global business environment, it is certainly a distinct advantage to capture the genuine and major customer's requirements effectively by eliminating defects. To take advantage of this, the unique way

12 92 is to analyze customer's requirements systematically and to transform them into the appropriate product features properly. Total Quality Management (TQM) has emerged as an important aspect to assure the quality improvement in many organizations. Specifically, QFD, identified as the implementation vehicle of TQM, has been proposed as an effective approach for implementing quality improvement programs in a variety of product and service environments. QFD is a well-known planning methodology for translating customer needs into relevant design requirements. QFD helps to transform customer needs (Voice of the customer) into engineering characteristics for a product or service, prioritizing each product or service characteristic while simultaneously setting development targets for product or service. Management, in general, can be seen as the process of setting objectives for a system and then monitoring the system to see what its true performance is. Many tools and techniques are already used for quality assurance in software project management. It is already proved that the software quality improvement can be effectively done by implementing a systematic approach of quality management tools and techniques like quality circle, control charts, statistical quality tools and techniques, Kaizen and six sigma concepts etc. In this research part, it is planned to manage the software projects using QFD technique QFD Vs SQFD (Haag et al 1996) Total Quality Management (TQM) is a customer oriented management philosophy and strategy which is centered on quality so as to achieve customer delight. The tools and techniques used for quality improvement in manufacturing industries can be effectively used in software applications also (Parnas and Lawford 2003). QFD is a TQM tool that appeals

13 93 to improve the quality of the product. Basically, QFD is designed to improve customer satisfaction with the quality of one product and its services. QFD is a method to ensure quality by incorporating the customer requirements in the software product from the design, planning and development stages. It is an upstream process of determining the quality of design needed to satisfy the customer and at the same time improve the key points for quality assurance. Several attempts have been made to integrate QFD into software process improvement. But no one is concentrating on component based software quality improvement. So, to minimize the bugs in the component based software and also to manage the component based software development process, it is planned to apply the SQFD technique in a systematic manner to manage the software development process to improve the quality of the component software Details of SQFD Process The concept of SQFD originated in Japan, as did QFD. The methodological transfer of technology from QFD to SQFD first took place in 1984, when the Japanese began to explore its use in the development of embedded software. Four years later, Digital Equipment Corporation (DEC) announced that QFD was being utilized for software development. SQFD is a front-end requirements solicitation technique, adaptable to any software engineering methodology that quantifiably solicits and defines critical customer requirements. SQFD precedes the SDLC (System Development Life Cycle) process, allowing it to remain largely intact. As a front-end technique, SQFD is an adaptation of the A-1 matrix, the House of Quality, the most commonly used matrix in the traditional QFD methodology. Figure 6.3 provides an overview of the SQFD process, with the following steps (Haag et al 1996).

14 94 Step 1: Customer requirements are solicited and recorded in the initial step. The customers would include end users, managers, system development personnel, and any people who would benefit from the use of the proposed software product. The requirements are usually short statements recorded specifically in the customers terminology (e.g., easy to learn ) and are accompanied by a detailed definition, the SQFD version of a data dictionary. Step 2: In cooperation with the customers, the requirements are then converted to technical and measurable statements of the software product and recorded for further improvement. For example, easy to learn may be converted to time to complete the tutorial, number of icons, and number of online help facilities. It is important to note here that some customer requirements may be converted to multiple technical product specifications, making it crucial to have extensive user involvement. Additionally, the technical product specifications must be measurable in some form. The metrics used are usually numerically based, but may also be Boolean. For example, the customer requirement provides multiple print formats may be converted to number of print formats (using a numerically based metric) and does landscape printing (measured using Yes or No ). Step 3: The customers are then asked to complete the correlation matrix by identifying the strength of the relationships between the various customer requirements and the technical product specifications. For example, easy to learn is highly correlated to time to complete tutorial (a high correlation may receive a score of 9 in the correlation matrix) but not does landscape printing (which would receive a score of 0 in the correlation matrix). Because there are many customers involved in this process, it is important to gain consensus concerning the strength of relationships.

15 95 Step 4: Based on customer survey data, the requirement priorities for the stated customer requirements are developed and listed. Additional information may be gathered at this point from the customers concerning assessments of competitors software products. Data may also be gathered from the development team concerning sales and improvement indices. Step 5: This process involves developing the technical product specification priorities by summing the results of multiplying the customer requirement priorities by the correlation values between the customer requirements and the technical product specifications. These raw priority weights for the technical product specifications are then usually converted to a percentage of the total raw priority weights. Additional data may be solicited from the development team concerning targeted measures of the technical product specifications along with estimates of cost, difficulty, and schedule feasibility. The end result of the SQFD process will, at a minimum, contain measurable technical product specifications, their importance percentage, and targeted measures. This information is then carried forward as input to the SDLC process. The cited benefits of SQFD include: i) Fosters better attention to customers perspectives ii) iii) iv) Creates better communication among departments Provides decision justification Quantifies qualitative customer requirements v) Represents data to facilitate the use of metrics vi) vii) Facilitates cross-checking Avoids the loss of information viii) Reaches consensus of features quicker

16 96 ix) Reduces product definition interval x) Can be adapted to various software development life cycle methodologies Technical Product Specifications Customer Requirements Correlation Matrix Customer Requirement Priorities Cost Difficulty Index Schedule Feasibility Technical Product Specification Priorities Product Assessment Competitor Assessment Sales Index Improvement Index Figure 6.3 Basic SQFD Model It is significant that all software companies that utilize SQFD also use quality policies based on TQM in software development process. Additionally, all organizations had quality policies in place at the time of the introduction of SQFD. Therefore, the transfer of the quality technology (QFD to software development) should be applied after the implementation of the quality policies. 6.5 APPLICATION OF SQFD IN COTS SOFTWARE Several attempts have been made to integrate QFD into software development process. But this approach is a new attempt to apply SQFD technique in component based software development to integrate the customer requirements. This research approach develops a methodology which derives action plans based on customer requirements. In the first phase,

17 97 Voice Of Customer (VOC) is collected about the component based software. Then the affinity diagram is constructed based on the VOC. By giving the prioritization to the customer requirement, House of Quality is constructed and identified important parameters to be concentrated in the software development process to increase the quality. This directly results in the improvement of the organization process. The framework is designed in such a way that the requirements from a particular perspective are prioritized within perspectives. At the same time, each perspective carries its own priority. The requirements from multiple perspectives are correlated with each other. As a result, the priority value of each requirement is adjusted after their impacts of requirements from other perspectives are assessed. The case study of component based ERP system is used to illustrate the applicability of the proposed approach Voice of Customer The "voice of the customer" is a process used to capture the requirements/feedback from the customer (internal or external) to provide the customers with the best in class service/product quality. This process is all about being proactive and constantly innovative to capture the changing requirements of the customers with time. The "voice of the customer" is the term used to describe the stated and unstated needs or requirements of the customer. The voice of the customer can be captured in a variety of ways: Direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports, complaint logs, etc. This data is used to identify the quality attributes needed for a supplied component or material to incorporate in the process or product. Once a product plan is established which defines the target market and customers, the next step is to plan how to capture these customer's needs for each development project. This includes determining how to identify target

18 98 customers, which customers to contact in order to capture there needs, what mechanisms to use to collect their needs, and a schedule and estimate of resources to capture the voice of the customer (project plan for product definition phase). As opportunities are identified, appropriate techniques are used to capture the voice of the customer. The techniques used will depend on the nature of the customer relationship. So, the initial step in this process is to identify the right customer who involved in the application area of the component software. Then it is needed to record the customer s own word to create the list of customer requirement. The voice of customer is collected for component based ERP from the real customer and it is listed in Table 6.5. Once customer needs are gathered, they then have to be organized. The mass of interview notes, requirements documents, market research, and customer data needs to be distilled into a handful of statements that express key customer needs. Affinity diagramming is a useful tool to assist this effort. Brief statements which capture key customer needs are transcribed onto cards. A data dictionary which describes these statements of need is prepared to avoid any mis-interpretation. These cards are organized into logical groupings or related needs. This will make it easier to identify any redundancy and serves as a basis for organizing the customer needs. In addition to "stated" or "spoken" customer needs, "unstated" or "unspoken" needs or opportunities should be identified. Needs that are assumed by customers and, therefore not verbalized, can be identified through preparation of a function tree. Excitement opportunities (new capabilities or unspoken needs that will cause customer excitement) are identified through the voice of the engineer, marketing, or customer support representatives. These can also be identified by observing customers use or maintain products and recognizing opportunities for improvement.

19 99 Table 6.5 Voice of customer (verbal and written data) 1 Add new functionality with minimum effort 2 Adopt portability rules from internal document 3 Alert that new functionality is available 4 Application of new formula 5 Balance sheet preparations 6 Budget requirement & allocation details 7 Clear definition of modification 8 Complete transaction cycle without execution errors 9 Continue operation if data not available. 10 Data must look same in every printer 11 Demand & delivery dates 12 Detailed contingency plan 13 Details of Accepted/Rejected component details 14 Details of all department 15 Export data to MS Excel, PDF and other software packages. 16 Facilitate data access in every screen 17 Final status for new project 18 Integration of various formula for pension, PF related calculations 19 List of materials 20 Manpower availability & requirement 21 Organize items logically in screen 22 Provide adequate training 23 Provide online help 24 Purchase order & delivery details 25 Recover operations completed before a power failure 26 Requirement of components 27 Skill level 28 Status of finished & semi-finished goods 29 Stock of raw materials 30 Training details 31 Use secondary server if main server fails

20 Affinity Diagram Affinity diagram is a QFD tool used to organize a lot of qualitative data. Generally, it is a tool used to organize and present large amounts of data (ideas, issues, solutions, problems) into logical categories based on user perceived relationships and conceptual frame working. It is used to organize verbal and pictorial data consisting of facts, opinions and experience into natural clusters that bring out the latent structure of the problem under study. Frequently, the input into an affinity diagram is the output of a brainstorming session. In the initial process, the team leader transfers all ideas generated from brainstorming session for recording in cards. The important and valid points in customer requirement record is refined, sorted and constructed as affinity diagram. This is one of the important qualitative tool among the seven management tools which are used in Total Quality Management. The affinity diagram for ERP software is shown in Figure 6.4. MANUFACTURING COMPONENT List of materials Status of Finished & Semi-Finished Goods Details of Accepted/Rejected component details SUPPLY CHAIN MANAGEMENT COMPONENT Stock of raw materials Requirement of components Purchase order & delivery details MAINTENANCE Facilitate data access in every screen Data must look same in every printer Add new functionality with min effort RELIABILITY Complete transaction cycle without execution errors Use secondary server if main server fails Recover operations completed before a power failure Figure 6.4 Affinity diagram

21 101 HUMAN RESOURCE MANAGEMENT COMPONENT Manpower availability & Requirement Skill level Training details PROJECT MANAGEMENT COMPONENT Demand & delivery dates Details of all department PORTABILITY Export data to Excel, PDF and other software packages. Adopt portability rules from internal doc. USABILITY Organize items logically in screen Provide online help Alert that new functionality is available Provide adequate training FINANCIAL MANAGEMENT FUNCTIONALITY COMPONENT Budget requirement & allocation details List of materials Final status for new project Details of Accepted & Rejected components Balance sheet preparations Stock of materials Requirement of components Demand and delivery dates Balance sheet preparation Figure 6.4 (Continued) Kano model The Kano Model of Customer Satisfaction classifies product attributes based on how they are perceived by customers and their effect on customer satisfaction. These classifications are useful for guiding design decisions in that they indicate when good is good enough, and when more is better. The Kano Model of customer satisfaction divides product attributes into three categories: threshold, performance and excitement. A competitive

22 102 product meets basic attributes, maximizes performances attributes, and includes as many excitement attributes as possible at a cost the market can bear Basic attributes Basic (Threshold) attributes are the expected attributes or musts of a product, and do not provide an opportunity for product differentiation. Increasing the performance of these attributes provides diminishing returns in terms of customer satisfaction, however the absence or poor performance of these attributes results in customer dissatisfaction Performance attributes Performance attributes are those for which more is generally better, and will improve customer satisfaction. Conversely, an absence or weak performance attribute reduces customer satisfaction. These attributes will form the weighted needs against which product concepts will be evaluated. The price for which customer is willing to pay for a product is closely tied to performance attributes Excitement attributes Excitement attributes are unspoken and unexpected by the customer. When these attributes are properly addressed, customer would be delighted. Excitement attributes often satisfy latent needs real needs of which customers are currently unaware. In a competitive marketplace where manufacturers products provide similar performance, providing excitement attributes that address unknown needs can provide a competitive advantage.

23 Other attributes Products often have attributes that cannot be classified according to the Kano Model. These attributes are often of little or no consequence to the customer, and do not factor into consumer decisions. A relatively simple approach to applying the Kano Model Analysis is to ask customers two simple questions for each attribute: i) Rate your satisfaction if the product has this attribute?; and ii) Rate your satisfaction if the product did not have this attribute? The information obtained from the Kano Model Analysis, specifically regarding Performance and excitement attributes, provides valuable input for the Quality Function Deployment process. By considering theses attributes, the kano model is prepared for ERP software which is shown in Figure 6.5.

24 104 Figure 6.5 Kano Model for ERP software House of Quality SQFD uses a matrix format to capture a number of issues that are vital to the planning process. The House of Quality Matrix is the most recognized and widely used form of this method. It translates customer requirements, based on marketing research and benchmarking data, into an appropriate number of engineering targets to be met by a new product design. Basically, it is the nerve center and the engine that drives the entire SQFD process The House of Quality is the first matrix in a four-phase SQFD process. Four phases are: product planning, parts deployment, process planning and production planning. It's called the House of Quality because of the correlation matrix that is roof shaped and sits on top of the main body of

25 105 the matrix. The correlation matrix evaluates how the defined product specifications optimize or sub-optimize each other. Each requirement quantification is done by building the House of Quality. The quantification is done according to the relationship between the requirements and also the correlation between the requirements. The quantification is done using the 10 point scale in this process. In building house of quality, the relationship between the quality attributes and components are classified into three categories. They are i) strong (H) ii) medium(m) iii) weak (L) and the score value allotted based on the strength of H,M,L is 9, 3, 1 respectively. Then, the target direction is taken according to the components information requirements with regards to ERP software. This is classified in this research as more is better, less is better and specific amount. Then the correlation between the components (interaction of the software components) are considered in terms of strong + ve, + ve, - ve and strong - ve. The most demanded quality attributes are considered and allotted the weight value according to the customer opinion. Here, functionality, reliability, usability, maintenance and portability factors are considered and the weight value of 5,5,3,3,3 have been allotted respectively. According to these information ERP software components are analyzed and then, it is build the house of quality to identify the most important component and quality attributes and to find the importance in building the software. The house of quality result for component based ERP software is shown in Figure 6.6.

26 Figure 6.6 House of Quality 106

27 RESULTS AND DISCUSSION According to the application of SQFD, customer requirements are converted to design parameters such as technical attributes and component attributes. The score value of quality attributes as per the House of Quality is shown in Figure Score value Functionality Reliability Usability Maintenance Portability Figure 6.7 Score value of quality attributes as per house of quality In this case study the parameters of functionality, usability and reliability play a major role in increasing the quality of component based ERP software. The normalized percentage contribution of the quality attributes in component based software is given as follows: Functionality % Reliability % Usability % Maintenance - 6.8% Portability - 5.6%

28 108 This means that based on customer importance, expert opinion, and company vision, 38.1% of the design focus should be in the area of functionality and 27.6% on usability to improve the quality which is in top priority. So, it is required to emphasize on these parameters in the early phase of design for quality improvement. In House of Quality, one of the sub components of manufacturing component (MC) i.e list of materials component has top priority in column wise. So, it is needed to prepare this component with high quality attributes. By considering the important design parameters (functionality and usability) based on the outcome of SQFD, the software is redeveloped. By concentrating on the sub attributes of functionality like suitability, accuracy, interoperability, compliance and security the degree to which the software satisfies stated needs is increased. Similarly the sub attributes of usability are understandability, learnabiltiy, operability. The degree to which the software is easy to use is increased by improving these attributes. Once again the component reliability is measured to predict the system reliability using the Dolbec s reliability model which is given in Table 6.6. Table 6.6 Reliability and usage ratio after applying SQFD in ERP Components (k) Component reliability (C k ) Probability of failure (β k ) Usage ratio (µ k ) Manufacturing component Supply chain management Financial component Project management component Human resources management Customer relationship management

29 109 calculated a Using equation (6.1) the unreliability of the software system can be Q s = (0.17* * * * * *0.09) Q s = 0.12 Using equation (6.2) the reliability of ERP software is: R s = 1-Qs = R s = 0.88 The reliability after applying SQFD is considerably improved from 67% to 88%. It means that other quality parameters are improved automatically when functionality and usability are improved. This shows that SQFD can be used for continuous improvement of quality to maintain policies, procedures and standards of a software and also in component based software. 6.7 CONCLUSION Literature on software quality measurement and improvement dates back to the inception of computers. Many of the earlier researchers stressed on quality assurance activities. The application of quality improvement tools in products and processes is the one way of improving and assuring the quality. So, in this research approach, it is tried by applying SQFD in component based ERP software design. QFD has achieved remarkable popularity around the world in a wide variety of software, hardware and service products. This is due to its systematic linking of customer requirements to and throughout the entire design, development and

30 110 implementation process. As customer requirements and technological advancements rapidly change, it is necessary to assure that customer satisfaction is achieved in the quickest, least costly and most efficient way. This is addressed in this work and also it is proved by improving the total system reliability of ERP software.