A FAHP-BASED TECHNOLOGY SELECTION AND

SPECIFICATION METHODOLOGY

Kin Chung Liu, Dennis F. Kehoe

The Aimes Centre, the University of Liverpool, 10 Duke Street, Liverpool, L1 5AS, U.K.

Dong Li

The University of Liverpool, Chatham Street, Liverpool, L69 7ZH, U.K.

Keywords: Fuzzy analytic hierarchy process (FAHP), system design, technology selection, system specification.

Abstract: Selection of technology in IT projects is recognized as a multi-criteria decision-making (MDCM) problem

because it is important to incorporate multiple opinions from people and consider the interdependence

among criteria (Lee and Kim, 2000). Various techniques were proposed to address the technology selection

problems and some of them, such as analytic hierarchy process (AHP) (e.g. Bard, 1986), were proved

effective in literatures. However, technology selection problem in a system development project can be

viewed as a system design activity and there is lack of literatures view technology selection from system

design perspective and integrate it with other system design activity. The research argues that AHP can be

applied to generate technology specification and other useful information for system design purpose, in

additions of technology selection. A high-level system design framework and the FAHP-based technology

selection and specification (TSS) methodology are presented in this paper.

1 INTRODUCTION

Assessment and selection of technology in IT

projects are required when more than one alternative

are available and commit to a right technology can

lead to optimal benefits to the business. Literatures

(e.g. Chou et al., 2004) suggested that the

technology selection can be viewed as a MDCM

problem. It is because it involves activities that

intakes multiple opinions from different parties and

considers the interdependence among criteria (Lee

and Kim, 2000). Analytic hierarchy process (AHP)

has been studied extensively and been used in

almost all the applications related with MCDM in

the last 20 years (Ho, 2007). Literatures (e.g. Bard,

1986; Nelson and Kastenberg, 1986) indicate that

AHP is an effective technique in the field of

technology selection.

Technology assessment and selection happens in

two stages of an IT project: project justification

(Gunasekaran et al., 2006) and system design. The

former activity may influence the later process by

providing partial technology selection decisions to

system designer in order to bind the developing

system to certain technology strategically.

From a system development perspective,

technologies that compose the developing system

must be well-defined in the system design process.

However, there is lack of literature associates

technology selection with system design activity.

Also, the research proposes that the characteristics

of AHP provide opportunities for system designer to

collect useful information from people for purposes

not limited to technology assessment.

The research proposes a generic high-level

system design framework and an FAHP-based

technology selection and specification (TSS)

methodology as a member of the framework.

2 A HIGH-LEVEL SYSTEM

DESIGN (HLSD) FRAMEWORK

According to Sommerville (2002), system design

generally encompasses six activities include

architecture design, abstract specification, interface

161

Chung Liu K., F. Kehoe D. and Li D. (2008).

A FAHP-BASED TECHNOLOGY SELECTION AND SPECIFICATION METHODOLOGY.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 161-168

DOI: 10.5220/0001721001610168

 SciTePress

design, component design, data structure design and

algorithm design. Each of the activity takes design

product input from previous activity and generate

design product for the next activity (see figure 1).

In particular, the architecture design activity

aims to identify sub-systems and relationships of the

system while the abstract specification aims to

specify the sub-system. These two activities aim to

describe a complete picture of system with system

architecture and specification of the architectural

components. On the other hand, the other four

activities specify the details of the architectural

components. Therefore, these six activities can be

separated into two groups according to the level of

detail they concern, namely high-level design

activities and detailed design activities.

Figure 1: A general model of the system design process

(source: Sommerville, 2002).

According to above, there are two general high-

level design activities and they aim to produce the

system architecture and system specification for the

use of detailed design. Technology may be decided

strategically before the high-level design. Despite

the technology decisions made in project

justification before system design, the need for

technologies must be identified after the relevant

details of the related architectural components are

defined. This indicates that the technology selection

is a part of the abstract specification activity. In fact,

the activity aims to generate a system specification

which includes the technology definitions.

The research proposes a high-level system

design (HLSD) framework based on Sommerville’s

generic model and results from case studies. Based

on case studies, eleven functional areas of abstract

specification including technology selection and

specification are identified. The framework covers

the scope of the two activities mentioned above and

proposes that the second activity is composed by the

eleven identified functional areas. The eleven

functional areas are divided into four groups,

indicated by four different colours, according to the

subject they concern. The framework aims to

identify the role of technology selection within a

general system design process. Figure 2 illustrates

the proposed high-level system design (HLSD)

framework.

A FAHP-based TSS methodology is proposed in

section 4 that supports technology selection and

technology specification indicated by figure 2. The

function of the proposed methodology is to provide

a mean for decision-makers to assess technologies

and then select technologies among alternatives.

Furthermore, it utilizes the AHP process to collect

useful information from people and thereby generate

technology specification of the developing system

which serves as the part of the content of system

specification.

Figure 2: The proposed HLSD framework.

3 FUZZY-AHP (FAHP)

3.1 Introduction to FAHP

AHP was developed by Saaty in 1971 (Saaty, 1980)

and is recognized as an effective technique for

handling unstructured or semi-structured decision-

making problem with involvements of multiple

persons and multiple criteria inputs simultaneously

(Durán and Aguilo, 2007; Saaty and Kearns, 1985).

It has been proved to be effective tool for decision

supporting in MCDM problems such as ranking,

selection, evaluation, optimization, and prediction

(Lee et al., 2001; Ho, 2007). In particular, AHP has

been extensively applied to various technology

selection problems and is proved to be an effective

approach (e.g. Bard, 1986; Lai et al., 1999).

According to Saaty (1980) and other literatures

(e.g. Liu et al., 2007; Lee et al., 2006; Chang, 1996),

the conventional AHP encompasses two phases:

decomposition and synthesis. The first phase is to

decompose the complexity of problem by building a

hierarchy model in order to discover and structure

the relations. The second phase is to obtain useful

results with the hierarchy model through pairwise

comparisons and other techniques.

System

archi tecture

Architectural

design

Abstract

specification

Interface design

Component

design

Data structure

design

Algorithm design

Software

specification

Interface

specification

Component

specification

Data structure

specification

Algorithm

specification

Requirement

specification

Design activities

Design products

Architectural

Design

Abstract Specification

Performance Requirement

Definition

Data Flow Definition

Data Synchronization

Definition

Component Composition

Definition

Component Functionality

Definition

Physical Distribution

Definition

Data Integration Definition

Component Compatibility

Requirement Definition

Data Communication

Protocol Definition

Technology Selection

Technology Specification

The FAHP-based

TSS Methodology

System

Architecture

Technology

Specification

Requirement

Specification

ICEIS 2008 - International Conference on Enterprise Information Systems

162

However, AHP has weakness in treating

fuzziness and vagueness data which commonly exist

in many decision-making problems (Levary and

Wan, 1998; Ribeiro, 1996). Integrate the fuzzy set

theory to the pairwise comparison of the AHP is

believed an effective solution (Karsak and

Kuzgunkaya, 2002; Mon et al., 1994). The

integration of the fuzzy set theory and the

conventional AHP is named fuzzy-AHP (FAHP)

which was first introduced by Van Laarhoven and

Pedrycz (1983).

The FAHP approaches presented by literatures

(e.g. Lee et al., 2006; Liu et al., 2007; Chang, 1996)

are variable in steps and use of techniques.

According to literatures (Lee et al., 2006; Liu et al.,

2007; Sadiqa and Husain, 2005; Zeng et al., 2007;

Durán and Aguilo, 2007), FAHP has modified the

conventional AHP with the following steps

generally:

 Fuzzification: judgments are transformed into

fuzzy values and pairwise comparisons are

based on fuzzy judgment matrices.

 Synthesis: instead of dealing with crisp

judgment values conventionally using

techniques such as eigenvalue and eigenvector,

FAHP approach handles synthesis in a fuzzy

environment. Methods such as fuzzy extent

analysis (Chang, 1992, 1996) were proposed

by literatures.

 Defuzzification: in order to obtain an overall

ranking of alternatives, the score of

alternatives in fuzzy number must either be

transformed into crisp number or be

compared.

3.2 FAHP as a Technology Selection

and Specification Approach

FAHP is adopted in the proposed TSS methodology

not only for technology selection purpose but also

for generation of information. FAHP is adopted for

the reason of its characteristics and the advantages it

brings:

 AHP is “excellent for clarifying a problem and

displaying the decision process” (Nelson and

Kastenberg, 1986). Useful information such as

end users’ and decision makers’ concerns and

preferences, performance measurement of

alternatives, and reasons of selection result

can be identified through the AHP process. In

the proposed methodology, AHP process

contributes in the production of technologies

specification.

 AHP is a powerful tool for communication

(Roper-Lowe and Sharp, 1990). Outcome

from AHP is a conclusion of selected

participants’ judgments. This meets the need

in an IT project that people from different

parties can be involved in selection of

technology. This also shares the responsibility

among different people as well as have useful

data input from appropriate people.



Use of FAHP instead of conventional AHP

means a significant benefit in a technology

selection problem since failed to deal with the

data fuzziness can lead to inaccurate

performance measurement of alternatives.

4 THE FAHP-BASED

TECHNOLOGY SELECTION

AND SPECIFICATION (TSS)

METHODOLOGY

4.1 Objectives

The proposed FAHP-based TSS methodology aims

to facilitate the high-level design process mainly by

1) provides a mean for decision makers to assess

alternatives and make decision on selection of

technologies; 2) specify technologies and generate

respective technology specifications.

4.2 Multi-level Solution Structuring

As a matter of previous literatures, technology is to

be evaluated and decided separately from other parts

of the system. The proposed methodology considers

technology selection as a part of system design

activity which aims to achieve a technology solution

instead of only part of it.

To do that, the selection and specification needs

of the developing system must be identified and

structured into multiple hierarchical levels.

Terminologically, the top level is the technology

solution that includes solution components at lower

levels. A solution component means a particular

architectural component which requires the

technology selection and specification process. For

instance, design of an enterprise system requires

selection and specification of a database

management system which can be viewed as a

solution component. A solution means a set of

solution components indicated by system

architecture.

A FAHP-BASED TECHNOLOGY SELECTION AND SPECIFICATION METHODOLOGY

163

The proposed methodology aims to evaluate

alternatives of different solution components

efficiently and thereby propose the best-performed

solution considering compatibility issues.

4.3 The Six Phases

The proposed methodology is illustrated by figure 5.

It includes six phases: Preparation, Decomposition,

Solution Component Decomposition, Solution

Component Assessment, Solution Assessment, and

Conclusions. Each phase contains one or more steps

and each step is composed by one or more process.

Process may require external data input such as the

requirement specification document and survey

results.

The proposed methodology begins with the

Preparation phase in which a project team must be

constituted (process 1.1.1) and the team will act as

an important source of data in the later stages.

The second and the third phases are Solution

Decomposition and Solution Component

Decomposition respectively. The term

“decomposition” was adapted from the first of the

two basic phases of conventional AHP according to

Saaty (1980). Decomposition is a process that

decomposes the complexity of problem by building

a hierarchy model in order to discover and structure

the relations (Saaty, 1980).

In the second phase, the goal (process 2.1.1) and

objectives (process 2.1.2), solution components

(process 2.2.1) and the alternatives (process 2.2.2)

of them are identified and arranged into a solution-

level hierarchical model. Example of the goal can be

“Evaluate and specify the most suitable technology

solution “. Process 2.1.2 is a generalization process

that translates the requirements into objectives for

technology. The objectives must be created based on

requirement specification in order to ensure the

selection and specification results are responsible to

it. The solution components can be defined with

system architecture created previously in system

design process.

As the outcome of the phase, the hierarchical

model is based on a well-defined fundamental-

objective hierarchy (process 2.1.3) that graphically

illustrates the relations between the hierarchy

elements (see figure 3 for example). In particular,

compatibilities of alternatives of each solution

component to alternatives of each other solution

component are considered. The alternatives that are

considered completely incompatible or poorly

compatible to alternatives of other solution

component should be eliminated (process 2.2.3).

In the third phase, solution-component-level

hierarchy models are created. While the solution-

level hierarchy model reflects the solution-level

elements, a solution-component-level hierarchy

model is defined with a solution components

perspective in regard to the solution-level goal and

objectives.

Each solution component will have a hierarchy

model created as the output of the third phase. The

third phase is composed by two steps (step 3.1 and

3.2) and they are in iteration where each round will

create a solution-component-level hierarchy model

for one solution component. A solution-component-

level hierarchy model is created by define the means

to the solution-level objectives by a particular

solution component (process 3.1.1) and thereby to

build the respective means-objective network for the

solution component (process 3.1.3). As the means-

to-objectives of different solution component can be

different, some solution-level objectives may be

found irrelevant to certain solution component and

they must be eliminated from the solution-

component-level hierarchy (process 3.1.2). On the

other side, goal for the hierarchy must be defined

according to the solution-level goal (process 3.2.1).

With the goal and objective structured, the

fundamental-objective hierarchy can be defined

Figure 3: An illustrative example of a solution-level

hierarchy model.

Figure 4: An illustrative example of a solution-

component-level AHP hierarchy model.

Goal

Objective 1 Objective 2

Objective 1.1 Objective 1.2 Objective 2.2

Mean 1 Mean 2 Mean 3 Mean 6 Mean 7

Mean 2.1 Mean 2.2

Alternative a1 Alternative a2 Alternative a3

Alternative a1

Goal

Objective 1 Objective 2

Objective 1.1 Objective 1.2 Objective 2.1 Objective 2.2

Solution Component a

Alternative a2

Alternative a3

Alternative b1

Solution Component b

Alternative b2

Alternative c1

Solution Component c

Alternative c2

Alternative c3

ICEIS 2008 - International Conference on Enterprise Information Systems

164

Figure 5: The proposed FAHP-based technology specification (TSS) methodology.

(process 3.2.2). A means-objective network and a

fundamental-objective hierarchy together form a

solution-component-level hierarchy model (see

figure 4 for example).

Following the decomposition phases, the created

hierarchy models will be used in the fourth phase

Solution Component Assessment: It is a FAHP-

based process for assessment of each solution

component. It consists of two steps (step 4.1 and

4.2) and they are in iteration where each round will

have created assessment result for one solution

component. General FAHP steps are proposed in

this phase: surveying (process 4.1.1 and 4.2.1),

building of pairwise matrices (process 4.1.2 and

4.2.2), consistency test (process4.1.3 and 4.2.3),

fuzzification (process 4.1.4 and 4.2.4),

defuzzification and obtain overall ranking as the

assessment result (process 4.1.6 and 4.2.6).

The key differences of the use of FAHP in the

proposed methodology from other FAHP/AHP-

based approaches in literatures can be summarized

as below:

 The proposed methodology is not for project

justification purpose but for the system design

benefit. Instead of involving people from

different background, Step 4.1 of the proposed

methodology requires the involvement of

experts to the fields of relevant technology. It

helps to improve the data quality and the

accuracy of assessment results.

 Assessment of alternatives in step 4.2 requires

judgers to make judgment based on the

means-to-objectives and the objectives are the

4.2.2

Construct PCMs

(alternatives)

Consistent?

Survey

Results

4.2.1

Surveying

yes

4.2.3

Consistency

Test

4.2.4

Fuzzification

of PCMs

4.2.5

Synthesis

4.2.6 Defuzzification

and Obtain Overall

Ranking of Alternatives

1.1

Preparations

1.1.1

Constitution of

project team

Start

Finish

6.1 Conclusions

Phase 1:

Preparation

Phase 3: Solution Component Decomposition

Phase 4: Solution Component Assessment

Phase 6: Conclusions

4.1 Evaluation of Fundamental-objectives

4.1.2

Construct PCMs

(objectives)

Consistent?

Survey

Results

4.1.1

Surveying

yes

4.1.3

Consistency

Test

4.2 Evaluation of Alternatives

4.1.4

Fuzzification

of PCMs

4.1.5

Synthesis

4.1.6 Defuzzification

and Obtain Overall

Ranking of Objectives

Phase 5: Solution Assessment

5.1 Evaluation of Solutions

5.1.1 Identify

Potential Solutions

5.1.2 Obtain Overall

Ranking of

Potential Solution

Phase 2: Solution Decomposition

2.2 Construction of Solution Structure

More solution

component?

yes

6.1.1 Assessment Result

Analysis, Decision-making

and Conclude Findings

Keys:

Document

Process

Step /

Group of

Process

3.2.2 Define Fundamental-

objective Hierarchy

3.2 Construction of Fundamental-

objective Hierarchy II

3.2.1

Define Goal

3.1.2 Eliminate

Irrelevant Fundamental-

objectives

A FAHP-BASED TECHNOLOGY SELECTION AND SPECIFICATION METHODOLOGY

165

generalization results of requirement

specification. Therefore, the means-objective

network acts as a linkage between the

requirement specification and participants’

judgments. This ensures the assessment results

be responsible to requirement definitions.

 Judgers must provide evidence for the

judgment based on the means-to-objectives.

The evidence can be qualitative knowledge

relate to the alternatives or quantitative

measurement of their capabilities. These

information explain how and how well a

technology alternative satisfies the objectives.

In additions, the information can be used for

generate specification information about the

assessed alternatives (process 6.1.1).

Alternatives of each solution component are

ranked at the end of assessment (process 4.2.6). The

rankings of solution component alternatives can be

used to derive a score with crisp value through

defuzzification methods, for example. The scores are

useful for the assessment of the potential solutions in

the fifth phase Solution Assessment. With the result

from the compatibility analysis (process 2.2.3), the

potential solutions to be assessed must first be

defined (process 5.1.1) and thereby to be assessed

(process 5.1.2). The assessment aims to rank the

potential solutions by assign an overall score to each

of them. An overall score is obtained through

calculation with the scores of included solution

component alternatives. The calculation should

consider the relative importance of solution

component and other necessary criteria. The final

scores reflect how relatively well the solutions

satisfy the solution-level objectives for the solution-

level goal in regard to the requirement specification.

Finally, the sixth phase Conclusions provides a

space for decision makers to make use of the

information generated through the previous phases.

The best performed solution(s) suggested by phase 5

will be proposed to decision makers and thereby

decision makers may make decision on technology

selection. On the other hand, the specification

information of technologies can be identified

qualitatively and/or quantitatively in phase 4. The

process 6.1.1 concludes these findings and

documents relevant information to form the

technology specification for the detail design and for

other project management purpose. Furthermore,

other useful information such as relative importance

weight of objectives obtained in step 4.1, ranking of

alternatives obtained in step 4.2, and score of

potential solutions in step 5.1 can be documented for

various project management purposes as well.

5 CASE STUDY

5.1 Background

This section outlines the use of the key steps of the

application of the proposed TSS methodology to a

transportation management system development

project.

ContainerPort (www.containerport.co.uk) is a

commercial project conducted by the Aimes Centre

(www.aimes.net), the University of Liverpool. The

project has developed an UK-based transportation

management system with GPS (Global Positioning

System), Oracle database, Microsoft .net Platform,

and Web portal technologies.

Technology selection and specification were

important in the system design stage of the system

development process. The proposed TSS

methodology was applied to the case for testing and

demonstration purposes.

5.2 Demonstration of the TSS

Methodology

This section briefly outlines the key activities of the

six phases of the TSS methodology with the case

study.

In the first phase, a project team was formed with

project manager and technology experts from the IT

consultant (the Aimes Centre), personnel from

management level of clients and end user.

In the second phase, solution components,

alternatives of them, and solution-level fundamental-

objective hierarchy were defined with goal “select

and specify the best technology solution”. Table 1

shows the 4 identified solution components and their

alternatives.

Table 1: Solution component and alternatives.

Solution Component Alternatives

Database

management system

Oracle database, SQL database

Vehicle tracking

technology

Long-range RFID (Radio

Frequency Identification),

short-range RFID, GPS system

Software platform Microsoft .Net Platform, Java-

based platform

Presentation GUI , Web page

Network Connection Web standards, private

network standards

ICEIS 2008 - International Conference on Enterprise Information Systems

166

Therefore, the third phase had the four AHP

hierarchy models created with means-objective

network and the fundamental-objective hierarchy

included. Each of the models was created for

assessment of one of the solution components in the

next phase.

The FAHP processing in the fourth phase has

suggested the best-performed alternative of the

solution components as shown in table 2.

Table 2: Solution component assessment results.

Solution Component Best Performed Alternative

Database

management system

Oracle database

Vehicle tracking

technology

GPS system

Software platform Microsoft .Net Platform

Presentation GUI

Network Connection Web standards

Through the assessment process, information of

judgment and reason for judgment were collected

from experts. The data explain the reason for

assessment result as well as providing specification

data of the technologies. For instance, GPS was

believed more preferable for the lower

implementation cost as well as its satisfying

capabilities. Before researched above opinion,

capability and implementation cost of GPS and other

alternatives were given, evaluated and compared.

The information was documented for technology

specification purpose.

Although GUI (

Graphical User Interface) was

recognized as the best-performed presentation

technology for the capability, the fifth phase had

proposed the best-performed solution without it. The

main reason was that GUI was recognized relatively

less compatible than that of web portal in the fifth

phase: it requires installation of extra application on

user’s computer, local security settings may disallow

database connection, and GUI-based application is

usually software platform dependent. Accessing

Web portal through Web browser will not meet

above problems and thereby will work better with

other solution components. The proposed solution

includes Oracle database, GPS system, .Net

Platform, Web portal, and web standard network.

The best-performed solution above is currently

applied by the live system. As there has no issue

indicates any need in change of technology after the

system has gone live for approximately a year, I can

conclude that the proposed methodology provides

satisfying selection result to the goal.

6 CONCLUSIONS

A HLSD framework was proposed to indicate the

role of technology selection process within a generic

system design process. It suggests that the

technology specification and specification can be a

separate activity apart from other functional areas of

abstract specification.

A FAHP-based TSS approach was proposed to

support technology selection and specification

activities of the HLSD framework. As a part of the

framework, it takes input from the previous system

design step and aims to generate specification

information for later system design activities. By

taking the advantages of AHP (see section 3.2), the

proposed methodology attempts to generate useful

information, such as technology specifications, for

system design and project management purposes.

The proposed methodology applies the means-

objective network technique to strengthen the

linkages between requirement specification and

decision-makers’ judgments in order to ensure that

both technology selection and specification results

are responsible to the requirement definitions. The

proposed methodology also introduced the multiple-

hierarchical-level solution structure technique to

address the system design needs.

Beside the general advantages of FAHP that was

mentioned in section 3.2, some advantages of the

proposed FAHP-based TSS methodology are

outlined below.

 Complete picture of technology solution is

considered by the proposed methodology with

compatibility issues between solution

components.

 Instead of assess all of the potential solution

using pairwise comparison according to

conventional AHP approach, the proposed

methodology divides the assessment of

solution into two parts – phase 4 and phase 5.

This greatly reduces the number of

comparison judgment necessarily to be made

and thereby has improved the efficiency. It

implies reduction in risk of creating

inconsistent datasets.

 As the proposed HLSD framework is

developed based on a general design process

model (see section 2), it’s highly adaptable by

various software process model such as

waterfall model.

Nevertheless, there are several identified

limitations of the proposed TSS methodology that

indicates space of improvement in the future. For

A FAHP-BASED TECHNOLOGY SELECTION AND SPECIFICATION METHODOLOGY

167

example, although the TSS methodology considers

the compatibility of solution component alternatives

in assessment of potential solutions, it can be more

specific in handling different levels of compatibility

since it may influence the ranking of potential

solutions effectively.

REFERENCES

Bard, J. F., 1986. Evaluating space station applications of

automation and robotics. IEEE Transactions on

Engineering Management 33, 102-111.

Chang, D.Y., 1992. Extent Analysis and Synthetic

Decision. Optimization Techniques and Applications,

Vol. 1. World Scientific, Singapore, p. 352.

Chang, D.Y., 1996. Applications of the extent analysis

method on FAHP. European Journal of Operational

Research 95(3):649-655.

Chou, Y., Lee, C., and Chung, J., 2004. Understanding m-

commerce payment systems through the analytic

hierarchy process. Journal of Business Research, 57,

12, 1423–1430.

Durán, O., Aguilo, J., 2007. Computer-aided machine-tool

selection based on a Fuzzy-AHP approach. Expert

Systems with Applications.

Ho, William, 2007. Integrated analytic hierarchy process

and its applications – A literature review. European

Journal of Operational Research.

Karsak, E.E., Kuzgunkaya, O., 2002. A fuzzy multiple

objective programming approach for the selection of a

flexible manufacturing system. Int. J. Production

Economics 79 101-111.

Lai, V.S., Trueblood, R.P., Wong, B.K., 1999. Software

selection: A case study of the application of the

analytical hierarchical process to the selection of a

multimedia authoring system. Information &

Management 36, 221–232.

Lee, A.H.I., Kang, H.Y. and Wang, W.P., 2006. Analysis

of priority mix planning for semiconductor fabrication

under uncertainty. International Journal of Advanced

Manufacturing Technology, 28(3-4), 351-361.

Lee, J.W. and Kim, S.H., 2000. Using analytic network

process and goal programming for interdependent

information system project selection. Computers &

Operations Research 27, 367–382.

Lee, W. B., Lau, H., Liu, Z., and Tam, S., 2001. A fuzzy

analytic hierarchy process approach in modular

product design. Expert Systems, February, 18(1), 32–

42.

Levary, R.R., Wan, K., 1998. A simulation approach for

handling uncertainty in the analytic hierarchy process.

European Journal of Operations Research 106, 116–

122.

Liu, Y.-W., Kwon, Y.-J., Kang, B.-D., 2007. A Fuzzy

AHP approach to evaluating e-commerce websites.

Fifth International Conference on Software

Engineering Research, Management and Applications.

114-122.

Mon, D.K., Cheng, C.H, Lin, J.C., 1994. Evaluating

weapon system using fuzzy analytic hierarchy process

based on entropy weight. Fuzzy Sets and Systems 62

127-134.

Nelson, P. F. and Kastenberg, W. E., 1986. An extended

value-impact approach for nuclear regulatory decision-

making. Nuclear Engineering and Design 93, 311-

317.

Ribeiro, R.A., 1996. Fuzzy multiple attribute decision

making: A review and new preference elicitation

techniques. Fuzzy Sets and Systems 78, 155–81.

Roper-Lowe, G.C. and Sharp, J.A., 1990. The Analytic

Hierarchy Process and its Application to an

Information Technology Decision. Journal of

Operational Research Society 41(1):49-59.

Sadiqa, R. and Husain, T., 2005. A fuzzy-based

methodology for an aggregative environmental risk

assessment: a case study of drilling waste.

Environmental Modelling & Software 20 33-46.

Saaty, T.L., 1980. The Analytic Hierarchy Process.

McGraw-Hill, New York, NY, U.S.A.

Saaty, T. L. and Kearns, K. P., 1985. Analytical Planning.

Pergamon, New York.

Sommerville, Ian, 2001. Software Engineering, Sixth

Edition. Addison-Wesley. ISBN 0-201-39815.

Van Laarhoven, P. J. M. and W. Pedrycz, 1983. A Fuzzy

extension of Saaty's Priority Theory: Fuzzy Sets and

Systems, Volume: 11, pp. 229-241.

Zeng, J.H., An, M., and Smith, N. J., 2007. Application of

a fuzzy based decision making methodology to

construction project risk assessment. International

Journal of Project Management.

ICEIS 2008 - International Conference on Enterprise Information Systems

168