Cost Benefit Decision Model

A Cost-Benefit Decision Model:
Analysis, Comparison, and Selection

of Data Management Systems
STANLEY Y. W. SU, JOZO DUJMOVIC, D. S. BATORY, S. B. NAVATHE,
RICHARD ELNICKI
Database Systems Research and Development Center, University of Florida
AND
This paper describes a general cost-benefit decision model that is applicable to the evaluation,
comparison, and selection of alternative products with a multiplicity of features, such as complex
computer systems. The application of this model is explained and illustrated using the selection of
data management systems as an example.
The model has the following features: (1) it is mathematically based on an extended continuous
logic and a theory of complex criteria; (2) the decision-making procedure is very general yet systematic,
well-structured, and quantitative; (3) the technique is based on a comprehensive cost analysis and an
elaborate analysis of benefits expressed in terms of the decision makers preferences. The decision
methodology, when applied to the problem of selecting a data management system, takes into
consideration the life cycle of a DMS and the objectives and goals for the new systems under
evaluation. It allows the cost and preference analyses to be carried out separately using two different
models. The model for preference analysis makes use of comprehensive performance (or preference)
parameters and allows what we call a logic scoring of preferences using continuous values between
zero and one, to express the degree with which candidate systems satisfy stated requirements. It
aggregates preference parameters based on their relative weights and logical relationships to compute
a global performance (preference) score for each system. The cost model incorporates an aggregation
of costs which may be estimated over different time horizons and discounted at appropriate discount
rates. A procedure to establish an overall ranking of alternative systems based on their global
preference scores and global costs is also discussed.
Categories and Subject Descriptors: H.2.7 [Database
K.6.3 [Management
of Computing
and Information
Management]:
Database Administration;
Systems]: Software Management
General Terms: Economics, Management

Additional Key Words and Phrases: Cost-benefit analysis, data management system selection,
evaluation methodology
This research was supported by the National Bureau of Standards under contract NBSOSBCA0449.
Authors current addresses: S. Y. W. Su, S. B. Navathe, and R. Elnicki, Database Systems Research
and Development Center, University of Florida, Gainesville, FL 32611; J. Dujmovic, Department of
Electrical Engineering, University of Belgrade, Bulevar Revolucije 73, 11000 Belgrade, Yugoslavia;
D. S. Batory, Department of Computer Sciences, The University of Texas at Austin, Austin, TX
78712.
Permission to copy without fee all or part of this material is granted provided that the copies are not
made or distributed for direct commercial advantage, the ACM copyright notice and the title of the
publication and its data appear, and notice is given that copying is by permission of the Association
for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific
permission.
0 1987 ACM 0362-5915/87/0900-0472 $01.50
ACM Transactionson DatabaseSystems,Vol.
12, No. 3, September
1987, Pages 472320.
A Cost-Benefit Decision Model
473
1. INTRODUCTION
The evaluation, comparison, and selection of alternative products and services is

a very difficult decision problem that is frequently encountered by many individuals and organizations. When the products are costly and complex, the need to
make a systematic and quantitative evaluation and a justifiable selection is
critical. Unfortunately, many such problems are resolved by a decision maker
(i.e., an individual, committee, or company management) using subjective judgment, personal preference, and quite often, bias. Justification under these
conditions is at best minimal.
The evaluation, comparison, and selection of alternative data management
systems (DMSs) is a good example of a complex decision problem. When a DMS
fails to meet the data processing objectives and requirements of an organization
(e.g., response times are too long, query language facilities are inadequate), an
upgrade of the DMS is in order. The upgrade may simply involve enhancing the
existing DMS with in-house software to provide the needed functional capabilities. Alternatively, a new DMS may be chosen from a set of candidate replacements. How to choose among these alternatives is not simple. It requires a careful
and systematic cost-benefit analysis. Such an analysis can be realized with the
aid of a comprehensive decision model.
We have developed a general cost-benefit decision model that can be applied
to a variety of complex decision problems [l&20, 22, 23, 55, 561. It is called the
Logic Scoring of Preferences (LSP) model. There have been two implementations
of evaluation systems based on this model: a prototype system for database
management system evaluation implemented at the National Bureau of Standards and an evaluation system for selection of computer systems implemented
by Dujmovic at the University of Belgrade. In this paper we explain how the
model can be used to evaluate, compare, and select alternative DMSs in a
systematic and quantitative way. To emphasize the capability of our approach,
we use the term DMS loosely; a DMS can refer to a traditional file management
system, a report generation and writing system, or a customized or generalpurpose database management system. All can be treated as competing alternative solutions for data management problems.
The work reported here has been influenced by three areas of research. The
first includes surveys of database management systems; these surveys arose out
of the need to classify DMSs, to standardize classification of parameters of
DMSs, and to informally compare and evaluate systems [l, 4, 9-11, 13, 25-27,
37, 40, 43, 45, 46, 581. The.second area involves efforts to develop data management system parameters for use in formalized decision models [7, 8, 12, 16, 17,
30,33,36,41,44,50,51,53,59].
Among these works, the works of White, Scott,
and Schulz [59], Miller [41], and Sable [50] have the most comprehensive
treatment of an evaluation methodology. In these methodologies, either a simple
weighted arithmetic mean or a simple weighted geometric mean are used to
aggregate individual ratings of system features which are two of several methods
used in our model. The logical relationships among features and the distinction
of mandatory, desirable, and optional selection criteria, which are distinguished
and recognized in our model, are not incorporated in these early models. The
ACM Transactions
on Database Systems, Vol. 12, No. 3, September
1987.
474
S. Y. W. Su et al.
third area relates to costs. Existing literature on applications of file management

and data management systems provides little by way of standards to assesscosts
[14, 15, 31, 34, 57, 601. The general literature in data processing, for example,
[2, 3, 24, 42, 47-49, 541 does, however, provide a general set of issues useful in
cost estimation and evaluation. In addition to these three areas, our work has
benefited from literature on performance and optimization of DMSs, logical and
physical database designs, data models, and data languages.
In the following section we present an overview of the decision model and
discuss its role in the system life cycle. We also identify the models major
components. In Section 3, a step-by-step approach to construct and use these
components for a general decision problem is presented. Conclusions are given
in Section 4.
2. THE SYSTEM LIFE CYCLE AND AN INTRODUCTION
METHOD FOR DECISION MAKING
TO THE LSP
In this section a general model of the system life cycle of a DMS is presented,
and the role of a cost-benefit decision model in the life cycle is discussed. The
logical scoring of preference (LSP) method for decision making is outlined.
2.1 System Life Cycle
Basic components of the system life cycle are shown in Figure 1. An operational
DMS is constantly being evaluated by its users. The result of an evaluation
directly reflects the global level of satisfaction of the user community. Since this
result is usually derived from various system performance indicators, it is called
the global performance of the system.
Changes to the system are not made as long as its global performance is
considered satisfactory. Once the global performance falls below satisfactory, the
need for improving the existing system is identified. This need often motivates
an organization to enter an analysis phase in which a set of new goals or objectives
for its future applications is defined. Some examples of possible goals are (1) the
organization would provide its employees with an interactive accessto databases,
(2) the average response time of a typical transaction will be less than 3 seconds,
(3) the new DMS should provide data processing services to ten additional
customers, and so on.
Besides identifying goals for the improved system, a strategic assessment would
generally be conducted to determine if the estimated resource requirements for
carrying out a change to the existing system is in line with the overall organizations objectives and resource constraints. If it is, a decision is made to change
the existing system. At this stage, the organization faces a number of alternatives
to set up the improved system. The organization may carry out software development or hardware modification to modify and upgrade its existing system. It
may develop or purchase a new DMS or contract its data management task to a
service bureau. If a new system is to be developed or purchased, the organization
needs to decide what type of DMS would be desirable: a file management system,
a report writer, a full-scale DBMS, or others. A cost-benefit analysis of these
alternative approaches or systems needs to be conducted to determine the best
alternative. The method described below is used to aid such decision making.
ACM Transactions on Database Systems, Vol. 12, No. 3, September 1987.
475
Existing System
Evaluation of Global Performance of the
4
Decision to Chance
/
Existing
System
I
I,
/
Improved
System
----
System Requirement and Parameter Tree

I
--v
L1.1
LSP
:thod
unuysis
vIode1
{Criterion)
L-uw
f
Cost Preference Analysis
il
+
Ranking of Competitive Systems Sl, . . . , SN
Decision
(Selection of the Best Alternative)
Transition from the Existing System
to the Improved System
Improved System
in Operation
Fig.
1.
An outline of the system life cycle and the LSP decision method.
ACM Transactions
1987.
476
S. Y. W. Su et al.
2.2 The Decision Method Based on Logical Scoring or Preferences

The decision method to be introduced is called the logical scoring of preference
(LSP) method. As shown in Figure 1, it contains the following main components;
a system requirement and parameter tree, a preference analysis tree, a cost
analysis tree, a preference analysis model, a cost analysis model, and a costpreference analysis component. The functions of each are briefly outlined below.
A decision model starts with an organizations specification of the requirements
for a system that are deemed necessary for meeting the organizations goals. The
requirement specification is represented by a system requirement and parameter
(SRP) tree containing both cost and preference parameters. These parameters
are used to determine costs and to evaluate the decision makers preferences over
a number of alternative systems. Once defined, the SRP tree is split into two:
a preference analysis tree and a cost analysis tree. They are used, respectively,
as input to a preference analysis model and a cost analysis model to produce
a global preference score and a cost value for each system under evaluation.
An extended continuous logic and a theory of complex criteria are used to
perform preference analyses and to arrive to a global preference score. The theory
allows an explicit statement of the evaluation criteria whereas the logic allows
the preference to be expressed on a continuous scale between 0 and 1 rather than
in a binary way (0 or 1). The cost analysis procedure is relatively more straightforward in that it involves computing an arithmetic sum of the cost estimates
developed for the cost nodes of the cost tree.
Once the global preferences and the global costs of all evaluated systems are
known, the decision maker (or the organization) can proceed with the final part
of the decision process consisting of the cost-preference analysis (see Figure 1).
The goal of the cost-preference analysis is to provide the decision maker with a
final ranking of competitive systems.
The decision model outlined above represents a solution to the cost-benefit
problem. It enables a decision maker to compare all alternative systems in a
systematic and quantitative way. The final ranking of competitive systems
obtained from the cost-preference analysis yields a justifiable selection of the
most suitable system. That is followed by contracting and other related activities
that are necessary for the transition to the improved system. After the transition,
the system life cycle starts again from the beginning, since the new (improved)
system now appears in the role of an existing system.
In the following section we discuss the LSP method in detail and use the
evaluation, comparison, and selection of data management systems as an example
to describe and illustrate the general decision method outlined above.
3. THE LSP COST-BENEFIT DECISION MODEL
We shall use a step-by-step approach to present the LSP decision model. The
following steps form the general procedure by which the decision model can be
used for the analysis, evaluation, and selection of a data management system.
3.1 Step 1. System-Requirement-Based Analysis of Cost
and Preference Parameters
In order to compare DMS alternatives that are quite different in objectives and
design, it is necessary to establish a set of common parameters on which
ACM Transactions
1987.
477
comparisons can meaningfully be made. This set should contain parameters

for evaluating the costs of the alternative systems as well as their capabilities
in satisfying the system requirements that are defined by an organization.
System requirements pertain to the computational and personnel resources and
support necessary to establish and maintain an operational data management
system.
Our approach to derive the set of cost and preference parameters is to identify
the major categories of system requirements based on the specific data processing
environment and needs of the organization. Figure 2 shows six general categories
of system requirements: vendor support, computer and facility environment,
DMS software, conversion, application system, and operations. Each is identified
with a node of a system requirement and parameter (SW) tree. Initially, the SRP
tree contains only the requirement nodes that are labeled R for requirement.
Each of these nodes (categories) in turn can be further decomposed into lower
level nodes (subcategories) based on the following criteria and guidelines.
(1) The decomposition of a higher level node into its components should be
based on the following considerations: (a) how the requirements are satisfied in
the existing data management systems or how they can be satisfied by the current
and new data management technology, and (b) what costs are typically incurred
on the development and operation of computer software and hardware to satisfy
the requirements.
(2) The top levels of the tree should be the system requirements familiar to
general data management personnel and the lower level nodes should be cost and
performance parameters reflecting the technical and cost details for implementing hardware and/or software to satisfy the requirements. Since the upper level
nodes represent requirements and have cost and performance (or preference)
values associated with them, they are labelled by R, P, and C in Figure 2.
The lower level nodes (not shown in Figure 2) may represent cost or preference
nodes only, and thus will be labelled with a P or C, without R. Each parent
node on the tree should branch to a limited number of sons, to make it easier for
the user of this tree to assign relative weights and to aggregate these nodes during
logical aggregation of preference parameters (see Section 3.3). In the event that
there are many subcomponents under one node, a grouping and classification of
these subcomponents into subtrees under the original parent node should be
made.
(3) A C node should be decomposed into components if the data management
facilities or features they represent are supplied by at least one vendor with
additional or separate costs.
(4) The decomposition of the cost parameters should stop at the level at which
the parameters reflect the basic factors used by the management in computing
or preparing a budget. The decomposition of the performance parameters should
be carried out to a level at which parameters represent the most up-to-date
techniques, facilities, or algorithms for achieving the function represented by
their parent node.
(5) The decomposition of a cost/preference parameter should not be continued
if further decomposition does not result in a more accurate assignment of cost
and/or preference score to the node.
478
S. Y. W. Su et
al.
Figure 2 shows the top two levels of a comprehensive SRP tree reported on in
[Xl. The structure and contents of an SRP tree may vary, depending on different
decision situations. The decision methodology presented in this paper can be
applied to any SRP tree defined by an organization.
The main purpose of decomposition is to make the computation of cost and
the assignment of preference score to a requirement node simpler and more
accurate. For example, it is difficult to determine the cost of an operation for a
system without breaking it down into more detailed items such as the hiring of
a programmer, the purchasing of supplies, and so on. On the other hand, it is
easier for a decision maker to determine the salary of a new programmer, which
is a cost node in the subtree of an operation. Similarly, to assign a preference
score to DMS software is a difficult task. But it is much easier for a decision
maker to say whether he or she is satisfied with a DMS that does not have
COBOL as a host language (host language support is a node in the subtree for
DMS software). As requirements become more and more specific with further
decomposition, the computation of costs becomes more accurate and the assignment of preference scores becomes more specific, easy to define, and, as much as
possible, objective.
Although the methods for assigning costs and preferences are considered in
subsequent sections, we note here that a single feature of a DMS can help satisfy
many needs. A facility to handle special data types, for example, may contribute
to better performance as well as simplifying the development of programs for
customized applications. However, it is also possible for a feature to satisfy one
need while making it difficult to satisfy others. For example, user-oriented
features such as better language interfaces/graphic support, typically may increase the processing load on a system and result in worse response times, greater
storage requirements, and so on. The so-called preference parameters inherently
have some built-in trade-offs, which make the selection process a nontrivial task
in the first place. Moreover, most of the time, adding one feature implies that
one has less money to spend on other features. For example, report writers may
not be included in a basic DBMS/FMS package and may need to be purchased
separately. A purchase might satisfy data processing requirements but at the
same time increase the cost of the system.
While we claim that an SRP tree can be used to model all of the above
situations, the choice of the nodes, their relative placements, and so on are
certainly subject to human judgment.
An SRP tree derived using the above criteria and guidelines has leaf nodes
that represent (1) cost parameters to which only cost values can be assigned by
the decision maker, (2) preference parameters to which only preference scores
can be assigned, and (3) cost and preference parameters that have both cost
values and preference scores. The nonleaf nodes will have cost and/or preference
values by aggregating the values of their descendants. The nodes of an SRP tree
can be labeled by codes (e.g., R for requirement, P for preference, and C for cost)
as illustrated in Figure 2. These character codes facilitate the splitting of an SRP
tree into a cost tree and a preference tree containing cost and preference
parameters, respectively. These two trees are used for the subsequent cost and
preference analyses using two different models. We present the preference
System
Requirement
and
Parameter Tree
I RPC Vendor support
11 RPC Vendor support for DMS

12 RPC Vendor support for system software
13 RPC Vendor support for hardware
2 RPC Computer and facility environment
21 RPC System software

22 RPC Hardware
23 RPC Facility
3 RPC DMSsoftware
[ 34 iRPC ~~~~
Data organization and access
w
op
4 RPC Conversion
41 RPC Data conversion

42 RPC Program conversion
5 RPC Application system
51 RPC Program development

52 RPC DMS performance requirements
6 RC Operations
ii
E;iazF
w
Fig. 2. An SRP tree (first two levels). RPC: a requirement node with a preference score and cost value; RC: a requirement node with a
cost value; n: node number expressed as a trace from the root.
480
S. Y. W. Su
et al.
analysis first in steps 2, 3, and 4 (Sections 3.2 to 3.4) and the cost analysis in
step 5 (Section 3.5).
3.2 Step 2. Formulation of Elementary Criteria
The first step of preference analysis is the formulation of elementary criteria for
the preference parameters (X1, X2, . . . , X,) that are the leaf nodes of the
preference tree. An elementary criterion is a mapping of the values that can be
assigned to a preference parameter to real numbers in the range of zero to one.
The assignment of a value VXi of parameter Xi of preference score Ei means that
Ei expresses the decision makers degree of satisfaction with parameter Xi having
value VXi. Stated another way, the elementary preference Ei is the degree of
truth in the statement that asserts the value that VXi completely fulfills the
requirement of performance parameter Xi. The values of the preference parameters (not their preference scores) are provided by the vendor of the DMS under
consideration.
Consider the Vendor-Service preference parameter. Suppose that half-day,
daytime-only, and 24-hour service are the values that could be assigned to VendorService. The decision maker can express the degree of satisfaction for such
service by assigning a preference score ranging from 0 percent to 100 percent to
each value. Scores that might be assigned are shown in Figure 3(a). In this figure
a vendor who provides 24-hour service is rated as 100 percent satisfactory by the
decision maker. Daytime-only service is rated at 30 percent, and half-day is
completely unsatisfactory (0 percent).
Vendor-Service is an example of a parameter whose value set can be enumerated. A parameter whose value set is not enumerable is Average-Response-Time.
Suppose t is the average response time of some specified DMS process. An
elementary criterion for Average-Response-Time might be the function El(t) in
Figure 3(b). Criterion El states that a decision maker is completely satisfied (i.e.,
El(t) = 1) if the response time is less than or equal to &in. An average response
time greater than or equal to tmm is considered completely unsatisfactory (i.e.,
El(t) = 0). If t is between t&in and t,,, the requirement is partially fulfilled and
a linear interpolation is used for calculating the partial degree of fulfillment.
The elementary criterion El utilizes an absolute scale (tmin, tmlu) by which
individual response times are mapped to preference scores. Alternatively, a
relative scale could be used. Let ti be the average response time measured for
system i and let TMIN be the minimum value of ti for the m system (i = l..m)
that are being evaluated. An Average-Response-Time elementary criterion could
be the function E2(t) shown in Figure 3(c). Criterion E2 states that a decision
maker is completely satisfied (i.e., E2(t) = 1) if the response time is the best that
is achieved by all candidate systems. Other response times partially satisfy the
criterion, and if t 2 lz:TMIN then E2(t) = 0 (we assume k > 1, and most
frequently we use 2 < k < 4). So E2 assigns high scores to response times that
are close to TMIN, and low scores to those that are not.
In general, there are many ways of formulating elementary criteria. The
preferred methods are those that are simple and evident, such as the above
examples that rely on absolute and relative rankings, and the enumeration of
value sets. Although a detailed classification of elementary criteria has been
ACM Transactions
1987.

half-day
24-hour service
daytime-only
I
I .2I .3I .4I .5I .61 .7I .8I .9I
0 .l
VS(r) =
1 Preference score
0
.3
1
if
if
if
481
x = half-day
x = daytime-only
x = 24-hour service
(4
Preference
1
El@) =
F
M1- Lin
i 0
if
t 5 ttin
if
td I t 5 t,..
if
t Z t,,
LiIl
0.4
Preference
n(t)
I
TMIN
where TMIN is minimum of all measured times

for candidate systems
= (k TMIN/t - l)/(k - l),

TMIN 5 t I k l TMIN
=0, t>krTMIN
k*TMIN
(4
Fig. 3. Elementary criteria. (a) An elementary criterion for Vendor-Service. (b) An elementary
criterion for Average-Response-Tie. (c) Another elementary criterion for Average-Response Time.
developed (see [22]), we do not dwell on this classification here, since it is

straightforward and not essential to the understanding of the LSP method.
As mentioned earlier, the purpose of elementary criteria is to transform values
of preference parameters ( VX,, VX2 , . . . , VX,) to preference scores or elementary
preferences (el, . . . , e,) on a normalized scale of (0, 100). These scores are used
in the next step of preference analysis, that is, the aggregation of preferences.
3.3 Step 3. Aggregation of Preferences
3.3.1 Preference Aggregation Functions. The aggregation of elementary preferences into a global preference rating is a basic objective of DMS evaluation.
An aggregation is accomplished through the use of preference aggregation functions which accept as input elementary preferences el, . . . , e, with their relative
weights wl, . . . , w,,, and return an aggregate preference E as output. The weights
are chosen so that they are positive and normalized (i.e., CC1 Wi = 1);
individual weights indicate the relative importance of their corresponding
preference parameters.
ACM Transactionson DatabaseSystems,Vol. 12,
No. 3, September
1987.
482
S. Y. W. Su
et al.
Table I. Special Cases of the Weighted Power

Mean for n = 2
Name
mink, 4
1
wIleI + de2
kP . WY
weI + wzez
wlef + w&m
maxh 4
--m
Minimum
-1
Harmonic mean
0
1
2
+a,
Geometric mean
Arithmetic mean
Square mean
Maximum
For example, if the elementary preferences of the parameters data compression

and data encryption are to be aggregated, and data compression is considered to
be twice as important as data encryption, the weights assigned to data compression and encryption would be .67 and .33, respectively. (Weights, like preference
scores, can also be expressed in terms of percentages.) Also, it is obvious that the
assignment of specific weights, such as .67 and .33 above, in the context of
specific organizations with specific applications involves subjectivity. Consequently, decision makers are assumed to be experts for the evaluated system, so
that weights can be assigned and interpretations can be ascribed to aggregated
preferences in a meaningful manner. Moreover, other techniques such as the
Delphi technique are known to provide a good approximation of the collective
opinion of groups of individuals and may be employed to arrive at the weights.
Many functions can be used to aggregate preferences. Weighted arithmetic and
geometric means are common, and so too are maximum and minimum functions.
We use a general aggregation function called the weighted power mean:
E = (wl . el + w2 . ez + .-- w,, . e:),
(1)
where --a, I r 5 00.By varying the value of r, a spectrum of aggregation functions

is generated. This spectrum encompasses the most common aggregation functions, including the weighted arithmetic and geometric mean. Table I lists some
of the more important special cases.
Just as Boolean interpretations can be ascribed to preference scores,
so too can Boolean interpretations be given to aggregation functions. For example, the logical conjunction operation corresponds to the minimum function
min(el, . . . , e,) and logical disjunction corresponds to max(el, . . . , e,). Although
aggregate preferences may take on nonintegral values, the essential concept of
disjunction and conjunction is still present.
Logical conjunction and disjunction, or the minimum and maximum functions,
are the endpoints of the spectrum of aggregation functions that is defined by the
weighted power mean. Aggregation functions of this spectrum have been referred
to as generalized conjunction-disjunction (GCD) functions. Although the number
of distinct GCD functions is enormous, only a very few are actually used. Even
if the simultaneous satisfaction of requirements is very desirable, one does not
normally treat the cases el = e2 = 5, and el = 5, and e2 = 1 as fully equivalent,
nor are the cases el = e2 = 1, el = .5, and e2 = 1 fully equivalent, even if the
satisfaction of any single requirement is of primary concern. In practice, GCD
ACM Transactions
1987.
483
functions other than conjunction or disjunction are chosen so that the above
situations can be distinguished.
Five basic GCD functions have been identified and are given special names.
These are the conjunction (C), medium quasiconjunction (CA), arithmetic mean
(A), medium quasidisjunction (DA), and disjunction (D). Four intermediate
functions that interpolate between each of these aggregate functions are strong
quasiconjunction (C+), weak quasiconjunction (C-), weak quasidisjunction (D-),
and strong quasidisjunction (D+). Table II ranks these functions, going from
total disjunction to total conjunction.
On a practical note, GCD functions using the weighted power mean parameter
r 5 0 are said to be mandatory. That is, if any input preference is zero, the
aggregate preference will be zero. This is not a characteristic of nonmandatory
functions.
The value of r that is assigned to a particular GCD function in Table II is
computed in the following way. We can define a quantity 0 5 c 5 1, called the
conjunction degree, which indicates the degree of conjunctivity of an aggregate
function. c = 0 corresponds to pure disjunction and c = 1 is pure conjunction.
To relate values of c to r, the average value of the weighted power mean is used:
Intuitively, E(r, n) is the expected aggregate preference of n equally weighted

elementary preferences where all possible preference combinations are equally
likely. E(r, n) is strictly decreasing with greater conjunctivity (i.e., smaller r).
The conjunction degree c is defined as a linear interpolation between the minimal
and maximal values of E(r, n) for a fixed n:
E(+m, n) - E(r, n)
= E(+m, n) - E(-m, n)
(3)
Values of c and r are therefore in 1: 1 correspondence for a fixed n. The GCD

functions of Table II have conjunctive degrees that differ by equal increments
(i.e., AC = Q).The values of r associated with particular values of c and n were
obtained by solving equations (2) and (3) numerically.
Figure 4 shows a diagrammatic notation for GCD functions. A function is
represented by a circle labeled with its name. There is one weighted input arc for
each input preference, and a single output arc that denotes the aggregated
preference score. The sum of the weights on the arcs leading into one GCD is 1,
but it is usually convenient to express weights as percentages. (We avoid the
percentage sign so as not to clutter the diagrams.) As we will see shortly, this
notation enables compositions of GCD functions to be expressed easily.
One particular aggregate function that is quite useful needs to be discussed. It
is called the partial absorption function [21] and is used in the following situation.
Not all preference parameters of an SRP tree are identified with features that a
DMS must exhibit. Some preference parameters correspond to features whose
presence is optional. The elementary preferences assigned to these optional
parameters should therefore only slightly influence the overall preference ratings
given to essential DMS features by either increasing or reducing their preferACM Transactions
1987.
Table II.
Generalized Conjunction-Disjunction
Functions [ 191
Value of r
Mandatory
requirement
Name of
operation
Symbol of
operation
Conjunctive
degree (c)
n=2
n=3
n=4
n=5
No
Disjunction
Strong QD
Medium QD
Weak QD
Arithmetic mean
Weak QC
Medium QC
Strong QC
Conjunction
D
D+
DA
DA
CCA
C+
C
0.000
0.125
0.250
0.375
0.500
0.625
0.750
0.875
1.000
+CQ
9.52
3.93
2.02
1.00
.26
-.72
-3.51
-Ca
+m
11.09
4.45
2.19
1.00
.20
-.73
-3.11
-co
+a
12.28
4.82
2.30
1.00
.17
-.71
-2.18
-co
+oO
13.16
5.09
2.38
1.00
.16
-.67
-2.61
-co
No
No
No
No
No
Yes
Yes
Yes
485
e2
n input
preferences
E bgpregab
preference)
em-l
e.
where
jl wi = 1
Fig. 4. A preference aggregation function diagram.
_,..k,.,&-.
E (aggregate preference)
Fig. 5. A partial absorption function diagram.
ence scores by a small value. (Note that such an influence cannot always be
achieved solely by using a GCD function and by assigning small weights to
optional parameters. In cases where r 5 0 it is possible, for example, that an
optional preference score of zero may drive an aggregated preference to zero even
though essential DMS features are scored highly.) The partial absorption function
aggregates two preferences: a primary (e,) and a secondary (e,). When the primary
preference score goes to zero, the output (E) goes to zero no matter how high the
secondary preference score is. It outputs a preference score that is on the average
within the range (eP - 6-, e, + a+). The values of 6- and 6+ have a direct
relationship with weights assigned to this function (see an example below). They
indicate the range of influence of the secondary preference variable (e,) on the
output (E).
A partial absorption function can be realized by cascading the two GCD
functions A and CA as illustrated in Figure 5. Note that unlike individual GCD
functions, where weights must accompany elementary preferences, the specification of (a-, 6+) determines the weights to be used. Table III lists (-a-, 6+) pairs
as a function of weights w1 and w2 of the partial absorption function shown in
Figure 5. Figure 6 shows that a partial absorption function with 6- = .14 and
a+ = .08 is equivalent to the assignment of 0.7 and 0.6 to w1 and w2 of the
function, respectively.
It should be emphasized that the mandatory requirements and partial absorption functions are fundamental concepts indispensable for the realization of
quantitative models for evaluation and selection of general complex systems.
Consequently, proper preference logic functions must support these concepts,
and similarly, these concepts can be used for testing the suitability of a preference
r The choice of CA as the secondary GCD function of Figure 5 is not the only choice. Others such as
C-, C, and C could also be used; each would have its own table similar to Table III (see [21]) to
show the relationship between (-a-, 6+) and weights.
ACM Transactionson DatabaseSystems,Vol. 12,
No. 3, September
1987.
486
S. Y. W. Su et al.
Table III.
WI
w2 = 0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
0.1
-88.8
64.0
-87.2
49.4
-85.3
38.7
-82.8
30.3
-79.4
23.3
-74.8
17.4
-68.1
12.2
-57.4
7.7
-38.9
3.6
Partial Absorption Function Weights [21]
0.2
-77.9
57.8
-75.5
45.0
-72.5
35.5
-68.8
27.9
-64.2
21.6
-58.2
16.1
-50.4
11.4
-39.6
7.2
-24.0
3.4
0.3
0.4
0.5
0.6
0.7
0.8
0.9
-67.4
51.5
-64.4
40.4
-60.9
32.1
-56.7
25.4
-51.7
19.7
-45.7
14.8
-38.2
10.5
-28.7
6.6
-16.4
3.1
-57.2
45.0
-53.9
35.7
-50.3
28.5
-46.1
22.6
-41.3
17.7
-35.7
13.3
-29.0
9.5
-21.2
6.0
-11.7
2.9
-47.1
38.2
-44.0
30.6
-40.5
24.7
-36.6
19.7
-32.3
15.5
-27.4
11.7
-21.8
8.4
-15.6
5.3
-8.3
2.5
-37.3
31.3
-34.5
25.4
-31.4
20.6
-28.0
16.6
-24.3
13.1
-20.3
10.0
-16.0
7.1
-11.2
4.6
-5.9
2.2
-27.7
24.0
-25.3
19.8
-22.8
16.3
-20.1
13.2
-17.3
10.5
-14.3
8.0
-11.0
5.8
-7.6
3.7
-3.9
1.8
-18.3
16.5
-16.6
13.8
-14.8
11.5
-12.9
9.4
-11.0
7.6
-8.9
5.8
-6.8
4.2
-4.6
2.7
-2.4
1.3
-9.1
8.5
-8.1
7.3
-7.2
6.2
-6.2
5.1
-5.2
4.2
-4.2
3.3
-3.2
2.4
-2.1
1.6
-1.1
0.8
Fig. 6. A partial absorption function example.
logic function for use in system evaluation models. For example, using the
quasidisjunction
(or) and negation (not (e) := 1 - e), it is possible to define
quasiconjunction
(and) from De Morgans law:
el and e2 and . . . and e, := 1 - [(l - el) or (1 - e2) or - . - or (1 - e,)].
However, it is easy to see that such a form of quasiconjunction,
which is used in
extended Boolean information
retrieval [52], cannot support either the concept
of mandatory requirements or the realization of partial absorption functions, and
accordingly it is not suitable for system evaluation models.
In the following section we provide guidelines for the selection of appropriate
GCD functions for aggregating preferences. Although the actual choice of a GCD
function is completely subjective, a question arises as to why there are so many
functions to choose from. An intuitive justification
can be given by means of a
familiar example. University instructors assign letter grades to indicate student
performance. Normally, one of five grades are given (A . . . E). However, a more
refined set of eight different grades might also be used (A, B+, B, C+, . . . , D,
E). In both examples, well-defined criteria are used to distinguish between grades.
ACM Transactionson DatabaseSystems,Vol. 12,No.
3, September
1987.
487
Analogously, well-defined criteria can be formulated to distinguish between GCD

functions. Further details on GCD functions are given in [18, 191 and [22].
3.3.2 Aggregation Structures. An aggregation structure is a composition of
aggregation functions which produces a global preference rating from elementary
preferences. An aggregation structure can be generally developed as a composition
of GCD functions. During the aggregation process for each group of related
parameters an SRP subtree is defined. If the parameters of the subtree affect the
aggregate preference in the same logical way (e.g., all parameters are essential
for the fulfillment of users requirements), then we have a subtree with singleclass parameters. On the other hand, the parameters of an SRP subtree may
affect the aggregate preference in logically different ways (e.g., some parameters
can be essential while some others can be optional), and in such cases we have a
multiclass SRP subtree. A single-class SRP subtree may be considered a special
case of a multiclass SRP subtree and, consequently, below we suggest a technique
for organizing multiclass subtrees only.
Following is a simple three-stage procedure for the synthesis of multiclass SRP
subtrees:
(1) classify the parameters of an SRP subtree;

(2) aggregate parameters within a classification;
(3) aggregate different classifications to produce a preference rating for the
subtree.
Aggregation is applied repeatedly by moving from the leaf nodes of an SRP
tree toward the root node. Stages 1 to 3 are applied at each iteration. The
following paragraphs will explain and illustrate each of these stages.
State 1. The first stage is to classify the preference parameters of a designated
subtree of an SRP tree into three categories: essential, desirable, and optional.
(Generally, some categories may be empty.) Essential parameters describe features that a DMS must exhibit if it is to satisfy the requirements of the subtree.
If an essential feature is absent, the preference rating of the DMS for that subtree
is penalized so severely that, for all practical purposes, it can be considered zero.
Desirable parameters describe features that are strongly desired, but are themselves not absolutely essential to satisfy the requirements of the subtree. In
contrast to essential features, a desirable feature may be missing from a DMS
without causing the preference rating to drop to zero. The selection of a proper
GCD can ensure that a zero-desirable parameter value will not cause the whole
aggregation to become zero. Intuitively, the greater the number of desirable
features a DMS exhibits, the higher its preference rating for that subtree. Optional
parameters describe features of a DMS that are nonessential. The presence or
absence of optional features impacts minimally the overall preference rating of a
DMS for a subtree. Optional features are included in an SRP tree as a way of
assessing the generality of a DMS.
As an example, consider the Record Implementation subtree shown in
Figure 7. Suppose a classification of the parameters consistent with the goals
ACM Transactions
1987.
488
S. Y. W. Su
et al.
r 3411 Variable length records
3416 Null values
t 3417 Record size limitations

Fig. 7. F&cord implementation subtree.
and requirements of a companys DMS decision problem is

Essential:
Desirable:
Optional:
record size limitations;

variable length records, repeating groups;
hierarchical records, duplicate keys, null values.
That is, in order to avoid unnecessarily complex database designs, it is essential

that the record sizes of the current and anticipated files not exceed the size
limitations of a DMS. Variable length records and repeating groups are desired
features. Hierarchical records, duplicate keys, and null values are features that
would enhance the DMSs capabilities, but are themselves nonessential for the
current and projected needs.
Stage 2. The next stage is to aggregate the preference scores of the parameters
that belong to the same classification. Since the parameters of a classification
have a similar significance, a structure that aggregates their scores can be quite
simple. The aggregation of preferences within a given class is shown as a part of
Figure 8. For example, the preference score of the optional parameters may be
obtained by a weighted average, where the weight assigned to each parameter
reflects its relative importance among the other parameters (Figure 8(c)). Analogous reasoning can be applied to the aggregation of desirable parameters
(Figure 8(b)) and essential parameters (Figure 8(a)). Note that the GCD functions
used to aggregate optional, desirable, and essential parameters become increasingly more conjunctive. This reflects the increased need for the simultaneity of
high preference scores for all parameters.
Figure 9 shows an example aggregation of the optional and desirable parameters
for the Record Implementation subtree. (Note that weights are expressed as
percentages). Variable length records and repeating groups are considered of
equal importance, whereas hierarchical records are deemed less important than
duplicate keys and null values. Aggregation functions are not required whenever
a classification (e.g., essential) contains zero or one parameters.
The aggregation functions of Figure 8 are only representative and are suggested
as examples. While they may be used as guidelines, they are by no means the
only functions that can be (and have been) used. We examine some alternatives
in Section 3.4. A cursory examination of the aggregation structure given in
Appendix A will show some others.
Stage 3. The third stage is to aggregate the preference ratings of different
classifications. This can be done incrementally by first aggregating the optional
and desirable category ratings, and then aggregating this intermediate result with
the essential category rating.
ACM Transactions
1987.
I
I
I
I
I
I
Preference Aggregation Within a Class
Preference Aggregation for Three Basic Classes
Essential parameter
)
Essential parameter
(84
.
Essential preference rating
Essential parameter
Desirable
and
Optional parameter
(W
bma~
preference
rating for
t
1 Optional preference rating
Optional parameter
I
Optional parameter
Fig. 8. A general three-class preference aggregation structure.
..-
__-_ ._ -
. ._ --
- -
- --
._
-._
---
490
S. Y. W. Su
et al.
Hierarchical records
Duplicate keys
Null values
Fig. 9. Desired and optional category aggregation structures.
The aggregate preference of the optional and desirable categories should

be primarily determined by the desirable category rating; the influence of
the optional rating should only be slight. The partial absorption function of
Figure 8(d) may be used for this purpose. Similarly, the aggregation of this
result and the preference rating of the essential category should be primarily
determined by the essential category rating. Another partial absorption function
shown in Figure 8(e) may be used for this purpose. The composition of both
aggregation functions yields a single function.
The fundamental property of the preference aggregation structure shown in
Figure 8 is that both the desirable preference rating and the optional preference
rating may be zero, but if the essential preference rating is positive, then the
aggregate preference rating will also be positive. In many real cases, however, it
may reasonably be expected that the evaluated systems will have nonzero
desirable and optional preference ratings, and then it is possible to use simpler
aggregation structures as shown in Figure 10. Assuming that the desired and
optional category rating in Figure 10 is positive, the simplified aggregation
structure shown in Figure 10 yields similar results as the general structure of
Figure 8. Obviously, this assumption is critical, since otherwise the zero rating
of the desired and optional category would yield a zero aggregate rating.
The overall procedure of aggregation involves applying the above three stages
repeatedly on each subtree until the entire SRP tree is reduced to a single global
preference score.
As an example, assuming nonzero desired and optional preference, the preference rating for Record Implementation can be computed using the aggregation
structure of Figure 11(a). Analogously, aggregation structures for Implementation Requirements (Figure 11(b)) and Database Organization and Access
(Figure 11(c)) can be developed. (Note that the preference rating of Database
Organization and Access is an aggregation of the preference ratings of the Record
Implementation, Implementation Requirements, and Other Operations subtrees.
In Figure 11(c), it is essential that each subtree have a high preference score.)
Continuing in this manner, an aggregation structure that evaluates the preferences of all parameters of an SRP tree can be developed.
491
Desired category
rating
(104
80
(lob) Essential category .

rating
Aggregate
rating
Fig. 10. Aggregation of different category ratings.
Appendix A contains a proposed aggregation structure for the ABC companys

hypothetical DMS decision problem. The weights, structure, and aggregation
functions assigned to each substructure reflect the requirements and decisions of
the ABC company under its decision situation. Appendix A can be used as a
guide for the users of this decision model for constructing aggregation structures
for their own decision problems. The numbers in parentheses following the
elementary criterion titles in the figures of Appendix A are the decimal codes for
the criteria. They are developed on the basis of a hierarchical numbering scheme
which uses a digit to number each subtree in an SRP tree; they are provided for
cross-referencing.
3.4 Step 4. Sensitivity Analysis
The aggregation of preferences is a conceptually straightforward task. In practice,

however, it becomes difficult for three very different reasons. First, the specification of elementary criteria, the assignment of weights, and the choice of
aggregation structures clearly involve elements of subjectivity. Second, GCD
functions are highly nonlinear. Situations may arise where a decision makers
insight fails to predict the outcome of LSP computations. Third, global preference
ratings must be interpreted. For example, if System A has an 85 percent rating
and System B has 68 percent, one may conclude that System A is better than
System B. But why and due to what factors? Accuracy, insight, and justifiability
are essential in choosing the best available system.
Central to these issues is the recognition that global preference ratings cannot
be treated as absolute performance metrics. The reason is that altering any
elementary criterion, weight, or GCD function can change a global rating.
However, if it is known that ratings do not critically depend on weights, GCD
functions, or some (but not all) elementary criteria, then subjectivity is reduced,
and an accurate and justifiable interpretation of global preferences can be
ascribed. Such insights can be gained through a sensitivity analysis.
Sensitivity analysis in the present context is a systematic investigation of the
impact of GCD function parameters and elementary preferences on global preference ratings. Its purpose is to identify those factors (from among weights, GCD
ACM Transactions
1987.
S. Y. W. Su
et al.
Variable length
records
Desired
Repeating groups
Hierarchical records
Optional
i
Essential
RECORD
IMPLEMENTATION
{ limitations
11 (a)
File
implementation
Relationship
implementation
Desired
Index
1 implementation
Optional
Essential
(
DMS size
IMPLEMENTATION
REQUIREMENTS
-i
11 OJ)
Desired
RECORD
IMPLEMENTATION
35
IMPLEMENTATION
REQUIREMENTS
39
. DATA ORGANIZATION
and ACCESS
Other
1 operations
Fig. 11. An aggregation structure for database organization and access. Note: Preference ratings for
elementary criteria are in lowercase letters, ratings for subtrees are in uppercase.
function exponents, and elementary preferences) that have the strongest influence on global ratings, and hence whose values should be chosen with care, and
to provide a meaningful interpretation of aggregate preference scores. In the
following paragraphs we outline three tests (or trial experiments) which we
have found useful to help understand the preference ratings of candidate systems.
These tests are not exhaustive but are representative of the types of analyses
which can be undertaken.
ACM Treneections
1987.

Table IV.
Input Preference
Criteria
493
Scores for Three DMSs
DMS-A
Variable length records

Repeating groups
Hierarchical
records
Duplicate keys
Null values
Record size limitations
File implementation
Relationship implementation
Index implementation
File placement
DMS size limitations
Other operations
0.1
0.6
0.0
1.0
0.0
1.0
0.8
0.5
0.4
0.8
1.0
1.0
DMS-B
0.2
0.6
0.0
1.0
0.0
1.0
0.6
0.3
0.7
1.0
1.0
0.9
DMS-C
0.9
0.1
0.5
0.0
1.0
0.8
1.0
0.1
1.0
0.0
1.0
0.6
Our tests use the Data Organization and Access aggregation structure of
Figure 11 and the elementary preferences for three different systems, whose
values are listed in Table IV. Note that DMS-A and DMS-B have preference
ratings that are quite similar, while those for DMS-A and DMS-C are rather
different. This is reflected in their respective global preference scores of 85, 84,
and 68 percent, which were obtained by a straightforward evaluation of the
aggregation structure of Figure 11.
3.4.1 Test 1. Variation of GCD Functions. A first test is to examine the effects
of using different GCD functions to aggregate optional, desirable, and essential
preferences while keeping elementary preferences and aggregation structure
weights constant. The functions that are used in Figures 8 and 11 are A, C-, and
CA. Different sets of functions can be obtained by shifting the conjunctivity of
each aggregation function up (i.e., C- to CA to C) or down (i.e., C- to A to D-)
along the spectrum of GCD functions of Table II. Yet another way would begin
with a different initial set, such as (DA, A, CA), which has a wider GCD spread
and is thus less conjunctive. The same shifting operations could then be applied.
Figure 12(a) shows the changes in Data Organization and Access ratings as
the conjunctivity of the basic set (A, C-, CA) is shifted. Figure 12(b) shows
similar results using a different basic set (DA, A, CA). Note that not all function sets that appear in these figures would normally be used. As explained in
Section 3.3.1, one typically avoids the use of pure conjunction (C) and pure
disjunction (D). Thus, the middle three function sets of Figures 12(a)-(b) are
of primary interest.
It is clear from these figures that the preference ratings of the three systems
are relatively insensitive to GCD functions. DMS-A and DMS-B consistently
rate better than DMS-C. Notice, however, that the rankings of DMS-A and
DMS-B do change (albeit slightly) with different function sets. The reason is
that DMS-A and DMS-B have approximately equal aggregate ratings and a slight
The values of Table IV were chosen randomly and do not reflect preference scores of actual systems.
The absolute variations in values are therefore not significant. They should be treated strictly as
illustrations.
494
S. Y. W. Su et al.
Data organization
and access
Data organization
and access
1
----__
----__
.
--,
L.
.5
0
DA
DA
DA
C-
A
CCA
CCA
C+
Function set
CA Optional
C+ Desired
C
Essential
0 -11
D
DA
A
(a)
D+
DC-
DA
A
CA
DCC+
Function set
Optional
A
CA Desired
C
Essential
(b)
Legend: DMS-A
DMS-B
DMS-C
----------
Fig. 12. Sensitivity curves for aggregation functions. (a) Basic function set (A, C-, CA). (b) Basic
function set (DA, A, CA).
change in these ratings is enough to change their ranking. But which of these
two systems is better? Although no absolute advantage can be attributed to
either, the following observation can be used to distinguish them. Highly conjunctive function sets severely penalize a single low preference rating, whereas
highly disjunctive functions excessively reward a single high score. It follows that
those systems that have consistently high scores on all elementary criteria (but
do not necessarily achieve the individual best elementary preference ratings) will
rank the highest as the conjunctivity
of the function set increases; those that
score the best on some (but not all) criteria will rank highest as the conjunctivity
decreases. Thus Figures 12(a)-(b) suggest that DMS-B has consistently good
scores and DMS-A has some of the individually
highest scores.
3.4.2 Test 2. Varziztion of Individual
Preference Ratings. A second test is to
the effects of changes in individual elementary preference ratings on
aggregated preference scores. Figure 13(a)-(c) shows the effects of the preference
ratings of optional (Hierarchical
Records), desired (Variable Length Records),
and essential (Record Size Limitations)
parameters on the Data Organization
and Access rating. As expected, the influence of a parameter is directly related
to its category (i.e., optional, desired, etc.). That is, optional parameter ratings
influence aggregate scores minimally, while essential parameter ratings influence
them strongly.
The influence of sensitive parameter ratings is nonlinear. A small change in a
low rating has a much greater effect on an aggregated score than a similar change
in a high rating (see Figure 13(c)). This is quite important.
It means that
inaccurate preference assignments to these parameters may produce unreliable
aggregate ratings. This indicates that care should be taken whenever scores
(especially low scores) are assigned to sensitive performance parameters; such
scores should be assigned as accurately as possible. Most care should normally
investigate
ACM Transactions
1987.
495
Data organization
and access
1.0 -I-
Data organization
end access
1.0
--_---_-___--
0 t#mIlI
.5
0
.5
Hierarchical
records
.5
records
(b)
(4
Data organization
and access
1.0
/DMS-A9B
.ii
Record
size
limitations
Cc)
Legend: DMS-A
DMS-B
DMS-C
----------
Fig. 13. Sensitivity curves for elementary criteria. (a) Optional parameter. (b) Desired parameter.
(c) Essential parameter.
be given to essential parameters, less to desirable ones, and the least to optional
parameters, which is intuitively appealing. Graphs such as those in Figure 13 are
useful in identifying the parameters and preference ranges with the greatest
sensitivity.
3.4.3 Test 3. Variation of Weights. A third test is to investigate the importance
of weights used in aggregation structures. Figure 14 shows the results of shifting
a weight AW from one parameter to another. (The aggregation structure of
Figure 11 and the elementary preferences of Table IV remain constant in these
evaluations.) Although the choice of weights normally does affect aggregate
scores, in this particular example it does so marginally. This means that for this
example the choice of weights is not critical and the use of particular weights
does not have to be extensively justified. (Different conclusions may be reached
for other examples.) Graphs such as those in Figure 14 are useful in determining
the relative importance of weight assignments.
Some insight into the results of Figure 14(c) reveals why DMS-A and DMS-B
are rated better than DMS C. A Data Organization and Access preference is an
ACM Transactions
1987.
496
S. Y. W. Su
et al.
Data organization
and access
Data organization
and access
0 I,.,.
-20 -10
0 I,,,.
-20 -10
AW
0
+10
+20
+10 +20
Repeating
groups
Variable
length records
) Duplicate
keys
Hierarchical (
records
AW
0
0-4
(4
Data organization
and access
0
-20
AW
-10
+10 +20
Other
operations
Record
implementation
(4
Legend: DMS-A
DMS-B
DMS-C
-------_-_-
Fig. 14. Sensitivity curves for aggregation weights. (a) Optional weightings. (b) Desired weightings.
(c) Essential weightings.
aggregation of three preference ratings: Record Implementation, Implementation Requirements, and Other Operations. From the elementary preferences of
Table IV and the aggregation structures of Figure 11, we find
Criteria
DMS-A
DMS-B
DMS-C
Record Implementation
Implementation Requirements
Other Operations
.70
.89
1.00
.77
.87
.90
.66
.84
.80
DMS-C rates lowest on all three counts, and thus has no advantage over
DMS-A and DMS-B. On the other hand, DMS-A rates higher than DMS-B
ACM Transactions
1987.
497
in Other Operations, whereas the opposite is true for Record Implementation.

Therefore, depending on the weight (or emphasis) given to Other Operations,
DMS-A or DMS-B may be the preferred system.
Many other tests could be applied (see [22]). Measuring the effects of different
factors (i.e., GCD functions, weights) taken in combination, or linearly ranking
all preference parameters in order of decreasing (global) sensitivity are obvious
possibilities. But it should be kept in mind that sensitivity analyses are essential
to a meaningful and accurate interpretation of aggregate preference scores. The
subtleties of using certain elementary criteria and aggregation structures cannot
otherwise be adequately understood.
3.5 Step 5. Cost Computation
and Aggregation
This step is the counterpart of preference analysis and aggregation, and may
actually be conducted concurrently and fairly independently. As we pointed out
in the introduction, the current literature was of little help in suggesting any
standards for cost estimation. The DMS applications literature also lacks discussion of costs; however, the following general set of issues do apply to the
present cost evaluation problem:
(i) Include all direct and indirect costs.
(ii) Consider specific knowledge about application complexity, languages, and
choice of hardware and software in estimating costs of software development.
(iii) Reflect personnel skill levels, organizational/personnel time constraints,
and system constraints in time estimation.
(iv) Tailor the estimates to the organizations structure, capabilities, and limitations; anticipate political and behavioral implications.
In the following subsections we discuss the issues and approaches involved in
the estimation and aggregation of costs. No hard-and-fast formulas for cost
computation are considered, a more detailed treatment of the cost analysis may
be found in [22].
It is necessary to make some clarifications regarding the C nodes in our tree.
It is well known that the pricing policies of manufacturers are such that attributing costs to individual features is impossible in most situations. On the other
hand, vendors do package systems in terms of basic system-plus add-on
modules. The costs of these add-on components can be easily figured. Therefore,
as a general rule, it is not possible to break cost trees down to as fine a level as
preference trees. A manager or a committee in charge of defining the cost tree
needs to do so on the basis of available information. Only those nodes should be
included whose costs can be computed. Any further breakdown is meaningless.
It is also reasonable to consider different cost trees for different candidate systems
that may be packaged differently.
Although the costs being considered include initial acquisition, training, and
operation, they still constitute only a part of the entire system life-cycle costs.
Long-term operation costs, hardware, and communication costs may be included
if they can be calculated reasonably.
3.5.1 Cost Computation Using the Cost Tree. As far as the estimation of costs
related to data management systems is concerned, our overall SRP tree approach
498
S. Y. W. Su et al.
Table V.
System Cost Tree

cost
nodes
1 RPC vendor support

11 RPC vendor support for DMS software
111 PC manuals
1111 PC amount of general DMS documentation
1113 PC DMS product update documentation
1114 PC DMS periodical documentation and information
1115 PC DMS nonvendor documentation
113 PC backup facility
1131 PC location
1132 PC hours
114 PC installation
115 PC warranty
117 PC service availability
118 PC office space
119 PC maintenance
2 RPC computer facility and environment
21 RPC system software
216 PC system monitor
22 RPC Hardware
222 RPC central site hardware
2221 RPC mainframe section
22215 RPC main memory
2222 RPC DASD section
22222 PC disk drives
service
n
X
x
X
x
x
X
X
X
X
x
x
3 RPC DMS software

31 RPC supporting software for DMS
311 RPC DMS sort utility
3114 PC internal sorting technique
312 RPC report generation
3121 RPC report for formatting
31211 PC output formatting
312111 PC output device specifications
31212 PC spacing control
312121 PC pagination
312122 PC title, row, column, and line control
3122 RPC built-in programs
31221 PC editing functions
31222 PC statistical routines
31223 PC report aggregate functions
313 RPC data dictionary/directory
321 RPC security
3211 RPC access control
3212 RPC processing restriction
3213 RPC threat monitoring
323 RPC integrity
324 RPC date independence
3241 RPC immunity to structural changes
325 RPC backup and recovery
3251 RPC mechanism for backup
33 RPC language interface
331 RPC data definition
332 RPC data manipulation
ACM Transactions
1987.
x
x
x
x
x
x
X
X
X
x
x
x
X
X
X
499
Table V-Continued
cost
nodes
34
35
36
37
RPC data organization and access

344 PC other operations
RPC advanced features
352 RPC data restructuring
353 PC portability
354 RPC compatibility
with existing system
3541 PC file compatibility
3542 PC program compatibility
RPC history of use
363 PC user organizations
364 PC documentation on experience
RPC operation mode of DMS
371 RPC batched operation mode
372 RPC on-line operation mode
4 RPC conversion
41 RPC data conversion effort
42 RPC program conversion effort
5 RPC application systems
51 PC DMS program development
52 RPC DMS performance requirements
521 PC transaction performance
6 RPC operations
61 RC Personnel
611 C management (DBA)
613 C systems analysts
615 C programmers
62 RPC training and professional development
621 CP managers
622 PC systems analysts and engineers
623 PC applications analysts
624 PC programmers
625 PC data entry
626 PC operators
627 PC users
63 RC facility operations
634 C alterations of facilities
64 RC Expendables
641 C I/O materials and supplies (tapes and packs)
x
n
x
x
x
x
31
X
n
X
X
31
31
X
X
X
X
would require one to compute the costs of the leaf nodes of the cost tree and then
aggregate them using an aggregation procedure.
The general structure of the System Requirements and Parameter Tree and
labels for different node types (Figure 2) makes it easy to construct a cost tree
for a decision problem. An example cost tree is shown in Table V in an outline
form to demonstrate how the general structure can also be easily reproduced in
a short, easily readable format for a specific decision. It includes all the cost
nodes (i.e., nodes with a C label) of an SRP tree that need to be considered for
the decision problem. The tree in Table V starts with all the first-level nodes
and is expanded into about two or three lower levels (with some exceptions, such
as Node #22215 Main Memory, which is at the fifth level) to show how the costs
500
S. Y. W. Su
et al.
can be further decomposed. The cost tree represents a comprehensive breakdown

of items subjected to costing, starting from the major categories (e.g., Computer
Facility) to the smallest categories (e.g., Disk Drives). It involves both direct
and indirect costs. It is easy to see that this tree is more of a checklist than a
standard that every organization needs to follow for every DMS selection. In
specific instances, managers/committees would prune the tree to include nodes
for which reasonable cost estimates are possible.
Computation of costs may be delegated to different individuals after the cost
tree has been pruned and selected by the centers management. The chief financial
officer can, for example, assign parts of the system cost tree to the financial
personnel best qualified to work on the various nodes, in cooperation with
technically oriented personnel. The cost tree and aggregation, as well as the
preference aggregation structure, are normally broken down to such a level of
detail that it would automatically force the participation of all members of the
organization affected by the DMS choice. Although the cost tree is fixed by the
management on the basis of available costing information, as well as categories
of costs that are separable, the above decision is also influenced by the packaging
of the hardware/software products by vendors. If certain cost categories (e.g.,
different access methods) are always packaged together in the product, it is not
meaningful to separate them for cost estimation. Moreover, the actual cost
aggregation process may vary from vendor to vendor, depending on the features
of the system under consideration and the nature of packaging.
3.5.2 Cost Modules. The cost module concept was developed from the standpoint of building a software subsystem for cost computation; such a subsystem
would be a component of the overall cost-preference analysis software tool. In
the cost tree, many cost nodes required exactly the same type of costing information but for different resources. Cost modules are developed for reference
every time a given type of cost item (or object) is encountered in the cost
parameters. This results in two benefits. First, it reduces unnecessary repetition
in cost computation. Second, the use of the same form for estimation helps assure
that the same factors relevant to the estimates will be included, thus permitting
consistency in the estimation process. Cost modules have been developed for the
following categories of resource requirements.
(1) Square feet costs
(2) Software costs
(3) Hardware costs
(4) Programming F.T.E. time costs
(5) Data entry F.T.E. time costs
(6) Personnel costs
(7) Secretarial/clerk F.T.E. costs
(8) Training and development expenditures
Modules are allowed to be nested (e.g., the programming-time cost module may
call the square-feet cost module). Detailed descriptions of individual cost modules
and cost items considered in these modules are given in [22].
3.5.3 The Cost Aggregation Problem. The cost aggregation problem in this
DMS Cost/Benefit model is simply formulated. For each alternative DMS
considered, first, all costs must be measured in commensurate units and identified
ACM Transactions
1987.
501
by the time periods in which they will occur. Methods for doing this are detailed
in the various cost and performance descriptions and in various cost modules; all
resource requirements must be stated in the same units, say dollars, with related
beginning and ending dates. Second, a common time horizon or ending date must
be specified by using theoretical and practical considerations to permit comparable and pragmatic evaluations of the alternatives. Third, the dollar amounts
accumulated by time periods must be discounted by an appropriate discount rate
to make the dollar amounts comparable in the decision time period.
There is no disagreement found in the literature regarding the method to be
employed to find the global cost for an alternative. For each alternative, there is
a vector of costs or expenditure sums by time period, usually a year:
where t = horizon year.
Cl, c2, G, - - - , Ct,
For an organization there is an appropriate rate, r, for discounting the years
costs, so that the same time-value units are given to the decision maker. The
discounting process permits the summation of commensurate units into a present
value, which is designated here as the global cost (GC) of an alternative. That is,
Ct
- Cl
- C2
~
= iil (Ci (1 + r)-i).
GC = (1 + r)l+ (1 + r)2 + * + (1 + r)t
This definition is uniform across the various disciplines and specialties, as
indicated by a sampling of texts in finance [6, pp. 34-561, information systems
[38, pp. 289-2921, operations management [35, pp. 232-2501, microeconomic
theory [32, pp. 296-3191, and economics [5, pp. 446-4511. However, there are
sharply differing positions in the literature concerning the selection of time
horizon and discount rate. We consider these two issues in the following two
subsections.
Theoretical and Pragmatic Horizon Period Issues in Cost Aggregation. From a
theoretical point of view, the horizon time issue in this DMS Cost/Benefit model
applies as follows. The set of DMSs under evaluation may have the same or
different life expectancies. That is, a candidate system, Si, is expected to last
until or be considered for replacement in full or part at time tl and S2 (Si) at
time t2(tl). If the life expectancies of all alternatives are the same, there is no
horizon problem. However, if they are different, they present a problem for a fair
comparison, since a system with a shorter life expectancy will presumably be
replaced by another system, which amounts to an additional cost that needs
to be taken into consideration. The traditional approach to this problem is to
introduce a series of so-called replacement chains [6, 32, 351 which extend
through time to the first common denominator year, that is, the year in which
all candidate systems would be considered for replacement. This permits the
comparison of equal service periods.
The time horizon problem and replacement chain concept can be illustrated
by the following example. Assume the following costs for two systems: S1 with
tl = 2 and S2with t2= 3.
Cost in
Cost in
Cost in
year 2
year 3
year 1
Sl
s2
$20
$20
ACM Transactions
$10
$10
$lo
1987.
502
S. Y. W. Su et al.
If only the first life cycles are considered for both, then the global cost (GC)
of S1 will always be less than the GC of S1 at positive discount rates (e.g.,
28 percent less at a 10 percent rate). But extending both systems at given cycle
costs to t = 6 years where both would be considered for replacement, the absolute
cost for two S2s is less than the absolute cost for three &s. Moreover, the GCs
at 10 percent are $59.45 for SZ and $66.35 for S1; i.e., SZ is 9 percent less. This
chain assumes that the organization will continue to require some system over
the replacement chains first common denominator year.
With multiple systems having different life expectancies ti, the first common
denominator year naturally becomes large. For example, t1 = 3 and tZ = 4 moves
the first common replacement year to year 12. At t1 = 4 and t2 = 5, it is 20. And
if tl = 3, t2 = 4, and t3 = 5, the common replacement year is 60! Obviously, a
realistic situation can involve a large first common denominator
year. The
application of replacement chains to the DMS selection problem can be practically insurmountable
since the ti)s of systems are almost impossible to specify.
Finding the common denominator, therefore, becomes senseless.
An alternative procedure is the equivalent annual annuity method. Here the
GCs over one cycle are computed for each alternative. Each GC is then converted
to an equivalent annual annuity. The system with the lowest equivalent annual
annuity GC will be the same as the system with the lowest replacement chain
GC. An additional step, assuming infinite replacements, is to divide each equivalent annual annuity by the discount rate, giving the infinite horizon net GC for
each alternative. This result is obtained when, for i = 1, 2, . . . , m, the value of
Ci is a constant Kin the following expression:
Infinite
which is also known
example:
Horizon
net GC = lim i Ci . (1 + T)-~ = K/r,

t-+UZi=l
as the capitalization
of a constant
flow. For the above
GC1 = $26.44, t = 2, r = 10%

GC2 = $33.95, t = 3, r = 10%
Present value of an annuity of $1, t = 2, r = 10%: 1.7355
Present value of an annuity of $1, t = 3, r = 10%: 2.4869
Equivalent annual annuity GC1 = $26.4411.7355 = $15.23
Equivalent annual annuity GC2 = $33.9512.4869 = $13.65
Infinite horizon net GC1 = $15.23/.10 = $152.30
Infinite horizon net GC2 = $13.65/.10 = $136.50
The choice between the replacement chain and the equivalent annuity method
is based on pragmatic considerations. Replacement chains are easier to explain
and understand but can be more clumsy computationally.
Equivalent annual
annuities are more difficult to explain and understand but can be easier to
compute. A pragmatic problem of both methods is the estimation of life expectancy of systems and the reasonableness of extending estimated costs to years
beyond the individual alternative horizon times.
Replacement chains require extensions that are multiples of individual horizon
times. Equivalent annual annuities implicitly extend the cost estimates to infinACM Transactions
1987.
503

Table VI.
Discounted
Costs by Year at 14.43%
System A Costs
Year
Discount
Factor
(A)
03)
1
2
3
4
.8739
.7637
.6674
.5832
$474K
$163.7K
$167.2K
$167.2K
Discounted
Global System Costs
Annual
Discounted
(A x B)
$414K
125K
$111.6K
997.5K
$748K
System B Costs
Annual
Discounted
(Cl
(A x Cl
$500K
$166.5K
$166.5K
$166.5K
$437#
$127K
$lllK
$97K
$772K
1. Four-year yield on U.S. Government bonds as of July 5, 1981. Source: Merrill

Lynch, Gainesville, Florida office.
2. Discount factor = (1 + .1443)-, t = year.
ity. Present and foreseeable economic conditions indicate such extensions are
unrealistic because of general inflation expectations and the widely divergent
movements of salary, hardware, software, and other expense price levels in the
computing and data processing industries. Most, if not all, the individuals who
have attempted to estimate distant computing costs agree that the fourth years
estimates are tenuous at best. This makes the choice of theoretically
correct
decision horizon times and discounting methods very difficult, since present
systems are generally considered to have a four to five year life span, and some
writers have speculated that the typical life of a DBMS system can be five to ten
years [34].
Discount Rate Considerations. The comparison of the costs of two systems
with variable pricing schedules over time, as well as with different life expectancies, is further influenced by the choice of the discount rate. An appropriate rate
to be used would be the social welfare discount rate. This rate ideally measures
the worth to the household sector of the economy of current versus future
consumption. A lower (higher) discount rate results in placing a higher (lower)
value on future consumption or expenditures. Federal agencies are recommended
to use the current market yield rates on debt instruments with life spans that
match the projects being evaluated as the proper discount rate in their computation. This was suggested in the last general statement on discount rates,
applicable to projects where Congress has not set a rate-OMB
Circular A-70,
dated February 1, 1965. The General Accounting Office of the U.S. Government
also recommends the use of the above practice [28,29,39].
A hypothetical example for comparing the GCs of Systems A and B by taking
into account the present value at a specific discount rate is given in Table VI.
Most organizations and their accounting departments have set policies regarding
the choice of discount rates.
3.5.4 Recommended Cost Aggregation Model. The cost aggregation
recommended for this DMS Cost/Benefit Model are as follows:
methods
(1) Specify the major alternatives to be considered for the analyses (e.g., a file
system and a DBMS system), based on the major features of the systems
and appoint a member of top management as project coordinator.
ACM Transactions
1987.
504
S. Y. W. Su
et al.
(2) Choose one time horizon (year or month) by considering the major alternatives. This horizon time should be the most future period for which the user
considers cost estimates reasonable for inclusion in decisions. Or the time
horizon can be considered as the time period just before that period for which
cost estimates would be unreasonable.
(3) Estimate the cost elements of each major alternative through the time
horizon. This might include additional investments in an existing system
during future years to permit desired applications. A recommended procedure
is as follows:
(a) Top and middle management review all cost nodes and determine which
are most likely to be included in the cost tree for each alternative. This
results in a pruned tree.
(b) The various included nodes are assigned to various employees for evaluation based on the employees knowledge, experience, and skills.
(c) Employees responsible for the various nodes determine whether they can
be assigned cost values with information available in-house and/or
whether an RFP is required. Cost tree descriptions and module listings
indicate the types of detail required about resources and prices to find
cost totals by time period.
(d) Employees responsible for the various nodes estimate the costs over the
horizon times using information when it becomes available.
(e) Completed cost estimates are reported to the employees immediate
supervisors for review and coordination until all cost information is held
by top management.
(f) Minor alternatives are specified by top management (e.g., one or more
features of a major alternative are varied), and costs are adjusted as
appropriate by the top management officer designated as the project
coordinator.
(4) Aggregate absolute cost levels by years for each major and minor alternative.
(5) Choose a discount rate per the accounting policy of the organization. If no
such policy exists, compute the discount rate by weighting the current yields
at which the Federal government is borrowing money on instruments with
lives similar to the chosen horizon time:Or use the rate the Congress specifies,
if any.
(6) Compute the global cost of each DMS alternative under consideration by
discounting the absolute yearly costs at the appropriate discount rate.
3.6 Step 6. Cost-Preference Analysis
Cost-preference analysis is a systematic procedure for comparing and ranking
alternatives on the basis of the requirements defined by the SRP tree. If
we refer to the alternatives being compared as systems S(l), S@), . . . , SC),
then the preference analysis produces a set of global preference scores EF,
E(2)
E$ for these systems, while the cost analysis produces a set of
gl%a; Gts C$, Ch, . . . , Cg). Consequently, the problem of ranking n systems
reduces to the mapping of each pair (El;, C$) into a global cost-preference
505
indicator Qti), and then ranking the systems in order of their Q values. In this
section we explain some mapping and ranking processes.
We can visualize that the global preference E. and the global cost Co form a
two-dimensional space (or an Eo-Co plane). Each pair of scores (Et, C$?) is a
point on the Eo-Co plane. A region of acceptable solutions (ROAS) can be defined
so that the systems for which the point (E,, C,) falls in the region are considered
to be acceptable systems.
The criterion for defining the ROAS may differ from case to case. Most
frequently the system selection committee specifies the nominal global cost
indicator C,* and the corresponding nominal global preference EZ. Usually, Et is
defined as the minimal level of acceptable global preference (most frequently
60% 5 E$ I 80%), and C,* is computed from the financial limitations of
the particular organization, and represents the maximal cost indicator the
organization can afford. Using the point (C,*, E$), the following regions in
the (E,, C&plane can be defined:
(p) := Region of satisfactory preference (EO> E,*)
(c) := Region of satisfactory cost (C, < C,*)

(r) := Region of satisfactory preference-cost ratio (EO/Co> E$/C,*).
Taking combinations of these regions and eliminating redundancies yields six
possible ways of defining a ROAS:
ROAS
ROAS
ROAS
ROAS
(5) ROAS
(6) ROAS
(1)
(2)
(3)
(4)
:=
:=
:=
:=
:=
:=
(p)
(c)
(r)
(p) and (c)
(p) and (r)
(c) and (r)
These six possibilities are shown in Figure 15. The system selection committee
should be able to select a ROAS according to the particular conditions of the
given organization.
After rejecting systems that fall outside of the ROAS, the final step in the
cost-preference analysis is the ranking and comparison of those competitive
systems that remain. To accomplish this step, we need a method of mapping
each (Et, (26) pair to a global cost-preference indicator, Qti), and then to
compare the Qti) values
Suppose that k competitive systems remained inside the ROAS (k s n). We
define the boundary systems (denoted by indices i,,,,, and imiD) as follows:
S&J.
Q(h) = max Q(i)
lsisk
S&i,).
Q(Cd
min
Q(i).
l&Sk
Among various possible mapping and ranking criteria, the following four approaches are the most frequently used:
(1) Ranking according to decreasing preferences:
Q(i) := E&i;
select S(k=).
506
S. Y. W. Su et al.
% Eo
00 ,, .. . . . : :::, :.:. 2 , ,,.:.-a.**y;.:.;- : ..d,
.:7: :.: :
,,,: -(r.
.., -., . . &is
I (p) .~:..I;;.;;:
.,*:.,,,
.1.-.>.:,.., : ..-..,::.,
,,, ..*I.. . . .
...
.
G
OL
0
co
%
100 t
co*
co-
%1Eo
Eo
E:
0
Fig. 15.
(2) Ranking
(3) Ranking
ACM Transactions
Definition
of the region of acceptable solutions
(ROAS).
according to increasing cost indidators:

Q(i)
:= C$;
select SCimin).
according to decreasing preference-cost ratios:
Q
:= @$/C-6;
select SC=).
1987.

(4) Ranking according to increasing
o < a :i;:
=;;i
507
global effective cost indicators:
;I 2:
;,r;
- a;e;f;~;;;,.
ISiS.
The indicator Q reflects the overall goodness (or desirability)

of system i.
The system selection committee would generally be in charge of selecting one or
more of the above frequently used methods for ranking systems that fall within
the ROAS.
To summarize, the task of selecting an alternative comprises the following
activities:
(i) Define the ROAS in the cost-preference plane.
(ii) Perform the preference analysis and cost analysis for all alternative systems
and arrive at the Et and (26values for each system i.
(iii) Reject those systems that lie outside of the ROAS in the (Eo-Eo) plane.
(iv) Rank the systems inside the ROAS according to decreasing (or increasing)
values of the system comparison indicator Q.
4. CONCLUSIONS
In this paper we have described a methodology for a systematic analysis, comparison, and selection of alternatives for any general decision problem. Although
the presentation of this methodology is directed to a specific problem, namely,
the selection among data management alternatives, the overall procedure and
techniques introduced are very general and are not restricted to the data
management area.
We believe that the present methodology, which is based on the concept of
logic scoring of preferences, has the unique advantage of accounting for users
preferences and aggregating them in a very systematic manner. The range of
aggregating functions from the most conjunctive to the most disjunctive gives
decision makers a powerful tool for expressing their preferences for the simultaneous existence of system functions or facilities. The aggregation structure,
which utilizes weighted aggregate functions, allows complex logical relationships
among preference parameters to be unambiguously expressed. The separation of
preference analysis from cost analysis allows the performance and cost aspects
to be dealt with independently. This may allow two entirely different groups to
study the problem separately, without influencing one another.
The data management SRP tree was validated by visiting six industrial sites
and arriving at a consensus of the opinions of management, technical, and DBA
personnel. An interactive system has been designed at the level of functional
specifications of modules. A prototype implementation
of this decision model has
been undertaken by the staff members of the National Bureau of Standards for
an in-house comparison of several DBMSs. A system has also been implemented
by J. J. Dujmovic at the University of Belgrade, Yugoslavia, for the evaluation
and selection of computer systems based on this model. The detailed reports of
our methodology have been made available to Federal Data Processing Managers
through our sponsor, NBS. We hope that our approach will be found useful in
dealing with complex decision problems involving a selection among alternative
software/hardware
systems.
ACM Transactions
1987.
508
S. Y. W. Su et al.
CRITERIA
AGGREGATfON STRUCTURE
A-l
ACM Transactions
1987.
509
CRITERIA
AGGREGATION STRUCTURE
PO70
xuuxxatia
075 uarranty
(115)
CRITERJA
ACM Transactions
on Database Systmns, Vol. 12, No. 3, September
1987.
510
S. Y. W. Su et al.
CRITERIA
AGGREGATION
STRUCTURE
CRITERIA
AGGREGATION
STRUCTURE
I I
ACM Transactions
A
-3
1987.
511
CRITERIA
*Is.?
1
-I.$
* CA
&fQ
0
IO
3oIbo
CRITERIA
ACM Transactions
1987.
512
S. Y. W. Su et al.
CRITERIA
AGGREGATION
STRUCTURE
UL.
L.,
-
d
i
f
3
CRITERIA
AGGREGATION
STRUCTURE
A-S
ACM Transactions
1987.

CRITERIA
, .---_,
3:
cd
103bO
5
CRITERIA
6
ACM Transactions
1987.
514
S. Y. W. Su et al.
CRITERIA
CRITERIA
A
ACM Transactions
l--
1987.
515
CRITERIA
CRITERIA
ACM Transactions
1987.
516
S. Y. W. Su et al.
CRITERIA
CRITERIA
ACM Transactions
1987.
517
CRITERIA
5015
aq
n..
0223)
CRITERIA
IL.
.nr
-
.EL
ACM Transactions
1987.
518
S. Y. W. Su et al.
REFERENCES
1. ANSI/X3/SPARC.
Study Group on Data Base Management Systems Interim Report. Bull.
ACM-SZGMOD 7,2 (1975).
2. AUERBACHPUBLISHERS. Estimating time, cost and resource requirements: Systems analysis.
In Data Base Management, Auerbach, Pennsauken, N.J. 1976,34-01-05, pp. l-22.
3. AUERBACHPUBLISHERS. Justifying a database system. In Data Base Management, Auerbach,
Pennsauken, N.J., 1976,21-02-01, pp. l-10.
4. BASSLER, R. A., AND LOGAN, J. J. Eds., The Technology of Data Base Management Systems.
College Readings, Alexandria, Va., 1976.
5. BAUMOL, W. J. Economic Theory and Operations Analysis, 3rd ed. Prentice-Hall, Englewood
Cliffs, N.J., 1972.
6. BRIGHAM, E. F. Financial Management: Theory and Practice, 2nd ed. Dryden Press, Hinsdaie,
Ill., 1979.
7. CAGAN, C. Data Management Systems. Melville, 1973.
8. CARLSON,E. D. Techniques for analysis of generalized data base management systems. Ph.D.
thesis, Univ. of North Carolina, Chapel Hill, 1972.
9. CODASYL SYSTEMS COMMITTEE. A Survey of Generalized Data Management Systems.
CODASYL Systems Committee Tech. Rep., ACM, New York, May 1969.
10. CODASYLSYSTEMSCOMMITTEE. Feature Analysis of Generalized Data Base Management Systems. CODASYL System Committee Tech. Rep., ACM, New York, May 1971.
11. CODASYLSYSTEMS COMMITTEE. Selection and Acquisition of Data Base Management Systems.
ACM, New York, 1976.
12. COHEN, L. J. Data Base Management Systems: A Critical and Comparative Analysis. Q.E.D.
Information Science, Wellesley, Mass., 1973.
13. DATAPRORESEARCH. A buyers guide to data base management systems. Datapro Feature Rep.,
Datapro Research Corp., Delran, N.J., Nov. 1974.
14. DATAPRORESEARCH. Developing accurate time estimates. In Management and Administration,
Datapro Research Corp., Delran, N.J., 1978, E40-350, pp. 101-104.
15. DATAPRO RESEARCH. A review of software cost estimation methods. In Management and
Adminitration, Datapro Research Corp., Delran, N.J., May 1978, E40-350, pp. 601-614.
16. DAVIS, D. The Selection of Database Software. The National Computing Centre, Ltd., Manchester, 1977.
17. DOWKANT, A. J., ET AL. A Methodology for Comparison of Generalized Data Management
Systems: PEGS (Parametric Evaluation of Generalized Systems), 1967.
18. DUJMOVIC, J. J. Weighted conjunctive and disjunctive means and their application in system
evaluation. J. Univ Belgrade, Series on Mathematics and Physics, 483 (1974), 147-158.
19. DUJMOVIC,J. J. Extended continuous logic and the theory of complex criteria. J. Univ. Belgrade,
Series on Mathematics and Physics, 537 (1975), 197-216.
20. DUJMOVIC, J. J. Computer selection and criteria for computer performance evaluation. Znt. J.
Comput. Znf. Sci. 9,6 (Dec. 1980), 435-458.
21. DUJMOVIC, J. J. Partial absorption function. J. Univ. Belgrade, Series on Mathematics and
Physics, 659 (1980), 156-163.
22. DUJMOVIC, J. J., AND ELNICKI, R. A DMS cost/benefit decision model: Mathematical models
for data management system evaluation, comparison and selection. Special Rep. 2 (Part I),
National Bureau of Standards, contract NB80SBCA0449, July 1981. Available from NTIS: PB
82-170150.
23. DUJMOVIC, J. J., BATORY, D. S., AND Su, S. Y. W. A DMS cost/benefit decision model: DMS
decision software system (DDSS). Special Rep. 3, National Bureau of Standards, contract
NB80SBCA0449, July 1981.
24. Federal Information Processing Standard 77. National Bureau of Standards, Guideline for Planning and Management of Database Applications, FIPS PUB 77, Sept. 1977,90 pp.
25. FIFE, D. W. Alternatives in Evaluation of Computer Systems. The MITRE Corp., Bedford,
Mass., 1968.
26. FONG, E., COLLICA, J., AND MARRON, B. Six data base management systems: Feature analysis
and user experiences. NBS Tech. Note 887, Nov. 1975.
27. FRY, J. P., ET AL. Data management system survey. MITRE Corp. Rep. MTP-329, Jan. 1969.
519
28. GAO. COMPTROLLERGENERAL OF THE UNITED STATES. Change proposed in interest rate
criteria for determining financial costs of Federal power program. GA0711253, B-167712,
Jan. 13,1970,32 pp.
29. GAO. COMPTROLLERGENERAL OF THE UNITED STATES. Legislation needed to revise the
interest rate criteria for determining the financing costs of water resource projects. GA0701238,
B-16772, Aug. 11,1972,32 pp.
30. GILB, T. Software Metrics. Studentlitteratur, Lund, 1976.
31. HALSTEAD, M. H. Operating and Programming Systems Series: Elements of Software Science.
Elsevier North-Holland, New York, 1977.
32. HENDERSON,J. M., AND QIJANDT, R. E. Microeconomic Theory: A Mathematical Approach.
McGraw-Hill, New York, 1971.
33. HERZOG,J. P. System evaluation technique for users. J. Syst. Manage. (May 1975), 30-35.
34. HESPRICH,S. F. The woes of DBMS. J. Syst. Manage. 30, 10 (Oct. 1979), 27-31.
35. JOHNSON, R. A., NEWELL, W. T., AND VERGIN, C. Production and Operations Management.
Houghton Mifflin, Boston, 1974.
36. KING, J. L., AND SCHREMS,E. L. Cost-benefit analysis in information systems development
and operation. ACM Comput. Suru. 10, 1 (Mar. 1978), 19-34.
37. KNUTSEN, K. E., AND NOLAN, R. L. On cost/benefit of computer-based systems. In Mannging
the Data Resource Function. Nolan, Ed. St. Paul, Minn., 1974, pp. 253-276.
38. MADER, C. Information Systems: Technology, Economics, Applications, Management, Science
Research Associates, Chicago, 1979.
39. MAKIEN, G. Program analysis. General Accounting Office, phone interview, Apr. 23,1981.
40. MCLEOD, D. Selecting a data base management system. Interface 5, 2 (1980).
41. MILLER, J. R. Professionul Decision Making. Praeger, New York, 1970.
42. MILLER, F. W. Navigating through DBMS waters. Znfosystems28,3 (Mar. 1981), 70-78.
43. PALMER, I. Data Base Systems: A Practical Reference. QED Information Sciences, Wellesley,
Mass., 1975.
44. POWELL, J. D., AND CANTER, S. J. Evaluating database management systems using the costvalue technique. North Carolina State Univ. Tech. Rep. TR 77-03, 1977.
45. PRENDERGAST,S. L. Selecting a data management system. Comput. De&. (Aug. 1972), 12-15.
46. Q.E.D. INFORMATIONSCIENCES. Data Base Management Systems: A Critical and Comparative
Analysis, Q.E.D. Information Sciences, Wellesley, Mass., 1975.
47. QUINNAN, R. E. The management of software engineering. Part V: Software engineering
management practices. IBM Syst. J. 19,4 (1980), 466-477.
48. READ, N. S., AND HARMON, D. L. Assuring MIS success. Datamation 27, 2 (Feb. 1981),
109-120.
49. RULLO, T. A., ED. Advances in Data Base Management. Hayden & Sons, New York, 1980.
50. SABLE, J. D. System evaluation methodology. In INFORM Data Management System Study,
Auerbach Tech. Rep. AUER-1834-TR-2,197O.
51. SABLE, J.D. Generalized data management systems: Query and language processing. In Proceedings of the International Seminar on Information Storage and Retrieval (1971), pp. 93-111.
52. SALTON, G., Fox, E. A., AND WV, H. Extended Boolean information retrieval. Commun. ACM
26,11 (1983), 1022-1036.
53. SIBLEY, E. H. Evaluation and selection of data base systems. Unpublished paper (presented in
POW77).
54. SIRCAR,S. The importance of database management systems. Business Q. 43,2 (Summer 1978),
45-49.
55. Su, S. Y. W., BATORY, D. S., DUJMOVIC, J. J., ELNICKI, R., NAVATHE, S. B., OLAGUNJU, A.,
AND PARKES,J. A DMS cost/benefit decision model: Cost and preference parameters. Special
Rep. 1, National Bureau of Standards, contract NB80SBC0449, Jan. 1981. Available from NTIS:
PB 82-169566.
56. Su, S. Y. W., BATORY, D. S., NAVATHE, S. B., OLAGUNJU,A., AND PARKES, J. A DMS coat/
benefit decision model: Analysis, comparison, and selection of DBMSs. Special Rep. 2 (Part II),
National Bureau of Standards, contract NB80SBCA0449, July 1981.
57. TOUCHE ROSS & CO. Managing the Systems Development Process. Prentice-Hall, Englewood
Cliffs, N.J., 1980.
520
S. Y. W. Su et al.
EXTENSION CONTINUING EDUCATION IN MANAGEMENT, LABOR AND BUSINESS.

National Comparative Data Base Management Systems Conference (1975).
59. WHITE, D. R. J., SCOTT, D. L., AND SCHULZ, R. N. POED-A method of Evaluating System
performance. IEEE Trans. Eng. Manuge. (Dec. 1963), 177-182.
60. WIORKOWSKI,
A. K., AND WIORKOWSKI,
J. J. Does a data base management system pay off?
Datamation 24,4 (Apr. 1978), 109-114.
58. UCLA
Received January 1986; revised October 1986; accepted December 1986

Cost Benefit Decision Model

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cost Benefit Decision Model

Uploaded by

Copyright:

Available Formats

A Cost-Benefit Decision Model:

Analysis, Comparison, and Selection

General Terms: Economics, Management

12, No. 3, September

1987, Pages 472320.

A Cost-Benefit Decision Model

The evaluation, comparison, and selection of alternative products and services is

on Database Systems, Vol. 12, No. 3, September

third area relates to costs. Existing literature on applications of file management

A Cost-Benefit Decision Model

Evaluation of Global Performance of the

System Requirement and Parameter Tree

Cost Preference Analysis

on Database Systems, Vol. 12, No. 3, September

2.2 The Decision Method Based on Logical Scoring or Preferences

on Database Systems, Vol. 12, No. 3, September

A Cost-Benefit Decision Model

comparisons can meaningfully be made. This set should contain parameters

I RPC Vendor support

11 RPC Vendor support for DMS

2 RPC Computer and facility environment

21 RPC System software

41 RPC Data conversion

5 RPC Application system

51 RPC Program development

on Database Systems, Vol. 12, No. 3, September

A Cost-Benefit Decision Model

I .2I .3I .4I .5I .61 .7I .8I .9I

where TMIN is minimum of all measured times

= (k TMIN/t - l)/(k - l),

developed (see [22]), we do not dwell on this classification here, since it is

Table I. Special Cases of the Weighted Power

For example, if the elementary preferences of the parameters data compression

where --a, I r 5 00.By varying the value of r, a spectrum of aggregation functions

on Database Systems, Vol. 12, No. 3, September

A Cost-Benefit Decision Model

Intuitively, E(r, n) is the expected aggregate preference of n equally weighted

Values of c and r are therefore in 1: 1 correspondence for a fixed n. The GCD

on Database Systems, Vol. 12, No. 3, September

A Cost-Benefit Decision Model

Fig. 4. A preference aggregation function diagram.

Partial Absorption Function Weights [21]

Fig. 6. A partial absorption function example.

A Cost-Benefit Decision Model

Analogously, well-defined criteria can be formulated to distinguish between GCD

(1) classify the parameters of an SRP subtree;

on Database Systems, Vol. 12, No. 3, September

3416 Null values

t 3417 Record size limitations

and requirements of a companys DMS decision problem is

record size limitations;

That is, in order to avoid unnecessarily complex database designs, it is essential

on Database Systems, Vol. 12, No. 3, September

Preference Aggregation Within a Class

Preference Aggregation for Three Basic Classes

Essential preference rating

Fig. 8. A general three-class preference aggregation structure.

The aggregate preference of the optional and desirable categories should

A Cost-Benefit Decision Model

(lob) Essential category .

Fig. 10. Aggregation of different category ratings.

Appendix A contains a proposed aggregation structure for the ABC companys

The aggregation of preferences is a conceptually straightforward task. In practice,

on Database Systems, Vol. 12, No. 3, September