IJMRS’s International Journal of Engineering Sciences, Vol.

02, Issue 02, June 2013, ISSN: 2277-9698

Software Component Quality Models from ISO 9126 Perspective:

A Review
Sonu Mittal 1, Pradeep Kumar Bhatia 2

1
Research Scholar, SGVU, Jaipur, India
[email protected]
2
Professor, GJUS&T, Hisar, India
[email protected]

Abstract Object Model), DCOM, .NET Framework, Sun’s Java

Accessing the quality of Software products and process has been Beans, EJB (Enterprise Java Beans), J2EE Specification
always a thrust area for the software engineering researchers. and OMG’s (Object Management Group) CORBA
There are several existing quality models used to evaluate (Common Object Request Broker Architecture). Inside the
software systems, namely: McCall’s, Boehm, ISO 9126, FURPS, CBSD, many different types of components are integrated
Dromey, Triangle and Quality Cube etc. Software systems today
such as in-house developed components or third party
are composed from prefabricated commercial components known
as COTS components. The quality of these COTS component components. Third party components exist in two forms –
based software systems (CBSS) depends on the quality of these Commercially produced or Open Source. Commercial
components. There are several quality models proposed by the software components are previously tested, and their code
researchers to evaluate the quality of components; primarily based cannot be modified. These components are known as COTS
on the ISO 9126 model. None of them agrees on all the (Commercial-Off-The-Shelf). “A COTS product as one that
characteristics/sub characteristics to be as it is used for evaluating is (i) sold, leased, or licensed to the general public, (ii)
the components. This paper emphasis on review of these offered by a vendor trying to profit from it, (iii) supported
component quality models based on the addition, deletion and the and evolved by the vendor, (iv) available in multiple
changes made to various characteristics and sub characteristics of
identical copies, or (v) used without modification of the
the ISO 9126 model. The objective of this review is to identify
and select better and common characteristics and sub internals.”[4].
characteristics from the ISO 9126 model for development and Due to COTS component’s plug-and-play nature they
assessment of the components and CBSS quality. become very popular in short time. However, despite all the
advantages, component-based development has still not
Keywords: Quality characteristics, Quality sub characteristics, reached its full potential due to a few major hurdles. One
ISO 9126, Components Quality, CBSD, COTS quality evaluation, such hurdle is selecting quality components. Selecting one
component quality models of the low quality components may lead to failure of the
entire system. Such two case studies have been already
pointed by S.srinivasn [15]. Therefore, it is very necessary
1. Introduction to build a quality framework through which we can
evaluate the quality of these third party components for
The idea of constructing software in the same way as Component Based Software Systems (CBSS).Some issues
hardware is constructed i.e. by assembling reusable related to evaluation of COTS components and CBSS are:
components is becoming very popular in the last decades. • What should be the characteristics and sub
Software reuse reduces development time, effort, cost and characteristics relevant to the component quality
increases productivity and quality. Studies in software models?
engineering confirm these benefits [1,2]. Software reuse in • To what extent the ISO 9126 fulfills this quality
its most common form can be seen in component based framework requirement for the COTS component and
software development (CBSD). CBSD is an approach in CBSS?
which systems are built from well -defined, independently To address these issues present paper reviews the various
produced pieces, known as components. Reference [3] software component quality models proposed by the
defined software component as “A coherent package of researchers in this area. After this introduction, section 2
software artifacts that can be independently developed and defines the basic concepts and terminologies with regard to
delivered as a unit and that can be composed, unchanged, software quality and quality models. Section 3 outlines the
with other components to build something larger.” There ISO 9126 quality model and the reason for choosing it as
are many software component models available in the the framework for the component based quality models
industry, for example: Microsoft’s COM (Component
IJMRS
www.ijmrs.com
6
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

have been derived. Section 4 presents a literature review on FireSmith[8].He defines a quality model as a hierarchical
various component based quality models. Section 5 model (i.e. a layered collection of related abstractions and
presents a review analysis of the different proposed simplifications) for formalizing the quality of a system in
component based quality models. Section 6 concludes the terms of its factors, sub-factors, criteria and measures as
different models and discusses different ways in which the described below:
models can be improved in future research.
• Quality Characteristics – high level characteristics
of a system that capture major aspects of its quality (E.g.
2. Software Quality and Quality Models Functionality, Maintainability etc)
• Quality Sub-Characteristics – major components
Let us first have a look at the basic concepts and of the quality factors mentioned above that capture a
terminologies with regard to software quality and quality subordinate aspect of the quality of the system (E.g.
models. According to the IEEE Standard Glossary of Accuracy is a sub characteristic of Functionality)
Software Engineering Terminology [5], software quality is • Quality Attributes – specific descriptions of a
defined as “the degree to which a system, system system that provide evidence for or against the existence of
component, or process meets specified requirements “, or a specific quality factor or sub-factor. (E.g. Precision is an
“the degree to which a system, system component, or attribute of the quality sub factor Accuracy)
process meets customer or user needs or expectations.” • Quality Metrics- gauges that quantify the quality
Software quality can either refer to the software product attributes and thus make them measurable, objective and
quality or the software process quality. Examples used for unambiguous (E.g. Precision=Number of adequate results
product quality are the CMM (Capability Maturity Model). retuned/Number of total results returned)
The ISO standards have been set for both product as well as
process quality. For example, ISO/IEC JTC1 ISO 9126 [6], Diagrammatically it can be shown as in fig. 1.
talks of software product quality while ISO/IEC JTC1,
ISO-15504-5 [7] talks about software process quality. The Software Product quality assessment can either be
quality models, we refer to in this paper, are for the product white box or black box assessment. White box assessment
quality of software components and CBSS. is based only on the source code, but source code will not
Quality is mainly studied by quality models. The be available for black box assessment. There is no source
quality model describes the set of characteristics, which are code available for the COTS components unlike in-house
the basis for establishing the quality requirements and for components (since in-house components are developed
evaluating software quality According to Ljerka Beus inside the organization itself). Black box quality assessment
Dukic and Jorgen Boegh [9], software quality evaluation is is based on the evaluation of externally viable
defined as “the systematic examination of the software characteristics that can be done using quality models and
capability to fulfill specified quality requirements.” A that can also be applied to all kinds of software components.
software quality model is defined as,” a set of There is several existing quality models used to
characteristics and sub characteristics, as well as the evaluate software systems, namely: McCall’s, Boehm, ISO
relationships between them that provide the basis for 9126, FURPS, Dromey, Triangle and Quality Cube etc.
specifying quality requirements and evaluating quality”. There are several models proposed exclusively for COTS
Therefore, a software quality model is a good tool to and CBSS also. But most of these models
evaluate the quality of a software product. A more concise [11,12,13,14,16,19] are based or derived from ISO 9126.
definition of a quality model is presented by Donald

Divided to
Characteristic Refined to
Sub characteristics Formalized to
Attribute
Metric
Figure 1: Quality Model Hierarchy
standard, which was selected for the component quality
3. The ISO/IEC 9126 Quality Model model, for the following reasons:[10]
• Due to its generic nature, the standard fixes some
The International Organization for Standardization and high-level quality concepts, and therefore quality models
International Electrotechnical Commission 9126-1 quality can be tailored to specific package domains. This is a
IJMRS
www.ijmrs.com
7
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

crucial point, because quality models can dramatically The ISO/IEC 9126-1 standard fixes 6 top level
differ from one domain to another. characteristics: functionality, reliability, usability,
efficiency, maintainability and portability. It also fixes their
• The standard lets us create hierarchies of quality further refinement into 27 subcharacteristics but does not
features, which are essential for building structured quality elaborate the quality model below this level, making thus
models. the model flexible.
• The standard is widespread The decomposition of characteristics, as proposed by the
ISO 9126, is presented in Table 1[6]

Table 1: ISO/IEC 9126 characteristics and subcharacteristics

Sub
Characteristics Description
characteristics
determines the degree of the precision of calculated values. It also describes
Accuracy
how effectively and authentically the attributes describe the software quality
Functionality, a set Suitability determines the fitness for the purpose
of attributes that bear
on the existence of a deals with the attributes that describes the ability of the software to interact
Interoperability
set of functions and with specific system
their specified deals with the attributes that describe the ability of the software to prevent
Security
properties the unauthorized access of it.
Functionality refers to the adherence of the software to standards and conventions related
Compliance to applications and regulations by law.
Maturity describes the frequency of failure of the software by faults
Reliability, a set of evaluates the robustness of the software. It describes the software attributes
attributes that bear on that describe the ability of the software to maintain a specified level of
Fault Tolerance
the capability of performance in cases of software faults or the violation of its specified
software to maintain interface.
its level of describes the capability of the software to re-establish its level of
performance under Recoverability performance and to recover the data directly affected in case of failure and
stated conditions for a the time and effort needed for it
stated period of time
Reliability determines whether the software adheres to the compliance standards of
Compliance reliability or not
Efficiency, a set of
is related to the attributes that measure the response time, processing time,
attributes that bear on Time Behaviour
and throughput rates.
the relationship
between the level of Resource describes the amount of resources used and the respective duration of the
performance of the Behaviour use.
software and the
amount of resources Efficiency
used, under stated describes whether the software adheres to the standards of efficiency
Compliance
conditions
deals with the attributes of software that describe the relative ease of
Usability, a set of Understandability
recognizing the logical concept and its applicability
attributes that bear on
deal with the software attributes that describe the relative ease for the users
the effort needed for Learnability
to learn the application
use, and on individual
deals with the software attributes that are associated to the relative ease of
assessment of such Operability
learning the operations of the software
use, by a stated or
Attractiveness describes the degree to which the software has been made attractive
implied set of users
Usability determines whether the software adheres to the compliance standards of
Compliance usability or not
Portability, a set of is described by the attributes of the software that explain the opportunity for
Replaceability
attributes that bear on the adaptation of the software
IJMRS
www.ijmrs.com
8
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

the ability of software describes the relative ease for the software to adapt itself to different
to be transferred from Adaptability environments without applying any changes other than those provided for
one environment to this purpose
another describes the relative ease of installing the software in a given environment
Installability
or platform.
determines whether the software can exist in the system without colliding
Co – existence
with the remaining processes
Portability defines the attributes allowing the software to adhere to standards or
Compliance conventions relating to portability
describes the relative ease of diagnosing the deficiencies, the causes of
Maintainability, a Analyzability
failure, and identifying the parts to be modified
set of attributes that
describes the relative ease of modifying the software for removing the faults
bear on the effort Changeability
or to adjust to the environmental changes
needed to make
Testability describes the relative ease of testing the software to determine the bugs.
specified
describes the attributes of software that describe the risk of unexpected
modifications. Stability
modifications.
Maintainability determines the adherence of the software to the maintainability compliance
Compliance standards.

4. Literature Review of various Component related metrics for the components evaluation. The model
Based Quality Models developed was based on ISO/IEC 9126 and a set of updates
in the Characteristics and Sub-Characteristics were
In 2002, it was Bertoa et al. [12] who first defines the provided in order to be used in a software component
characteristics and sub-characteristics in the changed context. At least, some metrics were presented in order to
context of component based systems. The paper divides provide means to measure the quality characteristic
sub-characteristics into runtime and lifecycle categories proposed in the model.
based on their nature. It adds compatibility sub- In 2006, Adnan [11] also conducted a survey on
characteristic under functionality, which indicates whether various quality models available, which includes McCall,
former versions of the components are compatible with its Boehm, FURPS, Dromey and ISO 9126. It performs some
current version. The paper also proposes various attributes tailoring on ISO 9126 model by adding compatibility sub-
associated with the sub-characteristics and finally defines characteristic under functionality and complexity under
these attributes with the classification for the measurement usability. It omits stability and analyzability from
of such attributes like ratio, presence, integer and time. maintainability and adds manageability to it. It also adds
Although the paper presents a good description on quality new characteristic, named Stakeholders in its proposed
characteristics, sub-characteristics and their measurement, model who are the members of the team responsible for
it fails to perform any empirical evaluation of the attributes developing, maintaining, integrating and/or using COTS
on any application, thus leaving the proposed work as systems. The paper performs a good comparison for various
incomplete [17]. quality models; however, all the models considered are
In 2003, S.D.Kim et al. [16] proposed a practical traditional models and may not fit for component-based
quality model for evaluating COTS components, based on systems, as-it-is. Moreover, the proposed model does not
ISO 9126 model. It used CORBA component model as a explain how the attributes belonging to various
base for defining the framework of their model. It uses characteristics and sub-characteristics will be measured to
functionality, reusability, maintainability and conformance finally evaluate the quality of the system.
characteristics factors which are further divided into In 2008, Sharma et. al. [14] presents a survey of
commonality, suitability, completeness, modularity, various quality models proposed so far for non- component
customizability, comprehensiveness, abstractness and and component based systems. It is defines the
changeability subcharacteristics/subfactors. Further metrics characteristics and sub-characteristics of the component
for these four factors is also defined that can be effectively and proposes to add some more sub-characteristics to it,
used to derive the overall quality of components. However, which may be relevant in the component context, using a
it has used product level metrics evaluation. It further did weight assignment technique called Analytical Hierarchical
not differentiate the runtime and lifetime subcharacteristics. Process (AHP). The work have demonstrated the use of the
In 2005, Alvaro et al. [13] presented a Component technique in an experiment by taking a real-life example
Quality Model describing mainly the quality attributes and and evaluated the overall quality of the component.

IJMRS
www.ijmrs.com
9
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

In 2008, Choi et al. [19] proposed an in-house defining a group of techniques, metrics, models and tools to
Component Quality Model which includes metrics for evaluate and certificate software components, aiming to
component quality evaluation, tailoring guidelines for establish a well-defined component evaluation standard;
evaluations, and reporting formats of evaluations. The and (iv) a Metrics Framework, responsible for defining a
model proposed was based on ISO/IEC 9126 and Choi et al. set of metrics to track the components properties and the
have applied this Component Quality Model to embedded component evaluation process in a controlled way.
system development projects. The future works will try to
automate some quality characteristics through a set of tools 5. Review Analysis
developed in Samsung – Korea labs. The model proposed
in this work is specific to embedded system domain which
A review analysis of the different proposed quality
means that the literature started to tailor some models to
models is presented in this section. The review of the
specific kind of domains.
models is based on the following points (Table 2):-
At last in 2010, Alvaro et al.[18] proposed a software
• ADDED: refers to new
component quality framework to evaluate the quality of
Characteristics/subcharacteristics added to the ISO
software components in an efficient way. They extended
9126 model
their previous work [13] by adding an experimental study
was accomplished in order to evaluate the viability of the • DELETED: refers to deleted
proposed framework. The proposed framework is Characteristics/subcharacteristics to the ISO 9126
composed of four modules (i) a Component Quality Model model
(CQM), with the purpose of determining which quality • DIVIDED: describes whether the subcharacteristics
characteristics should be considered (defining the essential are divided into runtime (dynamic)/ lifecycle (static).
CBD characteristics) and which sub-characteristics are • METRICS : a description of the metrics used in the
necessary; (ii) a Evaluation Techniques Framework, which model (if any)
defines a number of techniques (divided in five quality- • VALIDATION: whether the validation /evaluation of
levels I-V and the closer to the last level, the higher is the the model done
probability that the component is trusty) that will be applied • TARGET AUDIENCE: describes the target users of
to software components evaluation where was proposed the the model
Software Component Evaluation Techniques Model • SCOPE: refers to the domain of the model
(SCETM); (iii) a Evaluation Process, responsible for

Table 2: Analysis of various component quality models

TARGET VALI
DIVID METRI
Ref. ADDED DELETED AUDIEN DATI SCOPE
ED CS
Model CE ON
Individual
COTS
Component
Portability* The Presenc
Compatibility to Yes Level as
Fault Tolerance software e,
Bertoa et Functionality, (runtim Not well as in
Stability architects Time,
al. [12] Complexity to e/lifecy done the
Analyzability and Level,
Usability cle) Component
Attractiveness designers Ratio
evaluation
at system
level
Reusability*(customiz Portability* Done
for COTS
ability, Commonality, Reliability* (CIP
Ratio component
Modularity, Usability* Proje
The based Quality
Comprehensiveness), Efficiency* ct)
Soo D. consumer metrics evaluation,
Commonality and Compliance but
Kim et NO of COTS for all considered
Completeness to Accuracy not
al. [16] compone the only
Functionality, Interoperability show
nts subfact CORBA
Modularity and Security n in
ors component
Interface Abstractness Analyzability the
Model
to Maintainability Stability paper
IJMRS
www.ijmrs.com
10
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

Conformance* Testability

Compatibility to End
Portability*
Adnan Functionality, User, for COTS
Fault Tolerance Yes (
Rawash Complexity to Analyst, Not component
Stability product/ NO
deh et Usability, QA done Quality
Analyzability process)
al.[11] Manageability* with Officer, evaluation
Attractiveness
quality management Project
Manager
Reusability*(customiz
ability, Functional Yes
Commonality, (Pilot
to evaluate
Domain Model Analyzability evalu
In House
Conformance, Accuracy The ation
Ratio Component
Y.Choi Component Model Interoperability producer on
based quality,
et al. Conformance), Compliance NO of two
some mainly for
[19] Modularity*(Cohesion Installability compone In
metrics embedded
, Coupling ), Stability nts house
system
Completeness to Attractiveness comp
domain
Functionality, onent
Scalability to s)
Efficiency
Reusability to
Functionality The A set of Yes
Arun Scalability to consumer metrics (Usin
for
Sharma Efficiency Complexity /evaluator for 11 g
Compliance NO component
et al. to Usability of subchar AHP
evaluation
[14] Trackability and compone acteristi Proce
Flexibility to nt cs ss )
Maintainability
Any kind
Yes (
of
Self-contained to A
The component
Functionality frame
Yes consumer Presenc evaluation
Configurability to work
Alvaro (runtim /evaluatio e, IV both at
Usability Scalability Analyzability with
et al. 18] e/lifecy n team of value, individual
to Efficiency SCET
cle) compone Ratio as well as
Reusability to M
nt at the
Portability levels
System
)
level
* indicates Characteristics with all of its subcharacteristics.

As shown in table 2, most of the researchers agree on the Similarly, a complexity Sub characteristic should be added
reusability feature to be added to the ISO 9126 model to under the usability. Because the source code of the
extend it for the component quality evaluation model. component is not available to the application developer, the
Although they differ in whether to add these at the complexity of a component in CBSD is limited to interface
characteristics level or at the subcharacteristics level. Since methods, pre and post conditions, properties and
COTS components are targeted for inter-organizational interactions available to the developer. Measuring the
reuse, they must be highly reusable to be valuable. If we complexity at the initial stage is helpful during analyzing,
consider evaluating the quality at the internal level then it testing, and maintaining the system [14].
should be considered at the characteristic level otherwise it Usability, this characteristic and all its subcharacteristics
should be considered as the subcharacteristics of the have a completely different meaning for software
functionality. components. The reason is that, in CBSD, the end-users of
IJMRS
www.ijmrs.com
11
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

components are the application developers and designers metric would help the developer/integrator to build a
that have to build applications with these components, quality COTS based software product. So these metric
rather than the people that have to interact with them. Thus, should be easy to calculate and be feasible for practical use.
the usability of a component should be interpreted as its The field of quality attribute determination of component-
ability to be used by the application developer when based system is extensive and more research can and
constructing a software product or system with it. The should be performed in this field. This will help in
researchers are also in favor of deletion of analyzability and increasing confidence in the use of research results, to solve
attractiveness subcharacteristics. problems in practical industrial settings.
Although some researchers favors the deletion of
portability characteristics and all of its subcharacteristics References
but we considers it to be an important characteristic for the
component based quality models as a component may be [1] Krueger, C. W.: Software reuse, ACM Comput. Surv., 24,
used and reused in various different environments. 131-83 (1992).
Therefore the specification of a component should be [2] Mohagheghi, P., and Conradi, R.: Quality, productivity and
economic benefits of software reuse: a review of industrial
platform independent [14]. studies, empirical software Engg., 12, 471-516 (2007).
Dividation of subcharacteristics into runtime (that are [3] D’ Souza D. F., Wills, A. C. ,”Objects, Components and
discernable at component execution time) and lifecycle Frameworks with UML: The Catalysis Approach.” Addison
(that are discernable at component development and Wesley, Reading, MA, (1999).
CBSD) makes it clearer in its use and objective. [4] John, D. et al.,“A Process for COTS Software Product
Most of the researchers proposed metrics for these Evaluation” Technical Report CMU/SEI- 2003-TR-017,
(2004).
characteristics (mostly ratio based) but very few work on [5] IEEE Standard Glossary of Software Engineering
the evaluation part of these metrics. Terminology (Std 610.12-1990) by IEEE.
[6] ISO, International Organization for standardization,” ISO
9126-1:2001 Software engineering-Product quality, Part 1:
6. Conclusion and Future scope Quality Model”, (2001)
[7] ISO/IEC JTC1, ISO-15504-5: “Information Technology –
A good component quality evaluation procedure is Process assessment-Part 5: An exemplar process assessment
necessary to ensure that organizations are able to procure mod-el”, Technical Report, (2004)
high quality components for software development. An [8] Donald FireSmith:“Achieving Quality Requirements with
important consideration in component selection and Reused Software Components – Challenges to Successful
Reuse”, Second International Workshop on Models and
integration is the evaluation of the component using quality
Processes for the Evaluation of Off – The – Shelf Components
models. This paper is a review study of the different quality (MPEC) (2005)
models proposed in component research literature. All the [9] Ljerka Beus Dukic and Jorgen Boegh: “COTS Software
proposed models follow the ISO 9126 quality model Quality Evaluation”, In the proceedings of ICCBSS, Ottawa,
framework with a few corrections and adjustments made to Canada(February2003)
suit the software component domain. The flexibility of ISO [10] X. Franch, J.P. Carvallo. “Using Quality Models in Software
Package Selection”. IEEE Software, 20(1),( 2003).
9126 model makes it most appropriate candidate for the
[11] Adnan Rawashdeh, Bassem Matalkah, “A New Software
formation and evaluation of the quality for component Quality Model for Evaluating COTS Components”, Journal of
based systems. Computer Science, (2006), Vol. 2 Iss. 4, 373-381.
However, they all have one common drawback that there [12] M. Bertoa, A. Vallecillo, “Quality Attributes for COTS
are too many attribute that have to measured that will lead Components”, In the Proceedings of the 6th International
to confusion. Not only that, it won’t be possible to measure ECOOP Workshop on Quantitative Approaches in Object-
Oriented Software Engineering (QAOOSE), Spain, (2002).
some of the attributes due to a number of reasons. The
[13] Alexandre Alvaro, duardo Santana de Almeida, Silvio
major reason will be lack of information from the Romero de Lemos Meira, “Quality Attributes for a
component vendors [12]. Another drawback is the fact that Component Quality Model”, Proceeding of 10th International
most of the quality models have not been adequately Workshop on Component Oriented Programming (WCOP),
validated. Glasgow, Scotland, (2005)
Future work in the development of CBSD research could [14] A. Sharma, R. Kumar and P.S. Grover, “Estimation of
Quality for Software Components - an Empirical Approach,”
include determination of quality metrics for components
ACM SIGSOFT Software Engineering Notes, Vol.33, No.5,(
integration in CBSD. Their Integration point is an November, 2008), pp.1-10
important factor for their quality consideration as CBSS [15] S. Kalaimangal and R. Srinivasan, “A Retrospective on
complexity, reusability, maintainability and testability are Software Component Quality Models,” ACM SIGSOFT
based on their proper integration and design work. These
IJMRS
www.ijmrs.com
12
 IJMRS’s International Journal of Engineering Sciences, Vol. 02, Issue 02, June 2013, ISSN: 2277-9698

Software Engineering Notes, Vol.33, No.5, (November, [18] Alvaro, A., Almeida, E.S., Meira, S.R.L. “A Software
2008), pp.1-9 Component Quality Framework”, ACM SIGSOFT Software
[16] S.D. Kim and J.D Park, "C-QM: A Practical Quality Model Engineering Notes, (November 2010) Volume 35 Number 1
for Evaluating COTS Components", Proceedings of the 21st [19] Choi, Y., Lee, S., Song, H., Park, J., Kim, S., “Practical S/W
IASTED International Conference on applied informatics, Component Quality Evaluation Model”, In the 10th IEEE
Innsbruck, Austria ( February,2003) International Conference on Advanced Communication
[17] Preiss, O., Weqmann, A., Wong, J, “On Quality Attribute Technology (ICACT), Korea (2008.)
Based Software Engineering”, Proceeding of 27th EuroMicro
Conference, (2001), 114-121.

IJMRS
www.ijmrs.com
13