A cloud-based multi-criteria decision support system for selecting urban housing projects

3.1 Cloud computing

Cloud computing has been defined by National Institute of Standards and Technology (NIST) as “a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or cloud provider interaction” [19]. The increasing trend of virtualization and cloud computing create a new trend that business intelligence (BI) applications are moving from company-internal information systems to the cloud. Cloud computing providers offer a new service BI as a service (BIasS), in addition to three service models: infrastructure as-a-service (Iaas), platform-as-a-service (PaaS), and Software-as-a-service (SaaS). Hosted BI platforms for small- and medium-size companies is the target of huge investments and the focus of large research efforts by industry and academia [20]. The advancement of cloud computing technologies makes it feasible for urban planners to monitor all details of the metropolitan planning processes and involve them in the design and the decision making process with a cloud-based DSS [21].

3.2 MCDM, negotiation support, and integrated DSS

A multiple criteria decision support system (MCDSS) can be defined as an multiple criteria decision making model (MCDM) model embedded DSS to solve various semi-structured and unstructured decisions involving multiple attributes or multiple objectives or both, with an objective of aiding decision makers in analyzing, exploring, and comparing a set of incompatible alternatives. Zeleny [22, p.17] defines the term MCDM as “the general class of problems that involve multiple attributes, objectives, and goals.” He strongly believes that MCDM is a misnomer [23]. Rather, all decision making (DM) problems are MCDM.

All human DM takes place under multiple criteria only. All the rest is analysis, measurement and search.  … … … … … … … … .

Clearly, there can be no DM without multiple criteria. DM is that which must be performed after we have measured and searched. Problem with a single objective function, no matter how complex, important or aggregate [the function], are not problem of DM or optimization, but only problem of measurement and search.  … … … … … … … .. It appears that we have no need for prefix “MC” in front of DM: all DM is with multiple criteria [23,p.78].

MCDSS intend to support decision makers to help decision makers solve ill-structured problems through direct interaction with analytical models. The various features of MCDM include (1) the multiple-objective goal structure, designed to handle quantitative and qualitative information crucial for ill-structured problems), (2) the interactive solution search procedure, designed to analyze continuous trade-offs among various alternatives until the best available solution is attained, and (3) the emphasis on the decision maker’s judgment or bounded rationality, which better reflects his/her actual cognitive behaviors.

Integration of MCDM into DSS has long been advocated by the researchers in both areas. Founding fathers of DSS such as Keen and Scott Morton [24, p.48] believe that the multiple criteria decision problem is at the core of decision support and “a marriage between MCDM and DSS promises to be practically and intellectually fruitful.” The emergence of MCDM model-based DSS was predicted in the early 1980s [22]. A series of studies [25–27] reached the compelling conclusion that the MCDM model-embedded DSS have positioned themselves at the core of DSS. An important reason for the emergence of the MCDM model-embedded DSS is that MCDM complements DSS and vice versa due to the differences in underlying philosophies, objectives, support mechanisms, and relative support roles [28].

Jarke [29] proposed four dimensions to classify multi-person DSS: spatial distance, temporal distance, commonality of goals, and type of control over the decision process. Most group DSS help solve a common problem cooperatively, while negotiation support systems (NSS) support potentially hostile parties. An early NSS, MEDIATOR, was introduced by [30]. MEDIATOR supports the negotiation process. The essence of any negotiation is compromise, which is a settlement of differences by mutual adjustment or modification of opposing claims and demands, etc. MEDIATOR is a set of networked DSSs for each player and one mediator. MEDIATOR helps the users (players and a mediator) by providing separate private data and tools for each player and data and tools for the mediator as well as shared data and tools.

Lim and Benbasat [31] presented a traditional view of negotiation support systems. This view is based on the desktop computer based DSSs with communication links between negotiators. A NSS is a system of the individual DSSs assigned to individual bargainers and electronic communication systems that permit both computer-mediated and non-computer-mediated communication between bargainers. NSS should support the decision making process in any negotiation situation of interdependence, perceived conflict, opportunistic interaction, and possibility of agreement. A proposed theoretical model seeks to improve negotiation outcomes in terms of the following five dependent variables - time to settlement, satisfaction, distance from efficient frontiers, distance from Nash solution (fairer solution), and confidence with solution. Using traditional architecture, a specific NSS is developed to deal with a hostage crisis situation [32]. Espinasse and others [33] developed a prototype negotiation support system, NegocIAD, based on a multi-criteria conceptual framework of the negotiation based on a multi-agent architecture from distributed artificial intelligence.

Later Kersten and Noronha [34] presented a Web-based asynchronous NSS generator/shell, INSPIRE-INterneg Support Program for Intercultural Research. The traditional NSS architecture of Lim and Benbasat has been expanded by WWW based negotiation support systems architecture. The Web-based architecture is based on the net-centric computing paradigm and object-oriented design. The client/server model architecture allows the user with only a Web browser and an Internet connection to be part of NSS. Programs such as electronic bargaining facilities, analytical tools, quantitative, and qualitative tools reside at their developers’ home site. When the user needs a part of functionality, it will be downloaded. The NSS system shell supports most negotiation activities such as preference assessment, analysis of alternative offers, counter-offer evaluation, etc.

Since MCDM inherently necessitates a simultaneous comparison of the large number of decision criteria and alternatives, which demand a complex array of information, an integration of MCDM with DSS is inevitable. Zeleny even goes further by saying that DM support should be integrated from MCDSS to include all other forms of information technologies such as expert systems, artificial intelligence tools and techniques (intelligent agents, fuzzy algorithm, genetic algorithm, support vector machines, etc.), management support systems, knowledge management systems, data mining, wisdom systems, and others to create an integrated decision support system. The integrated DSS, the DIKWE coordination system, should be able to manager all five dimensions of informatiom needs of oragnizations: data, information, knowledge, wisdom, enlightnment [23, 35].

4.1 Phase 1: Multi-criteria analysis

Multi-criteria decision aid is employed in various domains in order to help the decision maker to choose the optimal solution among a set of solutions. Thus according to Vincke [38] the multi-criteria decision aid aims, as its name indicates it, to provide to a decision maker the tools enabling him to progress in the resolution of the problem of decision where several points of view of, often contradictory, must be considered. Many real problems can be formulated by defining a set of criteria which evaluate action performances. When modeling a real world decision problem using multiple criteria decision aid, different problematics can be considered [39]. This distinction differs in the way alternatives are considered and in the type of result expected from the analysis. Roy determines four problematics [40]: choice problematic consists in working out a procedure of selection, sorting problematic allows to carry out a procedure for assigning, ranking problematic consists in arranging the various actions while going from the best action to the least good and description problematic allows describing the actions and their consequences.

To select the urban housing development projects, there are various methods such as: PROMETHEE (Preference Ranking Organization METHod for Enrichment of Evaluations) I, PROMETHEE II, ELECTRE (ELimination Et Choix Traduisant la REalité) II, ELECTRE III and ELECTRE IV. The PROMETHEE II is selected as a method for ranking various urban housing development projects from the best to the worst. PROMETHEE II is a prominent method for multi-criteria decision aid that builds a complete ranking on a set of potential actions by assigning each of them a so-called net flow score. However, to calculate these scores, each pair of actions has to be compared [41].

For urban project, multiple decision makers can employ multiple criteria to evaluate actions (projects). In such circumstances, a preference of participant given through the actions can be different for each established criterion. The components for this kind of problems of decision-making aid are following:

{Di, i = 1, 2,…, n} is a set of decision makers,

{aj, j = 1, 2,…, m} is a set of possible actions by decision makers,

{cik, k = 1, 2,…, li} is a set of criteria for the decision maker i, i = 1, 2,…, n,

{eikj, j = 1, 2,…, m} is a set of evaluations for the decision maker i, i = 1, 2,…, n

and criterion k, k = 1, 2,…, li, relatively to the set of actions, A_j, j = 1, 2,…, m.

The general structure of MCDM problem is exposed in Table 1.

These characteristics represent the basic attributes of an urban development housing project. The decision making process by the PROMETHEE II method is composed of four steps that are presented hereafter [42]:

Step 1: The first step computes for each pair of projects and for each criterion, the value of the preference degree. Let g _j  (pk) be the value of a criterion j for a project pi. We note d _j  (pi, pk), the difference of value of a criterion j for two projects pi and pk. d j ( pi , pk ) = g j ( pi ) - g j ( pk )(1) P _j  (pi, pk) is the value of the preference degree of a criterion j for two projects pi and pk. The preference functions used to compute these preference degrees are defined such as: { 0 : if d j ( pi , pk ) ⩽ 0 1 : if d j ( pi , pk ) > 0(2)

Step 2: The second step consists in aggregating the preference degrees of all criteria for each pair of projects. For each pair of projects, we compute a global preference index. Let C be the set of considered criteria and w _j the weight associated to the criterion j (specified by the decision maker). The global preference index for a pair of project pi andpk is computed as follows: π ( pi , pk ) = ∑ j ∈ C w j × P j ( pi , pk )(3)

Step 3: The third step, which is the first that concerns the ranking of the projects, consists in computing the outranking flows. For each project pi, we compute the positive outranking flow φ ⁺ (pi) and the negative outranking flow φ ^- (pi). Let A be the set of projects and n the number of projects. The positive outranking flow of a project is computed by the following formula: φ + ( pi ) = 1 n - 1 ∑ x ∈ A P j ( pi , x )(4)

The negative outranking flow of a project is computed by the following formula: φ - ( pi ) = 1 n - 1 ∑ x ∈ A P j ( pi , x )(5)

Step 4: The last step consists in using the outranking flows to establish a complete ranking between the projects. The ranking is based on the net outranking flows. These are computed for each project from the positive and negative outranking flows. The net outranking flow φ (pi) of a project pi is computed as follows: φ ( pi ) = φ + ( pi ) - φ - ( pi )(6)

In our context there are several decision makers where each decision maker express his personal point of view by specifying the subjective parameters (i.e. fix the weight of the criteria for each urban project), for that we use PROMETHEE II for each decision maker; therefore we will obtain several rankings where each ranking corresponds to a decision maker as shown in Fig. 1; in this case there will be a problem of conflict between the decision makers to choose the best project among a set of rankings. To solve this problem we propose to use a negotiation process.

The essence of any negotiation is compromise, which is a settlement of differences by mutual adjustment or modification of opposing claims and demands, etc. Some researchers used the negotiation to solve problems of the urban planning: Longfei and Hong [43] proposed an approach for resolving the problem of parking in the city using negotiation process based on calculation of routes utility. Takahashi, Kanamori and Ito [44] described a route providing method to acquire efficient traffic flow based on anticipatory stigmergy for estimating vehicle position and negotiation system for changing route assignment. Di Lecce and Amato [45] proposed a solution for the problem of hazardous goods by creating a new planning route based on multi agent cooperative negotiation paradigm.

One way of coming to an agreement is voting. In order to resolve the problem of conflict between decision makers, we use the voting system to elect an urban housing development project among a set of rankings of urban projects carried out by the multi-criteria analysis. There are different methods of vote such as: Condorcet method, Borda method, and Hare method. For our DSS we employed the Hare method. This is also known as “ranked choice voting”, or “preferential voting”. This method is an electoral system used to elect a single winner from two or more candidates, by ranking the candidates in order of preference rather than voting for a single candidate. This method eliminates the least desired alternatives (urban projects) successively in order to elect the best urban project. We choose to use the Hare method because this one does not present any disadvantage and we are sure to find the social choice whereas the Borda method makes it possible to find the best alternative but has the disadvantage of encouraging the tactical or reasoned votes and the Condorcet method has the disadvantage of not always finding a winner [46].

Figure 2 illustrates the functioning of our proposed DSS which is composed of two steps: the Multi-criteria analysis and the negotiation process in order To give the final choice (the best urban project) to the decision-makers.

4.3 Phase 3: Cloud deployment of MCDSS

In this section we will present the architecture of the private Cloud that we have suggested to deploy our Multi-Criteria DSS for evaluation of urban projects, as illustrated by Fig. 3. We chose to integrate our DSS in a private Cloud because the proposed Multi-Criteria DSS (MCDSS) is not intended for the general public; it is used by a group of decision makers. By deploying our Multi-Criteria DSS in private Cloud, data will be more protected and secure.

Our cloud computing application is composed of three essential layers: an infrastructure layer, a platform layer and a user layer. This section discusses the implementation of our proposed architecture to integrate our suggested MCDSS in private Cloud. The scenario of implementation is illustrated in Fig. 4.

5.1 Negotiation process

We suppose that we have five decision makers, the results of application of multi-criteria analysis for each decision maker are represented below in Table 4:

Hare method uses the results of projects ranking according to each decision-maker to determinate the best housing development project. The negotiation process by Hare method is illustrated in Fig. 9. The best housing development project given by Hare method is project 1.

5.2 Cloud deployment process

We note that if the number of decision makers is large, the time of development and execution of the application (MCDSS) will be increased, the memory space will be insufficient, and the speed of accessibility and communication will be slow. At this stage we decide to deploy our Multi-Criteria DSS (MCDSS) on PaaS Cloud, we take CloudBees as a platform of development for the deployment of our MCDSS. As represented in Fig. 10, we can easily deploy our MCDSS and benefit from the options offered by CloudBees according to our needs. We use CloudBees for affecting an instance to each decision-maker where each instance is composed of material and software resources necessary to the operation of our MCDSS. The use of instances facilitates the accessibility of the decision makers by connecting with any device (PC, laptop, tablet, Smartphone   … ), ameliorates the communication and the cooperation between decision-makers and reduces the deployment and the processing time.