Software Component Quality Characteristics Model for Component Based Software Engineering

Transcription

1 2015 IEEE International Conference on Computational Intelligence & Communication Technology Software Component Quality Characteristics Model for Component Based Software Engineering Arti Tiwari 1, Partha Sarathi Chakraborty 2 Department of Computer Science and Engineering, SRM University, India artitiwari88@gmail.com 1 parthasarathi@live.com 2 Abstract In Component Based Development, applications are built from existing components, primarily by assembling and replacing interoperable parts. Thus a single component can be reused in many applications, giving a faster development of applications with reduced cost and high quality as components are reused in various applications. Software component has been developed lively. Thus they are likely to be more reliable than software developed abolitions. The reason is that these components are tested under varieties of situations before being used in the application(s). As we move from traditional software engineering to component-based software engineering, we should resolve many technical and non-technical issues. One of the major and very important issues is quality of the software components. Although many researchers already proposed various kind of quality metrics and models for traditional software but the less information is provided about components of software. The main aim of this paper is to find out various quality aspects of software components. Also determine the relationship between components quality characteristics and subcharacteristics. However, the measurement of software component quality is relatively less researched against conventional software quality in practice. Key words Component base software engineering, Quality Characteristics and Subcharacteristics. I. INTRODUCTION Software community faces a major challenge that is raised by fast growing demand for rapid and cost effective development and maintenance of large-scale and complex software systems. To overcome the challenge, the new trend is to adopt component-based software engineering (CBSE). The key difference between CBSE and traditional software engineering is that CBSE views a software system as a set of off-the shelf components integrated within an appropriate software architecture. CBSE promotes large-scale reuse, as it focuses on building software systems by assembling off-the-shelf components rather than implementing the entire system from scratch. CBSE also emphasizes on selection and creation of software architectures that allow systems to achieve their quality requirements. As a result, CBSE has introduced fundamental changes in the software development and maintenance. Component Based Software Development (CBSD) paradigm is based on reuse of already existing components to produce new applications. In a Component Based system, many different types of components are integrated such as in-house developed components or third party components. Third party components exist in two forms commercial off the shelf (COTS) or Open Source. New components may need to be developed for the application in hand and then added to the component library for future use. It is believed that such an approach can reduce the development effort and time, and increase the productivity and quality of the software. Besides these advantages of CBD, however, the quality aspects are not addressed adequately for such systems. There are quite a few quality models like McCall model, Boehm Quality model and ISO9126 model, proposed by researchers for general software systems, but these models may not be adequate for assessing the quality of component-based systems due to the change in the nature and procedure of development of these systems. II. QUALITY OF THE SOFTWARE COMPONENT According to the IEEE, 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. Component-Based Software Engineering (CBSE) is being used in a wide variety of application areas, including embedded systems, and the correct operation of the components is often critical for business success and, in some cases, human safety. In this way, assessment and evaluation of software components has become a compulsory and crucial part of any CBSE lifecycle. A risk of selecting a product with unknown quality properties is no longer acceptable and, when happened, may cause catastrophic results. Thus, the software components quality evaluation has become an increasingly essential activity in order to bring reliability in (re)using software components. In this way, we propose a quality verification framework to evaluate the quality of embedded software components in an efficient way. This document is based in component characteristics, sub-characteristics, quality attributes and metrics. In CBS, quality aspect becomes more important due to its architectural difference. Here, application developers have to rely on the component vendors or the developers. The quality of the component will have a very high impact on the quality of the final system. Several software quality models have been proposed for the measurement of the quality of software products. Also, some of these models have been customized and established for specific categories of software product such as Components, COTS (Commercial Off-The-Shelf), or Open Source. These customized models are to focus on important attributes for those software product categories with specific purposes. From the viewpoint of component quality models, it is necessary to define a model that considers quality requirements for software components. We should provide not only how to measure the quality of source codes but also guarantee the product or system level of quality when /15 $ IEEE DOI /CICT

2 components are deployed and consider component development lifecycle. Additionally, we should define a specialized level of evaluation for each kind of software component providing evaluation criteria, tailoring guidelines, well-formed evaluation result reporting format and related processes to make component quality evaluation easy. In this context, existing quality models don't satisfy these requirements. This paper presents software component quality model which is based on the quality model structure in IEEE 1061[8] as in Figure 1 and conforms ISO/IEC 9126 standards. We aim to provide software component developers quality evaluation results as initiatives of component quality improvement. To define the objective level of component quality, we have surveyed existing component quality reference models, related papers and materials. As a result, we could collect fundamental component definitions and characteristics based on the research and classify types of components according to component size, and the scope and purpose for component reuse. Finally, we derive quality characteristics and sub characteristics of component from analyzing requirements for reusable components. component as an opaque implementation of functionality subject to third party composition and conformant to a component model. An individual software component is a software package, a Web service, or a module that encapsulates a set of related functions (or data). A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard. As considering various points of view for component definition, we suggest general component definition, which is "a reusable software product which is independently developed and deployed to perform specific functions with well-defined interfaces." In detail, we summarize representative definitions as follows; 1) S/W unit which can be composable with other S/W modules or components to build a complete application system, 2) Originally designed for reuse and independently developed and deployed to provide explicit services, and 3) Only executed through predefined interfaces. In this paper, based on these component definitions we identify requirements of component quality and made them specialized for the establishment of measurable metrics and evaluation methods for each quality characteristic. The purpose of this research is to establish, introduce and apply CQCM (Component Quality Characteristics Model) for the development of reusable and quality components and to derive the cost reduction and quality improvement in the future. Figure 1. The structure of quality model defined in IEEE 1061 Quality and performance concerns can be alleviated by using software metrics to guide quality and risk management in a CBS, accurately quantifying various factors contributing to the overall quality of a CBS, and identifying and eliminating sources of risk. Metrics can guide decisions throughout the software life cycle and determine whether software quality improvement initiatives are financially worthwhile. As in any development or manufacturing process, software quality is achieved at a cost. This paper outlines existing challenges in cost and quality management of CBSs and illustrates the use of metrics for quantifying the concept of software quality, investigating the tradeoff between cost and quality, and using the information gained to guide quality management. This paper outlines existing challenges in cost and quality management of CBSs and illustrates the use of metrics for quantifying the concept of software quality, investigating the tradeoff between cost and quality, and using the information gained to guide quality management. III. COMPONENT QUALITY REQUIREMENTS Software component: A software component is a unit of packaging, distribution or delivery that provides services within a data integrity or encapsulation boundary. The Software Engineering Institute (SEI) defines a Figure 2. The Procedure Software Component Quality Characteristics model According to many researchers, CQM consists of quality characteristics (Quality level) and subcharacteristics (Quality Factor level) in component and relations between them. Also it specifies metrics (Metric level) categorized by the characteristics and subcharacteristics with measure factors (Quality Subfactor level). Mainly, measure factors exist for the seamless mapping between the level of subcharacteristics and the level of metric items. IV. COMPONENT QUALITY CHARACTERISTICS ISO 9126 defines the characteristics of software quality as follows: 48

3 Functionality Maintainability Usability Efficiency Reliability Portability Functionality: This characteristic maintains the same meaning for components rather than for a system composed by the integration of several software components. It tries to express the ability of a component to provide the required services and functions, when used under the specified conditions. It presents as sub-characteristics: Suitability, Accuracy, Interoperability, Compliance and Security. The capability of software component to provide functions which meet the stated and implied needs when S/W is used under specified conditions. Maintainability: This characteristic describes the ability of a software product to be modified. Modifications include corrections, improvements or adaptations to software. The user of a component (the developer) does not need to carry out internal modifications but he or she does need to adapt it, re-configure it, and perform the testing of the component before it can be included in the final product. It presents as sub-characteristics: Changeability and Testability. The capability of software component to simplify the internal structure of component to be modified or adapt functional changes easily. Usability: This characteristic and all its sub characteristics have a completely different meaning for software components. The reason is that, in CBSD, the end-users of 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. It presents as sub-characteristics: Learning capacity, Understandability and Operability. The capability of supporting software component to be understood learned, used, configured, and executed. Efficiency: This is a set of attributes that refer to the relationship between the level of performance of software and the amount of resources used, under stated conditions. It presents as sub-characteristics: Time behaviour and Resource behaviour. The capability of software component to provide appropriate performance, relative to the amount of resources or time use. Reliability: this is a set of attributes that refer to the capability of software to maintain its level of performance under stated conditions for a stated period of time. It is directly applicable to components, and essential for reusing them. It presents as sub-characteristics: Maturity and Recoverability. The capability of software component to maintain a specified level of performance or quality level when used under specified conditions. Portability: this is defined as the ability of a software product to be transferred from one environment to another. In CBSD, portability is an intrinsic property of the nature of components, Which are in principle designed and developed to be re-used in different environments? It presents as sub-characteristic: Replaceability. The capability of software component to be transferred from one environment to another or between heterogeneous hardware. V. CHOOSING QUALITY CHARACTERISTICS There are two main threads in the research of software quality: one of them is concerned with evaluating the software process quality while the other focuses on the product quality itself. Our current research deals with the latter. Several product quality models can be found in the literature, such as [3-9]. Among these models, the most consensual model is the one offered by ISO9126. These models include generic software quality attributes. Besides, they were conceived at the system level, not at the component one. While some of their characteristics are appropriate to the evaluation of software components, others are not well suited for that task. Some of their quality characteristics, such as fault tolerance are typically evaluated at the system level, rather than for each of the components. A quality model for components should be tailored to use only the characteristics that apply to components. In one such model is proposed for the evaluation of COTS components. The model proposed in this paper has a wider spectrum of application, as it is targeted for software components in general. As a starting point, we will use the quality model described in (reference) which is an attempt to improve some of the shortcomings of the ISO9126 model. We will adapt it to the special needs of quality components. We are currently researching which of these characteristics are applicable to software components.discrimination between white box and black box characteristics will be made. The former are more suited for component quality evaluation on the to the developers of components point of view, while the latter are of special interest to the components consumers (developers using components in the construction of their applications). VI. COMPONENT QUALITY CHARACTERISTICS From the viewpoint of component quality models, it is necessary to define a model that considers quality requirements for software components. We After analyzing all the quality aspects of software and software components, in this paper researchers find out so many kinds of subcharacteristics. Out of them researchers collect few subcharacteristics regarding 6 main characteristics of ISO The main subcharacterics are discussed in following Table1. Table 1: Component quality Sub Characteristics Characteristics Sub-characteristics Functionality Complexity, Correctness, interoperability, security, completeness, Suitability Maintainability Usability Efficiency Reliability Portability Diagonoseability, repairabilty, expendability, testability, Maturity, Recoverabilty Installability, learnability, configurability, operability, Monitorability Time behaviour, resource behaviour, Repairability Maturity fault tolerance Adaptability, replaceability 49

4 VII. COMPONENT QUALITY CHARACTERISTICS MODEL We've combined the analysis all the component quality requirements and traditional quality model such as ISO 9126, Figure 3. Component Quality Characteristics model and then we've extracted 6 important quality characteristics including functionality, maintainability, usability, efficiency, reliability, and portability among so many different characteristics. With this categorization, we've clustered 23 quality sub-characteristics while combining ones which are regarded as the similar meanings in the component domain. Also each definition of quality characteristics refers to various quality models, such as IS09126, Boehm, McCall and other specific component quality models. Software CQCM (Component Quality Characteristics Model) has been organized as shown in Figure 3. As with component various quality characteristics and sub-characteristics, we can also use model for classification of various component quality metrics: whether they are white box or black box metrics. This classification will be relevant for the definition of responsibilities in the evaluation process. The software component quality characteristics model should not be tied to a particular metrics set. In fact, there is no metrics set that is commonly accepted as the standard metrics set for software components. Besides concentrating on quality characteristics only, we also created other characteristics level called Marketability. This characteristic presents some sub-characteristics that we think important to a certification process, such as: Development time: The time it takes to develop a component; Cost: The cost of the component; Time to market: The time it takes to make the component available on the market; Targeted market: The targeted market volume; and Affordability: How affordable is the component. This information are not only important to evaluate component quality, but also important to analyze some factors that bring credibility to the component customers (i.e. developers and designers), for example, the time that component was available to the market means that the component is more mature, because some bugs are corrected and some test cases were applied. VIII. EVOLUTION OF RELATIONSHIP BETWEEN COMPONENT QUALITY CHARACTERISTICS AND SUBCHARACTERISTICS Table 2: Relatonship between characteristics quality Characteristics Fun Mai Usa Eff Rel Por Subcharacterstics Complexity Correctness Interoperability Security Completeness Suitability Diagonoseability Repairabilty Expendability Testability Maturity Recoverability Installability Learnability Configurability Operability Monitorability Time Behaviour Resource behaviour Repairability Maturity fault tolrence Adeptability Replaceability Sub Characteristics In fact, relations between component quality characteristics and sub-characteristics should be based on the results of practical component quality evaluation with quantitative measure data per each characteristic. However, because of insufficient evaluation data, instead of that, we've summarized the opinions of S/W quality experts by Delphi method as in Table 2. Each column means the quality characteristics and each row means the quality sub-characteristics. In particular, Table 2 only presents common quality sub-characteristics and doesn't include variable ones. IX. CONCLUSION In order to properly enable the evaluation of software components, supplying the real necessities of the software component markets, a component quality model is strictly necessary. Thus, this work presented a Component Quality characteristics Model, its characteristics, sub-characteristics, quality attributes and the relationship between quality characteristics and sub characteristics that compose the model. X. FUTURE WORK As future work, we intend to update the CQCM with the new ISO/IEC 9126, still on, Researchers are working with the definition of a Software Component Maturity Model (SCMM). Based on the CQM proposed, the SCMM will be constituted of certification levels where the components could be certified. The idea is to develop a model in which the component could increase its level of reliability and quality as it evolves. The SCMM will be described in future papers. 50

5 REFERENCES [1] Kuljit Kaur Chahal, Hardeep Singh, 2008, A Metrics Based Approach to Evaluate Design of Software Components, IEEE International Conference on Global Software Engineering, pp: [2] Eun Sook Cho, Min Sun f im,soo Dong Kim, 2001,Component Metrics to Measure Component Quality, Software Engineering Conference, APSEC,pp: [3] Yoonjung Choi ; Sungwook Lee ; Houp Song ; Jingoo Park ; SunHee Kim, 2008, Practical S/W Component Quality Evaluation Model, 10th International Conference on Advanced Communication Technology, pp: [4] Alexandre Alvaro, Eduardo Santana de Almeida, Silvio Lemos Meira, 2006, Software Component Quality Model: A Preliminary Evaluation, 32nd EUROMICRO Conference on Software Engineering and Advanced Applications, pp: [5] Goulao, M. ; Abreu, F.B,, 2007, Composition assessment metrics for CBSE, 31st EUROMICRO Conference on Software Engineering and Advanced Applicationspp: [6] Richard Berntsson Svensson, Martin Höst, Björn Regnell, 2010, Managing Quality Requirements: A Systematic Review,36th EUROMICRO Conference on Software Engineering and Advanced Applications, pp: [7] Sedigh-Ali, s. ; Ghafoor, A. ; Paul, R.A, 2003, Metrics and models for cost and quality of component-based software, Proceedings of the Sixth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 03), pp: [8] Aggarwal, K. K., Singh, Y., Chandra, P., Puri, M., 2005, Measurement of Software Maintainability, Journal of Computer Sciences, Vol. 1, Issue 4, pp: [9] Aggarwal, K. K., Singh, Y., Kaur, A., Malhotra, R., 2005, Software Reuse Metrics for Object-Oriented Systems, Proceedings of the Third ACIS Int'l Conference on Software Engineering Research, Management and Applications, Issue 8, pp: [10] Ahn, Y., Suh, J., Kim, S., Kim, H., 2003, The Software Maintenance Project Effort Estimation Model Based on Function Points, Journal of Software Maintenance: Research and Practice, Vol. 15, Issue 2, pp: [11] Alvero, A., Santana, E., Almeida, R., Meira, S., 2005, Quality Attributes for a Component Quality Model, Proceeding of 10th International Workshop on Component - Oriented Programming, pp: 1-9. [12] Ardimento, P., Bianchi, A., Visaggio, G., 2004, Maintenance-oriented Selection of Software Components, Proceedings of 8th European Conference on Software Maintenance and Reengineering, Issue 3,pp: [13] Bandi, R. K., Vaishnavi, V. K., Turk, D. E., 2003, Predicting maintenance performance using object-oriented design complexity metrics, IEEE Transactions on Software Engineering, Vol. 29, Issue 1, pp: [14] Bandini, S., Paoli, F. D., Manzoni, S., Mereghetti, P., 2002, A support system to COTSbased software development for business services, Proceedings of the 14th International Conference on Software Engineering and Know ledge Engineering, Italy, Issue 1,Vol. 27, pp: [15] Bansiya, J., Davis, C., 2002, A Hierarchical Model for Object-Oriented Design Quality assessment, IEEE Transactions on Software Engineering, Vol. 28, Issue 1, pp: [16] Bertoa, M., Troya, J. M., Vallecillo, A., 2006, Measuring the Usability of Software Components, Journal of Systems and Software, Vol. 79, Issue 3, pp: [17] Brereton, P., Budgen, D., 2000, Component-Based Systems: A Classification of Issues, IEEE Computer Transactions on Software Engineering, Vol. 33, Issue 11, pp: