All Software Engineering (SE) processes include steps where several alternatives call for decisions. However, in many cases, the choice is intuitive and thereafter hazardous with unpredictable consequences. On the other side, the operational research domain has produced many methods that could be adequately used in these situations. Using these methods should facilitate the decision making activity by considering specific SE situations. However, no work has been done to understand how, when, or which of these methods could be used in SE. This paper describes how multicriteria methods could be applied to consider the situation in the SE.
Information system (IS) conception, development, implementation, and every other process in Software engineering (SE) includes steps where several alternatives are considered and a decision must be made. Existing SE methodologies sometimes offer a way to guide decisions, for instance, in the requirements engineering [1], in the method engineering [2], or in other contexts. SE-related decisions result from the need to satisfy practical constraints such as quality, cost or time [3]. However, this field can be characterized by poor understanding and describing decision problems, a lack of transparency, of considering decision consequences and stakeholders' interests [3]. Therefore, we believe that an advanced decision aid is needed in the SE context.
On the other hand, the operational research area has developed numerous decisionmaking (DM) methods, for instance, multicriteria (MC) methods (a large overview of MC methods is presented in [4]). However, bibliographic researches show that few attempts have been conducted to systematically guide the selection of DM methods [5] and that none was developed to deal with in the IS engineering context.
In this paper, we study the application of MC methods in order to take into account specific SE situations. The paper is organized as follows. The next section provides an overview of MC methods application for considering situations in the SE. Related works and our research perspectives are discussed in the concluding section.
The manner to consider the specific situation in SE using MC methods is threefold: (i) by structuring specific DM situation, (ii) by considering DM situation specificity, and (iii) by application of MC method adapted to this concrete situation.
Many decisions are made in the field of IS. Despite their importance, these decisions are most often ill-formulated. They are characterized by poor understanding and describing decision problems, misunderstanding of decision consequences, and by a lack of transparency. To solve these problems, we investigate the main notions of DM and introduce two DM levels that help structuring the problem of DM in the SE.
B. Roy defines three basic concepts that play a fundamental role in analysing and structuring decisions [6]: alternatives (potential actions), criteria family, and decision problem. The decision problem [6] can be defined by the result expected from a DM. When the result is a subset of potential alternatives (most often one alternative) then it is a choice problem. When the result represents the potential alternatives' affectation to some predefined clusters, then it is a classification problem. When the result consists in potential alternatives ordered collection then it is a ranking problem. The concept of alternative designates the decision object. Any decision involves at least two alternatives that must be identified. A criterion can be any type of information that enables the alternatives evaluation and comparison. There are many different kinds of criteria: intrinsic characteristics of artefacts or processes, stakeholders' opinion, potential consequences and impacts of alternatives etc.
From a DM perspective, we propose considering two decision types: (i) the actual decision that aims at solving a SE problem and (ii) the decision on selection of a DM method that matches the situation in the former decision. These two types of decisions are respectively represented in Fig. 1 within the levels 1 and 2. At level 1, an engineering decision leads to the choice, ranking, or classification of given alternatives with respect to various criteria defined in the situation. At level 2, a decision is made on different methods that enable to deal with the first level decisions. In this case, the MC methods are the alternatives; and the solution is selecting MC method that shall be used to make the actual level 1 decision.
The DM situation can be specified accordingly to the characteristics of DM problem (problem, alternatives, and criteria) and to the specific conditions of MC method application (usage). These characteristics and possible values are shown in figure 2. Several strategies may be applied to specify the characteristics values of alternatives, criteria, and problem (for instance, retaining the problem type, calculating alternatives number, retaining criteria measure scale, and so on). By instantiating these characteristics according to a given need, the engineer takes into account the specific situation. Additional information may also be required to specify the MC method usage in the concrete situation: the tool is required or not, the nature of the notation, the method easiness, and the level of engineer skills required for applying the method.
The selection of an appropriate MC method is carried out by its interface, which does not require focusing on the method content. The interface represents situations in which a given MC method can be used and corresponds to the characteristics described above.
The engineer specifies the values of these characteristics in a given situation. On this basis, a MC method could be chosen by different strategies. In this paper, we foresee the following possibilities: by MC search or by weighting.
First, a MC method may be selected by MC search. This means that the engineer applies a request to MC methods with identified values for obtaining one or several MC methods corresponding to the situation at hand. If it drives to the selection of several MC methods, it is possible to choose one of them by weighting. Using this approach, weights must be given to the characteristics. These weights indicate their relative importance in the situation at hand. Then, "0" or "1" are given to candidate MC methods according to each characteristic (in function of their correspondence to the situation). The method having the highest weighted sum of values is then chosen.
DM is a crucial problem. A poor choice may drive to a loss of time, money, and poor alignment to the situation. Our purpose is to spread MC methods in the SE. These methods would allow considering specific situation, better involving stakeholders, and increasing their confidence in the final decisions in SE.
In SE, the issue of DM was already explored with respect to requirements engineering [1,7], to method engineering [2,8], and more generally, to systems engineering [3]. Ruhe emphasized the importance of DM in SE along the whole life cycle [3]. Several examples of MC methods application can also be mentioned: AHP for prioritizing requirements [7]. Saeki uses weighting method to deal with software metrics [2]. The application of two MC methods (outranking and weighting) is illustrated in the field of method engineering [8]. The examples of selecting an appropriated MC method for business process prioritization are presented in [9,10]. Our proposal differentiates by focusing on MC decision aiding and MC methods selection corresponding to the situation.
A few proposals have been made before to help selecting an appropriate MC method. [5] presents a state of the art of existing approaches on the MC methods selection. In the SE field, [9,10] suggest constructing an analysis grid used for selecting a MC method according to the specificity of a given situation.
In the near future, our research perspectives involve: (i) improving the DM methods signatures to better select the MC methods; (ii) developing a tool supporting our approach; (iii) defining the MC methods as fragments for their integrating into existing SE methodologies; and (iv) evaluate our proposal by extensive case studies.