Software Component Quality Models from ISO 9126 ...

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

Software Component Quality Models from ISO 9126 Perspective: A Review Sonu Mittal 1, Pradeep Kumar Bhatia 2 1

Research Scholar, SGVU, Jaipur, India [email protected] 2

Professor, GJUS&T, Hisar, India [email protected]

Object Model), DCOM, .NET Framework, Sun’s Java Beans, EJB (Enterprise Java Beans), J2EE Specification and OMG’s (Object Management Group) CORBA (Common Object Request Broker Architecture). Inside the CBSD, many different types of components are integrated such as in-house developed components or third party components. Third party components exist in two forms – Commercially produced or Open Source. Commercial software components are previously tested, and their code cannot be modified. These components are known as COTS (Commercial-Off-The-Shelf). “A COTS product as one that is (i) sold, leased, or licensed to the general public, (ii) offered by a vendor trying to profit from it, (iii) supported and evolved by the vendor, (iv) available in multiple identical copies, or (v) used without modification of the internals.”[4]. Due to COTS component’s plug-and-play nature they become very popular in short time. However, despite all the advantages, component-based development has still not reached its full potential due to a few major hurdles. One such hurdle is selecting quality components. Selecting one of the low quality components may lead to failure of the entire system. Such two case studies have been already pointed by S.srinivasn [15]. Therefore, it is very necessary to build a quality framework through which we can evaluate the quality of these third party components for Component Based Software Systems (CBSS).Some issues related to evaluation of COTS components and CBSS are: • What should be the characteristics and sub characteristics relevant to the component quality models? • To what extent the ISO 9126 fulfills this quality framework requirement for the COTS component and CBSS? To address these issues present paper reviews the various software component quality models proposed by the researchers in this area. After this introduction, section 2 defines the basic concepts and terminologies with regard to software quality and quality models. Section 3 outlines the ISO 9126 quality model and the reason for choosing it as the framework for the component based quality models

Abstract Accessing the quality of Software products and process has been always a thrust area for the software engineering researchers. There are several existing quality models used to evaluate software systems, namely: McCall’s, Boehm, ISO 9126, FURPS, Dromey, Triangle and Quality Cube etc. Software systems today are composed from prefabricated commercial components known as COTS components. The quality of these COTS component based software systems (CBSS) depends on the quality of these components. There are several quality models proposed by the researchers to evaluate the quality of components; primarily based on the ISO 9126 model. None of them agrees on all the characteristics/sub characteristics to be as it is used for evaluating the components. This paper emphasis on review of these component quality models based on the addition, deletion and the changes made to various characteristics and sub characteristics of the ISO 9126 model. The objective of this review is to identify and select better and common characteristics and sub characteristics from the ISO 9126 model for development and assessment of the components and CBSS quality.

Keywords: Quality characteristics, Quality sub characteristics, ISO 9126, Components Quality, CBSD, COTS quality evaluation, component quality models

1. Introduction The idea of constructing software in the same way as hardware is constructed i.e. by assembling reusable components is becoming very popular in the last decades. Software reuse reduces development time, effort, cost and increases productivity and quality. Studies in software engineering confirm these benefits [1,2]. Software reuse in its most common form can be seen in component based software development (CBSD). CBSD is an approach in which systems are built from well -defined, independently produced pieces, known as components. Reference [3] defined software component as “A coherent package of software artifacts that can be independently developed and delivered as a unit and that can be composed, unchanged, with other components to build something larger.” There are many software component models available in the industry, for example: Microsoft’s COM (Component

IJMRS www.ijmrs.com 6

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

have been derived. Section 4 presents a literature review on various component based quality models. Section 5 presents a review analysis of the different proposed component based quality models. Section 6 concludes the different models and discusses different ways in which the models can be improved in future research.

FireSmith[8].He defines a quality model as a hierarchical model (i.e. a layered collection of related abstractions and simplifications) for formalizing the quality of a system in terms of its factors, sub-factors, criteria and measures as described below: • Quality Characteristics – high level characteristics of a system that capture major aspects of its quality (E.g. Functionality, Maintainability etc) • Quality Sub-Characteristics – major components of the quality factors mentioned above that capture a subordinate aspect of the quality of the system (E.g. Accuracy is a sub characteristic of Functionality) • Quality Attributes – specific descriptions of a system that provide evidence for or against the existence of a specific quality factor or sub-factor. (E.g. Precision is an attribute of the quality sub factor Accuracy) • Quality Metrics- gauges that quantify the quality attributes and thus make them measurable, objective and unambiguous (E.g. Precision=Number of adequate results retuned/Number of total results returned)

2. Software Quality and Quality Models Let us first have a look at the basic concepts and terminologies with regard to software quality and quality models. According to the IEEE Standard Glossary of Software Engineering Terminology [5], software quality is defined as “the degree to which a system, system component, or process meets specified requirements “, or “the degree to which a system, system component, or process meets customer or user needs or expectations.” Software quality can either refer to the software product quality or the software process quality. Examples used for product quality are the CMM (Capability Maturity Model). The ISO standards have been set for both product as well as process quality. For example, ISO/IEC JTC1 ISO 9126 [6], talks of software product quality while ISO/IEC JTC1, ISO-15504-5 [7] talks about software process quality. The quality models, we refer to in this paper, are for the product quality of software components and CBSS. Quality is mainly studied by quality models. The quality model describes the set of characteristics, which are the basis for establishing the quality requirements and for evaluating software quality According to Ljerka Beus Dukic and Jorgen Boegh [9], software quality evaluation is defined as “the systematic examination of the software capability to fulfill specified quality requirements.” A software quality model is defined as,” a set of characteristics and sub characteristics, as well as the relationships between them that provide the basis for specifying quality requirements and evaluating quality”. Therefore, a software quality model is a good tool to evaluate the quality of a software product. A more concise definition of a quality model is presented by Donald

Diagrammatically it can be shown as in fig. 1. Software Product quality assessment can either be white box or black box assessment. White box assessment is based only on the source code, but source code will not be available for black box assessment. There is no source code available for the COTS components unlike in-house components (since in-house components are developed inside the organization itself). Black box quality assessment is based on the evaluation of externally viable characteristics that can be done using quality models and that can also be applied to all kinds of software components. There is several existing quality models used to evaluate software systems, namely: McCall’s, Boehm, ISO 9126, FURPS, Dromey, Triangle and Quality Cube etc. There are several models proposed exclusively for COTS and CBSS also. But most of these models [11,12,13,14,16,19] are based or derived from ISO 9126.

Divided to

Characteristic

Sub characteristics

Refined to

Attribute

Formalized to

Metric

Figure 1: Quality Model Hierarchy standard, which was selected for the component quality model, for the following reasons:[10] • Due to its generic nature, the standard fixes some high-level quality concepts, and therefore quality models can be tailored to specific package domains. This is a

3. The ISO/IEC 9126 Quality Model The International Organization for Standardization and International Electrotechnical Commission 9126-1 quality

IJMRS www.ijmrs.com 7

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

crucial point, because quality models can dramatically differ from one domain to another.

The ISO/IEC 9126-1 standard fixes 6 top level characteristics: functionality, reliability, usability, efficiency, maintainability and portability. It also fixes their further refinement into 27 subcharacteristics but does not elaborate the quality model below this level, making thus the model flexible. The decomposition of characteristics, as proposed by the ISO 9126, is presented in Table 1[6]

• The standard lets us create hierarchies of quality features, which are essential for building structured quality models. • The standard is widespread

Characteristics

Functionality, a set of attributes that bear on the existence of a set of functions and their specified properties

Table 1: ISO/IEC 9126 characteristics and subcharacteristics Sub Description characteristics determines the degree of the precision of calculated values. It also describes Accuracy how effectively and authentically the attributes describe the software quality Suitability

determines the fitness for the purpose

Interoperability

deals with the attributes that describes the ability of the software to interact with specific system

Security

deals with the attributes that describe the ability of the software to prevent the unauthorized access of it.

Functionality Compliance Maturity Reliability, a set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time

Efficiency, a set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions Usability, a set of attributes that bear on the effort needed for use, and on individual assessment of such use, by a stated or implied set of users Portability, a set of attributes that bear on

Fault Tolerance

Recoverability

refers to the adherence of the software to standards and conventions related to applications and regulations by law. describes the frequency of failure of the software by faults evaluates the robustness of the software. It describes the software attributes that describe the ability of the software to maintain a specified level of performance in cases of software faults or the violation of its specified interface. describes the capability of the software to re-establish its level of performance and to recover the data directly affected in case of failure and the time and effort needed for it

Reliability Compliance

determines whether the software adheres to the compliance standards of reliability or not

Time Behaviour

is related to the attributes that measure the response time, processing time, and throughput rates.

Resource Behaviour

describes the amount of resources used and the respective duration of the use.

Efficiency Compliance

describes whether the software adheres to the standards of efficiency

Understandability Learnability Operability Attractiveness Usability Compliance Replaceability

deals with the attributes of software that describe the relative ease of recognizing the logical concept and its applicability deal with the software attributes that describe the relative ease for the users to learn the application deals with the software attributes that are associated to the relative ease of learning the operations of the software describes the degree to which the software has been made attractive determines whether the software adheres to the compliance standards of usability or not is described by the attributes of the software that explain the opportunity for the adaptation of the software IJMRS www.ijmrs.com 8

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

the ability of software to be transferred from one environment to another

Adaptability Installability Co – existence Portability Compliance

Maintainability, a set of attributes that bear on the effort needed to make specified modifications.

Analyzability Changeability Testability Stability Maintainability Compliance

describes the relative ease for the software to adapt itself to different environments without applying any changes other than those provided for this purpose describes the relative ease of installing the software in a given environment or platform. determines whether the software can exist in the system without colliding with the remaining processes defines the attributes allowing the software to adhere to standards or conventions relating to portability describes the relative ease of diagnosing the deficiencies, the causes of failure, and identifying the parts to be modified describes the relative ease of modifying the software for removing the faults or to adjust to the environmental changes describes the relative ease of testing the software to determine the bugs. describes the attributes of software that describe the risk of unexpected modifications. determines the adherence of the software to the maintainability compliance standards.

related metrics for the components evaluation. The model developed was based on ISO/IEC 9126 and a set of updates in the Characteristics and Sub-Characteristics were provided in order to be used in a software component context. At least, some metrics were presented in order to provide means to measure the quality characteristic proposed in the model. In 2006, Adnan [11] also conducted a survey on various quality models available, which includes McCall, Boehm, FURPS, Dromey and ISO 9126. It performs some tailoring on ISO 9126 model by adding compatibility subcharacteristic under functionality and complexity under usability. It omits stability and analyzability from maintainability and adds manageability to it. It also adds new characteristic, named Stakeholders in its proposed model who are the members of the team responsible for developing, maintaining, integrating and/or using COTS systems. The paper performs a good comparison for various quality models; however, all the models considered are traditional models and may not fit for component-based systems, as-it-is. Moreover, the proposed model does not explain how the attributes belonging to various characteristics and sub-characteristics will be measured to finally evaluate the quality of the system. In 2008, Sharma et. al. [14] presents a survey of various quality models proposed so far for non- component and component based systems. It is defines the characteristics and sub-characteristics of the component and proposes to add some more sub-characteristics to it, which may be relevant in the component context, using a weight assignment technique called Analytical Hierarchical Process (AHP). The work have demonstrated the use of the technique in an experiment by taking a real-life example and evaluated the overall quality of the component.

4. Literature Review of various Component Based Quality Models In 2002, it was Bertoa et al. [12] who first defines the characteristics and sub-characteristics in the changed context of component based systems. The paper divides sub-characteristics into runtime and lifecycle categories based on their nature. It adds compatibility subcharacteristic under functionality, which indicates whether former versions of the components are compatible with its current version. The paper also proposes various attributes associated with the sub-characteristics and finally defines these attributes with the classification for the measurement of such attributes like ratio, presence, integer and time. Although the paper presents a good description on quality characteristics, sub-characteristics and their measurement, it fails to perform any empirical evaluation of the attributes on any application, thus leaving the proposed work as incomplete [17]. In 2003, S.D.Kim et al. [16] proposed a practical quality model for evaluating COTS components, based on ISO 9126 model. It used CORBA component model as a base for defining the framework of their model. It uses functionality, reusability, maintainability and conformance characteristics factors which are further divided into commonality, suitability, completeness, modularity, customizability, comprehensiveness, abstractness and changeability subcharacteristics/subfactors. Further metrics for these four factors is also defined that can be effectively used to derive the overall quality of components. However, it has used product level metrics evaluation. It further did not differentiate the runtime and lifetime subcharacteristics. In 2005, Alvaro et al. [13] presented a Component Quality Model describing mainly the quality attributes and

IJMRS www.ijmrs.com 9

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

In 2008, Choi et al. [19] proposed an in-house Component Quality Model which includes metrics for component quality evaluation, tailoring guidelines for evaluations, and reporting formats of evaluations. The model proposed was based on ISO/IEC 9126 and Choi et al. have applied this Component Quality Model to embedded system development projects. The future works will try to automate some quality characteristics through a set of tools developed in Samsung – Korea labs. The model proposed in this work is specific to embedded system domain which means that the literature started to tailor some models to specific kind of domains. At last in 2010, Alvaro et al.[18] proposed a software component quality framework to evaluate the quality of software components in an efficient way. They extended their previous work [13] by adding an experimental study was accomplished in order to evaluate the viability of the proposed framework. The proposed framework is composed of four modules (i) a Component Quality Model (CQM), with the purpose of determining which quality characteristics should be considered (defining the essential CBD characteristics) and which sub-characteristics are necessary; (ii) a Evaluation Techniques Framework, which defines a number of techniques (divided in five qualitylevels I-V and the closer to the last level, the higher is the probability that the component is trusty) that will be applied to software components evaluation where was proposed the Software Component Evaluation Techniques Model (SCETM); (iii) a Evaluation Process, responsible for

defining a group of techniques, metrics, models and tools to evaluate and certificate software components, aiming to establish a well-defined component evaluation standard; and (iv) a Metrics Framework, responsible for defining a set of metrics to track the components properties and the component evaluation process in a controlled way.

5. Review Analysis A review analysis of the different proposed quality models is presented in this section. The review of the models is based on the following points (Table 2):• ADDED: refers to new Characteristics/subcharacteristics added to the ISO 9126 model • DELETED: refers to deleted Characteristics/subcharacteristics to the ISO 9126 model • DIVIDED: describes whether the subcharacteristics are divided into runtime (dynamic)/ lifecycle (static). • METRICS : a description of the metrics used in the model (if any) • VALIDATION: whether the validation /evaluation of the model done • TARGET AUDIENCE: describes the target users of the model • SCOPE: refers to the domain of the model

Table 2: Analysis of various component quality models Ref. Model

ADDED

DIVID ED

DELETED

Bertoa et al. [12]

Compatibility to Functionality, Complexity to Usability

Portability* Fault Tolerance Stability Analyzability Attractiveness

Soo D. Kim et al. [16]

Reusability*(customiz ability, Commonality, Modularity, Comprehensiveness), Commonality and Completeness to Functionality, Modularity and Interface Abstractness to Maintainability

Portability* Reliability* Usability* Efficiency* Compliance Accuracy Interoperability Security Analyzability Stability

Yes (runtim e/lifecy cle)

NO

TARGET AUDIEN CE

The software architects and designers

The consumer of COTS compone nts

VALI DATI ON

SCOPE

Presenc e, Time, Level, Ratio

Not done

Individual COTS Component Level as well as in the Component evaluation at system level

Ratio based metrics for all the subfact ors

Done (CIP Proje ct) but not show n in the paper

for COTS component Quality evaluation, considered only CORBA component Model

METRI CS

IJMRS www.ijmrs.com 10

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

Adnan Rawash deh et al.[11]

Y.Choi et al. [19]

Arun Sharma et al. [14]

Alvaro et al. 18]

Conformance*

Testability

Compatibility to Functionality, Complexity to Usability, Manageability* with quality management

Portability* Fault Tolerance Stability Analyzability Attractiveness

Reusability*(customiz ability, Functional Commonality, Domain Model Conformance, Component Model Conformance), Modularity*(Cohesion , Coupling ), Completeness to Functionality, Scalability to Efficiency Reusability to Functionality Scalability to Efficiency Complexity to Usability Trackability and Flexibility to Maintainability Self-contained to Functionality Configurability to Usability Scalability to Efficiency Reusability to Portability

NO

Not done

for COTS component Quality evaluation

NO

The producer of compone nts

Ratio based some metrics

Yes (Pilot evalu ation on two In house comp onent s)

to evaluate In House Component quality, mainly for embedded system domain

NO

The consumer /evaluator of compone nt

A set of metrics for 11 subchar acteristi cs

Yes (Usin g AHP Proce ss )

for component evaluation

Presenc e, IV value, Ratio

Yes ( A frame work with SCET M levels )

Any kind of component evaluation both at individual as well as at the System level

Yes ( product/ process)

Analyzability Accuracy Interoperability Compliance Installability Stability Attractiveness

Compliance

Yes (runtim e/lifecy cle)

Analyzability

End User, Analyst, QA Officer, Project Manager

The consumer /evaluatio n team of compone nt

* indicates Characteristics with all of its subcharacteristics.

As shown in table 2, most of the researchers agree on the reusability feature to be added to the ISO 9126 model to extend it for the component quality evaluation model. Although they differ in whether to add these at the characteristics level or at the subcharacteristics level. Since COTS components are targeted for inter-organizational reuse, they must be highly reusable to be valuable. If we consider evaluating the quality at the internal level then it should be considered at the characteristic level otherwise it should be considered as the subcharacteristics of the functionality.

Similarly, a complexity Sub characteristic should be added under the usability. Because the source code of the component is not available to the application developer, the complexity of a component in CBSD is limited to interface methods, pre and post conditions, properties and interactions available to the developer. Measuring the complexity at the initial stage is helpful during analyzing, testing, and maintaining the system [14]. Usability, this characteristic and all its subcharacteristics have a completely different meaning for software components. The reason is that, in CBSD, the end-users of IJMRS www.ijmrs.com 11

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

components are the application developers and designers that have to build applications with these components, rather than the people that have to interact with them. Thus, the usability of a component should be interpreted as its ability to be used by the application developer when constructing a software product or system with it. The researchers are also in favor of deletion of analyzability and attractiveness subcharacteristics. Although some researchers favors the deletion of portability characteristics and all of its subcharacteristics but we considers it to be an important characteristic for the component based quality models as a component may be used and reused in various different environments. Therefore the specification of a component should be platform independent [14]. Dividation of subcharacteristics into runtime (that are discernable at component execution time) and lifecycle (that are discernable at component development and CBSD) makes it clearer in its use and objective. Most of the researchers proposed metrics for these characteristics (mostly ratio based) but very few work on the evaluation part of these metrics.

metric would help the developer/integrator to build a quality COTS based software product. So these metric should be easy to calculate and be feasible for practical use. The field of quality attribute determination of componentbased system is extensive and more research can and should be performed in this field. This will help in increasing confidence in the use of research results, to solve problems in practical industrial settings.

References [1] Krueger, C. W.: Software reuse, ACM Comput. Surv., 24, 131-83 (1992). [2] Mohagheghi, P., and Conradi, R.: Quality, productivity and economic benefits of software reuse: a review of industrial studies, empirical software Engg., 12, 471-516 (2007). [3] D’ Souza D. F., Wills, A. C. ,”Objects, Components and Frameworks with UML: The Catalysis Approach.” Addison Wesley, Reading, MA, (1999). [4] John, D. et al.,“A Process for COTS Software Product Evaluation” Technical Report CMU/SEI- 2003-TR-017, (2004). [5] IEEE Standard Glossary of Software Engineering Terminology (Std 610.12-1990) by IEEE. [6] ISO, International Organization for standardization,” ISO 9126-1:2001 Software engineering-Product quality, Part 1: Quality Model”, (2001) [7] ISO/IEC JTC1, ISO-15504-5: “Information Technology – Process assessment-Part 5: An exemplar process assessment mod-el”, Technical Report, (2004) [8] Donald FireSmith:“Achieving Quality Requirements with Reused Software Components – Challenges to Successful Reuse”, Second International Workshop on Models and Processes for the Evaluation of Off – The – Shelf Components (MPEC) (2005) [9] Ljerka Beus Dukic and Jorgen Boegh: “COTS Software Quality Evaluation”, In the proceedings of ICCBSS, Ottawa, Canada(February2003) [10] X. Franch, J.P. Carvallo. “Using Quality Models in Software Package Selection”. IEEE Software, 20(1),( 2003). [11] Adnan Rawashdeh, Bassem Matalkah, “A New Software Quality Model for Evaluating COTS Components”, Journal of Computer Science, (2006), Vol. 2 Iss. 4, 373-381. [12] M. Bertoa, A. Vallecillo, “Quality Attributes for COTS Components”, In the Proceedings of the 6th International ECOOP Workshop on Quantitative Approaches in ObjectOriented Software Engineering (QAOOSE), Spain, (2002). [13] Alexandre Alvaro, duardo Santana de Almeida, Silvio Romero de Lemos Meira, “Quality Attributes for a Component Quality Model”, Proceeding of 10th International Workshop on Component Oriented Programming (WCOP), Glasgow, Scotland, (2005) [14] A. Sharma, R. Kumar and P.S. Grover, “Estimation of Quality for Software Components - an Empirical Approach,” ACM SIGSOFT Software Engineering Notes, Vol.33, No.5,( November, 2008), pp.1-10 [15] S. Kalaimangal and R. Srinivasan, “A Retrospective on Software Component Quality Models,” ACM SIGSOFT

6. Conclusion and Future scope A good component quality evaluation procedure is necessary to ensure that organizations are able to procure high quality components for software development. An important consideration in component selection and integration is the evaluation of the component using quality models. This paper is a review study of the different quality models proposed in component research literature. All the proposed models follow the ISO 9126 quality model framework with a few corrections and adjustments made to suit the software component domain. The flexibility of ISO 9126 model makes it most appropriate candidate for the formation and evaluation of the quality for component based systems. However, they all have one common drawback that there are too many attribute that have to measured that will lead to confusion. Not only that, it won’t be possible to measure some of the attributes due to a number of reasons. The major reason will be lack of information from the component vendors [12]. Another drawback is the fact that most of the quality models have not been adequately validated. Future work in the development of CBSD research could include determination of quality metrics for components integration in CBSD. Their Integration point is an important factor for their quality consideration as CBSS complexity, reusability, maintainability and testability are based on their proper integration and design work. These

IJMRS www.ijmrs.com 12

IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

Software Engineering Notes, Vol.33, No.5, (November, 2008), pp.1-9 [16] S.D. Kim and J.D Park, "C-QM: A Practical Quality Model for Evaluating COTS Components", Proceedings of the 21st IASTED International Conference on applied informatics, Innsbruck, Austria ( February,2003) [17] Preiss, O., Weqmann, A., Wong, J, “On Quality Attribute Based Software Engineering”, Proceeding of 27th EuroMicro Conference, (2001), 114-121.

[18] Alvaro, A., Almeida, E.S., Meira, S.R.L. “A Software Component Quality Framework”, ACM SIGSOFT Software Engineering Notes, (November 2010) Volume 35 Number 1 [19] Choi, Y., Lee, S., Song, H., Park, J., Kim, S., “Practical S/W Component Quality Evaluation Model”, In the 10th IEEE International Conference on Advanced Communication Technology (ICACT), Korea (2008.)

IJMRS www.ijmrs.com 13