Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
SCAM – Software Component Assessment Model

SCAM – Software Component Assessment Model

Ratings: (0)|Views: 12 |Likes:
Published by ijcsis
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.
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.

More info:

Published by: ijcsis on Jul 07, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/12/2014

pdf

text

original

 
(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 EngineeringCollege of Electrical & Mechanical EngineeringNational University of Sciences and Technology (NUST)Islamabad, Pakistanhasanmailbox@yahoo.comaasia@ceme.nust.edu.pk ruhmatahir@ce.ceme.edu.pk 
 Abstract-
 
It is widely understood that component baseddevelopment is different from conventional developmentbecause components offer accelerated growth. In the absenceof an effective component assessment strategy the developers of a software project have no way of assessing the quality of thesoftware component they are about to incorporate into theproject. We present two laws that link software components,software projects and their quality. We further propose asimple software component assessment strategy based onwhich both the component developers and componentconsumers can independently assess their component.
 
 Keywords
 – 
software component; software component quality; software component assessment
I.
 
INTRODUCTIONWidespread use of computers and our dependency onsoftware has forced software developers to reconsider howwe develop software systems. Now developers focus onproducing systems that are cheaper, more efficient, requireless development time and are not prone to errors. Toachieve the above goals developers now increasingly usesoftware components that can be plugged/imported intosoftware development project [1] [2]. An advantage of suchcomponents is that they largely promote reuse and areconsidered tried and tested before they are added to thesoftware project. Hence a precise definition for a componentwould 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 softwarecomponents for reuse in their future software products.Similarly many organizations purchase components fromother organizations while other components are available asopen source components readily downloadable from theinternet. COTS component (Commercial off-The Shelf components) is a term that exactly explains the financialaspect of the component development industry. Brown andWallnau define COTS components as
“Commercial entities – 
i.e. that can be sold or licensed thatallow for packaging, distribution, storage, retrieval andcustomization by users, which are usually coarse grainedand that live in sof 
tware repositories”
[4]Using components to speed up the development processseems to present a very flexible and efficient solutiontowards reaching our final product but in the absence of acomponent assessment framework these components canprove 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 componentassessment model according to which software componentsare ranked and appreciated. As the trend of usingcomponents increases the situation starts becoming evengraver because more and more developers now post theirown components on communities/groups/discussion groupsfor the benefit of other fellow developers. In this paper wefirst present two laws that govern software components,software projects and their quality. We further explain theneed for an assessment model for components. Then adetailed study of the quality attributes of components ispresented. In the end a five step assessment model ispresented that is easily adoptable, extendible andcustomizable.II.
 
THE STRUCTURE OF A SOFTWARECOMPONENTA widely accepted view of software component is that it is asoftware element with two interfaces i.e. provides interfaceand required interface. The services available from thecomponent are accessible through the provide interfacewhile the required interface is a collection point for theservices/ parameters required by the software component. Asoftware component is a complex entity because therequired and provide interface work together to produce thepromised functionality of the software component. Using
This research work is funded by National University of Sciences andTechnology (NUST), Pakistan.
229http://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.an entity that can be attached and removed to the softwareunder development with relatively lesser effort. Newersoftware component models reflect a software component asarchitectural units where the services are seen as ports. Portsof two different units can be linked together usingconnectors [5]. The services available in a softwarecomponent can be advertised and accessed. A fundamentalproperty of all software components is that they can beincorporated into a wide range of software and that they arenot specifically designed for incorporation into a fixed set of software.
Figure I.
 
The two interfaces of a software component
III.
 
NEED FOR COMPONENT ASSESSMENTSoftware consumers use CMMI (Component MaturityModel Integrated) rating to assess an organization in termsof coherence to the best software development practices.Similarly software component consumers need to be assuredthat the components they are adopting have been developedkeeping in view the best practices and procedures. Ourvision for a component assessment model is that once acomponent is assessed it should be appreciated and valuedaccording to its rating. The greatest advantage of such amechanism is that the components can be embedded into thesystem under development with as little labour as possible.But it is important to point out that the full potential of asoftware component can only be unleashed when thesoftware component is used in collaboration with acomponent based software development model. It is widelyunderstood that component based development is differentfrom conventional development because components offeraccelerated growth with certain limitations and problems.Most software assessment methodologies assess thesoftware on its code structure and requirementdocumentation [6]. A very small number of componentassessment methodologies assess components at theelemental level. A software component should be fullyanalyzed before it can be certified for wide circulation.Since all software components are designed for reuse andadoptability therefore assessment is a necessary requirementbefore masses of consumers report errors and adoptabilityissues.IV.
 
LAWS OF SOFTWARE COMPONENTQUALITYSince there is no widely accepted software componentassessment model and strategy we therefore present twolaws that link software and software components in relationto quality.Suppose we have a software system
S
. The software systemis further composed of one or more software components
.It is neither mandatory for the software or the component tobe assessed before they are both fully integrated.
Figure: A software system
which is composed of components
where
=1,2,
,
 
Mathematically the integrated software components are asubset of the whole software system
S
.
=
=1
(1)
Pre-integration Law
The quality of an entire softwaresystem cannot be certified unless the components thatconstitute the software system are individually assessed andcertified.
Post-integration Law
If a software system and a componentare individually assessed and certified prior to integrationthen the software must be again fully tested after theintegration of component is complete.V.
 
COMPONENT QUALITY CERTIFICATIONA very common method of assuring quality is through theuse of certification. Essentially certification is the process of assessing an entities quality against a set of properties. Afterthe assessment procedures, a formal certificate stating thequality level is issued in favour of the assessed entity. Thereare numerous hurdles in component quality certificationbecause the software component industry still has notreached consensus on how certification should take place.Researchers are still unable to define the assessmentprocedures, assessment guidelines (properties) andnecessary frameworks. Once all these are in place thecertification procedures can take place in a cyclic andorganized manner.VI.
 
COMPONENT QUALITY ATTRIBUTESSoftware components are different from regular softwaresystems because they are intended to be part of a largersystem. Therefore it is recommended that softwarecomponents be assessed based on a wider scale and with adifferent perspective. The quality attributes arefundamentally influenced by the FURPS model. All qualityattributes possess fuzzy overlapping boundaries because a
230http://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 perspectivesand sometimes attribute can be better defined in conjuncturewith other attributes. Here it is vital to define that there aresome metrics that are internal while others are externalmetrics. Internal metrics are more commonly known aswhite box metrics. These view the component from aninternal perspective. Things like coding and specificationsare mostly viewed here. On the other hand external metricsmostly discuss the component from an external perspective.That is why external metrics are also known as black boxmetrics. External metrics study things like componentoperations, testing procedures and reliability. COTScomponents generally fall under the category of externalmetrics. It is also worth noting that the effect of componentscan be both local and global in nature [7]. For examplesome components have a very limited/restricted scope; onthe other hand there are components whose effect is on thesoftware architecture level. Even though SCAM presents acomprehensive list of software assessment attributes still itcan never be guaranteed that the attribute full and completein all respects. Discussed below is a range of qualityattributes and their respective sub attributes based on whichthe actual assessment will be done.
 A.
 
 Design Quality
 Design quality is an attribute that reflects the general qualitywith which the component has been designed. Designquality can be seen as generally accepted design principlesthat component developers base their component on. Subattributes for the design quality broadly explain this attributewith 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 reusabilityproperty of the software component. It describes the easewith which the component can be added or removed fromthe software under development. A good softwarecomponent should have high plugability i.e. it should beeasy to assemble, easy to partially or entirely disassembleand highly adaptable. Since the plugability of thecomponent cannot be actually tested until the component isactually incorporated into the software system therefore it isessential for the software architects to study the componentin terms of availability of relevant interfaces, availability of specific classes and libraries.
C.
 
 Reusability
This component attribute clearly explains if the componentis reusable on a wide scale or not. This property implies thatthe 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 andincrease plugability on a wider scale.
 D.
 
Functionality
The functionality attribute dictates whether the componentprovides services just as it is supposed to under the specifiedconditions. Another sub attribute of the component shouldbe that it presents an attractive solution to problem that willbe resolved by integrating the said component [9]. Inaddition the component should be highly suitable for thesystem under development.
 E.
 
 Reliability
The reliability aspect is one of those attributes that isoverlooked by many component developers. This attribute isdirectly related with the quality attributes of the component.Reliability expresses the need for fault tolerance, errorhandling, recoverability and maturity. Evidence has shownthat in order for a component to be tolerated by a system anadditional wrapper has to be written for the component [9].The purpose of such a scheme is that a wrapper provides aborder within which the component must operate. Thewrapper limits the problematic inputs and outputs to andfrom the component thereby increasing the reliability of thecomponent and the overall system. We can very easilycompare a component wrapper with a network firewall thatfilters out what is bad for the system. If a component issupplied with an optional wrapper class then it will assistthe designers in fault tolerance and testing. Fig III shows acomponent 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 allsoftware products. In maintainability we ensure that thecomponent has been developed keeping in view bestprogramming practices and therefore the component is inconformance with widely understood programmingguidelines like modularity, structuredness and conformanceto style.
G.
 
 Documentation Quality
In most cases the designers and users of the component willbe entirely different therefore it is necessary for thecomponent to be supplied with supporting documentation.This documentation is crucial in providing support to theusers of the component because it will provide usageinstructions, relevant demos, known issues in thecomponent, plugability details etc. Preferably thedocumentation should be exhaustive in nature coveringevery aspect of the component in a way that is easy tointerpret for the reader. When we say aspect this meanscoverage of - functionality, interfaces, configurable entities,version relevant information. Many components are freely
231http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->