American Journal of Operations Research, 2011, 1, 249-258
doi:10.4236/ajor.2011.14029 Published Online December 2011 (http://www.SciRP.org/journal/ajor)
Copyright © 2011 SciRes. AJOR
249
A Fuzzy Approach for Component Selection amongst
Different Versions of Alternatives for a Fault Tolerant
Modular Software System under Recovery Block Scheme
Incorporating Build-or-Buy Strategy
P. C. Jha1, Ritu Arora2, U. Dinesh Kumar3
1Department of Operational Research, University of Delhi, Delhi, India
2Maharaja Agrasen Institute of Technology, GGSIP University, Delhi, India
3Indian Institute of Management, Bangalore, India
E-mail: jhapc@yahoo.com, arora_ritu21@yahoo.co.in, dineshk@iimb.ernet.in
Received September 20, 2011; revised October 22, 2011; accepted November 8, 2011
Abstract
Software projects generally have to deal with producing and managing large and complex software products.
As the functionality of computer operations become more essential and yet more critical, there is a great
need for the development of modular software system. Component-Based Software Engineering concerned
with composing, selecting and designing components to satisfy a set of requirements while minimizing cost
and maximizing reliability of the software system. This paper discusses the fuzzy approach for component
selection using “Build-or-Buy” strategy in designing a software structure. We introduce a framework that
helps developers to decide whether to buy or build components. In case a commercial off-the-shelf (COTS)
component is selected then different versions are available for each alternative of a module and only one
version will be selected. If a component is an in-house built component, then the alternative of a module is
selected. Numerical illustrations are provided to demonstrate the model developed.
Keywords: Modular Software, Software Reliability, Software Components (COTS and In-House), Fault
Tolerance & Fuzzy Optimization
1. Introduction
Computer software is very important in today’s world. In
particular, science and technology demand high quality
software for making improvements and breakthroughs.
The software development companies are continuously
developing/modifying/updating their software according
to the changing needs and requirements. The concept of
“software reliability” and its measurement is receiving
much attention in the software development community.
Software reliability is one of the important parameters of
software quality and system dependability. Software re-
liability engineering balances customer needs in the ma-
jor quality characteristics of reliability, availability, de-
livery time and cost more effectively. The reliability of
software can be controlled during the development life
cycle through the application of reliability improvement
techniques. Two of the best-known fault tolerant soft-
ware design methods are N-version programming and
Recovery block scheme. The basic mechanism of both
the schemes is to provide redundant software to tolerate
software failures. Software whose failure can have bad
effects afterwards can be made fault tolerant through
redundancy at module level [1].
When the design of software architecture reaches a
good level of maturity, software engineers have to take a
decision on the selection of software components. Non
functional aspects play a significant role in determining
software quality. Given the fact that lack of proper han-
dling of non functional aspects of a software application
has led to a series of software failures [2], nonfunctional
attributes such as reliability security and performance
should be considered during the component selection
phase of software development. This paper discusses a
framework that helps developers to decide whether to
buy or build components of software architecture on the
P. C. JHA ET AL.
250
basis of cost and non functional factors. While develop-
ing software, components can be both bought as com-
mercial off-the shelf (COTS) products, and probably
adapted to work in the software system, or they can be
developed in-house. This decision is known as “build-or-
buy decision”. This decision affects the overall cost and
reliability of the system. Most of the current software
systems include one or more COTS products. COTS are
pieces of software that can be reused by software pro-
jects to build new systems. Benefits of COTS based de-
velopment include significant reduction in the develop-
ment cost, time and improvement in the dependability
requirement. The components, which are not available in
the market or cannot be purchased economically, can be
developed within the organization and are known as in-
house built components. Reference [3] discussed issues
related to reliability of systems, caused by integrating
COTS components. The optimal selection is achieved
through weighted maximization of system quality subject
to budget as a constraint in which an upper limit is
placed over the constraint.
This paper discusses the issues related to reliability of
the software systems and cost caused by integrating
COTS or in-house built components. Fault tolerance is
achieved through redundancy in Recovery Block model
and redundancy results in additional cost. We assume
that for all the alternatives available for a module, cost
increases if higher reliability is desired. Several alterna-
tives of a software module may be available as COTS,
almost equivalent from the functional viewpoint. Pur-
chase of high quality COTS products can be justified by
the frequent use of the module. Large software systems
possess the modular structure to perform a set of func-
tions. Each function is performed by different modules
having different alternatives for each module. In case, a
COTS component is selected then different versions are
available for each alternative of a module and only one
version will be selected. If a component is an in-house
built component, then the alternative of a module is se-
lected. A schematic representation of the software sys-
tem is given in Figure 1.
In the existing research related to the software deci-
sion, it is assumed that all the parameters of the problem
are known precisely. Various objectives and restrictions
are set by the management and cost coefficients involved
in the cost function are determined based on past experi-
ence and the available data base. This makes it difficult
for the management to provide precise values of the var-
ious cost coefficients and objectives to be met. More-
over due to changing customer specifications, lack of
experience of testing team or novelty, changing testing
environment, complexity in the project involved, un-
known emerging factors at the start of the project adds
Figure 1. Structure of the software.
imprecision and ambiguity to the above-mentioned defi-
nitions. It may also be possible that the management it-
self does not set precise values in order to provide some
tolerance on these parameters due to competitive consid-
erations. All this leads to uncertainty (fuzziness) in the
problem formulation. Crisp mathematical programming
approaches provide no such mechanism to quantify these
uncertainties. Fuzzy optimization is a flexible approach
that permits more adequate solutions to real problems in
the presence of vague information, providing well-de-
fined mechanisms to quantify the uncertainties directly.
The idea of fuzzy programming was first given by [4]
and then developed by [5-7]. A number of researchers
thereafter have contributed to the development of fuzzy
optimization technique [8,9]. Today, similar to the de-
velopments in crisp optimization, different kinds of ma-
thematical models have been proposed and many practi-
cal applications have been implemented by using the
fuzzy set theory. Reference [10] formulated fuzzy multi
objective optimization models for selecting the optimal
COTS software products in the development of modular
software system. Recently, Reference [11] de- velops a
crisp multi-objective programming model from the fuzzy
basic data. When a feasible solution to the problem exists,
single and multiple objective fuzzy opti- mization pro-
cedure are used to solve the problem. How- ever, it is
assumed that a crisp or a constant value of all the pa-
rameters is known. However, in practice, it is not possi-
ble for a management to obtain a precise value of reli-
ability and cost for a software system. Or they may de-
cide not to set precise levels due to the market consid-
erations and are ready to have some tolerance of their
objectives. When the precise values of parameter of the
problem are not known, the problem becomes a fuzzy
optimization problem and the solution so obtained is a
fuzzy approximation.
This paper proposes two fuzzy multi-objective opti-
mization models for selecting the best software product
for each module. The first optimization model (optimiza-
Copyright © 2011 SciRes. AJOR
251
P. C. JHA ET AL.
tion model-I) of this paper is a joint optimization prob-
lem that maximizes the system reliability with simulta-
neous minimization of the cost. The second optimization
model (optimization model-II) considers the issue of
compatibility between different alternatives of modules
as it is observed that some COTS components cannot
integrate with all the alternatives of another module. We
apply fuzzy optimization procedure to solve the problem,
when a feasible solution of the problem exists, but in
case we reach the infeasibility case, then we apply fuzzy
goal programming optimization technique to provide a
compromised solution for the same. The rest of this pa-
per is organized as follows. Section 2 consists of pro-
posed notations. In Section 3, we discuss the assump-
tions of optimization models and we develop a crisp
model for reliability and cost and in Section 4, we de-
scribe Fuzzy Multi-Objective Optimization Model for
software products selection. In Section 5, Fuzzy optimi-
zation technique is discussed to solve the problem with
numerical illustration. In Section 6, we furnish our con-
cluding observations.
2. Notations
R: System quality measure
l
f
: Frequency of use, of function l
l
s
: Set of modules required for function l
i
L
R: Reliability of module i
: Number of functions, the software is required to
perform
n: Number of modules in the software
i
m
V: Number of alternatives available for module i
ij : Number of versions available for alternative
of module
j
i
tot
ij : Total number of tests performed on the in-house
developed instance (i.e. alternative of module )
Ni
s
uc
ij : Number of successful (i.e. failure free) test per-
formed on the in-house developed instance (i.e. alterna-
tive of module )
N
j i
1: Probability that next alternative is not invoked
upon failure of the current alternative
t
2
t
t: Probability that the correct result is judged wrong.
3: Probability that an incorrect result is accepted as
correct.
ij
X
: Event that output of alternative of module
is rejected.
j i
ij
Yi: Event that correct result of alternative of mod-
ule is accepted.
j
ij
s
: Reliability of alternative of module j
ji
ij
C
r: Reliability of alternative for module i
ijk : Cost of version of alternative for module
k j
i
ijk
r: Reliability of version k of alternative for
module
j
i
i
i
ijk : Delivery time of version of alternative
for module
dk j
i
ij : Unitary development cost for alternative of
module
c j
ij : Estimated development time for alternative of
module
t j
ij
: Average time required to perform a test case for
alternative of module i j
πij: Probability that a single execution of software
fails on a test case chosen from a certain input distribu-
tion
t
y:
0,
1,
1
if constraint is active
if constraint is inactive
th
th
t
t
:
if the alternative of module is
in-house develoep.
0otherwise
th th
ji
ij
y
ijk
x
:
1,
0,
1
if the version of COTS alternative
of the module is chosen
ot h e r w i s e
th th
th
kj
i
ij
z: Binary variable taking value 0 or 1
if alternative is present in module
0otherwise
ji
3. Optimization Models
The first optimization model is developed for the fol-
lowing situations, which also holds good for the second
model, but with additional assumptions related to com-
patibility among alternatives of a module.
The following assumptions are common for optimiza-
tion models:
1) Software system consists of a finite number of mod-
ules.
2) Software system is required to perform a known
number of functions. The program written for a function
can call a series of modules . A failure occurs if a
module fails to carry out an intended operation.
n
3) Codes written for integration of modules do not
contain any bug.
4) Several alternatives are available for each module.
Fault tolerant architecture is desired in the modules (it
has to be within the specified budget). Independently
developed alternatives (primarily COTS/In-House com-
ponents) are attached in the modules and work similar to
the recovery block scheme discussed in [12,13].
5) The cost of an alternative is the development cost, if
developed in house; otherwise it is the buying price for
the COTS product.
Copyright © 2011 SciRes. AJOR
P. C. JHA ET AL.
252
6) Different In-house alternatives with respect to uni-
tary development cost, estimated development time, av-
erage time and testability of a module are available.
7) Cost and reliability of an in-house component can
be specified by using basic parameters of the develop-
ment process, e.g., a component cost may depend on a
measure of developer skills, or the component reliability
depends on the amount of testing.
8) Different versions with respect to cost, reliability
and delivery time of a module are available.
9) Other than available cost-reliability versions of an
alternative, we assume the existence of virtual versions,
which has a negligible reliability of 0.001, zero cost and
zero delivery time. These components are denoted by
index one in the third subscript of ijk
x
, and ijk .
for example 1 denotes the reliability of first version of
alternatives for module .
Cijk r
ij
r
j i
3.1. Model Formulation
Let be a software architecture made of modules,
with a maximum number of i alternatives available
for each module and each COTS alternatives has differ-
ent versions.
Sn
m
3.1.1. Build versus Buy Decision
For each module , if an alternative is bought (i.e. some
) then there is no in-house development (i.e.
) and vice versa.
i
1
ijk
x
0
ij
y
1
=1
ij
V
ij ijk
k
yx
; and 1, 2,,in1, 2,,i
jm
3.1.2. Redundancy Constrai nt
The equation stated below guarantees that redundancy is
allowed for the components.
2
ij
V
ijijk ij
k
yx

11
ij ij
xz
1
i
m
j
z1, 2,,in
1, 2,,in
1
ij 1, 2
; and
; and
;
1, 2,,i
jm
1, 2,,i
jm
z, ,in
3.1.3. Probability of Failure Free In-House
Developed Components
The possibility of reducing the probability that the
alternative of module fails by means of a certain
amount of test cases (represented by the variable ).
Reference [14] define the probability of failure on de-
mand of an in-house developed alternative of
module, under the assumption that the on-field users’
operational profile is the same as the one adopted for
testing [15].
th
j
tot
ij
th
i
th
iN
th
j
Basing on the testability definition, we can assume
that the number
s
uc
ij
Nth
j of successful (i.e. failure free)
tests performed on alternative of same module.
1π
uc tot
ijij ij
NN ; 1, 2,,in
and 1, 2,,i
jm
Let A be the event “
s
uc
ij
N failure-free test cases have
been performed ” and B be the event “ the alternative is
failure free during a single run”. If ij
is the probability
that the in-house developed alternative is failure free
during a single run given that
s
uc
ij
N test cases have been
successfully performed, from the Bayes theorem we get
the following.
 


ij
PABPB
PBA PABPB PABPB

The following equalities come straightforwardly:




•1
•1π
•1π
π
s
uc
ij
ij
N
ij
ij
PAB
PB
PAB
PB


therefore, we have

1π
1ππ1π
s
uc
ij
ij
ij N
ij ijij
 
;
1, 2,,in
and 1, 2,,i
jm
3.1.4. Reliability Equation of Both In-House and
COTS Components
The reliability (ij
s
) of alternative of module of
the software.
th
jth
i
ijij ijij
s
yr
; 1,2,,in
and 1, 2,,i
jm
where
1
ij
V
ijijk ijk
k
rrx
; 1, 2,,in
and 1, 2,,i
jm
3.1.5. Delivery Time Constraint
The maximum threshold has been given on the de-
livery time of the whole system. In case of a COTS
components the delivery time is simply given by ijk ,
whereas for an in- house developed alternative the deliv-
ery time shall be expressed as .
T
d

tot
ijij ij
tN
ij
V

11 1
i
m
ntot
ij ijijijijk ijk
ij k
y
tN dx
 
T






Copyright © 2011 SciRes. AJOR
253
P. C. JHA ET AL.
3.2. Objective Function
3.2.1. Reliability Objective Function
Reliability objective function maximizes the system
quality (in terms of reliability) through a weighted func-
tion of module reliabilities. Reliability of modules that
are invoked more frequently during use is given higher
weights. Analytic Hierarchy Process (AHP) can be effec-
tively used to calculate these weights.

1
Maximize
l
L
li
lis
RXf R
where i is the reliability of module of the system
under Recovery Block stated as follows.
R i


1
11
iij
ij
mj
z
z
iijik ij
jk
RzPXPY






13
111
ij ij
PXt s 

;
1, 2,,in

2ij
st


t
2
1
ij ij
PYs t
3.2.2. Cost Objective Function
Cost objective function minimizes the overall cost of the
system. The sum of the cost of all the modules is selected
from “build- or -buy” strategy. The in-house develop-
ment cost of the alternative of module can be
expressed as
j i
ij
V

tot
ijijij ij
ct N
m
n


11 1
Minimize
itot
ij ijijijijijk ijk
ij k
CXc tNyCx
 






3.3. Optimization Model I
In the optimization model it is assumed that the alterna-
tives of a module are in a Recovery Block. In a Recovery
block, more than one alternative of a program exist. For
COTS based software, multiple alternatives of a module
can be purchased from different vendors. Each module
works under a recovery block. Upon invocation of a
module the first alternative is executed and the result is
submitted for acceptance test. If it is rejected, the second
alternative is executed with the original inputs. The same
process continues through attached alternative until a
result is accepted or the whole recovery block (module)
fails. Fault tolerance in a recovery block is achieved by
increasing the number of redundancies.
Problem (P1)

1
Maximize
l
L
l
lis
RXf R
i
(1)


11 1
Minimize
ij
iV
m
ntot
ijijijijijijk ijk
ij k
CXctNyCx
 





 (2)
subject to
and are binary variable
ijk ij
XS xy


1
11
iij
ij
mj
z
z
iijik ij
jk
RzPXPY



; (3) 1, 2,,in


13
111
ijij ij
PXtstst
2
 

2
1
ij ij
PYst
1π
s
uc tot
ijij ij
NN; 1,2,,in
and
(4)
1, 2,,i
jm

1π
;
1ππ1π
1,2,, and 1,2,,
suc
ij
ij
ij N
ij ijij
i
inj
 
m
(5)
ijij ijij
s
yr
; 1, 2,,in
and (6) 1, 2,,i
jm
1
1
ij
V
ij ijk
k
yx
; 1,2,,in
1, 2,,jm
z
and (7)
i
2
ij
V
ijijk ij
k
yx
; 1, 2,,in1, 2,,jm and (8)
i
11
ij ij
xz
; 1, 2,,in
and (9) 1, 2,,i
jm
1
1
i
m
ij
j
z
; (10) 1, 2,,in

11 1
ij
iV
m
ntot
ijijijijijk ijk
ij k
ytNdx T
 





 (11)
where
X
is a vector of component ijk
x
and ;
ij
y
1, 2in, ,
; 1, 2,,i
jm
; .
1, ij
kV2, ,
3.4. Optimization Model II
As explained in the introduction, it is observed that some
alternatives of a module may not be compatible with
alternatives of another module [16]. The next optimiza-
tion model II addresses this problem. It is done, incorpo-
rating additional constraints in the optimization models.
This constraint can be represented as t
g
sqhu c
x
x, which
means that if alternative
s
for module
g
is chosen,
then alternative ,
t
u1, ,tz
have to be chosen for
module . We also assume that if two alternatives are
compatible, then their versions are also compatible.
h
t
g
sqhu ct
xMy
2, ,
g
s
qV
, 2,,t
hu
cV, 1, ,
g
s
m (12)
Copyright © 2011 SciRes. AJOR
P. C. JHA ET AL.
254
2
t
thu
yzV
(13)
Constraint (12) and (13) make use
subject to
of binary variable
t
y
fer
to choose one pair of alternatives from among dif-
ent alternative pairs of modules.
Finally, model can be re-written as
Problem (P2)

1
ximize
l
li
lis
RXf R


11
=
i
m
ntot
ij ijij ijij
ij
CXctNy



Ma
L
1
Minimize
ij
V
ijk ijk
k
Cx
X
S
t
g
sqthu c
xMy

2, ,
g
s, t
hu , qV2, ,cV1, ,
g
s
m,
2
atible co

u

t
th
yzV
If more than one alternative compmponent is
to be c
4. Fuzzy Multi-Objective Optimization
ris the concept
sed on
va
tion model for software
roducts selection based on maximizing the fuzzifier
x
subject to
hosen for redundancy, constraint (13) can be re-
laxed as follows.

2
t
thu
yzV
Model for Software Products
inciple to multi-objective optimization P
of an “efficient solution”, where any improvement of one
objective can only be achieved at the expense of another.
The fuzzy approach can be used as an effective tool for
quickly obtaining a good compromise solution. Conven-
tional optimization methods assume that all parameters
and goals of an optimization model are precisely known.
However, for many practical problems there are incom-
pleteness and unreliability of input information. This has
resulted in use of fuzzy multi-objective optimization
method with fuzzy parameters. For instance, a designer
is required to minimize the system cost while simultane-
ously maximizing the system reliability. Therefore mul-
tiple objective functions become an important aspect in
the reliability design of the engineering systems.
In general reliability optimization problem is solved
with the assumption that the coefficients or cost of com-
ponents is specified in a precise way. In real life, there
are many diverse situations due to uncertainty in judg-
ments, lack of evidence, etc. Sometimes it is not possible
to get relevant precise data for the reliability system.
This type of imprecise data is not always well repre-
sented by random variable selected from a probability
distribution. Fuzzy number may represent this data, so
fuzzy optimization method with fuzzy parameters is
needed for a fuzzy reliability optimization model.
Therefore, we formulate fuzzy multi-objective opti-
mization model for software products selection ba
gue aspiration levels, the decision maker may decide
his aspiration levels on the basis of past experience and
knowledge possessed by him. To express vague aspira-
tion levels of the decision, various membership functions
have been proposed [6,7]. A fuzzy mathematical pro-
gramming problem with non linear membership function
results in a non linear programming problem. Usually, a
linear membership function is employed to avoid non-
linearrity. Further, if membership function is interpreted
as the fuzzy utility of the decision maker, which describes
the behavior of indifference, preference or aversion to-
wards uncertainty, a non linear membership function is a
better representation than a linear membership function.
4.1. Problem Formulation
Fuzzy multi-objective optimiza
p
reliability function and minimizing the fuzzifier cost
function subject to crisp constraints are stated as follows.
Problem (P3)
L
1
ximize ()
l
li
lis
RXf R
Ma

111
Minimize(X) =
ij
iV
m
ntot
ijijijijijijk ijk
ij k
CctNyC
 





 
X
S
Here, we have defined the two objective functions, the
and cost that are considered to be vague and
un
tion
sed to solve the fuzzy mathe-
atical programming problem.
function. Same defuzzi-
fic
reliability
certain (i.e. fuzzy in nature) and the constraints are of
crisp nature. Cut-throat competition in the existing mar-
ket, system complexity, and intended flexibility makes it
difficult for the management to precisely define their
goals and constraints. Moreover a slight shift on bounds
can provide a more efficient solution. Hence, we have
used fuzzy optimization technique (fuzzy mathematical
programming) to solve the fuzzy multi-objective opti-
mization problem.
4.2. Problem Solu
The following steps are u
mStep 1. Compute the crisp equivalent of the fuzzy pa-
rameters using a defuzzification
ation function is to be used for each of the parameters.
Copyright © 2011 SciRes. AJOR
255
P. C. JHA ET AL.
Here we use the defuzzification function of the type


2
123
24FAaa a
where are the triangular fuzzy numbers.
Step Ie the objective function of the fuzzi-
n (maxn
(a
1
a,
2.
2
a,
ncor
3
a
porat
fier mi) as a fuzzy constraint with a restrictio
spiration) level. The above problem (P3) can be re-
written as
Problem (P4)
Find
X
subject to

0
1l
L
li
lis
RXfR R


0
11 1
ij
V
tot
ijijijijijijk ijk
ij k
CXc tNyCxC
 


i
m
n
X
S
Step 3. Define appropriate membership functions for
each fuzzy inequalities as well constraint correspond-
in
as
g to the objective function. The membership function
for the fuzzy less than or equal to and greater than or
equal to type are given as


 

0
*
0*
00
*
00
*
0
1; RX R
;
0;
R
RX R
X
RRXR
RR
RX R

where is the aspiration level and is the toler-
fuzzy reliability objfunction con-
0
R
ance level to the
*
0
R
ective
straint.

  
0
*
0*
00
*
00
*
0
1; CXC
;
0;( )
C
CC
X
X
CCXC
CC
CX C

where is the restriction level and is the toler-
he fuzzy budget constraint.
4. to
mathematical
pr
0
C
ance level to t
*
0
C
Step Extension principle is used identify the
fuzzy decision, which results in a crisp
ogramming problem given by
Problem (P5)
Maximize
subject to
X
R
,

CX
,
X
S
can be solved by the standard crisp mathem
gramming algorithms.
onstraint. Each constraint is
co
atical pro-
Step 5. While solving the problem, the objective of the
problem is also treated as a c
nsidered to be an objective for the decision maker and
the problem can be looked as a fuzzy multiple objective
mathematical programming problem. Further each objec-
tive can have a different level of importance and can be
assigned weights according to their relative importance.
The resulting problem can be solved by the weighted
minmax approach. The crisp formulation of the weighted
problem is given as
Problem (P6)
Maximize
subject to
1R
X
w
, C

2
X
w
,
X
S
where,
12
ww,0, 12
1ww
represents the gree up to which the aspira-
tion of the decision maker is met. If thnstraints are
de
e co
fuzzy as well as crisp, then in the equivalent crisp ma-
thematical programming problem, there will be no
change in the original crisp constraints since their toler-
ances are zero except for those constraints which are
fuzzy in nature. The problem (P6) can be solved using
standard mathematical programming approach.
Step 6. On substituting the values for
R
X
and
C
X
the problem becomes
Problem (P7)
mize Maxi
subject to

*
10
wR R
0
1R RX0

*
020
1CXCwC C
 
0
X
S
0, 1
12
,0ww, 12
1ww
Step 7. If a feasible solution is not otainable for the
problem (P7) then we can use fuzzy googramming
ap
aving two modules with
ore than one alternative for each module. The data sets
b
al pr
proach to obtain a compromised solution [9]. The me-
thod is discussed in detail in the numerical illustration.
5. Illustrative Examples
Consider a software system h
m
for COTS and in-house developed components are given
in Table 1 and Table 2, respectively.
Let 3L
,
11, 2, 3s,

21, 3s,
32s,
10.5f
, 20.3f
, 30.2f
. It is also assumed that
1
t0.01
, 2
t0.05
and
ent of weig
3
t
is based on the expert’s
0.01.
tsThe assignmh
judgment for the reliability and the cost criteria. Weights
as
nimum and Maximum Level of
Reliability and Cost
First liability and cost values are
omputed using fuzzied values of these parameters and
signed for reliability and cost are 0.7 and 0.3 respec-
tively.
5.1. Mi
ly, the triangular fuzzy re
c
Copyright © 2011 SciRes. AJOR
P. C. JHA ET AL.
256
Table 1. Data set for COTS components.
Version 1
Modules Alternatives
Cost Reliability Delivery Time
1 0 0.00 01
2 0 0.001 0
1
3 0 0.001 0
1 0 0.001 0
2 0 0.001 0
2
3 0 0.001 0
1 0 0.001 0
2 0 0.001 0
3
3 0 0.001 0
Version 2
Modules Alternatives
Cost Reliability Delivery Time
1 14 0.90 3
2 12.5 0.86 4
1
3 17 0.90 2
1 13 0.87 4
2 11 0.91 5
2
3 18 0.89 2
1 13 0.86 4
2 16 0.85 3
3
3 16 0.89 3
Version 3
Modules Alternatives
Cost Reliability Delivery Time
1 11 0.88 4
2 18 0.92 2 1
3 15 0.88 3
1 17.5 0.86 2
2 12 0.89 4
2
3 15 0.86 3
1 14 0.88 3
2 18 0.90 2
3
3 17 0.87 2
Table 2. Data set n-h omponen
Mo
for iouse cts.
dule i Alternatives i
j
t i
j
i
j
ci
j
1 8 0.005 5 0.002
2 60.005 4 0.00
2
3
21
3 7 0.005 4 0.002
1 9 0.005 5 0.002
2 5 0.005 2 0.002
3 6 0.005 4 0.002
4 5 0.005 3 0.002
1 6 0.005 4 0.002
2 5 0.005 3 0.002
then defuzzied using Hn’ s f thil-
ble reliability and cost are specified as TFN (triangular
The aspiration level of reliability is and
the restriction on cost is
eilper deuzzier.If e ava
a
fuzzy number) given as follows

00.93,0.95,0.97R
;

C
.
070,75,80
00.95R
075C
. The tolerance
*
085C.
level
fo
ming
(P7)
not feasible; hence the management goal cannot be
r reliability and cost is *
00.85R and
5.2. Fuzzy Goal Program Approach
On solving the problem, we found that the problem
is
achieved for a feasible value of
0,1
. Now we use
fuzzy goal programming technique to obtain a compro-
mised solution. The approach is the goal pro-
gramming technique for solving crisp goal programming
problem (Mohamed, 1997). The maximum value of any
membership function can be 1; maximization of
based on
0,1
is equivalent to making it as close to 1 as best
as possible. This can be achieved by minimizi
deviational variables of goal programming (i.e.
) from 1. The fuzzy goal programming formulation for
the given problem (P7) introducing the negative and pos-
itive deviational variables
ng the
negative
j
and
j
is given as
Minimize u subject to
11R1X



22
1
CX

 
j
j
uw
; 0
jj

; ,0
jj

1, 2j
X
S
;
0, 1
;
12
1ww
12
,0ww;
; 1u

5.3. Optimization Model I
for optimization model I.
he problem is solved using software package LINGO
l for compatibility, we
se previous results.
ond alternative of first module is
co econd
m
Table 3 presents the solution
T
[17]. The solution to the model gives the optimal com-
ponent selection for the software system along with the
corresponding cost and reliability of the overall system.
The sensitivity analysis to the delivery time constraint
has been performed. It is clearly seen from the table that
in case 1, when the delivery time was 15 units then one
in-house and other COTS components were selected
while in all other cases when the delivery time increases
along with in-house components there will be a corre-
sponding change in reliability and cost. In case 2, when
the delivery time was 18 units, our system reliability and
cost also increases and in case 3 as compared to case 2,
when delivery time was 20 units, system reliability in-
creases and cost decreases. Therefore, if the customer is
ready to wait then case 3 is an optimal solution. Redun-
dancy is also present in all the three cases.
5.4. Optimization Model II
To illustrate optimization mode
uCase 1. Delivery time is assumed to be 15 units.
We assume that sec
mpatible with second and third alternative of s
odule. Following solution was obtained using LINGO.
Copyright © 2011 SciRes. AJOR
P. C. JHA ET AL.
Copyright © 2011 SciRes. AJOR
257
Case No. Delivery Time In-House ty Overall System Cost α Value
Table 3. Solution for optimization model I.
COTS System Reliabili
1 15 y32 = 1
x111 = = 1
x21 0.92 75 0.84
x123 = x132
1 = x223 = x232 = x241 = 1
x311 = 1
2 18 y24 = y32 = 1
111 2
0.93 77.5 0.86
3 20 y24 = y32 = 1
111 2
0.94 76 0.90
x = x123 = x13 = 1
x211 = x223 = x232 = 1
x311 = 1
x = x123 = x13 = 1
x211 = x223 = x232 = 1
x311 = 1
It is observed that due to the comatibility condition,
th
32 1y
223
x
111123132 1xxx
233241 1xxx 311
x
211 1
p
ird alternative of second module is chosen as it is
compatible with second alternative of first module. The
system reliability for the above solution is 0.86 and cost
is 85 units. The achievement level of the membership
function is 0.40
.
Case 2. Delieme is assumed to be 20 units. vry ti
odule
is
We assume that second alternative of second m
compatible with second and third alternative of first
module. Following solution was obtained using LINGO.
2432 1yy 111123133 1xxx

211 222
xx
231 1x 311 1x
It is observed that due to the compatibility condition,
third alternative of first module is chosen as it is com-
patible with second alternative of second module. The
system reliability for the above solution is 0.93 and cost
is 77 units. The achievement level of the membership
function is 0.90
.
. Conclusions
ptimization models that supports the
and cost. This developed approach can effectively deal
efully acknowledges
nt of Maharaja Agrasen In-
ir permission to publish this
adrzejowicz, “An Approach to Reliability
oftware with Redundancy,” IEEE Transac-
re Engineering, Vol. 17, No. 3, 1991, pp.
310-312.
6
e have presented oW
decision whether to buy software components for soft-
ware architecture or to build them in-house. We have
formulated bi-criteria optimization models based on de-
cision variables indicating the set of structural compo-
nents “to buy” and “to build” in order to minimize the
software cost with simultaneous maximization of system
reliability. The problem is formulated for Recovery
Block fault-tolerant software system. It may be appreci-
ated that when different alternatives of the same module
are available with variations in the attributes of reliability
and cost, then it involves multi-objective decision mak-
ing environment that befits more of fuzzy approximation
than deterministic formulation. Therefore, we have drawn
on fuzzy methodology for the estimation of reliability
with the vagueness and subjectivity of expert’s informa-
tion. Fuzzy predictions of the triangular fuzzy statistical
data have been defuzzified using Heipern’s defuzzifier
and a crisp multi-objective model has been developed
using the defuzzified values. The component selection
problem is formulated as a multi-objective programming
problem and fuzzy goal programming technique is used
to provide a feasible solution.
7. Acknowledgements
ne of the authors, Ritu Arora, gratO
the Director and Manageme
titute of Technology for thes
research work.
8. References
] F. Belli and P. J[1
Optimization S
tion of Softwa
[2] L. M. Cysneiros and J. C. S. Leite, “Nonfunctional Re-
Quirements: From Elicitation to Conceptual Models,”
IEEE Transactions on Software Engineering, Vol. 30, No.
5, 2004, pp. 328-350. doi:10.1109/TSE.2004.10
[3] P. K. Kapur, A. K. Bardhan and P. C. Jha, “Optimal Reli-
ability Allocation Problem for a Modular Software Sys-
tem,” OPSEARCH, Vol. 40, No. 2, 2003, pp. 138-148.
[4] R. E. Bellman and L. A. Zadeh, “Decision-Making in a
Fuzzy Environment,” Management Science, Vol. 17, No. 4,
1970, pp. B141-B164. doi:10.1287/mnsc.17.4.B141
[5] H. Tanaka, T. Okuda and K. Asai, “On Fuzzy Mathe-
matical Programming,” Journal of Cybernetics, Vol. 3,
No. 4, 1974, pp. 37-46. doi:10.1080/01969727308545912
[6] H. J. Zimmermann, “Description and Optimization of
Fuzzy Systems,” International Journal of General Sys-
tems, Vol. 2, No. 4, 1976, pp. 209-215.
doi:10.1080/03081077608547470
[7] H. J. Zimmermann, “Fuzzy Set Theory and Its Applica-
P. C. JHA ET AL.
258
and Its Applica-
cht, 1991.
Sys-
tions,” Kluwer Academic Publishers, Boston, 1985.
[8] H. J. Zimmermann, “Fuzzy Set Theory
tions,” Academic Publisher, Dordre
[9] R. H. Mohamed, “The Relationship between Goal Pro-
gramming and Fuzzy Programming,” Fuzzy Sets and
tems, Vol. 89, No. 2, 1997. pp. 215-222.
doi:10.1016/S0165-0114(96)00100-5
[10] P. Gupta, M. K. Mehlawat, G. Mittal and S. Verma, “A
Hybrid Approach for Selecting Optimal COTS Products,”
Computational Science and Its Applicat
ringer Publication, Berlin, 2009, pp. 94
ion-ICCSA, Sp-
9-962.
[11] B. P. Gladish, I. Gonzalez; A. B. Terol and M. A. Parra,
“Planning a TV Advertising Campaign: A Crisp Multi
objective Programming Model from Fuzzy Basic Data,”
Omega, Vol. 38, No. 1-2, 2010, pp. 84-94.
doi:10.1016/j.omega.2009.04.004
[12] O. Berman and U. D. Kumar, “Optimization Models for
Reliability of Modular Software System,” IEEE Transac-
tion of Software Engineering, Vol. 19, No. 11, 1993, pp
ar, “Reliability Analysis of Fault Tolerant
essa, F. Marinelli and P. Potena, “An Optimiza-
.
1119-1123.
[13] U. D. Kum
Recovery Block,” OPSEARCH, Vol. 35, No. 4, 1998, pp.
281-294.
[14] V. Cortell
tion Framework for ‘Build-Or-Buy’ Decisions in Soft-
ware Architecture,” Computers and Operations Research,
Vol. 35, No. 10, 2008, pp. 3090-3106.
doi:10.1016/j.cor.2007.01.011
[15] A. Bertolino and L. Strigini, “On the Use of Testability
Measures for Dependability Assessment,” IEEE Transac-
tions on Software Engineering, Vol. 22, No. 2, 1996, pp.
97-108. doi:10.1109/32.485220
[16] H. W. Jung and B. Choi, “Optimization Models for Qual-
ity and Cost of Modular Software System,” European
Journal of Operations Research, Vol. 112, No. 3, 1999,
pp. 613-619. doi:10.1016/S0377-2217(98)00169-6
[17] H. Thiriez “OR Software LINGO,” European Journal of
Operational Research, Vol. 12, 2000, pp. 655-656.
Copyright © 2011 SciRes. AJOR