SCAM – Software Component Assessment Model

Shared by: ijcsiseditor

Stats

views:: 53
posted:: 7/5/2011
language:: English
pages:: 6

Public Domain

Document Sample

(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 Wallnau define COTS components as
development is different from conventional development “Commercial entities – i.e. that can be sold or licensed that
because components offer accelerated growth. In the absence allow for packaging, distribution, storage, retrieval and
of an effective component assessment strategy the developers of customization by users, which are usually coarse grained
a software project have no way of assessing the quality of the
and that live in software repositories” [4]
software component they are about to incorporate into the
project. We present two laws that link software components, Using components to speed up the development process
software projects and their quality. We further propose a seems to present a very flexible and efficient solution
simple software component assessment strategy based on towards reaching our final product but in the absence of a
which both the component developers and component component assessment framework these components can
consumers can independently assess their component. prove fatal to our software project.
Most software components available over the internet lack
Keywords – software component; software component quality; necessary information by which they can be assessed.
software component assessment Furthermore there is no global software component
I. INTRODUCTION assessment model according to which software components
are ranked and appreciated. As the trend of using
Widespread use of computers and our dependency on components increases the situation starts becoming even
software has forced software developers to reconsider how graver because more and more developers now post their
we develop software systems. Now developers focus on own components on communities/groups/discussion groups
producing systems that are cheaper, more efficient, require for the benefit of other fellow developers. In this paper we
less development time and are not prone to errors. To first present two laws that govern software components,
achieve the above goals developers now increasingly use software projects and their quality. We further explain the
software components that can be plugged/imported into need for an assessment model for components. Then a
software development project [1] [2]. An advantage of such detailed study of the quality attributes of components is
components is that they largely promote reuse and are presented. In the end a five step assessment model is
considered tried and tested before they are added to the presented that is easily adoptable, extendible and
software project. Hence a precise definition for a component customizable.
would be
“An independent deployable implementation of some II. THE STRUCTURE OF A SOFTWARE
functionality, to be reused as-is in a broad spectrum of COMPONENT
applications” [3] A widely accepted view of software component is that it is a
Many organizations design their own software software element with two interfaces i.e. provides interface
components for reuse in their future software products. and required interface. The services available from the
Similarly many organizations purchase components from component are accessible through the provide interface
other organizations while other components are available as while the required interface is a collection point for the
open source components readily downloadable from the services/ parameters required by the software component. A
internet. COTS component (Commercial off-The Shelf software component is a complex entity because the
components) is a term that exactly explains the financial required and provide interface work together to produce the
aspect of the component development industry. Brown and promised functionality of the software component. Using
This research work is funded by National University of Sciences and
Technology (NUST), Pakistan.

229 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

these both interfaces the component becomes pluggable i.e. to quality.
an entity that can be attached and removed to the software Suppose we have a software system S. The software system
under development with relatively lesser effort. Newer is further composed of one or more software components �������� .
software component models reflect a software component as It is neither mandatory for the software or the component to
architectural units where the services are seen as ports. Ports be assessed before they are both fully integrated.
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.

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

Mathematically the integrated software components are a
III. NEED FOR COMPONENT ASSESSMENT subset of the whole software system S.
���� = ���� ��������
����=1 (1)
Software consumers use CMMI (Component Maturity
Model Integrated) rating to assess an organization in terms
Pre-integration Law The quality of an entire software
of coherence to the best software development practices.
system cannot be certified unless the components that
Similarly software component consumers need to be assured
constitute the software system are individually assessed and
that the components they are adopting have been developed
certified.
keeping in view the best practices and procedures. Our
vision for a component assessment model is that once a Post-integration Law If a software system and a component
component is assessed it should be appreciated and valued are individually assessed and certified prior to integration
according to its rating. The greatest advantage of such a then the software must be again fully tested after the
mechanism is that the components can be embedded into the integration of component is complete.
system under development with as little labour as possible.
But it is important to point out that the full potential of a V. COMPONENT QUALITY CERTIFICATION
software component can only be unleashed when the A very common method of assuring quality is through the
software component is used in collaboration with a use of certification. Essentially certification is the process of
component based software development model. It is widely assessing an entities quality against a set of properties. After
understood that component based development is different the assessment procedures, a formal certificate stating the
from conventional development because components offer quality level is issued in favour of the assessed entity. There
accelerated growth with certain limitations and problems. are numerous hurdles in component quality certification
Most software assessment methodologies assess the because the software component industry still has not
software on its code structure and requirement reached consensus on how certification should take place.
documentation [6]. A very small number of component Researchers are still unable to define the assessment
assessment methodologies assess components at the procedures, assessment guidelines (properties) and
elemental level. A software component should be fully necessary frameworks. Once all these are in place the
analyzed before it can be certified for wide circulation. certification procedures can take place in a cyclic and
Since all software components are designed for reuse and organized manner.
adoptability therefore assessment is a necessary requirement
before masses of consumers report errors and adoptability VI. COMPONENT QUALITY ATTRIBUTES
issues. Software components are different from regular software
systems because they are intended to be part of a larger
IV. LAWS OF SOFTWARE COMPONENT
system. Therefore it is recommended that software
QUALITY
components be assessed based on a wider scale and with a
Since there is no widely accepted software component different perspective. The quality attributes are
assessment model and strategy we therefore present two fundamentally influenced by the FURPS model. All quality
laws that link software and software components in relation attributes possess fuzzy overlapping boundaries because a

230 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

single attribute can be viewed from different perspectives be that it presents an attractive solution to problem that will
and sometimes attribute can be better defined in conjuncture be resolved by integrating the said component [9]. In
with other attributes. Here it is vital to define that there are addition the component should be highly suitable for the
some metrics that are internal while others are external system under development.
metrics. Internal metrics are more commonly known as E. Reliability
white box metrics. These view the component from an The reliability aspect is one of those attributes that is
internal perspective. Things like coding and specifications overlooked by many component developers. This attribute is
are mostly viewed here. On the other hand external metrics directly related with the quality attributes of the component.
mostly discuss the component from an external perspective. Reliability expresses the need for fault tolerance, error
That is why external metrics are also known as black box handling, recoverability and maturity. Evidence has shown
metrics. External metrics study things like component that in order for a component to be tolerated by a system an
operations, testing procedures and reliability. COTS additional wrapper has to be written for the component [9].
components generally fall under the category of external The purpose of such a scheme is that a wrapper provides a
metrics. It is also worth noting that the effect of components border within which the component must operate. The
can be both local and global in nature [7]. For example wrapper limits the problematic inputs and outputs to and
some components have a very limited/restricted scope; on from the component thereby increasing the reliability of the
the other hand there are components whose effect is on the component and the overall system. We can very easily
software architecture level. Even though SCAM presents a compare a component wrapper with a network firewall that
comprehensive list of software assessment attributes still it filters out what is bad for the system. If a component is
can never be guaranteed that the attribute full and complete supplied with an optional wrapper class then it will assist
in all respects. Discussed below is a range of quality the designers in fault tolerance and testing. Fig III shows a
attributes and their respective sub attributes based on which component enclosed in a wrapper for increased reliability.
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 Figure III. A Wrapper around a component
with which the component can be added or removed from F. Maintainability
the software under development. A good software Maintainability is an attribute that lies at the heart of all
component should have high plugability i.e. it should be software products. In maintainability we ensure that the
easy to assemble, easy to partially or entirely disassemble component has been developed keeping in view best
and highly adaptable. Since the plugability of the programming practices and therefore the component is in
component cannot be actually tested until the component is conformance with widely understood programming
actually incorporated into the software system therefore it is guidelines like modularity, structuredness and conformance
essential for the software architects to study the component to style.
in terms of availability of relevant interfaces, availability of G. Documentation Quality
specific classes and libraries. In most cases the designers and users of the component will
C. Reusability be entirely different therefore it is necessary for the
This component attribute clearly explains if the component component to be supplied with supporting documentation.
is reusable on a wide scale or not. This property implies that This documentation is crucial in providing support to the
the component has been designed for a broad range of users of the component because it will provide usage
platforms and languages. Also prerequisite requirements of instructions, relevant demos, known issues in the
the component should be low to facilitate ease of reuse and component, plugability details etc. Preferably the
increase plugability on a wider scale. documentation should be exhaustive in nature covering
D. Functionality every aspect of the component in a way that is easy to
The functionality attribute dictates whether the component interpret for the reader. When we say aspect this means
provides services just as it is supposed to under the specified coverage of - functionality, interfaces, configurable entities,
conditions. Another sub attribute of the component should version relevant information. Many components are freely

231 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

available as open source components while others may need software component. It is not necessary that all the above
to be purchased from the developers. Since the components described attributes are required for the assessment. For
may be following different licensing policies it is necessary example a component that only presents a cursor animation
for the owners to include all copyright notices and licenses may not need to be assessed from the perspective of
with the documentation. efficiency attribute.
H. Efficiency Step IV
Efficiency is a factor that is secondary in nature when After a joint decision a group meeting is arranged to study
assessing software components. The primary reason for this the component for the prescribed quality attributes. The
is that most software components are tweaked and adjusted component is graded out of 5 marks for each quality
according to the need of the application. This means that attribute. 0 is given if an attribute is entirely missing while 4
code is added to and removed from the component. The marks are given if the component demonstrates superior
efficiency of a software component is assessed in terms of conformance to a quality attribute. A component must
resource consumption and time requirements. conform to the sub attributes that come under a main
attribute. Non conformance or poor conformance to a
VII. SUGGESTED ASSESSMENT METHODOLOGY specific sub attribute can cause the component to not score
The assessment methodology has been developed keeping in in that specific attribute. For example while considering the
view that the assessment process is a team activity. It is efficiency attribute; if a component scores very poorly in
suggested that an assessment lead may be assigned to the terms of resource consumption then this should render a
whole process. Given below are the steps that form the score of very low score in the entire efficiency of the
assessment process. component. The sub attributes score Si and the obtained
Step I total score TS can be described by the following set of
The assessment lead forms a small team that will assess a mathematical equations.
particular software component. The team must hold people 1 8
�������� = 8 ����=1 �������� (2)
from various disciplines like software architects, software
programmers, software quality assurance personnel, Step V
software analysts, team leaders, project managers etc. After individual grading of the component quality attribute
Composing a team that has people belonging to various the total score of the component is calculated. The total
departments adds diversity and ensures exhaustive analysis score of a component is actually an aggregation of all the
of the software component. values of �������� . Since a components quality attributes are
Step II further described using sub attributes therefore it is
With the consensus of the entire team a software component mathematically easier to actually assess the entire quality
is chosen and each team member is required to deeply study attribute in terms of a single number obtained through the
the component from his/ her role specific perspective. formulae given in table 1.
Step III
Jointly the team decides which component quality attributes
need to be assessed for a complete assessment of the
TABLE I. Component Quality Attributes and Sub Attributes with Grading Formulae

Quality Attribute Sub Attributes (Si) Grading Formula (Ti)
Design Quality Design Legibility T1=(S1+S2+S3+S4+S5)/5
Interface Understandability
API Simplicity
Customizability
Design Maturity
Replacability/ Plugability Ease of Assembly T2=(S1+S2+S3)/3
Ease of Disassembly
Adaptability
Reusability Prerequisite Requirements T3=(S1+S2+S3)/3
Platform Conformance
Language Conformance
Functionality Availability of functionality T4=(S1+S2+S3)/3
Attractiveness
Suitability

232 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

Reliability Fault tolerance T5=(S1+S2+S3+S4+S5)/5
Error Handling
Component Maturity
Recoverability
Component Wrapper
Maintainability Modularity T6=(S1+S2+S3)/3
Structuredness
Conformance to Style
Documentation Quality Usage instructions T7=(S1+S2+S3+S4 +S5)/5
List of Known issues
Plugability details Where
Ease of Interpretation S5=(SS1+SS2+SS3+SS4+SS5)/5
Coverage Extent
Functionality (SS1)
Interfaces (SS2)
Configurable Entities (SS3)
Versioning Information (SS4)
Copyright/ Licensing (SS5)
Efficiency Resource Consumption T8=(S1+S2)/2
Time Requirements
Total Score (TS) =
(T1+T2+T3+T4+T5+T6+T7+T8)/8

VIII. ANALYTICAL STUDY grading described in table II. The obtained score
While studying the common attributes we have tried to exhaustively describes the component from an assessment
provide a comprehensive list of attributes that are further perspective. The score will numerate the components
composed of sub attributes. The sub attributes explain the conformance to a large number of attributes that cover many
main attributes from varying perspectives. The grading different perspectives of the component. Based on the
criterion is very simple and the score can only be given on a obtained score the assessment team can decide if the
scale of 5 numerical values. The table below explains the component qualifies for integration into the software
individual grade and their individual significance. project.
CONCLUSION
TABLE II. Grading values and their significance The non deterministic nature of software components has
Grade Significance forced researchers to consider introducing software
0 Attribute entirely missing component models that aid the software developers in the
incorporation and assessment of software components. In
1 Poor conformance
the non existence of such component models the software
2 Normal level Conformance developers are forced to blindly incorporate components
3 Good Conformance into their system. Software components present a very
4 Superior conformance to attribute attractive way of accelerating the development of software
systems, but in the absence of an effective component
There are many attributes in which an attributes score will assessment model the success of the software project is
not really matter to the assessment team although there will under serious jeopardy. In this paper we present a software
also be times when the assessment team will be looking for component assessment model that can assist software
a grade between 3 and 4. For example an assessment team developers, component developers and component
may require a component to score between 3 and 4 in the consumers in their efforts. A software component is a
functionality attribute. Also a team may choose to give a collection of many different attributes that when collected
grade to individual sub attributes in the form of floating reflect on the entire quality of the software component. Our
point numbers because a situation may arise where a proposed model is designed to be a team activity so that
component does not exactly qualify in accordance with a team members can analyze a component according to their
certain grade. particular domains.
The total score (TS) of the component will be a number We have proposed a model that assesses a software
between 0 and 4. The resulting score can be a floating point component on the basis of 8 attributes that are further
number and it can again be analyzed according to the composed of 33 sub attributes. Our proposed model

233 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(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. 427-
439 June 2005.

[9] Miguel Goulão 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)

234 http://sites.google.com/site/ijcsis/
ISSN 1947-5500