J. Software Engineering & Applications, 2010, 3, 556-560
doi:10.4236/jsea.2010.36064 Published Online June 2010 (http://www.SciRP.org/journal/jsea)
On Some Quality Issues of Component Selection in
CBSD
Jeetendra Pande1, Raj Kishore Bisht1, Durgesh Pant2, Vinay Kumar Pathak3
1Department of Computer Science, Amrapali Institute of Technology & Sciences, Haldwani, India; 2Department of Computer
Science, Kumaun University, Uttarakhand, India; 3Uttarakhand Open University, Haldwani, India.
Received March 11th, 2010; revised March 27th, 2010; accepted March 29th, 2010.
ABSTRACT
Component based development offers many potential benefits, viz. software reuse, reduced time-to-market, inter-
operability, ease of quality certification etc. However, it is not always that benefits derived from addition of components
from a component repository are more than the costs involved in developing the module from scratch. This work evaluates
various software quality models and suggests recommendations for enhancing software quality in COTS (component
off-the-shelf) based software products by designing software quality metrics that would help in managing and enhancing
quality in component-based software development.
Keywords: Component Based Software Development (CBSD), Components-off-the-Shelf (COTS), McCall’s Model,
Dormey’s Model, Bohem’s Model
1. Introduction
Software is at the heart of most industrial systems in use
today. Rapid changes in industrial methods have led to a
situation where industrial products are now, more often
than not, systems consisting of software and hardware.
Industries in which the use of software is now essential
include, among others, Automotive, Medical-Systems,
Process-Control and Manufacturing. In these and others,
value added to products is provided largely by the asso-
ciated software.
The economics of software projects has been seen as
an important sub-discipline of software engineering for
some time. Projects need to be considered in a wider bu-
siness environment in which the issues of cost, schedule
and productivity are of considerable significance. A key
area in dealing with cost and quality of software systems
is the ease and benefits accruing from reuse, i.e. how
much can be saved by using existing software compo-
nents when developing new software systems? To this
end, Component Based Development (CBD) is widely
accepted as the approach that could best yield the long
sought after benefits of software reuse, reduced time-to-
market, interoperability and ease of quality certification.
The basis for reuse is the reliability of the components
intended for reuse and the gains achieved through their
application.
It is important to demonstrate to management and
funding agencies that reuse makes good business sense.
For this, it is necessary to have methods to collate and
furnish clear financial evidence of benefits of reuse in
real projects. To achieve this, we need to define good
metrics that capture these benefits and develop tools and
processes to allow effective use of these metrics. De-
ployment of component-based applications is a common
practice in the area of commercial software. To meet
market requirements, new functionality is frequently
added to industrial products. Introduction of new func-
tionality is often achieved by adding components to an
existing system. This is why component-based develop-
ment approach is attractive to industry.
Cost and time-to-market issues are addressed by taking
recourse to the rapidly emerging component-based de-
velopment (CBD) approach. Adding new functionality to
existing products must result in lower cost and higher
quality. In CBD, software systems are built as an assem-
bly of components already developed and prepared for
integration. The many advantages of CBD approach in-
clude effective management of complexity, reduced time
-to-market, increased productivity, and greater degree of
consistency and a wider range of usability. Thus, quality
of the final software is highly influenced by use of CBD
approach. Each component will have its own quality at-
tribute profile, but when interfaced and used together
with other components, the resulting composition may
show a different quality attribute profile altogether [1]. A

On Some Quality Issues of Component Selection in CBSD557
large range of components, which perform the same
function, are available from different vendors. This
makes it very difficulty for a developer to decide which
component to use and which to discard, based on the
quality attributes of available competing components.
Quality of an individual component is important but
there is no guarantee that integration of components with
high quality attributes will lead to a software product
with overall high quality attributes. When multiple com-
ponents are integrated, it is very difficult to reason about
the overall quality of the final product and developers
require some metric that helps them in evaluating and
choosing components in such a manner that the final
product is of high quality.
Project managers usually lay stress on the importance
of improving estimation accuracy and techniques to
support better estimates. This paper surveys the status of
quality framework in component based software devel-
opment and provides recommendations for future work
in improving the quality of component based software
development.
2. Software Quality Models
According to IEEE 610.12 standard [2], software quality
is:
 The degree to which a system, component or
process meets specified requirements.
 The degree to which a system, component or
process meets customer or user needs or expec-
tation.
The following section briefly explains the various
quality models for software development.
2.1 Mccall’s Model (1977)
The first quality model was proposed by Jim McCall et
al [3,4], in 1977. This model is also known as the Gen-
eral Electric Model. McCall split eleven different quality
attributes into three groups, as shown in Table 1.
1) Product Operation: It includes correctness, reliabil-
ity, efficiency, integrity and usability.
2) Product Revision: It includes maintainability, flexi-
bility and testability.
3) Product Transition: It includes portability, reusabil-
ity and interoperability.
With the aim of improving quality of software prod-
ucts, McCall included a number of quality factors in his
Table 1. McCall’s model
Product Operation Product Revision Product Transition
• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
• Maintainability
• Flexibility
• Testability
• Portability
• Reusability
• Interoperability
model that gave due weight to both users’ views and de-
velopers’ priorities.
The advantage of McCall’s Quality Model is the rela-
tionship created between quality characteristics and met-
rics. The major disadvantage is that functionality of the
software product is not considered.
2.2 Boehm’s Model (1978)
Barry W. Bohem gave the second quality model in 1978.
Boehm’s model is similar to the McCall’s Quality Model
in that it also presents a hierarchical quality model struc-
tured around high-level characteristics, intermediate-
level characteristics and primitive characteristics – each
of which contributes to the overall quality level [5,6].
High-level characteristics represent high-level requi-
rements of actual use. These characteristics address three
main questions:
1) As-is utility
2) Maintainability
3) Portability
These three primary uses had quality factors associated
with them, which represented the next level of Boehm's
hierarchical model, the intermediate-level characteristics.
Boehm identified seven quality factors, namely:
(a) Portability (b) Reliability (c) Efficiency (d) Usability
(e) Testability (f) Understandability (g) Flexibility
The lowest level structure of the characteristics hier-
archy in Boehm’s model is the primitive characteristics
metrics hierarchy, in which these quality factors are fur-
ther broken down into Primitive constructs that can be
measured. For example, Testability is broken down into
accessibility, communicativeness, structure and self-de-
scriptiveness. Bohem’s model lays emphasis on main-
tainability of the software product. It includes considera-
tions involved in evolution of a software product with
respect to the utility of the program. Boehm’s quality
model is based on a wide range of characteristics but
does not elaborate on the methodology of measuring
these characteristics.
2.3 FURPS/FURPS+ (1992)
This model, proposed by Robert Grady and Hewlett-
Packard Co, decomposes characteristics into two differ-
ent categories of requirements:
 Functional Requirements (F): Defined by input
and expected output.
 Non-functional Requirements (NF): Usability,
Reliability, Performance and Supportability.
FURPS is an acronym representing a model for clas-
sifying software quality attributes (requirements):
 Functionality–Feature set, Capabilities, Gener-
ality, and Security.
 Usability–Human factors, Aesthetics, Consis-
tency and Documentation.

On Some Quality Issues of Component Selection in CBSD 558
 Reliability–Frequency/severity of failure, re-
coverability, predictability, accuracy and mean
time to failure.
 Performance–Speed, efficiency, resource con-
sumption, throughput and response time.
 Supportability–testability, extensibility, adapt-
ability, maintainability, compatibility, configu-
rability, serviceability, installability, localizabil-
ity and portability.
The main disadvantage of the FURPS model is it does
not take into account the portability of the software pro-
duct. Rational Software extended this model to FUR-
PUS+, for use in corporate requirements such as design
constrains, implementation requirements, interface re-
quirements and physical requirements.
2.4 Dromey’s Model (1996)
R. Goeff Dromey proposed this model in 1996 [7,8].
According to Dormey, high level attributes like reliabil-
ity and maintainability cannot be built into software.
Therefore, he identified a set of properties to cover these
requirements. In this model, Dormey focused on those
properties of the software product that affect the quality
attributes. He connected software product quality with
software quality attributes (Table 2).
The disadvantage of this model is that efficiency of
software is not considered for determining the quality of
software.
2.5 ISO Model 9126 (1991)
ISO 9126 model was proposed in 1991. Unlike its
predecessors, MaCall’s Model and Bohem’s Model,
upon which this model was built, functionality of a soft-
ware product is also taken into consideration in this
model. It proposes a generic definition of software qual-
ity in terms of six quality factors, which further covers
some sub factors:
 Functionality–Suitability, accuracy, interoper-
ability, compliance and security.
 Maintainability–Analyzability, changeability,
stability and testability.
 Usability–Understandability, learnability, oper-
ability and likeability.
 Efficiency–Time-behaviour and Resource-be-
haviour.
 Portability–Adaptability, replaceability, instal-
lability, conformance and coexistence.
 Reliability–Maturity, recoverability, availabil-
ity and fault-tolerance.
It defines the internal and external quality characteristics
of the software product. The main disadvantage of this
model is how these characteristics are to be measured.
3. Component Based System Development
A component is [11,12] a language neutral, independ-
ently implemented package of software services, deliv-
ered in an encapsulated and replaceable container, ac-
cessed via one or more published interfaces. While a
component may have the ability to modify a database, it
should not be expected to maintain state information. A
component is neither platform-constrained nor is it ap-
plication-bound.
Following the success of the structured design and OO
paradigms, Component-Based Software Development
(CBSD) has emerged as the next revolution in software
development [13].
The idea behind CBSD is integrate the reusable com-
ponents to develop the final product. This strategy re-
duces the development effort, time-to-market and cost.
Quality and reliability come as inherited features in the
product developed using CBSD approach, as the compo-
nents used are time tested.
4. Quality of Component based software
Development
In software product development using CBSD, the pro-
grammer’s role is to integrate the pre-existing software
components. The various software quality models dis-
cussed above are generic models. These models do not
address the quality issues for CBSD. Bertoa [14] pro-
posed a quality model for component based software de-
velopment that allows an effective assessment of COTS
components. This quality model is based on ISO 9126,
adapted to deal with specific characteristics of COTS
components. In the proposed model, five of the charac-
teristics of the ISO 9126 model have been retained while
the sixth characteristic, namely Portability, has been re-
moved. Additionally, suitability and analyzability sub-cha-
racteristics have also been removed and two new sub-
Table 2. Dormey’s quality model
Software product Implementation
Software product quality Correctness Internal Contextual Descriptive
Software quality attributes Functionality, reliability
Maintainability
Efficiency,
reliability
Maintainability
Reusability,
Portability,
Reliability
Maintainability
Reusability,
Portability,
Usability

On Some Quality Issues of Component Selection in CBSD559
characteristics, namely compatibility and complexity,
have been introduced (Table 3). The sub-characteristics
have been further classified into two different categories,
namely run time and life cycle sub-characteristics. Some
of the characteristics (Usability) and sub-characteristics
(learnability, understandability and operability) have
changed meaning in the proposed model.
However, this model fails to validate itself on any ap-
plication. Adnan & Bassem [15] has also done excellent
work on developing a quality model for evaluating
COTS components that support a standard set of quality
characteristics. This model is developed based on study
done on the six generic quality models. Staring with ISO
9126 model as a base, necessary changes have been
made in it to customize it to suit COTS based develop-
ment. A new characteristic, viz. Stakeholders, is pro-
posed in this new model. It depends upon who are the
members of the team responsible for developing, main-
taining, integrating and/or using information system
based on COTS systems (Figure 1).
The major drawback of this model is that it fails to ex-
plain how to measure the internal quality characteristics.
Ali, Gafoor & Paul [P] proposed a new approach using a
set of 13 system-level metrics, which are divided into 3
categories viz. Management, Requirement and Quality
(Table 4).
This metrics helps managers select between appropri-
ate components from a repository of software products
and aid them in deciding between using COTS compo-
nents or developing new components. This model, how-
ever, does not say much about how these metric are mea-
sured/quantified. Jasmine & Vasantha [Q] propose De-
fect Removal Efficiency–a quality metric that provides
benefits at both project and process levels. They rede-
fined the basic definition of defect removal efficiency in
terms of the phases involved in reuse-based development
and proposed a systematic approach in the defect re-
moval process. Sharma et al. [R] proposed a quality
model based on ISO9126 that 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 CBSD context. This model can also be
used to estimate the efforts required to achieve the re-
quired value of any characteristic.
5. Untouched Quality Related Issues in
Component Selection Process
In an application developed using COTS approach, vari-
ous components are integrated with each other to build
the whole system of desired quality. This integration
process is the most crucial part of the CBSD. There may
be more than one component available in the repository
or more then one vendor available for the same compo-
nent that performs the desired task. Each individual com-
ponent from the different sources has different quality
attributes. When these individual components are inte-
grated to develop a whole system, the quality attributes
of components may change and affect the quality of the
overall system.
There is an absence of any kind of metrics that can
help in selecting between different components from
different sources with the same functionality by evaluat-
ing relevant quality parameters of the component, such as
cost-avoidance, reliability, productivity etc.
There is an increasing need for metrics meant specifi-
cally for component-based software, to help foster and
manage quality in component-based software development.
This is because traditional software product and process
metrics are neither suitable for nor sufficient in managing
the complexity of software components, which is neces-
sary for quality and productivity improvement within
Table 3. Quality model for COTS components by Bertoa
Characteristic Functionality Reliability Usability Efficiency Maintainability
Runtime Sub-characteristics Accuracy, Security Recove-rability Time Behavior,
Resource Behavior
Life Cycle Sub-characteristics
Suitability,
Interoperability,
Compliance,
Compatibility
Maturity
Learn ability,
Understand-ability,
Operability,
Complexity
Changeability,
Testability
Table 4. System level metric for component based system
Category Management Requirements Quality
Cost Requirements ConformanceAdaptability
Time to market Requirements stability Complexity of interfaces and integration
Software engineering environment Integration test coverage
System resource utilization End-to-end test coverage
Fault profiles
Reliability
Metric
Customer satisfaction

On Some Quality Issues of Component Selection in CBSD 560
Figure 4. The new quality model for COTS-based systems
organizations adopting component-based software deve-
lopment.
6. Conclusions
This paper presents a survey of various generic quality
models as well as quality models for COTS development.
Based on this survey, some unanswered issues related to
CBSD have been identified.
Future work in the development of CBSD research
could include determination of quality metrics for compo-
nents selection where there is more then one component
available for the same task. This metric would help the
developer/integrator in selecting between various compo-
nents or decide upon develop the component from scratch.
This metric should be easy to calculate and be feasible for
practical use. The field of quality attribute determination
of component-based system is extensive and more re-
search 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] J. A. Borretzen, “The Impact of Component-Based Deve-
lopment on Software Quality Attributes,” http://www. too-
doc.com/Software-quality-attribute-pdf.html
[2] “IEEE Standard Glossary of Software Engineering Term-
inologies,” IEEE Standard 610.12-1990, 10 December
1990.
[3] J. A. McCall, P. K. Richards and G. F. Walters, “Factors in
Software Quality,” Griffiths Air Force Base, New York
Rome Air Development Center Air Force Systems
Command, 1977.
[4] J. A. McCall, P. K. Richards and G. F. Walters, “Factors in
Software Quality,” National Technology Information
aracteristics of Software
nference on Software
Software Engineering, Vol. 21, No.
C
s and Guidelines for
www.
ng Machinery, Vol.
Machinery, Vol. 46, No. 8, August
d Software Engineering (QAOOSE), Malaga,
l of
Computer Science, Vol. 2, No. 4, 2006, pp. 373-381.
Service, Vol. 1, No. 2-3, 1977.
[5] B. W. Boehm, J. R. Brown, H. Kaspar, M. Lipow, G.
McLeod and M. Merritt, “Ch
Quality,” North Holland, 1978.
[6] B. W. Boehm, W. Barry, J. R. Brown and M. Lipow,
“Quantitative Evaluation of Software Quality,” Inter-
national Conference on Software Engineering, Procee-
dings of the 2nd International Co
Engineering, San Francisco, 1976.
[7] R. G. Dromey, “Concerning the Chimera (Software
Quality),” IEEE Software, Vol. 13, No. 1, 1996, pp. 33-43.
[8] R. G. Dromey, “A Model for Software Product Quality,”
IEEE Transactions on
2, 1995, pp. 146-163.
[9] ISO 9126, “Information Technology-Product Quality-
Part1: Quality Model,” International Standard ISO/IE
9126, International Standard Organization, June 2001.
[10] ISO 9126, “Information Technology-Software Product
Evaluation-Quality Characteristic
their Use,” ISO, December 1991.
[11] M. Sparling, “Is there a Component Market?”
cbd-hq.com/articles/2000/000606ms_cmarket.asp
[12] M. Sparling, “Lesson Learned through Six Years of
Component Based Software Development,” Communi-
cations of the Association for Computi
43, No. 10, October 2000, pp. 47-53.
[13] P. Vitharana, “Risk & Challenges of Component Based
Software Development,” Communications of the Associa-
tion for Computing
2003, pp. 237-252.
[14] M. Bertoa and A. Vallecillo, “Quality Attributes for COTS
Components,” Proceedings of the 6th International
ECOOP Workshop on Quantitative Approaches in Object-
Oriente
2002.
[15] A. Rawashdeh and B. Matalkah, “A New Software Quality
Model for Evaluating COTS Components,” Journa