(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No.

6, June 2011

SCAM Software Component Assessment Model

Hasan Tahir, Aasia Khannum, Ruhma Tahir
Department of Computer Engineering College of Electrical & Mechanical Engineering National University of Sciences and Technology (NUST) Islamabad, Pakistan hasanmailbox@yahoo.com aasia@ceme.nust.edu.pk ruhmatahir@ce.ceme.edu.pk

Abstract- It is widely understood that component based development is different from conventional development because components offer accelerated growth. In the absence of an effective component assessment strategy the developers of a software project have no way of assessing the quality of the software component they are about to incorporate into the project. We present two laws that link software components, software projects and their quality. We further propose a simple software component assessment strategy based on which both the component developers and component consumers can independently assess their component. Keywords software component; software component quality; software component assessment

I.

INTRODUCTION

Widespread use of computers and our dependency on software has forced software developers to reconsider how we develop software systems. Now developers focus on producing systems that are cheaper, more efficient, require less development time and are not prone to errors. To achieve the above goals developers now increasingly use software components that can be plugged/imported into software development project [1] [2]. An advantage of such components is that they largely promote reuse and are considered tried and tested before they are added to the software project. Hence a precise definition for a component would be An independent deployable implementation of some functionality, to be reused as-is in a broad spectrum of applications [3] Many organizations design their own software components for reuse in their future software products. Similarly many organizations purchase components from other organizations while other components are available as open source components readily downloadable from the internet. COTS component (Commercial off-The Shelf components) is a term that exactly explains the financial aspect of the component development industry. Brown and
This research work is funded by National University of Sciences and Technology (NUST), Pakistan.

Wallnau define COTS components as Commercial entities i.e. that can be sold or licensed that allow for packaging, distribution, storage, retrieval and customization by users, which are usually coarse grained and that live in software repositories [4] Using components to speed up the development process seems to present a very flexible and efficient solution towards reaching our final product but in the absence of a component assessment framework these components can prove fatal to our software project. Most software components available over the internet lack necessary information by which they can be assessed. Furthermore there is no global software component assessment model according to which software components are ranked and appreciated. As the trend of using components increases the situation starts becoming even graver because more and more developers now post their own components on communities/groups/discussion groups for the benefit of other fellow developers. In this paper we first present two laws that govern software components, software projects and their quality. We further explain the need for an assessment model for components. Then a detailed study of the quality attributes of components is presented. In the end a five step assessment model is presented that is easily adoptable, extendible and customizable. II. THE STRUCTURE OF A SOFTWARE COMPONENT

A widely accepted view of software component is that it is a software element with two interfaces i.e. provides interface and required interface. The services available from the component are accessible through the provide interface while the required interface is a collection point for the services/ parameters required by the software component. A software component is a complex entity because the required and provide interface work together to produce the promised functionality of the software component. Using

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

these both interfaces the component becomes pluggable i.e. an entity that can be attached and removed to the software under development with relatively lesser effort. Newer software component models reflect a software component as architectural units where the services are seen as ports. Ports of two different units can be linked together using connectors [5]. The services available in a software component can be advertised and accessed. A fundamental property of all software components is that they can be incorporated into a wide range of software and that they are not specifically designed for incorporation into a fixed set of software.

to quality. Suppose we have a software system S. The software system is further composed of one or more software components . It is neither mandatory for the software or the component to be assessed before they are both fully integrated.

Figure: A software system which is composed of components where = 1,2, , Figure I. The two interfaces of a software component

III.

NEED FOR COMPONENT ASSESSMENT

Software consumers use CMMI (Component Maturity Model Integrated) rating to assess an organization in terms of coherence to the best software development practices. Similarly software component consumers need to be assured that the components they are adopting have been developed keeping in view the best practices and procedures. Our vision for a component assessment model is that once a component is assessed it should be appreciated and valued according to its rating. The greatest advantage of such a mechanism is that the components can be embedded into the system under development with as little labour as possible. But it is important to point out that the full potential of a software component can only be unleashed when the software component is used in collaboration with a component based software development model. It is widely understood that component based development is different from conventional development because components offer accelerated growth with certain limitations and problems. Most software assessment methodologies assess the software on its code structure and requirement documentation [6]. A very small number of component assessment methodologies assess components at the elemental level. A software component should be fully analyzed before it can be certified for wide circulation. Since all software components are designed for reuse and adoptability therefore assessment is a necessary requirement before masses of consumers report errors and adoptability issues. IV. LAWS OF SOFTWARE COMPONENT QUALITY

Mathematically the integrated software components are a subset of the whole software system S. = (1) =1 Pre-integration Law The quality of an entire software system cannot be certified unless the components that constitute the software system are individually assessed and certified. Post-integration Law If a software system and a component are individually assessed and certified prior to integration then the software must be again fully tested after the integration of component is complete. V. COMPONENT QUALITY CERTIFICATION

A very common method of assuring quality is through the use of certification. Essentially certification is the process of assessing an entities quality against a set of properties. After the assessment procedures, a formal certificate stating the quality level is issued in favour of the assessed entity. There are numerous hurdles in component quality certification because the software component industry still has not reached consensus on how certification should take place. Researchers are still unable to define the assessment procedures, assessment guidelines (properties) and necessary frameworks. Once all these are in place the certification procedures can take place in a cyclic and organized manner. VI. COMPONENT QUALITY ATTRIBUTES

Since there is no widely accepted software component assessment model and strategy we therefore present two laws that link software and software components in relation

Software components are different from regular software systems because they are intended to be part of a larger system. Therefore it is recommended that software components be assessed based on a wider scale and with a different perspective. The quality attributes are fundamentally influenced by the FURPS model. All quality attributes possess fuzzy overlapping boundaries because a

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

single attribute can be viewed from different perspectives and sometimes attribute can be better defined in conjuncture with other attributes. Here it is vital to define that there are some metrics that are internal while others are external metrics. Internal metrics are more commonly known as white box metrics. These view the component from an internal perspective. Things like coding and specifications are mostly viewed here. On the other hand external metrics mostly discuss the component from an external perspective. That is why external metrics are also known as black box metrics. External metrics study things like component operations, testing procedures and reliability. COTS components generally fall under the category of external metrics. It is also worth noting that the effect of components can be both local and global in nature [7]. For example some components have a very limited/restricted scope; on the other hand there are components whose effect is on the software architecture level. Even though SCAM presents a comprehensive list of software assessment attributes still it can never be guaranteed that the attribute full and complete in all respects. Discussed below is a range of quality attributes and their respective sub attributes based on which the actual assessment will be done. A. Design Quality Design quality is an attribute that reflects the general quality with which the component has been designed. Design quality can be seen as generally accepted design principles that component developers base their component on. Sub attributes for the design quality broadly explain this attribute with more accuracy. The sub attributes are design legibility, interface understandability [8], API simplicity, customizability and overall design maturity. B. Replaceability/ Plugability This component attribute directly influences the reusability property of the software component. It describes the ease with which the component can be added or removed from the software under development. A good software component should have high plugability i.e. it should be easy to assemble, easy to partially or entirely disassemble and highly adaptable. Since the plugability of the component cannot be actually tested until the component is actually incorporated into the software system therefore it is essential for the software architects to study the component in terms of availability of relevant interfaces, availability of specific classes and libraries. C. Reusability This component attribute clearly explains if the component is reusable on a wide scale or not. This property implies that the component has been designed for a broad range of platforms and languages. Also prerequisite requirements of the component should be low to facilitate ease of reuse and increase plugability on a wider scale. D. Functionality The functionality attribute dictates whether the component provides services just as it is supposed to under the specified conditions. Another sub attribute of the component should

be that it presents an attractive solution to problem that will be resolved by integrating the said component [9]. In addition the component should be highly suitable for the system under development. E. Reliability The reliability aspect is one of those attributes that is overlooked by many component developers. This attribute is directly related with the quality attributes of the component. Reliability expresses the need for fault tolerance, error handling, recoverability and maturity. Evidence has shown that in order for a component to be tolerated by a system an additional wrapper has to be written for the component [9]. The purpose of such a scheme is that a wrapper provides a border within which the component must operate. The wrapper limits the problematic inputs and outputs to and from the component thereby increasing the reliability of the component and the overall system. We can very easily compare a component wrapper with a network firewall that filters out what is bad for the system. If a component is supplied with an optional wrapper class then it will assist the designers in fault tolerance and testing. Fig III shows a component enclosed in a wrapper for increased reliability.

Figure III. A Wrapper around a component

F. Maintainability Maintainability is an attribute that lies at the heart of all software products. In maintainability we ensure that the component has been developed keeping in view best programming practices and therefore the component is in conformance with widely understood programming guidelines like modularity, structuredness and conformance to style. G. Documentation Quality In most cases the designers and users of the component will be entirely different therefore it is necessary for the component to be supplied with supporting documentation. This documentation is crucial in providing support to the users of the component because it will provide usage instructions, relevant demos, known issues in the component, plugability details etc. Preferably the documentation should be exhaustive in nature covering every aspect of the component in a way that is easy to interpret for the reader. When we say aspect this means coverage of - functionality, interfaces, configurable entities, version relevant information. Many components are freely

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

available as open source components while others may need to be purchased from the developers. Since the components may be following different licensing policies it is necessary for the owners to include all copyright notices and licenses with the documentation. H. Efficiency Efficiency is a factor that is secondary in nature when assessing software components. The primary reason for this is that most software components are tweaked and adjusted according to the need of the application. This means that code is added to and removed from the component. The efficiency of a software component is assessed in terms of resource consumption and time requirements. VII. SUGGESTED ASSESSMENT METHODOLOGY The assessment methodology has been developed keeping in view that the assessment process is a team activity. It is suggested that an assessment lead may be assigned to the whole process. Given below are the steps that form the assessment process. Step I The assessment lead forms a small team that will assess a particular software component. The team must hold people from various disciplines like software architects, software programmers, software quality assurance personnel, software analysts, team leaders, project managers etc. Composing a team that has people belonging to various departments adds diversity and ensures exhaustive analysis of the software component. Step II With the consensus of the entire team a software component is chosen and each team member is required to deeply study the component from his/ her role specific perspective. Step III Jointly the team decides which component quality attributes need to be assessed for a complete assessment of the Quality Attribute Design Quality

software component. It is not necessary that all the above described attributes are required for the assessment. For example a component that only presents a cursor animation may not need to be assessed from the perspective of efficiency attribute. Step IV After a joint decision a group meeting is arranged to study the component for the prescribed quality attributes. The component is graded out of 5 marks for each quality attribute. 0 is given if an attribute is entirely missing while 4 marks are given if the component demonstrates superior conformance to a quality attribute. A component must conform to the sub attributes that come under a main attribute. Non conformance or poor conformance to a specific sub attribute can cause the component to not score in that specific attribute. For example while considering the efficiency attribute; if a component scores very poorly in terms of resource consumption then this should render a score of very low score in the entire efficiency of the component. The sub attributes score Si and the obtained total score TS can be described by the following set of mathematical equations.

= 8

8 =1

(2)

Step V After individual grading of the component quality attribute the total score of the component is calculated. The total score of a component is actually an aggregation of all the values of . Since a components quality attributes are further described using sub attributes therefore it is mathematically easier to actually assess the entire quality attribute in terms of a single number obtained through the formulae given in table 1.

TABLE I. Component Quality Attributes and Sub Attributes with Grading Formulae

Replacability/ Plugability

Reusability

Functionality

Sub Attributes (Si) Design Legibility Interface Understandability API Simplicity Customizability Design Maturity Ease of Assembly Ease of Disassembly Adaptability Prerequisite Requirements Platform Conformance Language Conformance Availability of functionality Attractiveness Suitability

Grading Formula (Ti) T1=(S1+S2+S3+S4+S5)/5

T2=(S1+S2+S3)/3

T3=(S1+S2+S3)/3

T4=(S1+S2+S3)/3

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

Reliability

Maintainability

Documentation Quality

Efficiency

Fault tolerance Error Handling Component Maturity Recoverability Component Wrapper Modularity Structuredness Conformance to Style Usage instructions List of Known issues Plugability details Ease of Interpretation Coverage Extent Functionality (SS1) Interfaces (SS2) Configurable Entities (SS3) Versioning Information (SS4) Copyright/ Licensing (SS5) Resource Consumption Time Requirements

T5=(S1+S2+S3+S4+S5)/5

T6=(S1+S2+S3)/3

T7=(S1+S2+S3+S4 +S5)/5 Where S5=(SS1+SS2+SS3+SS4+SS5)/5

T8=(S1+S2)/2 Total Score (TS) = (T1+T2+T3+T4+T5+T6+T7+T8)/8

VIII. ANALYTICAL STUDY While studying the common attributes we have tried to provide a comprehensive list of attributes that are further composed of sub attributes. The sub attributes explain the main attributes from varying perspectives. The grading criterion is very simple and the score can only be given on a scale of 5 numerical values. The table below explains the individual grade and their individual significance.
TABLE II. Grading values and their significance

grading described in table II. The obtained score exhaustively describes the component from an assessment perspective. The score will numerate the components conformance to a large number of attributes that cover many different perspectives of the component. Based on the obtained score the assessment team can decide if the component qualifies for integration into the software project.
CONCLUSION

Grade 0 1 2 3 4

Significance Attribute entirely missing Poor conformance Normal level Conformance Good Conformance Superior conformance to attribute

There are many attributes in which an attributes score will not really matter to the assessment team although there will also be times when the assessment team will be looking for a grade between 3 and 4. For example an assessment team may require a component to score between 3 and 4 in the functionality attribute. Also a team may choose to give a grade to individual sub attributes in the form of floating point numbers because a situation may arise where a component does not exactly qualify in accordance with a certain grade. The total score (TS) of the component will be a number between 0 and 4. The resulting score can be a floating point number and it can again be analyzed according to the

The non deterministic nature of software components has forced researchers to consider introducing software component models that aid the software developers in the incorporation and assessment of software components. In the non existence of such component models the software developers are forced to blindly incorporate components into their system. Software components present a very attractive way of accelerating the development of software systems, but in the absence of an effective component assessment model the success of the software project is under serious jeopardy. In this paper we present a software component assessment model that can assist software developers, component developers and component consumers in their efforts. A software component is a collection of many different attributes that when collected reflect on the entire quality of the software component. Our proposed model is designed to be a team activity so that team members can analyze a component according to their particular domains. We have proposed a model that assesses a software component on the basis of 8 attributes that are further composed of 33 sub attributes. Our proposed model

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 9, No. 6, June 2011

recommends the formation of an assessment team that assesses the component on the basis of these attributes. A grading criteria is also defined that is based on a scale of 5 (0 to 4) numerical values. During the assessment of a component the obtained grade is always in the range of 0 to 4 because first the component is assessed on the basis of individual attributes and then the individual scores are computed to form a total score based on which the assessment team can decide if the component qualifies for integration into the software project. The provided list of attributes is exhaustive in nature. This list will not continue to increase endlessly because if the team decides to incorporate more attributes into the assessment process then it will definitely discard some attributes as well. Since software components belong to a wide range of domains therefore it can be said that no single component will need to be assessed according to all the attributes given in this model. REFERENCES
[1] Bass, L., Buhman, C., Comella-Dorda, S., Long, F., Robert, J., Seacord, R. and Wallnau, K, Volume I: Market Assessment of Component-Based Software Engineering, Software Engineering Institute, 2001. [2] Williams, J. D, "Raising Components Application Development Trends, 7(9) (2000), pp. 27-32. [3] L. Bass, C. Buhman, S.Comella-Dorda, F. Long, J. Robert, R. Seacord and K. Wallnau, Volume I: Market Assessment of Component-Based Software Engineering, Software Engineering Institute, Technical Note CMU/SEI-2001-TN-007, May 2000. [4] A.W. Brown, K. Wallnau, The current state of CBSE. IEEE Software 15 (5), pp.37-46, 1999. [5] K. Lau, Z. Wang, Software Component Models IEEE Transactions on Software Engineering Volume 33 Number 10 2007. [6] Zhu H, Hall PAV, May JHR, Software Unit Test Coverage and Adequacy, ACM Computing Surveys 1997. [7] M. F. Bertoa, A. Vallecillo, Quality Attributes for COTS Components. [8] M. F. Berota, J. M.Troya, A. Vallecillo, Measuring the Usability of Software Components. Elsevier Journal of Systems and Software. pp. 427439 June 2005. [9] Miguel Goulo Fernando Brito e Abreu, The Quest for Software Components Quality, 2002. AUTHORS PROFILE Hasan Tahir is with the NUST College of Electrical & Mechanical Engineering (phone: +92-333-5241987; email: hasanmailbox@yahoo.com) Dr Aasia Khannum is with the NUST College of Electrical & Mechanical Engineering (phone: +92-51-9278050 Ext 4114; email: aasia@ceme.nust.edu.pk) Ruhma Tahir is with the NUST College of Electrical & Mechanical Engineering (email: ruhmatahir@ce.ceme.edu.pk)