Comparison of Software Quality Models: An Analytical Approach

Comparison of Software Quality Models: An Analytical Approach Sanjay Kumar Dubey 1, Soumi Ghosh 2, Prof. (Dr.) Ajay Rana 3 1 Amity University, Sec-125, NOIDA, India 2 Amity University, Sec-125, NOIDA, India 3 Amity University, Sec-125, NOIDA, India 1 skdubey1@amity.edu 2 soumi1069@rediffmail.com 3 ajay_rana@amity.edu Abstract With the objective of presenting qualitative software system most of the software producers have endeavoured and infact this is their main purpose. Software quality is having multi-dimensional content which may be distinguished and measured easily. To be specific, with the idea of determining the multidimensional content in a more exact pattern various qualitative models have been presented by virtue of which different aspects of this matter have been attempted to be investigated properly. Practically as because there are existences of different models which have used different expressions the comprehension of this basic content have become to some extent hard or difficult. Attempts have been made in this particular paper to introduce some models that have been mentioned and more clearly analysis the qualitative characteristics and side-by-side determine the software quality along with the analytical comparison of these models. This paper may serve the purpose of a reference for investigating software quality and its related models. Keywords Quality, Models, Analysis, System I. INTRODUCTION Software quality plays an important role in success of the overall software system. So it is considered as a very important aspect for the developers, users and project managers. Software quality is the extent to which an industry-defined set of desirable features are incorporated into a product so as to enhance its lifetime performance [11]. For any software system there must be following three specifications such as functional specification (what system is to do), quality specification (how well the functions are to operate), resource specification (how much is to be spent on the system). Quality comprises all characteristics and significant features of a product or an activity which relate to the satisfying of given requirements (German Industry Standard DIN 55350 Part 11). Quality is the total of features and characteristics of a product or a service that bears on its ability to satisfy the given needs (ANSI/ASQC A3/1978). Software quality has been categorized into two parts by Deutsch et al. [8] as software procedure quality and software product quality. Software engineering related elements like technology, tools, people, organisation and equipment were used in software procedure quality. However, software product quality consists of certain aspects like document clarity and integrity, design trace-ability, program reliability and test integrity as its basic characteristics. A quality model is usually defined as a set of characteristics and relationships between them which actually provide the basis for specifying the requirements of quality and evaluating quality [20]. It is also defined as a structured set of properties that are needed for an object of a class to meet defined purposes [12]. The benefit of quality model is given by decomposition of valuable object like process, product or organisation in the list of its characteristic/subcharacteristics measures. It is applicable for predicting, assuring and verifying the achievement of a defined goal. Quality, apart from describing and measuring the functional aspects of software also describes the extra functional properties such as how system is built and how it performs. This paper describes various quality models and their analytical comparison, determines software qualification and its qualitative characteristics more clearly. Different software quality models were proposed for software applications by various researchers. The ISO/IEC 9126-1[18] model which actually incorporates the findings of various other models i.e. Mc Call[31], Boehm[4], Dromey[9] etc. has been considered as the most prominent model and this has been widely accepted and recognised as a basic model in field of industry and research. 111

II. LITERATURE SURVEY The requirement to establish a quality model has been felt by users for the purpose of evaluating the software quality quantitatively and qualitatively. The quality models which are present nowadays are most hierarchical models based on quality criteria and associated metrics. All such models are categorized into three kinds according to the means by which these models have been generated. First one is the theoretical model based on the hypothesis relations among variables. Second one is the data-driven which are based on statistical analysis. Third is the combined model in which intuitions are used to determine the basic type of the model and data analysis is used to determine the constants of the model. Practically in most of the cases the combined model is adapted. A. Mc Call Model: The first quality model was proposed by Mc Call J. A. [31]. The proposal of the model was basically meant to design a complete layout the products quality through its various characteristics. The quality of software has been categorized in three different parts in this model namely Product Revision (maintainability, flexibility and testability, which contribute to product revision), Product Operation (correctness, reliability, efficiency, integrity and usability contribute to product operation) and Product Transition (portability, reusability and interoperability which contribute to product transition). B. Boehm Model: Boehm s [4] quality model presents the characteristics of software on a larger scale as compare to Mc Call s model. In this model As-Is-Utility describes how easily, reliably and efficiently software product can be used, maintainability describes how easily modified and retest the software product, and portability describes how the software product can be used even when environment has been changed. Software Quality Integrity Correctness Flexibility Reusability Interoperability Traceability Completeness Consistency Error Tolerance Execution Access control Access Audit Operability Training Communicativeness Simplicity Conciseness Instrumentation Self descriptiveness Expandability Generality Modularity Software System Independence Machine independence Communications Commonality Data Commonality Figure i. Mc Call s Software Quality Model C. FURPS Model: FURPS model [15] proposed by Grady B. R. and Hewlett Packard Co. categorized characteristics into two different requirements such as Functional Requirements (F) which is defined by expected input & output and Non Functional Requirements in which U stands for (includes human factors, aesthetic, documentation of user and material of training), R stands for (includes frequency and severity of failure, recovery to failure, time among failure), P stands for Performance (includes functional requirements) and S stands for Supportability (includes backup, requisite of design, implementation, interface and physiosts). 112 D. Ghezzi Model: Ghezzi C. et al. [14] state that internal qualities deal with the structure of software which helps the software developers to achieve those external qualities for which software users care a lot and also provided both the internal and external qualities of software which are, Flexibility, Integrity,,,, Reusability and.

Device Independence Self containedness Functionality Joint of characteristics Capacities Integrity Security Software Quality As Is- Utility Human Engineering Accountability Accessibility Communicativeness Structured-ness Human Factors Aesthetic Documentation of the user Material of training Frequency and severity of failures Self descriptiveness Accountability Recovery to failures Time among failures Velocity Accessibility Communicativene ss Performance Availability Time of answers Legibility Time of Recovery Understandabili ty Conciseness Structuredness Utilization of resources Self descriptiveness Extensibility Adaptability Modifiability Structurednes Augmentability Supportability Compatibility Configurability E. IEEE Model: Figure ii. Boehm s Quality Model IEEE [17] is basically standard for software maintenance to provide a qualitative model. In this standard an iterative process for management and execution of software maintenance activities has been described. Other standards like software quality assurance, verification and validation, software configuration management in which associated processes (external processes) are defined. This model shows various measurement ways of qualitative factors and represents factors such as, Functionality,,, and. F. Dromey s Quality Model: Dromey G. R. [9] quality model is based on evaluation criteria. In other words, it aims at evaluating the quality of the product when each software product has different quality then the other. Serviceability Installability Localizability Figure iii. FURPS Model This model helps in predicting defects and indicates the properties that were violated in order to create defects. This model is designed on the relationship between quality attributes and sub-attributes between software properties and software quality attributes. G. SATC s Quality Model: Software Assurance Technology Center (SATC) Hyatt L. E. et al. [16] which is engaged for NASA with the objective of improving the software quality is actually helping the software managers in establishing metrics programs which may meet their basic needs with minimum 113

Integrity Temporal Resource Non deficiency Qualities Error tolerance Availability Completeness Flexibility Reusability Functionality Security Compatibility Figure iv. Ghezzi Model Interoperability costs and it is also interpreting the resulting metrics in the context of the supported projects. The SATC helps in defining and testing a quality model for software by using the results of these metric programs and discussions with the projects as its basis. The SATC s quality model defines a set of goals related to the software product and process attributes following the structure of the ISO 9126-1 software quality model. H. ISO 9126-1 Quality Model: ISO 9126-1 [18] quality model has two main parts consisting of Internal and External Quality Attributes and Quality in Use Attributes. The Internal quality attributes refers to the properties of the system that can be evaluated without executing it while External quality attributes refers to the system properties that may be evaluated by observing the system during its execution. The quality in use attributes refers to the properties of the system that are experienced by the users of the system when the system is in operable condition and also during its maintenance. The characteristics of this model are, Functionality,,, and. I. QMOOD: Bansiya et al. [3] proposed a hierarchical Quality Model for Object-Oriented Design (QMOOD) which extends Dromey s quality model methodology and involves four levels as follows: Supportability Extensibility Correctability Hardware Independency Software Independency Installability Reusability Comprehensibility Ease of Learning Communicativeness Figure v. IEEE Model i. Identifying design quality characteristics:-the set of design quality attributes that were used in QMOOD to describe the characteristics of object-oriented systems are functionality, effectiveness, understand-ability, extendibility, reusability and flexibility. ii. Identifying object-oriented design properties:-design properties can be determined by examining the internal and external structure, functionality of design components, attributes, methods and classes. 114

Correctness Internal Functionality,,, Suitability Implementation Contextual Descriptive, Reusability,, Functionality Interoperability Security, Reusability,, Maturity Figure vi. Dromey s Quality Model The structural and object-oriented set of design properties that were used in QMOOD are design size, hierarchies, abstraction, encapsulation, coupling, cohesion, composition, inheritance, polymorphism messaging, complexity. iii. Identifying object-oriented design metrics:-the various object-oriented design metrics are design size in classes (DSC), Number of Hierarchies (NOH), Average Number of Ancestors (ANA), Data Access Metric (DAM), Direct Class Coupling (DCC), Cohesion among Methods of class (CAM), Measure of Aggregation (MOA), Measure of functional Abstraction (MFA), Number of Polymorphic methods (NOP), Class Interface Size (CIS), Number of Methods (NOM). iv. Identifying object-oriented design properties:-the design components were identified to determine the architecture of object-oriented designs such as objects, classes, generalization-specialization structures, class hierarchies. This model identified the paradigm (e.g. polymorphism, inheritance, data abstraction etc.) and also introduces a set of new object-oriented metrics. Fault Tolerance Recoverability Understand ability Learnability Operability Time behavior Resource Behavior Analyzability Changeability Stability Compliance Adaptability Install ability Conformance Replace ability J. Other Quality Models: Kazman et al. [25] model presented two different thoughts regarding the quality characteristics during the software existence cycle. These qualitative characteristics can be summarized as follows: i) efficiency, security, availability and function; ii) modifiability, portability, reusability, inheritability and testability. Figure vii. ISO 9126-1 Quality Model A quality model Khosravi K. et al. [28] process consists of two tasks i.e. i) choose a super-characteristic and ii) choose and organize characteristics related to super characteristic. This quality model is constructed based on software reusability as super-characteristics and focus on reusability, understandability, flexibility, modularity, robustness, scalability, usability. 115

This model organized quality characteristics and subcharacteristics using the definitions from IEEE, ISO/IEC and several other software quality models. In order to evaluate software quality by means of integrating the fuzzy theory and AHP (Analytic Hierarchy Process) the guidelines were provided by Chang et al. [7] and this quality assessment approach was applied on ISO 9126-1 quality model. The software quality evaluations were based on the characteristics and sub-characteristics of ISO 9126-1 model. A component based software development quality model was proposed by Sharma A. et al. [34] which include the entire characteristics and sub-characteristics of ISO 9126-1 quality model. It also comprises of new proposed subcharacteristics i.e. re-usability, flexibility, complexity, track ability, scalability. Analytic Hierarchy Process (AHP) was used in order to evaluate overall quality component. Khomh F. et al. [27] proposed a method DEQUALITE (Design Enhanced Quality Evaluation) to build a quality model to measure the quality of object-oriented systems with the help of their internal attributes and their designs and measure system by analyzing the impact of design patterns, antipatterns, and code smells on different software quality characteristics. An Aspect-Oriented Software Quality Model (AOSQUAMO) was proposed by Kumar et al. [30] which was an extension of ISO 9126-1 software quality model. This model has also included four new sub-characteristics i.e. modularity, code-reusability, complexity and reusability in addition to original characteristics and subcharacteristics of ISO 9126-1 quality model. A UML conceptual model REASQ (Requirements, Aspects and Software Quality) was developed by Castillo I. et al. [6] to clarify the AOSD (Aspect-Oriented Software Development) terminology i.e. aspect, composition, (functional, non-functional, cross-cutting) concern, (functional, non-functional) quality or (inherent, assigned) property requirements for the software product. Comparing REASQ model, ISO 9126-1 (2007) is used to relate the requirement engineering terminology with the aspectorientation and software quality. Sehra S. K. et al. [33] developed a model based on PSO (Particle Swarm Optimization), a computational method aimed at optimizing a problem through improvement of a solution in regard to a given measure of quality. This method is actually a refinement of the fuzzy estimates meant for the development of software projects and it gives nearly the same results like different basic models. III. LAYERED APPROACH OF QUALITY MODELS The quality models constitute layered approach (Table I). The number of layers may be. 2 (Mc Call and Boehm) or 3 layers (include metric). In Table I, 1:n relationships show that every characteristics has its own subcharacteristics (as in ISO 9126-1 model) and n:m relationships show that every characteristic is linked to one or more characteristics (as in Mc Call Factor-Criteria Model (FCM)). In summary, various characteristics affect the quality models that are represented in Table II. The comparative analysis of characteristics of various software quality models is also given in Table III. IV. CONCLUSION This is a comprehensive study to enumerate different characteristics of various software qualitative models and estimate their comparative viability. It is considered that successful completion of this study will definitely help the users to understand the quality factors properly. It will also help estimation of software quality, identification and definitions of the quality criteria in desired manner. Users will also be able to realize the importance and role of the quality models in estimating software quality. Simultaneously, the different models which have been used to evaluate the quality will be analyzed properly. 116

TABLE I. LAYERED APPROACH OF QUALITY MODELS Layer Mc- Call [31] Boehm [4] 1 Factor High Level characteristic FURPS [15] Ghezzi et al. [14] IEEE [17] Dromey [9] ISO-9126-1 [18] Kazman [25] Khosravi K. et al. [28] Characteristics Characteristics Factor Attribute Characteristic Characteristics Super- Characteristics 2 Criteria Primitive characteristic Sub - characteristic Subcharacteristics Subcharacteristics Subfactor Subattribute Subcharacteristics Subcharacteristics 3 n:m n:m 1:n 1:n 1:n n:m 1:n 1:n n:m TABLE II. CHARACTERISTICS DEFINITION Characteristics Definitions Ref. The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [18] Availability The degree to which a work is operational and available for use as a product or to users [10] Changeability The characterization of the amount of effort to change a system. [23] Correctness The ease with which minor defects can be corrected between major releases while the application or component is in use by [10] its users. The capability of the software product to provide appropriate performance, relative to the amount of resources used [18] understated conditions. Flexibility The effort required modifying an operational program. [13] Functionality The capability of the software product to provide functions meet stated and implied needs when the software is under [18] specified conditions. Interface facility The degree to which two software products can be connected successfully. [10] Integrity The extent to which access to software or data by unauthorized persons can be controlled. [13] Interoperability The capability of the software product to interact with one or more specified systems. [18] The capability of the software product to be modified. [18] Modifiability Corrections, improvements or adaptations of the software to changes in environment and in requirements and functional [18] specifications. Performance The degree to which timing characteristics are adequate. [10] The capability of the software product to be transferred from one environment to another. [18] The capability of the software product to maintain a specified level of performance when used under specified conditions. [18] Reusability The ease with which an existing application or component can be reused. [10] Robustness The degree to which an executable work product continues to function properly under abnormal conditions or [10] circumstances. Scalability The ease with which an application or component can be modified to expand its existing capabilities. [10] Supportability The ability to extend the program, adaptability and serviceability, in addition to testability, computability, configurability, the ease with which a system can be installed and the ease with which problems can be localized. [32] The capability of the software product to enable modified software to be validated. [18] Transferability The cost of transferring a product from its hardware or operational environment to another. [10] Understandability The capability of the software product to enable the user to understand whether the software is suitable and how it can be [18] used for particular tasks and conditions of use. The capability of the software product to be understood learned, used and attractive to the user, when used under specified conditions. [18] 117

TABLE III COMPARISON OF QUALITY MODELS Quality Characteristics Availability/Relia bility Correctness Mc Call [31] Boeh m [4] FUR PS [15] Ghezzi et al. [14] IEE E [17] Drome y [9] ISO9126-1 [18] Kazma n [25] Khosravi K. et al. [28] Sharma A. et al. [34] Flexibility Functionality Human Engineering Integrity Interoperability Modifiability Performance Process Maturity Reusability Robustness Scalability Security Supportability Understandability Kumar et al. [30] References [1] ANSI/IEEE Standard 610.12. 1990. IEEE Standard Glossary of Software Engineering Terminology. [2] AOSD, Aspect-Oriented Software Development Home Page. 2008. http://www.aosd.net/wiki/index.php?title=glossary. [3] Bansiya, J. and Davis, C. 2002. A Hierarchical Model for Object- Oriented Quality Assessment, IEEE Transactions on Software Engineering, vol. 28, Issue 1, pp. 4-17 [4] Boehm, B.W. et al. 1978. Characteristics of software Quality, TRW Series of software Technology, Amsterdam, North Holland. [5] Boehm, B. W., Brown, J. R., and Lipow, M. 1976. Quantitative evaluation of software quality, International Conference on Software Engineering, Proceedings of the 2nd international conference on Software engineering (2nd):592-605. [6] Castillo, I., Losavio, F., Matteo, A. and Boegh, J. 2010. Requirements, Aspects and Software Quality: the REASQ model, [7] Journal of Object Technology, vol. 9, no. 4, pp.69-91. http://www.jot.fm/contents/issue_2010_07/article4.html [8] Chang, C Wu C., Lin, H. 2008. Integrating Fuzzy Theory and Hierarchy Concepts to Evaluate Software Quality, Software Quality Control, 16(2), pp. 263-267. [9] Deutsch, M.S. and Wills, R. R. 1988. Software Quality Engineering, A Total Technical and Management Approach, Prentice-Hall Inc. [10] Dromey, G. R. 1995. A model for software product quality, IEEE Trans. on software Eng., vol.21, no. 2, pp.146-162 [11] Firesmith, D. G. 2003. Common concepts underlying safety, security, and survivability engineering, Carnegie Mellon Software Engineering Institute Technical Note CMU/SEI-2003-TN-033. [12] Fitzpatrick, R.1996. Software Quality: definitions and strategic issues, School of Computing Reports, Standfordshire University. [13] Fusani, M.1995. Quality Models for Software Evolution Instruments International Seminar on Software Measuring & Testing, IEI CNR /Qualital /SSSUP S.ANNA Pisa, Italia. [14] Gaffney, J. E.1981. Metrics in software quality assurance, no. 81, pp.126-130, ACM press. [15] Ghezzi, Jazayeri, C. M. and Mandrioli, D.1991. Fundamental of software Engineering, Prentice Hall, NJ, USA. 118

[16] Grady, R., Caswell, Deborah 1987. Software metrics: Establishing a companywide program, Prentice-Hall, ISBN 0138218447. [17] Hyatt, L. E. and Rosenberg, L. H.1996. Product Assurance Symposium and Software Product Assurance Workshop, Proceedings of meetings, European Space Agency, pp. 209 [18] IEEE 1993. Standard for Software Maintenance, Software Engineering Standards Subcommittee of the IEEE Computer Society. [19] International Standard, ISO 9126-1. 2001. Institute of Electrical and Electronics Engineers, Part 1, 2, 3: Quality model. [20] ISO 9126. 2000E. Standard ISO/IEC, Information technology- Software product quality Part1: Quality Model, ISO/IEC FDIS 9126-1: 2000(E) [21] ISO /IEC. 1986. International Standard 8402: Quality Vocabulary [22] ISO/ IEC 25030. 2006. Software Engineering: Software Product Quality Requirements and Evaluation (SQuaRE), Quality Requirements. [23] ISO/ IEC CD 25010. 2007. Software Engineering: Software Product Quality Requirements and Evaluation (SQuaRE) Quality Model and guide. [24] ISO/IEC TR 9126-3. 2002. Software Engineering Product Quality. [25] ISO 9126. 1991. Software Product Evaluation: Quality characteristics and guidelines for their use, ISO/IEC Standardization ISO 9126. [26] Kazman, R., Bass, L. and Clements, P. 2003. Software Architecture in Practice 2Ed.Addison Wesley. [27] Khayami, R., Towhidi, A. and Ziarati, K. 2009. The Analytical Comparison of Qualitative Models of Software Systems, World Applied Sciences Journal 6, IDOSI Publications. [28] Khomh, F., Haderer, N. and Antoniol, G. 2009. SQUAD: Software Quality Understanding through the Analysis of Design, Reverse Engineering, WCRE 09, 16 th working conference. [29] Khosravi, K., Gueheneuc, Y. 2005. On Issues with Software Quality Models, 9 th ECOOP workshop on Quantitative Approaches in Object-Oriented Software Engineering. [30] Klein, M., Clements, P. and Kazman, R.2002. Evaluating Software Architectures: Methods and Case Studies, Addison Wesley. [31] Kumar, A., Kumar, R. and Grover, P. S. 2006. A change Impact Assessment in Aspect-Oriented Software Systems, In the proceedings of International Software Engineering Conference Russia, (SECR-2006), Dec, pp. 83-87. [32] Mc Call J. A., Richards, P. K. and Walters, G. F. 1977. Factors in Software Quality, vol. 1, 2 and 3, AD/A 049-014/015/055, National Tech. Information service, Springfield. [33] Pressman, R. S.1992. Software Engineering a practitioner's Approach. McGraw-Hill, Inc. [34] Sehra, S. K., Brar, Y. S. and Kaur N. 2011. Soft Computing Techniques for Software Project Effort Estimation, International Journal of Advanced Computer and Mathematical Sciences, ISSN 2230-9624, vol. 2, Issue 3, pp. 160-167. [35] Sharma, A., Kumar, R. and Grover, P. S. 2008. Estimation of Quality for software components: an empirical approach, ACM SIGSOFT Software Engineering Notes, 33(6), pp. 1-10 119 [36] Word, W. A. and Venkataraman, B. 1999. Some observations on software quality, ACM proceedings of 37 th Annual Southeast regional conference, Article no. 2.