International Journal of Software Engineering and Its Applications

Vol. 5 No. 3, July, 2011

Maintainability Analysis of Component Based Systems

Vidushi Sharma and Prachi Baliyan

School of ICT, Gautam Buddha University, Yamuna Expressway, Greater Noida
vidushi@gbu.ac.in,baliyan.prachi@gmail.com

Abstract

Component based systems are increasingly being used nowadays and this has drastically
changed how we build and maintain systems. When the components are incorporated into a
system, maintenance becomes much harder because source code is either partially or
completely invisible. Various quality models have been proposed in context to the software,
which may not fulfill the requirements of component based software. Hence in this paper we
have identified the maintainability quality factors for the component based software
considering the existing quality models, i.e. McCall quality model, Boehm quality model and
ISO 9126 model. New sub characteristics on the basis of component based systems like
trackability, tailorability, scalability and reusability have been included. Also the evaluation
of the maintenance parameter is done by the survey method. The result computed help in
identifying the maintenance quality factor based on ISO rating levels.

Keywords: Component Based Development (CBD), Maintainability Model,

Trackability, Tailorability, Reusability

1. Introduction
Software maintenance is one of the most expensive and resource requiring phase of the
software development process. Maintainability is the capability of the software to be modified
[1, 2] from the perspective of component based systems, wherein the concept of
maintainability is of major importance [3, 4]. Maintainability of component based systems is
a complex issue, since maintenance personnel does not have access to the source code of the
component, which needs to be modified. Voas [5] discusses several aspects of maintainability
of Component based systems (CBS), which include difficulties in maintenance activities due
to frozen functionality, incompatible upgrades, defective and complex components. A
software quality model is defined as A set of characteristics and sub characteristics, as well
as the relationships between them that provide the basis for specifying quality requirements
and evaluating quality. A more precise definition of a quality model is - a hierarchical model
for formalizing the quality of a system in terms of its factors, sub-factors, criteria and
measures [6]. There are few quality models like McCall model, Boehm Model, and ISO 9126
model for general software systems but these are not adequate for assessing the quality of
component based systems. In this paper the maintainability attributes for Component based
software have been identified by comparative analysis of the existing quality models i.e.
McCall quality model, Boehm quality model and ISO 9126 quality model. The paper has
been divided into various sections. Section 1 presents the basic concept of CBS. In section 2
comparative analysis of the quality models is given and their critical examination in context
to CBS. Section 3 gives the proposed maintenance characteristics for the component based
software i.e. reusability, trackability, tailorability and scalability and finally in Section 4 the
evaluation of the maintainability parameter by the survey method is given.

107
International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

2. Comparative Analysis of Maintainability Aspect of Quality Models

Several quality models have been suggested by McCall, Boehm and ISO 9126 model.
Maintainability of the systems is an important aspect in each of these models. The table below
draws comparison among existing maintainability attributes for software systems, however,
all the attributes may not be suitable for a component based system. The sub characteristics of
maintenance identified from the existing quality models are given below.

Table1. Comparative Analysis of Maintainability Aspect of Quality Models

The table depicts a comparative analysis of the sub attributes as proposed by Boehm
Quality Model, McCall Quality Model and ISO 9126 model.
Y which indicates inclusion of sub characteristic in the model whereas
N denotes that the sub characteristic is not incorporated.
From this comparison, characteristics relevant to the component based system are
identified. The sub attributes can be critically examined to see their relevance in context to
CBS.

2.1. Testability

Testability is an important component attribute. According to the IEEE Standard Glossary

of Software Engineering Terminology [6] testability can be defined as, the degree to which a
component facilitates the establishment of test criteria and the performance of tests to
determine whether those criteria have been met. When a component is purchased from a
vendor, it is basically a black box. It can range, from a few lines of code to many thousands of
lines. In most cases, the source code is not available and if it is, very expensive to purchase.
The buyer usually receives an executable version of the component and a description of its
functionality. The testers have to make use of this little information to test if the component is
compatible and working. Hence, a higher testability degree increases the chance of
discovering errors, thereby increasing the quality of the component.

108
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

2.2. Understandability

This includes the attributes of software which relate to the users effort in recognizing
logical concept and its applicability. As the source code of the component is not available to
the application developer, documentation is the only source from where he or she can
understand the component. Documentation provides the ease with which a user can learn to
operate, prepare inputs for, and interpret outputs of a system or component.

2.3. Modifiability

The attribute Tailorability has been added by merging changeability and the
modifiability. Much of the maintenance effort for component based systems involves tailoring
the functionality to meet evolving user requirements.

2.4. Stability

This is the capability to avoid unexpected effects from modifications to the software. In
case of component-based systems, it may be defined as the degree to which software is
composed of discrete components such that a change to one component has the minimal or
zero impact on the other components. The user or the integrator can only adapt it, reconfigure
it and finally test so that it can be used in the final product. Therefore, stability cannot be
considered viable for component based systems from its users/integrators point of view and
may be removed from the list.

2.5. Analyzability

In the Maintainability characteristic, Analyzability sub characteristic has been removed.

In the context of components, it is seen that the result of evaluation of this sub characteristic
will be insignificant, because a component is developed to attend certain functionalities of the
application and, rarely methods are developed for its auto analyzability or to identify parts to
be modified [7] (i.e. this is the main concern of Analyzability characteristic, according to ISO
9126).

2.6. Changeability

This is the capability of software to enable the implementation of a specified

modification. Its meaning is almost same as modifiability, which means effort required to
modify software, so these two attributes have been merged under tailorability characteristic
[9].

2.7. Conciseness
A software product possesses the characteristic conciseness to the extent that no
excessive information is present. It can be improved by replacing repeated functionality by
one subroutine or function which achieves that functionality. It also applies to documents.

2.8. Self-Descriptiveness

The more self descriptive a software product is, the more is its understandability and
hence more maintainability. There is no need to define it as a separate attribute as it is
covered under understandability only.

109
International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

2.9. Modularity

Improving the modular structure of the system, improves the maintainability of the
system and hence the overall quality of the system.

2.10. Compliance

The sub characteristic compliance indicates if a component is conforming to any

international standard or certification etc, relating to its usability. Currently, no standards
have been set up for this sub characteristic in the component context; therefore it may be
omitted from the quality model for the time being [10], [11].

2.11. Simplicity

The more a component is simple, the more is its understandability and hence more
maintainable. Simplicity covers the understandability aspect only, so no need to define it
separately [12], [13].

Table 2. Maintainability Characteristics

Table 2 presents the maintainability attributes identified for the CBS after critically
examining the quality models.

3. Proposed Sub Characteristics for Maintainability Attribute of

Component Based Software
3.1. Reusability

This sub characteristic is essential in component based context. It is typically concerned

with reuse of component on new platforms. For better reusability, a component should be
highly portable and since reusability is very important while considering the component based
software the sub-attribute reusability should also be included under the maintainability
characteristic. Reusability is the primary purpose of component usage. Hence, reusability, by
itself, should be placed as a quality factor together with its own set of quality sub
characteristics, attributes and measures. Reusability promotes maintainability through
decreasing development costs. On the other hand, maintainability is a prerequisite for
reusable software, because there is no meaning without it. E.g. Long living reusable software
that is not maintainable. Sub attributes of reusability are:

3.1.1. Installability: It is the capability for a component to be installed easily on different

platforms.

110
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

3.1.2. Adaptability: It refers to the ability of the component to adapt to different specified
platforms.
3.1.3. Replaceability: This sub characteristic indicates whether the component is backward
compatible with its previous versions. This means the new component can substitute the
previous ones without any major efforts.

3.2. Tailorability

This attribute means the ability to enhance the services available to the end user by
configuring component based software products, configuring services of multiple products
etc. Much of the maintenance effort for component based systems involves tailoring the
functionality to meet evolving user requirements. Tailorability is a loose term used in
component-based software development to describe the ability to customize and configure
components, but also to add new components to the system and combining services of
multiple components in novel ways. Sub attributes of tailorability are:
3.2.1. Customizability: It is the ability to modify a component through its limited available
information, like interfaces and parameters.
A metric called Rate of Component Customizability (RCC), proposed by Washizaki et al.
[9] is the percentage of writable properties in all fields within a faade class of a component
C. It is given by:
RCC(C) = Pw(C)/A(C) If A(C) >0
Otherwise 0
Where Pw(C) is the writable properties in C and A(C) is the number of attributes in C.
3.2.2. Extensibility: The systems ability to acquire new components.

3.3. Trackability

It includes tracking versions of different component based products, tracking

development configuration, determining compatible versions of software. Keeping a proper
track thus helps in maintainability of the software. Thus maintainability must include keeping
a proper track of various system properties during the maintenance activities. Sub attributes of
trackability are:
3.3.1. Performance Tracking: It is observed that component vendors usually do not provide
application developers with any performance information. Hence, system testers and
integration engineers must spend a lot of efforts to identify the performance problems and the
components that cause the problems. Therefore, we need to check the performance aspects of
the system after any change is made. These performance aspects can include various sub
attributes like resource utilization, (CPU cycle, Execution time), Audit logs,
Average/Min/Max speed etc.
3.3.2. Compatibility Tracking: If the replaced component is developed under different
operating system environment or by using different programming language then we need to
address the issues of compatibility also. Also the new component may need different
glue/integration code to be embedded in the system, may be due to its changed environment
or functionality. Scalability is also important as it talks not only about data volume but also
about the maximum number of components, the component can interact with without
reducing its performance.

111
International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

Table 3. Modified Maintainability Characteristics for the Proposed Attributes

Table 3 represents the modified Maintenance characteristics for the CBS after adding the
above sub characteristics.

4. Analysis of the Proposed Attributes

A survey was conducted to evaluate the maintainability of the Learning Management
System Software. The proposed quality attributes of the maintainability were taken into
consideration. Questionnaires were developed and the quality attributes were evaluated to
find out the quality of the system. The consolidated Data of the questionnaire is presented in
table 4 and the questionnaire for the survey is given as annexure 1. The survey was conducted
on the users of the system and the quality mangers and the average score of the attributes
were calculated. The priority (pr) of each sub characteristic was determined by the
preliminary survey conducted for determining the importance for the sub characteristic for the
user.
Table 4: Consolidated Data of the Questionnaire

112
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

Determining the total quality value of the software

The Total Quality Value of the Software is equal to the sum of the Final Quality Value of
each Characteristic.
TQVS=FQVC of each characteristic
TQVS = 49.98 + 66.29 + 10.19 + 33.00 + 4.72+ 23.68+ 15.66
TQVS = 203.52

Determining the quality factor

Quality Factor (QF) = TQVS/ ITQVS
ITQVS is the Ideal Total Quality Value of the Software
ITQVS can be calculated when all the sub characteristics attain a rank of 3 by the users
and QMs.
Here, for this software
TQVS = 203.52
ITQVS = 328
QF = TQVS/ITQVS
QF = 203.52/328
QF = 0.62

Determining the quality from QF according to the ISO standard global rating levels
If 0.0 QF 0.25
Software quality is Poor
If 0.26 QF 0.50
Software Quality is Fair
If 0.51 QF 0.75
Software Quality is Good
If 0.76 QF 1.00
Software Quality is Excellent

The result indicates that the software evaluated rates Good on the proposed
maintainability model of the quality factor.

5. Conclusion
Component based systems have the advantages of low cost with high quality product
but maintaining systems that incorporate components can be very challenging due to
incompatible upgrades, unreliable components and so on. Knowing how a component affects
system behavior before we use it would certainly make component-based maintenance little
easy. This paper gives the comparison between the maintainability attributes of McCall
quality model, Boehms Model and ISO 9126 model for component based systems and
proposes various characteristics and sub characteristics for maintainability aspect related to
CBS and new attributes trackability, tailorability, scalability and reusability have been
proposed. A survey of a software is done based on the proposed characteristics to evaluate its
maintainability and hence the overall quality of the software. The work can be further
extended by developing a maintainability metric based on these maintainability
characteristics.

113
International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

References
[1] ISO/IEC, Information Technology-Software Quality characteristics and metrics Part 1: Quality
characteristics and sub characteristics, pp. 21, 1996. Weyuker: Testing Component Based Software: A
cautionary Tale, IEEE Software, Vol. 15, No. 2, 2008.
[2] IEEE, IEEE standard glossary of software engineering terminology, in Std 610.12-1990: IEEE, Vol. 84, 1990.
[3] M. Vidger. The Evolution, Maintenance and Management of Component Based Systems. Boston: Addison-
Wesley, 2001.
[4] P. Bengtsson and J. Bosch, Architecture Level Prediction of software Maintenance, in Proceedings of the
Third European Conference on Software Maintenance and Reengineering, pp. 139-147,1999.
[5] J. Voas : Maintaining Component-Based Systems, IEEE Software, Vol.15, No.4, 1998.
[6] Donald Firesmith: Achieving Quality Requirements with Reused Software ComponentsChallenges to
Successful Reuse, Second International Workshop on Models and Processes for the evaluation of Off-The
Shelf Components (MPEC), 2005.
[7] IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 729, 1983.
[8] H. Washizaki, H. Yamamamoto and Y Fukazawa: A Metrics suite for Measuring Reusability of Software
Components, Proceedings of the 9th International Symposium on Software Metrics, 2003.
[9] Kaur. Kamaljit, Mehan.Neha, Kakkar. Namita: World Academy of Science, Engineering and Technology,
Vol. 56, 2009.
[10] Lucia Kapov: Systematic Refinement of Performance Models for Concurrent Component Based Systems,
Electronic Notes in Theoretical Computer Science, Vol. 264, No 1, 10, pp.73-90, 2010.
[11] Marko Palviainen, Antti Evesti, Eila Ovaska: The reliability estimation, prediction and measuring of
component-based software, Journal of Systems and Software, Vol. 84, No. 6, pp.1054-1070, 2011.
[12] Heiko Koziolek: Software systems a survey Performance Evaluation, Vol.67, No. 8, pp.634-658, 2010.
[13] Claudia Ayala, Oyvind Hauge, Reidar Conradi, Xavier Franch, Jingyue Li :Selection of third party software
in Off-The-Shelf-based software developmentAn interview study with industrial practitioners, Journal of
Systems and Software, Vol. 84, No. 4, pp. 620-637, 2011.

Annexure 1. Questionnaire A and B

Preface
How to fill in the questionnaire: Answer all the questions according to your knowledge,
skills, and position with the organization. The questionnaire aims to check up the
maintainability activities of the Learning Management System pointing out different
viewpoints.
Each question has a multiple-choices answer (tick one of the choices). The lecture-key of the
answers is as follows:
N/A: Not Applicable, if the question does not fit for your software product.
UN: Unknown, if you cannot answer the question according to your knowledge, skills or
position within the university.
The other answers consist of four different levels namely, 0, 1, 2, 3, If you think the
question fits your knowledge, skills then answer the relative question with one.
Remark: The questionnaire is NOT to assess people and their work or knowledge. The
questionnaire aims only to assess the quality of the Learning Management System by
assessing its maintainability attribute
General Information: Fill the table with relative information.

114
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

The ISO Rating Levels

GLOBAL RATING
MARK RATING
3 Excellent
2 Good Satisfactory

1 Fair

0 Poor

A: Questionnaire for the Quality Manager

Question N/A UN 0 1 2 3

1. Can the
component interact with
many other components
without reducing its
performance?
2. Can the
component be adapted to
different specified
platforms, without
applying other means than
those provided for this
purpose for the software
considered?
3. Is the component
self descriptive?
4. Is the component
available modifiable
through limited available
information like interfaces,
parameters etc?
5. Is the system
complex or divided into
smaller pieces called
modules?
6. Can the system
acquire new components
easily?
7. Are there any
methods or reports for
keeping a track of its
performance like resource
utilization?
8. Are there any

115
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

methods for keeping a

track of the systems
compatibility, if the
component is developed
under different operating
systems or by using
different programming
languages?
9. Is the component
backward compatible with
its previous versions or
can it be used in place of
specified other software in
the environment of that
software?
10. Is the proper
documentation available
for the system thus
increasing its simplicity in
usage and is it concise?

B: Questionnaire for the User

Question N/A UN 0 1 2 3

1. Can the software be installed easily in

a specified environment?
2. Can the component interact with many
other components without reducing its
performance?
3. Can the component be adapted to
different specified platforms, without applying
other means than those provided for this
purpose for the software considered?
4. Can the user easily learn to operate,
prepare inputs and interpret outputs for the
system?
5. Is the component self descriptive?
6. Is the component available modifiable
through limited available information like
interfaces, parameters etc?
7. Is the system complex or divided into
smaller pieces called modules?

We have used a Hypothetical data involving 40 people who are assumed to participate for
the evaluation of quality of particular software.
15 Users
25 Quality Managers

116
 International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

Authors
Name : Dr. Vidushi Sharma
Designation : Assistant Professor
School : School of Information and communication
Technology, Gautam Buddha University
Qualification : Ph.D. (Computer Science) M.Sc, PGDBA, MCSE
Teaching Area : E commerce, MIS, SCM, Project Management,
Software Engineering, ERP, IT applications.
Research/Consulting Interest: IT applications in management and
Performance evaluation of Information Systems.
Email : vidushi@gbu.ac.in

Name : Ms. Prachi Baliyan

Designation : Student
School : School of Information and Communication
Technology, Gautam Buddha University
Qualification : B.Tech (CS), M.Tech (Software Engineering)
Email : baliyan.prachi@gmail.com

117
International Journal of Software Engineering and Its Applications
Vol. 5 No. 3, July, 2011

118