Elena Kornyshova
email: elena.kornyshova@univ-paris1.fr

Rébecca Deneckère
email: rebecca.deneckere@univ-paris1.fr

Camille Salinesi
email: camille.salinesi@univ-paris1.fr

Improving Software Development Processes with Multicriteria Methods

Keywords: Decision-making, Multicriteria Methods, Software Development Process

All software development processes include steps where several alternatives induce a choice, a decision-making. Sometimes, methodologies offer a way to make decisions. However, in a lot of cases, the arguments to carry out the decision are very poor and the choice is made in an intuitive and hazardous way. The aim of our work is to offer a scientifically founded way to guide the engineer through tactical choices with the application of multicriteria methods in software development processes. This approach is illustrated with three cases: risks, use cases and tools within Rational Unified Process.

Introduction

Researches on several engineering fields (systems engineering, process engineering, method engineering, and so on) show that there are many development cases where information system (IS) engineers has critical choices to carry out. As a matter of fact, they have to deal with a large number of characteristics, artifacts, ideas, possibilities, etc. Many strategies are offered to manage them and choosing one over the others is often a very difficult task to handle. Some development activities aim to sort possible alternatives by prioritizing them. However, these priorities are often applied intuitively and there is a great need for a better priorisation support.

Generally, a decision-making (DM) problem is defined by the presence of alternatives. The traditional approach consists in using only one criterion in order to select alternatives. The usual example is the selection of the projects according to the net present value. However, using a single criterion is not sufficient when the consequences of the alternatives to be analyzed are important [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF]. The goal of the Multicriteria (MC) DM methods consists in defining priorities between alternatives (actions, scenarios, projects) according to multiple criteria. In contrast to a monocriterion approach, MC methods allow a more in-depth analysis of the problem because they consider various aspects. However, their application has proved more difficult.

MC DM methods have shown their qualities for over 30 years [START_REF] Berander | Requirements Prioritization[END_REF] and they currently dominate in the field of decision-making [START_REF] Baudry | Multicriteria decision making[END_REF][START_REF] Gómez-Limón | Multi-Criteria Analysis of Factors Use Level: The Case of Water for Irrigation[END_REF]. They appeared at the beginning of the Sixties, and their number and application contexts increase continually. For example, these methods are employed for requirements priorisation [START_REF] Wiegers | First Things First: Prioritizing Requirements[END_REF], to choose evolution scenario [START_REF] Papadacci | Panorama des approches d'arbitrage dans le contexte de l'urbanisation du SI, Etat de l'art et mise en perspective des approches issues du monde de l'ingénierie des exigences[END_REF], or to make operational decisions [START_REF] Bouyssou | Outranking methods[END_REF].

Five families of MC methods can be considered: MAUT [START_REF] Keeney | Decisions with Multiple Objectives: Preferences and Value Trade-Offs[END_REF], AHP [START_REF] Saaty | The Analytic Hierarchy Process[END_REF], outranking methods [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF], weighting methods [START_REF] Keeney | Foundations for Making Smart Decisions[END_REF], and fuzzy methods [START_REF] Fuller | Fuzzy multiple criteria decision making: Recent developments[END_REF]. These methods will be detailed in the following.

We propose in this work to improve any development process with the use of multicriteria methods as a way to choose the most adapted alternative to each situation. We propose a process, illustrated by an example within Rational Unified Process (RUP) [START_REF]Rational Software[END_REF][START_REF] Kruchten | The Rational Unified Process. An introduction[END_REF], which integrates MC methods at the DM point of the development process. Our aim is to propose a formal approach for priorisation in order to enhance DM in development process.

The paper is organized as follows: section 2 gives an overview of our proposed process, which is illustrated in section 3 on three DM points of RUP, and concluded in section 4.

Overview of the multicriteria methods integration process

Our proposal consists of the integration of MC methods in the methodologies of software development. It is described by an "integration process" (IP) which is presented on Figure 1.

Identify requirements for priorisation

Specify requirements for MC methods

Select a MC method

Apply the MC method and validate results Fig. 1. Process of integration of MC method into software development methodologies.

The integration process includes four steps: 1) Identify requirements for priorisation, 2) Specify requirements for MC methods, 3) Select a MC method, and 4) Apply the MC method and validate results. This IP includes both direct steps and flashbacks. The former indicate the normal IP development, and the latter enable returns to the previous steps if necessary.

Identify Requirements for Priorisation

This step may also be seen as the recognition and description of a specific situation of DM. The first element to define is the identification of the presence of alternatives. If a process offers a different manner to fulfill a specific objective, we may see this process as a "DM point". Identifying these points may be a difficult task to perform and we suggest asking the following questions:

-"What is the type of guidance to run this task: linear or tree form (set of possibilities)? "

-"Does the guidance offer arguments (metrics or criteria) to choose between the alternatives?"

-"Does the guidance offer a way to assign a prioritization to these alternatives?" There are different kinds of DM problems. They may be classified (according to the number of criterion and of decision-makers they have) into five types (cf. Figure 2).

The first type presents a monocriterion problem and can be resolved as an optimization task. In the following, we will focus only on the problems that can be solved by MC methods (types: 2 to 5). When the DM point has been identified, the IP step guides the engineer in describing its situation. B. Roy defines three basic concepts that play a fundamental role in analysing and structuring decisions in close connection with the decision process itself [START_REF] Roy | Paradigms and challenges, Book chapter, In Multiple Criteria Decision Analysis -State of the Art Survey[END_REF]: alternatives (potential actions), criteria family, and decision problem. Based on this, we propose to specify decision situation as a <Problem; Alternative; Criterion> triplet, where problem refers decision problem; alternative refers the collection of alternatives among which one will be chosen; and criterion refers the list of criteria by which alternatives will be evaluated. This description will allow the engineer to define the DM point on a generic level (called level 1 in this work). The decision problem [START_REF] Roy | Paradigms and challenges, Book chapter, In Multiple Criteria Decision Analysis -State of the Art Survey[END_REF] can be defined by the result expected from a DM. When the result consists in a subset of a 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 a potential alternatives ordered collection, then it is a ranking problematic. Given that each MC method is able to support a specific type of decision, it is important to know which type of decision is faced to be able to select the appropriate DM method. The concept of alternative designates the object of decisions. Any decision involves at least two alternatives that must be well identified. A criterion can be any type of information that enables the evaluation of alternatives and their comparison. Often, development processes already propose a predefined criteria set. This set can be improved by adapting it to the project at hand. One of the improvement possibilities takes its roots in two directions: software metrics [START_REF] Mill | Software Metrics[END_REF] and typology of characteristics of IS development project [START_REF] Kornyshova | Method Chunks Selection by Multicriteria Techniques: an Extension of the Assembly-based Approach, Situational Method Engineering[END_REF]. Within a MC problem, the metrics and the projects characteristics are considered as criteria. In a general way, the criteria may be qualitative or quantitative, relative or absolute, and criteria of time, cost, quality, size, efficiency, and so on.

Specify Requirements for MC Methods

In order to deal with decisions, we define a second level of decision-making for selecting a MC method (DM Situation L2). Whereas the level 1 deals with the priorization problem, the level 2 is addressing the MC methods selection problem to solve the level 1 one. The identification of requirement for MC methods allows characterizing the specific parameters required for MC method selection. The problem is always a choice, the alternatives are MC methods, and the selection is made using criteria defined as (a) an aggregate view of the requirements for priorisation, and (b) supplementary criteria referring to the usage of the intended method. The Figure 4 illustrates the model of DM situation applied to the selection of MC method (L2 decision). Several strategies can be applied to specify requirements for MC methods. One of them is to specify the requirements by problem investigation. It means that the engineer has to identify the operations that enable to switch from the requirements for prioritization to the requirements for MC methods. These operations are (i) for problem: retaining the problem type; (ii) for alternatives: calculating the alternatives number, retaining alternatives nature, retaining alternatives incompatibility, and (iii) for criteria: retaining criteria data type, retaining criteria measure scale, and retaining weighting type. Additional information may also be required to specify the MC method usage in the given situation: if a DM tool is needed or not, the nature of the notation, the method easiness, and the level of engineer skills required for applying the MC method.

Select a MC Method

Each MC method is able to deal with problems with specific characteristics. For instance, the number and nature of the alternatives, the decision criteria or the presence of multiple stakeholders with different viewpoints. Besides, the existing methods have different characteristics such as complexity or ability to deal with quantitative or qualitative criteria. A few selection approaches were thus developed to guide specifically MCDM method selection. The state of the art is presented in [START_REF] Kornyshova | Selecting MCDM Techniques: State of the Art[END_REF].

Our assumption is that a process guiding the selection of a DM method should (a) be simple to use, (b) provide results that can be trusted, and therefore (c) take into account all the relevant aspects of the situation at hand. Our approach focusing on these relevant aspects focuses on the comparison technique presented in the next subsection. The current section focuses on the selection process itself.

We introduce the notion of MC method interface to guide MC method selection. The interface represents the characteristics of the situations in which a given MC method can be used and corresponds to the criteria set from the model presented in Fig. 4. The figure 5 shows the relationship between method and interface and several MC method family' interfaces, which are described in the Table 1. In this table, a line represents a general attribute of the interface (level 2) and a column represents a particular MC method family. Experience may be sufficient to select a method, in particular if the exact same situation has already been met.

An MC method may be selected by MC search. This means that the engineer has to search an appropriated method using L2 criteria identified earlier in order to obtain one or several MC methods corresponding to his/her requirements for MC method.

If the achievement of the MC search application 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 L2 criteria. These weights indicate the relative importance of the L2 criteria to the situation at hand. Then, "0" or "1" values are allocated to candidate MC methods according to each criterion. The method having the highest weighted sum of criteria values is then chosen. This strategy is not adequate when the previously selected methods have the same interfaces with reference to specified requirements.

Apply the MC Method and Validate Results

The final step of our proposed process is to apply the chosen multicriteria methods on the identified decision points of the development process. The validation is made following the matching between the users' requirements and the obtained results. The MC methods application and its complexity degree depend on the selected method. It may require additional skills or the acquisition of a tool that supports MC decision making. The presence of a tool is an important factor for practitioners who are concerned with the rapid application of a selected MC method. Tools are however, sometimes costly (purchasing and training), and their acquisition and deployment can be time consuming. The engineer may also execute the MC method by achieving manual calculation or by developing a tool ad hoc. Applying different methods involve different activities. For instance, the MAUT requires constructing partial utility functions and their aggregation into a general utility function by addition or multiplication [START_REF] Keeney | Decisions with Multiple Objectives: Preferences and Value Trade-Offs[END_REF]. AHP is based on a dominance hierarchy and carried out by decision-makers' pair-wise comparisons [START_REF] Saaty | The Analytic Hierarchy Process[END_REF]. Outranking methods are based on analysis of the degree of dominance of one alternative over another [START_REF] Papadacci | Panorama des approches d'arbitrage dans le contexte de l'urbanisation du SI, Etat de l'art et mise en perspective des approches issues du monde de l'ingénierie des exigences[END_REF][START_REF] Bouyssou | Outranking methods[END_REF]. Weighting methods are characterized by a weight assignment being applied to the decision criteria; and the aggregation of the evaluations is based on a weighted sum [START_REF] Keeney | Foundations for Making Smart Decisions[END_REF]. The fuzzy MC methods employ the fuzzy sets theory to add flexibility and to enrich methods by fuzzy parameters [START_REF] Fuller | Fuzzy multiple criteria decision making: Recent developments[END_REF].

Application example with the Rational Unified Process

We propose to illustrate the use of the proposed process by guiding decisions in the Rational Unified Process (RUP) [START_REF]Rational Software[END_REF][START_REF] Kruchten | The Rational Unified Process. An introduction[END_REF]. The RUP is a body of software engineering practices, which is maintained on a regular basis to reflect changes in industry practices. It provides a wealth of guidance on software development practices that both novice and experienced practitioners can exploit. However, although many RUP practices call for decision-making, there is very little information about how to achieve these decisions. All these arguments, together with the fact that the RUP is widely used in the industry, convinced us that it was a good candidate to apply our approach and evaluate it. This paper presents details about the core elements of our proposal, which consists on identifying requirements for decision, specifying requirements for MC methods, and selecting MC methods.

Guidance is provided by the RUP under the form of descriptions of the tasks that can be achieved and of the best practices attached to them. Putting ourselves in the position of a person who wants to prepare a method for a project beforehand, we start by scanning each task described to find those offering alternatives and some kind of DM guidance. We chose to study 3 tasks more closely: (a) select and acquire tools, (b) prioritize use cases, and (c) analyze and prioritize risks 2 .

Select and Acquire Tools. This task guides the adoption of tools that support other tasks in the RUP. Tools that need to be selected should fit the particular requirements of the organization for which the selection is made. Furthermore, special tools sometimes have to be developed internally to support special needs. One of the steps in this task is to collect information about tools in order to gain a better understanding. This information later serve as selection criteria to help the system engineer decide which tool is right for the project at hand. The criteria for tool selection are tool features, vendor and cost characteristics. The RUP proposes to grade each criterion for evaluating candidate tools. However, the guidance stops there and the engineer is left alone at the moment of the actual decision making.

Analyze and Prioritize Risks. This task describes how to identify, analyse and prioritize IS project risks. To achieve this, an inventory of what can go wrong within the project must be made. Events that might decrease the chance of delivering all the required IS features at the end of the project, at the required level of quality, and on time/within budget. The RUP guides this by telling how to (i) look within complementarities and redundancies to see if they would be a source of risk, (ii) put them in a table known as the Risk List, and (iii) rank risks in decreasing order of importance and associate them with specific mitigation or contingency actions. Again, the RUP is very vague with respect to this DM problem: an "order of importance" with respect to these criteria is not clearly defined.

Prioritize Use Cases. The prioritization of use cases allows deciding their order of development. The RUP guidance proposes that the software architect selects a certain number of scenarios and use cases to be analyzed and designed. This proposal is completed and refined in several ways: by development teams, customer requirements, and based on COTS products. The selection is then made by characterizing key factors. For instance, architecturally significant use cases that are poorly understood or likely to change should be prioritized for clarification and stabilization.

These examples are presented in Table 2., which gives an overview of requirements for L1 decisions. Some considerations must be made. For instance, the cost evaluation of tools is carried out according to 5-grade scale (in RUP, -a 3-grade scale) for facilitating DM. Based on the information from Table 2, the strategy by problem investigation allows identifying the requirements for L2 decisions. A summary of these requirements is given in the table 3 (these requirements are specified. For selecting MC method, we used the following process. Within the first iteration, we try to find a MC method that matches all requirements in each case. Figure 6. illustrates the first iteration. For three considered examples, we have retained the corresponding MC method characteristics. If a MC method satisfies a given characteristic, we add "1", if does not satisfy, "0". For tools prioritization, only the weighting method satisfies all requirements. With reference to risks analysis, two MC methods are found: MAUT and outranking. To make our final choice, the engineer decides to give a priority to methods offering a tool. So, the outranking method allowing a tool panel (PROMETHEE I and II, ELECTRE II and III [START_REF] Papadacci | Panorama des approches d'arbitrage dans le contexte de l'urbanisation du SI, Etat de l'art et mise en perspective des approches issues du monde de l'ingénierie des exigences[END_REF]) is selected. Regarding use cases prioritization, no MC method matches that requirement for criteria data type. In this case, another set of candidate methods must be considered (for instance, fuzzy methods) or some requirements removed (if it is possible to remove not-satisfied requirement in the given situation).

For the lack of space, we do not consider the application of selected methods. Our aim is to illustrate, firstly, the MC method selection based on two levels requirements and, secondly, the specific situation consideration expressed by these requirements.

Fig. 2 .

 2 Fig. 2. Typology of decision-making problems.

Fig. 3 .

 3 Fig. 3. Model of DM situation.

Fig. 4 .

 4 Fig. 4. Model of DM situation for selecting MC method (level 2).

Fig. 5 .

 5 Fig. 5. MC methods interfaces.

Fig. 6 .

 6 Fig. 6. MC method selection results (first iteration).

Table 1 .

 1 Instantiation of MC methods interfaces.

		MAUT	AHP	Outranking	Weighting Fuzzy Methods 1
	1. "Problem"
	1.1. Choice	Yes	Yes	Yes	Yes	Yes
	1.2. Ranking	Yes	Yes	Yes	Yes	Yes
	1.3. Sorting	No	No	Yes	No	Yes
	2. "Potential actions"
	2.1. Number of alternatives Great, medium,	Small	Great, medium,	Great,	Different
		small		small	medium, small
	2.2. Alternatives' set nature	discrete	discrete	discrete	discrete	Different
	2.3. Incompatibility and	Yes	No	Yes	No	Different
	conflicts of alternatives
	3. "Criteria"
	3.1. Data type	quant., qual.	quant., qual.	quant., qual.	quant.	Different
	3.2. Measure scale	Yes	No	Yes	No	Different
	3.3. Criteria weighting	Yes, simple	Yes, interdep Yes, interdep Yes, simple	Different
	4. "Usage"
	4.1. Tool	No	Yes	Yes	Yes	Different
	4.2. Notation	Utility function Weighted sum	Textual	Weighted sum	Different
	4.3. Easiness of use	Difficult	Easy	Medium	Easy	Difficult
	4.4. Decision maker skills	strong	medium	strong	week	strong

Table 2 . Examples description.

 2

	Task (task goal)	Criteria	Suggested method
	Select Tools	tool criteria (features and functions, integration,	importance of each feature or
	(select tools that fit	applicability, extendibility, team support, usability,	function: ranking following
	the need of the	quality, performance, maturity); vendor criteria	the next scale: must, nice, not
	project)	(stability, support availability, training, availability,	required; tool and vendor
		growth direction); cost (acquisition cost,	criteria: 5-grade scale; costs:
		implementation cost, maintenance cost)	low, medium, high
	Prioritize Risk	deviation of schedule from plan; deviation of effort	ranking according to the risk
	(rank the risks in	from plan; deviation of cost from plan; likelihood of	exposure; risk magnitude may
	terms of their impact	occurrence; risk exposure; risk magnitude; type:	be calculated in addition.
	on the project)	{direct, indirect}; resource: {organization, funding,
		people, time, business risks, technical risks, scope
		risks, technological risks, external dependency risks,
		schedule risks}
	Prioritize Use Cases	benefit of the scenario to the stakeholders: {critical,	selection following the
	(select a certain	important, useful}; architectural impact of the	architectural significance:
	number of scenarios	scenario: {none, extends, modifies}; risks to be	substantial architectural
	and use cases to be	mitigated: {performance, availability of a product,	coverage, specific
	analyzed and	suitability of a component}; completion of the	architectural point, delicate
	designed)	coverage of the architecture; demonstration to the user	architectural point.

Table 3 .

 3 Identify requirements for MC methods by problem investigation.

	Requirements for MC methods	Tools	Risks	Use cases
	Operations
	Retain problem type	choice	ranking	choice
	Calculate alternatives number	medium	great	great
	Retain alternatives nature	discrete	discrete	discrete
	Retain criteria data type	quantitative	mixed	mixed, fuzzy
	Retain weighting type	Yes, simple
	Usage
	Tool			yes
	Easiness	easy
	Skills	week

Fuzzy methods differ according to the "basic" MC method: MAUT, outranking methods, and so on. Hence, they have the value "Different".

Our case study is nominative and simplified. It was elaborated specially for illustrating suggested approach application.

Conclusion

Decision-making is a difficult process and prioritizing alternatives is a good and efficient way to improve development processes. This is usually done on an intuitive way. Our aim was to offer a scientifically founded way to make this priorization by offering a guidance process to the engineer. This process proposes to use the integration of multicriteria methods to choose the most adapted alternative to each situation. We illustrated this process with examples taken within the Rational Unified Process (RUP) [START_REF]Rational Software[END_REF][START_REF] Kruchten | The Rational Unified Process. An introduction[END_REF]. We showed how to use IP to integrate MC methods at a specific decision-making point.

Our research perspectives include:  improving the DM methods signatures to better select MC methods;  developing a tool that would offer a systematic guidance of IP;  defining MC methods as a method fragment to allow for their integration into any existing methodologies;  exploring the issue of adapting DM methods to the situation at hand. Several extensive case studies in the IS engineering area have also been undertaken.


Elena Kornyshova
email: elena.kornyshova@univ-paris1.fr

Rébecca Deneckère
email: rebecca.deneckere@univ-paris1.fr

Camille Salinesi
email: camille@univ-paris1.fr

Method Chunks Selection by Multicriteria Techniques: an Extension of the Assemblybased Approach

The work presented in this paper is related to the area of situational method engineering (SME). In this domain, approaches are developed accordingly to specific project specifications. We propose to adapt an existing method construction process, namely the assembly-based one. One of the particular features of assembly-based SME approach is the selection of method chunks. Our proposal is to offer a better guidance in the retrieval of chunks by the introduction of multicriteria techniques. To use them efficiently, we defined a typology of projects characteristics, in order to identify all their critical aspects, which will offer a priorisation to help the method engineer in the choice between similar chunks.

Introduction

It is now clearly assumed that one development process cannot fit all the existing problems and development contexts. This assumption has lead to the development of the Method Engineering domain, and more particularly of Situational Method Engineering (SME) [START_REF] Brinkkemper | Method Engineering: engineering of information systems development method and tools[END_REF] [START_REF] Harmsen | Situational Method Engineering[END_REF]. In this domain, approaches have been developed to adapt existing methods to deal with the specifications of the project at hand. It allows the construction of a specific process to meet the requirements of each particular situation by reusing and assembling parts of existing methodologies called either fragments [START_REF] Harmsen | Situational Method Engineering for information Systems Project Approaches[END_REF], chunks [START_REF] Rolland | Specifying the reuse context of scenario method chunks[END_REF], patterns [START_REF] Deneckere | Patterns for Extending an OO Model with Temporal Features, Object Oriented Information Systems[END_REF], etc, that, similarly to a software component, can be treated as separated unit. The knowledge encapsulated in these small method parts is generally stored in a classic library repository called Method Base [START_REF] Rolland | Specifying the reuse context of scenario method chunks[END_REF] [6] [START_REF] Saeki | CAME: the first step to automated software engineering[END_REF].

Following a complete assembly SME approach consists of executing the following phases: (a) identification and formalisation of the method chunks, (b) storage in a method chunks base, (c) chunks selection following the project needs, and (d) assembling of the selected method chunks. In this paper, we will consider the SME aspect regarding the selection of chunks in the repository. In our proposal, we refer to the notion of "chunk" to describe every type of small method parts (considered also as fragment or as pattern). The problem of chunk retrieval is an important part of this process and has to be easy and effective.

The assembly based approach [START_REF] Ralyté | An Assembly Process Model for Method Engineering[END_REF] uses a process (assembly process model -APM) that guides the engineer in the elaboration of a requirement map and uses this map in order to select a set of related chunks. The final selection is then realised with the help of similarity measures inspired from those proposed by [START_REF] Castano | A Constructive Approach to Reuse of Conceptual Components[END_REF] and [START_REF] Bianco | A Markov Random Field Approach for Querying and Reconciling Heterogeneous Databases[END_REF]. They distinguish two types of measures: those which allow to measure the similarity of the elements of product models and those which allow to measure the closeness of process models elements.

The similarity measures are provided in order to compare the method requirements with the solutions proposed by the selected chunks but their application is difficult. First, the difference between the formulation of requirements to achieve and of requirements that can be achieved is more or less inexistent, which made the requirements map creation difficult. Second, the results obtained by an application of the similarity measures are not simple to handle. Furthermore, the cost of a project can increase as, in order to offer a good comparison, method engineers have to manage an increasing number of artefacts, which induce a combinatory explosion of all the values to calculate. Finally, even if all these issues are solved, the final selected chunks may be quite similar; this means that the method engineer has to choose one over the other and to discriminate between them.

To solve these difficulties, we propose an extension of the APM by the introduction of multicriteria (MC) techniques (or MC methods). Our objectives are to (a) guide chunk retrieval and (b) to propose a priorisation of the selected chunks in order to guide the method engineer into the final selection process. In order to use the full potentiality of the MC techniques, we also propose a project characteristics typology, in order to identify all its critical aspects. This typology is an adaptation of two similar works. The first one is the typology created by Kees Van Slooten and Bert Hodes in [START_REF] Van Slooten | Characterising IS development project[END_REF] to prove that the project approach is affected by the project context. The second was made by Isabelle Mirbel and Jolita Ralyté in [START_REF] Mirbel | Situational Method Engineering: Combining Assembly-Based and Roadmap-Driven Approaches[END_REF]. In this work, they define the concept of Reuse frame and they apply it to the assembly approach. Their reasons are threefold: (a) to help the chunk selection by better qualifying them, (b) to enable the use of more powerful matching techniques to retrieve them when looking at similar methodological problems and (c) to express better methodological needs for a specific project, improving this way the chance to get adequate and useful method chunks. The merging of these two existing typologies and their adaptation to be used by MC techniques will multiply the process efficiency.

Our approach is presented in this paper as follows: In the section 2, we give a brief introduction in MC techniques. The section 3 describes the assembly-based approach extended by MC techniques with an example. The section 4 presents conclusion and future works.

Multicriteria Techniques

Multicriteria techniques currently dominate in the field of decision-making [START_REF] Baudry | Multicriteria decision making, First annual meeting on health science and technology[END_REF], [START_REF] Gómez-Limón | Multi-Criteria Analysis of Factors Use Level: The Case of Water for Irrigation[END_REF]. They appeared at the beginning of the Sixties, and their number and application contexts increase continually. For example, these techniques are employed for requirements priorisation [START_REF] Wiegers | First Things First: Prioritizing Requirements[END_REF], to choose evolution scenario [START_REF] Papadacci | Panorama des approches d'arbitrage dans le contexte de l'urbanisation du SI[END_REF], or to make operational decisions [START_REF] Bouyssou | Outranking methods[END_REF].

Generally, a decision-making problem is defined by the presence of alternatives. The traditional approach consists in using only one criterion to carry out the selection between alternatives. The traditional example is the selection of the projects according to the net present value (NPV). However, using a single criterion is not sufficient when the consequences of the alternatives to be analyzed are important [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF].

The goal of the multicriteria decision-making (MCDM) techniques consists in defining priorities between alternatives (actions, scenarios, projects) according to multiple criteria. In contrast to monocriterion approach, MC techniques allow a more in-depth analysis of problem because of taking into consideration various aspects. Nevertheless, their application has proved more difficult.

In spite of their complexity, MC techniques are often chosen and used by companies. In general, the MC formulation of a problem is based on the definition of [START_REF] Zopounidis | Décisions financières et analyse multicritère[END_REF]:

-alternatives set represented by "concurrent" actions, -criteria (attributes) set defined by parameters to be considered for priorisation, -alternatives evaluations according to criteria (partial evaluations, which are obtained by assignment of values to each alternative according to all criteria), -aggregation rules (to select an alternative, it is necessary to incorporate the partial evaluations in a general evaluation). The aggregation rules differ in different techniques. According to this, the decision-making steps are defined as follows: 1. diagnostics of problem (necessity to define priorities), 2. identification of problem's parameters: alternatives, criteria, 3. alternatives partial estimations, 4. priorities definition. Five families of MCDM techniques can be considered: MAUT [START_REF] Keeney | Decisions with Multiple Objectives: Preferences and Value Trade-Offs[END_REF], AHP [START_REF] Saaty | The Analytic Hierarchy Process[END_REF], outranking techniques [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF], weighting techniques [START_REF] Keeney | Foundations for Making Smart Decisions[END_REF], and fuzzy techniques [START_REF] Fuller | Fuzzy multiple criteria decision making: Recent developments[END_REF]. These are not detailed here for the sake of space.

Extended Assembly-based Approach

Using MC techniques allow to integrate new parameters into method chunk selection. We propose to adapt namely the assembly based SME approach by integrating of MC techniques expression.

The basic and extended APM are illustrated in Fig. 1 using the MAP formalism [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF].

The intentional modelling of MAP provides a generic model based on intentions (goals) and the possible strategies to achieve each intention. The map is presented as a graph where nodes are intentions and edges are strategies. The directed nature of the graph shows which intentions can follow which one. An edge enters a node if its manner can be used to achieve its intention. Since there can be multiple edges entering a node, the map is able to represent the many manners that can be used for achieving an intention. The map includes two predefined intentions: "Start" and "Stop", which mean accordingly the beginning and the end of the process. An important notion in process maps are the sections witch represent the knowledge encapsulated in a triplet <source intention, strategy, target intention>, in other terms, the knowledge corresponding to a particular process step to achieve an intention (the target intention) from a specific situation (the source intention) following a particular technique (the strategy).

In the following figure, the basic components of APM are presented by solid lines, and the components proposed to extend the basic approach are exposed by dashed lines.

Start

Stop

Specify Method Requirements

Select Method Chunks

Specify Project Characteristics

Requirements-driven strategy

Refinement strategy

Intention-driven strategy

Process-driven strategy Evaluation strategy

Completeness strategy

Refinement strategy

Fig. 1. Basic and extended APM

This map is described in the following sections. Firstly, we present the basic APM, secondly, the extended one, and, finally, an illustrative example.

Basic Assembly-based Approach

The APM [START_REF] Ralyté | An Assembly Process Model for Method Engineering[END_REF] is based on the notion of "chunk" as a representation of a method small unit. It proposes different ways to select them that match requirements as well as different strategies to assemble them. It is based on the achievement of two key intentions: Select method chunks and Assemble method chunks. Achieving the first intention leads to the selection of chunks from the method base that matches the requirements. The second intention is satisfied when the selected chunks have been assembled in a consistent manner.

The process starts by selecting candidate chunks that are expected to match the requirements expressed in a requirements map. Guidelines suggest formulating queries to the method base in order to identify the chunks that are expected to match part or the totality of the requirements. A set of strategies (decomposition, aggregation, refinement, decomposition, aggregation) help to refine the candidate chunk selection, but, any time a chunk has been retrieved, it can be validated by applying an evaluation strategy. This helps in evaluating the degree of matching of the candidate chunk to the requirements. This is based on similarity measures between the requirements map and the map of the selected chunk.

When at least two chunks have been selected, the method engineer can progress to the assembly of these chunks. Two strategies, namely the integration strategy and the association strategy, are proposed to fulfil the intention Assemble method chunks. The choice of the strategy depends on the presence/absence of overlaps between the chunks to assemble. Similarity measures are used to compare chunks before their assembly and to identify whether they are overlapping. This will help to choose the right strategy between the integration strategy and the association strategy.

Proposed Extension of Assembly-based Approach

As we can see in Fig. 1, the basic APM may be extended by the following sections:

1. Specify Project Characteristics by Project characterisation strategy, 2. Specify Project Characteristics by Refinement strategy, 3. Select Method Chunks by Project Characteristics (PC)-driven strategy, 4. Select Method Chunks by Verification strategy. These sections are described in the following paragraphs according to two intentions: "Specify Project Characteristics" and "Select Method Chunks".

Specify Project Characteristics

Project characteristics influence method chunks selection. Each method chunk is described according to its contribution to these characteristics. This typology can be enriched by introduction of characteristics proper to concrete methods (such a used approach, tool presence, notation, difficulty etc).

Project characteristics typology

Project characteristics describe the main properties of IS development project. Their difference with method requirements of basic APM lies in the way of definition and presentation. The method requirements are analysed and expressed in the form of requirements map, whereas the project characteristics form a predefined typology that method engineer investigates in order to choose those, which are needed for a project.

Based on studies [START_REF] Van Slooten | Characterising IS development project[END_REF] [12], we propose a typology of project characteristics, which includes four dimensions: organisational, human, application domain, and development strategy.

The typology of project characteristics is illustrated on Tables 1,2, 3, and 4. The characteristics proposed in this table are either inspired from the works presented in [START_REF] Van Slooten | Characterising IS development project[END_REF] and [START_REF] Mirbel | Situational Method Engineering: Combining Assembly-Based and Roadmap-Driven Approaches[END_REF] or suggested in this paper. In order to differentiate them in the table, we identify the source (1) as the work of Van Slooten [START_REF] Van Slooten | Characterising IS development project[END_REF], the source (2) as Mirbel's [START_REF] Mirbel | Situational Method Engineering: Combining Assembly-Based and Roadmap-Driven Approaches[END_REF] and ours will be noted as the source (3).

The organisational dimension highlights organisational aspects of IS development project and includes the following characteristics: management commitment, importance, impact, time pressure, shortage of resources, size, and level of innovation (Table 1).

The human dimension describes the qualities of persons involved into IS development project. It includes the following characteristics: resistance and conflict, expertise, requirements clarity and stability, user involvement, stakeholder number (Table 2).

The application domain dimension includes formality, relationships, dependency, complexity, application type, application technology, dividing project, repetitiveness, variability, and variable artefacts (Table 3). The development strategy dimension gathers source system, project organization, development strategy, realization strategy, delivery strategy, tracing project, and goal number (Table 4).

Specify Project Characteristics by Project characterisation strategy

This section consists in the identification of characteristics for a given project. The method engineer explores the project characteristics typology and brings out the project critical aspects, which are crucial for the current project.

Specify Project Characteristics by Refinement strategy

The refinement strategy is similar to this one of the basic APM. The distinction is concluded in a refinement objective. The selection result may be presented by a set of method chunks, which are homogeneous, i.e. have the same description with regard to previously identified project characteristics. Then, additional information is required to define more precisely the differences between homogeneous method chunks. In this case, the refinement aims to specify more closely the project characteristics.

Select Method Chunks

Select Method Chunks by PC-driven strategy

The PC-driven strategy consists in application of MC techniques for selecting alternatives method chunks. This section can be itself refined by a process (illustrated on Fig. 2), which contains two main intentions: "Define weights" and "Define priorities". The choice between these two intentions is made according to needs for criteria weighting. Criteria weighting enables to analyse their relative importance. When they are not weighted, it means that their relative importance is equal.

Define priorities

These two strategies are developed in the following paragraphs (for more details on outranking and weighting techniques, see Appendix 1).

1. Define weights. This intention can be achieved "by simple attribution of weight values", "by identifying criteria tot be improved first" (SWING), "by trade-off technique" (trade-off weighting), and "by importance analysis" (SMART). The choice between these possibilities can be carried out in function of decision-maker preferences. This intention can be achieved "by iteration" (when the result must be specified) and "by fuzzy weighting" (when fuzzy values are needed).

Define priorities (Priorisation)

. There are two ways to achieve this intention that are: priorisation strategy with or without weighting and priorisation strategy with weighting. The objective of this stage is to aggregate the alternatives evaluations into a unique (aggregated) evaluation and to priory alternatives.

Priorisation strategy without weighting. To carry out this strategy, we suggest application of the following strategies: "by outranking" (outranking) without weighting or "by addition". The addition of values requires that all of them must have a homogeneous qualitative nature and be normalised. The outranking can be applied to all data types (quantitative and qualitative) and does not require the normalisation. However, it is most complicated.

Priorisation strategy with weighting. The possible strategies are "by outranking" (outranking) with weighting or "by weighted sum" (weighting techniques). .The difference between the given strategies is similar to the previous selection.

This intention too can be completed "by iteration" if the result has to be specified.

The section Stop by impact analysis allows analysing the results of priorisation by considering the impact and interactions between selected chunks.

Hence, we have identified four main strategies corresponding to these four different MC techniques. Arguments for choosing one of them are presented in Table 5.

Table 5. Arguments for choosing a main strategy.

Addition Outranking Without weighting

All criteria have the same relative importance;

All criteria have a homogeneous qualitative nature and are normalised.

All criteria have the same relative importance; All data types.

With weighting

The criteria have different relative importance;

All criteria have a homogeneous qualitative nature and can be normalised.

The criteria have different relative importance; All data types.

This table presents the combination of arguments allowing the user to choose the right MC technique. The arguments include two essential aspects being the relative importance of the criteria ("same" or "different") and their nature ("all" or "homogeneous qualitative and normalised").

Select Method Chunks by Verification strategy

This strategy aims at verifying adequacy of chunks selected by MC techniques: if the result is not sufficient, other project characteristics are needed for final decisionmaking. Then the section "specify project characteristics by refinement" is available.

Example

To illustrate our proposal, we have selected method chunks that deal with information system (IS) security within requirements engineering (RE).

Five chunks of RE methods designed for analysing IS security were identified: NFR Framework [START_REF] Chung | Non-functional requirements in software engineering[END_REF], KAOS [START_REF] Dardenne | Goal-directed Requirements Acquisition[END_REF], Secure Tropos [START_REF] Bresciani | TROPOS: An Agent Oriented Software Development Methodology[END_REF], GBRAM [START_REF] Anton | Goal Identification and Refinement in the Specification of Software-Based Information Systems[END_REF], and Misuse Cases [START_REF] Alexander | Misuse cases help to elicit non-functional requirements[END_REF]. The comparison of these methods is presented in [START_REF] Lassoued | Shall IS Security be Treated Differently in the light of the Open World Assumption? A Literature Review[END_REF]. Within this example, we illustrate only one part of extended APM that concerns the application of MC techniques in SME.

The given project is described by:  the great influence on the whole organisation;  the need for ensuring the greater progress;  the organisation does not have the experts in this field and does not plan to employ them;  the need for a better explanation of method chunks and their application. The method engineer has chosen three project characteristics (since the weights of the others are equal to zero) and has described the method chunks according to methods properties. Thus, these methods chunks are compared according to six criteria, which concern two groups: project characteristics and proper method characteristics. The first group includes impact, level of innovation, and expertise. The second group comprises guidance, approach, and formalism.

Depending on project description, the method engineer has defined the following preferences rules for these criteria:

 Impact on organisation: maximum;  Level of innovation: maximum;  Required expertise: minimum;  Guidance: a predefined taxonomy is better than heuristics, which is better than a simple guidelines;  Approach: a systemic approach is better than exploratory, which is better than explanatory.  Formalism: a formal approach is better than semi-formal one, which is better than informal one. The summary of chunks evaluation is presented in Table 6. In order to compare these chunks and to select one of them, which is more adapted to the given project, we have applied three different calculations: simple addition, weighted sum, and outranking with weighting.

1) The simple addition was applied to the first three criteria, which are "quantifiable". Two method chunks, which are the best ones, present the result: NFR Framework and Misuse Cases (See Table 7).

As we can see, only one alternative (NFR Framework) dominates the others without any particular shortcoming in terms of discordance. As a result, this first chunk is selected.

Application of different MC techniques for selecting method chunks gives different results. The simple addition is the simplest technique, but it implies the following disadvantages: a) it does not take into account the relative importance of criteria and b) it is applicable only for numeric or easy quantifiable criteria. The weighted sum supports the criteria relative importance, but saves the restrictions on data type (quantitative). The outranking technique is more complex, its application requires additional skills. Nevertheless, the result is defined more precisely with consideration of all data types. In this case, the chunk "NFR Framework" was selected in order to analyse the requirements of IS security.

Hence, the approaches using diverse MC techniques imply a selection of different method chunks. For this reason, we recommend to use one of strategies described above to specify and to select the method chunks (by addition, by weighting, or by outranking) according to available criteria.

Conclusion

We have proposed an adaptation of the existing assembly process with the introduction of MC techniques. The two approaches (basic and extended) may be combined within the same method engineering process as it will offer a more complete guidance to select chunks.

Our objective is twofold. Firstly, we offer the possibility to the method engineer to qualify the method chunks by their correspondence with projects and to choose between similar chunks by an application of MC techniques. Secondly, we propose to characterise the project and the chunks to improve their selection. This typology allows to identify all their critical aspects and to weight them. Within our example, we showed the utility of application of MC techniques and revealed that different MC techniques give different selection result.

In near future, our research perspectives include:  improve the guidance;  adapt other situational methods by integrating MC techniques;  improve the typology presented in this paper in order to take into account other critical characteristics;  extend the MC techniques application to the field of System Engineering based on MC techniques chunks.

1. Calculation of the indices of concordance and discordance on the basis of estimation of two given alternatives. These indices define the concordance and discordance following the assumption that alternative A is preferred to alternative B. The principle is that the decision maker estimates that alternative A is at least as good as B if the majority of the attributes confirm it (concordance principle) and the other attributes (minority) are not strong enough (discordance principle).

2. Definition of levels for the concordance and discordance indices. If the concordance index is higher then defined level and the discordance one is lower, then an alternative is preferred to the other. If it is note the case, alternatives are incompatible (what means that A is preferred to B according to criterion X, and B is preferred to A according to the criterion Y).

3. Elimination of dominated alternatives. Then a first alternatives subset is obtained, which can be either equivalent, or incompatible.

4. Iterative application of stages 2 and 3 with "lower" levels of concordance and discordance indices. A more restricted subset of alternatives is then carried out.

The procedure is applied until a suitable subset is obtained. A last subset includes the best alternatives. The order of the obtained subsets determines the alternatives scale according to their criteria given suitability.

The ELECTRE family has several members: ELECTRE I (for choice problems), ELECTRE II, ELECTRE III, ELECTRE IV (for ranking problems), ELECTRE TRI (for alternatives sorting). An advantage of outranking techniques is that they are based on step-by-step identification of decision makers' preferences. A detailed analysis makes it possible to the decision makers to formulate his preferences and to define compromises between the criteria. The incompatibility relation can be employed to find the contradictory pairs of alternatives, to stop on a subset whose choice is justified (with available information). Difficulties can appear during the weight definition by the decision maker. Moreover, the appearance of the cycles (when alternative A is preferred to B, B is preferred to C and C is preferred to A) is rare but is not excluded.

Weighting techniques

Weighting techniques include SMART (Simple Multiattribute Technical Rating), SWING, and Trade-off weighting [START_REF] Keeney | Foundations for Making Smart Decisions[END_REF], [START_REF] Mustajoki | Decision Support by Interval SMART/SWING -Incorporating Imprecision in the SMART and SWING Methods[END_REF], and [START_REF] Poyhonen | On the convergence of multiattribute weighting methods[END_REF]. They are characterised by a weight assignment to the decision criteria. Aggregation of the evaluations is based on weighted sum.

The SMART technique (proposed by W. Edwards), which appeared the first, includes the following stages: criteria scaling according to their importance, criteria attribution of a value from 1 to 100, calculation of the relative importance of each criterion. We call it definition of criteria weights by importance analysis.

In SWING weighting (D. Winterfeldt и W. Edwards), all criteria are supposed bad. The expert chooses the one, which must be improved firstly and a value of 100 is attributed to this criterion. The same operation is carried out with the other criteria to determine their values (by identifying criteria to be improved first).

In Trade-off weighting (H. Raiffa and R.L. Keeney) the decision maker compares two hypothetical alternatives according to two criteria; other criteria are invariable. The weights of these two criteria are refined so that the values of two given weighted alternatives have the same importance for the decision maker. This operation is repeated until all the weights are defined.

Fig. 2 .

 2 Fig. 2. Select Method Chunks by PC-driven strategy's process map

Table 1 .

 1 Organisational dimension.

	Characteristic	Values	Source
	Management commitment	{low, normal, high}	(1), (2), (3)
	Importance	{low, normal, high}	(1), (3)
	Impact	{low, normal, high}	(1), (2), (3)
	Time pressure	{low, normal, high}	(1), (2), (3)
	Shortage of resources	{low, normal, high}	(1), (2), (3)
		{human, means}	(1), (2)
		{financial resources, human resources, temporal	(3)
		resources, informational resources}
	Size	{low, normal, high}	(1), (2), (3)
	Level of innovation	{low, normal, high}	(1), (2), (3)
		{business innovation, technology innovation}

Table 2 .

 2 Human dimension

	Characteristic	Values	Source
	Resistance and conflict	{low, normal, high}	(1), (3)
	Expertise (knowledge,	{low, normal, high}	(1), (2), (3)
	experience, and skills)	{tester, developer, designer, analyst}	(2), (3)
	Clarity and stability	{low, normal, high}	(1), (2), (3)
	User involvement	{real, virtual}	(2), (3)
	Stakeholder number	num

Table 3 .

 3 Application domain dimension.

	Characteristic	Values	Source
	Formality	{low, normal, high}	(1), (2), (3)
	Relationships	{low, normal, high}	(1), (3)
	Dependency	{low, normal, high}	(1), (2), (3)
	Complexity	{low, normal, high}	(1), (3)
	Application type	{intra-organization application, inter-organization	(2), (3)
		application, organization-customer application}
	Application technology	{application to develop includes a database,	(2), (3)
		application to develop is distributed, application to
		develop includes a GUI}
	Dividing project	{one single system, establishing system-oriented	(1), (2), (3)
		subprojects, establishing process-oriented
		subprojects, establishing hybrid subprojects}
	Repetitiveness	{low, normal, high}	(3)
	Variability	{low, normal, high}	(3)
	Variable artefacts	{organisational, human, application domain, and	(3)
		development strategy}

Table 4 .

 4 Development strategy dimension.

	Characteristic	Values	Source
	Source system	{code reuse, functional domain reuse, interface	(2), (3)
		reuse}
		{weak, medium, strong}	(2), (3)
	Project organization	{standard, adapted}	(1), (2), (3)
	Development strategy	{outsourcing, iterative, prototyping, phase-wise,	(1), (2), (3)
		tile-wise}
	Realization strategy	{at once, incremental, concurrent, overlapping}	(1), (2), (3)
	Delivery strategy	{at once, incremental, evolutionary}	(1), (2), (3)
	Tracing project	{weak, strong}	(1), (2), (3)
	Goal number	{one goal, multi-goals}	(3)

Table 6 .

 6 IS security chunks evaluation.

	Criteria	NFR Framework	KAOS	Secure Tropos	GBRAM	Misuse Cases
	Project Characteristics
	Impact	high	low	high	low	normal
	Level of	high	high	low	high	high
	innovation
	Expertise	normal	high	high	normal	low
	Method Chunk Characteristics
	Guidance	predefined	reuse of	No	documents	guidelines
		taxonomy	generic	guidance	analysis,
			refinement		heuristics
			patterns,
			heuristics
	Approach	explanatory	exploratory	systemic	Not	explanatory
					applicable
	Formalism	semi-formal	formal	formal	informal	informal

Elena Kornyshova1,2, Rébecca Deneckère1, and Camille Salinesi1

2) In the case of weighted sum, we add the weights assigned to criteria. These weights are defined by importance analysis (Appendix 1). The chunk "Misuse Cases" is the best one (see Table 8). 3) To apply the outranking technique, we selected ELECTRE [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF] (Appendix 1). All calculations are not presented here for the sake of space. The concordance and discordance matrices developed in our case study are shown in Table 9 (Table 9.aconcordance matrix; Table 9.b -discordance matrix). Application of outranking techniques allows considering the last three criteria, which are not quantifiable.

a)

Fr1 Fr2 Fr3 Fr4 Fr5 b) Fr1 Fr2 Fr3 Fr4 Fr5 Fr1 X 0,45 0,45 0,85 0,85 Fr1 X 0,33 0,67 0,50 0,50 Fr2 0,60 X 0,50 0,85 0,75 Fr2 1,00 X 1,00 0,50 1,00

Fr3 0,65 0,80 X 0,65 0,65 Fr3 1,00 0,67 X 0,67 1,00

Fr4 0,35 0,60 0,50 X 0,35 Fr4 1,00 0,67 1,00 X 0,33 Fr5 0,60 0,30 0,35 0,70 X Fr5 0,67 1,00 0,67 1,00 X

Appendix 1

This appendix presents a brief description of two groups of MC techniques: outranking and weighting techniques.

Outranking techniques

Outranking techniques [START_REF] Bouyssou | Outranking methods[END_REF], [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF], [START_REF] Kangas | Outranking Methods As Tools in Strategic Natural Resources Planning[END_REF] are inspired from the theory of social choice [START_REF] Bouyssou | Outranking methods[END_REF]. There are two kinds of approaches in the family of outranking techniques: ELECTRE (created by Roy, since 1968) and PROMETHEE (created by Brans J.P., Mareschal B., and Vincke Ph, since 1984) [START_REF] Roy | Multicriteria Methodology for Decision Aiding[END_REF], [START_REF] Kangas | Outranking Methods As Tools in Strategic Natural Resources Planning[END_REF]. The most known technique is ELECTRE (ELimination Et Choix Traduisant la REalité, B. Roy / Elimination And Choice Corresponding to Reality). Outranking techniques serve for approaching complex choice problems with multiple criteria and multiple participants. Outranking indicates the degree of dominance of one alternative over another. Outranking techniques enable the utilization of incomplete value information and, for example, judgments on ordinal measurement scale.

It includes the following steps:


Yves-Roger Nehan

Rébecca Deneckere
email: rebecca.deneckere@univ-paris1.fr

Component-based Situational Methods A framework for understanding SME

The work presented in this paper is related to the area of Situational Method Engineering (SME) which focuses on project-specific method construction. We propose a faceted framework to understand and classify issues in system development SME. The framework identifies four different but complementary viewpoints. Each view allows us to capture a particular aspect of situational methods. Inter-relationships between these views show how they influence each other. In order to study, understand and classify a particular view of SME in its diversity, we associate a set of facets with each view. As a facet allows an in-depth description of one specific aspect of SME, the views show the variety and diversity of these aspects.

Introduction

Method Engineering aims to bring effective solutions to the construction, improvement and modification of the methods used to develop information and software systems. Several authors tried to design methods that would be as effective and as adapted as possible to the development needs of information systems [1,2]. This goal was not always reached, especially because the methods were not always well adapted to projects specificities. The situational methods were designed to correct this weakness. The situational approach finds its justification in the practical field analysis which shows that a method is never followed literally [3,4]. The discipline of Situational Method Engineering (SME) promotes the idea of retrieving, adapting and tailoring components, rather than complete methodologies, to specific situations [5]. In order to succeed in creating good methodologies that best suit given situations, components (building blocks of methodologies) representation and cataloguing are very important activities. In particular, the components have to be represented in a uniform way that includes all the necessary information that may influence their retrieval and assembling. This paper is an attempt to explore some of the issues underlying component-based approaches to Situational Method Engineering (SME) and to propose a framework for their classification. This framework is 4-dimensional as it advocates that a SME approach can be defined by four views, each capturing a particular aspect of SME. Each view has multiple facets and the associated metric. The idea of a four views framework and its facets has been used in several domains such as: requirements engineering for understanding and classifying scenario based approaches [6], system engineering [7], etc. When used in the SME domain, a facet provides a means of classification. For instance, the formalism facet of the system view (see section below) helps in classifying SMEs according to the underlying paradigm used: informal, semi-formal and formal. Each facet has values which are defined in a domain. A domain may be a predefined type, an enumerated type, or a structured type. We use the four views framework as a baseline and attach an aspect of SME to each of the views and a set of facets to each view. As a result, it is possible to identify and investigate four major viewpoints of SME: what is the objective of SME, , how are represented the method components, how can the methods be developed and used and finally what does SME achieve. This paper is organised as follows: Section 2 describes our four views framework. Section 3, 4, 5, 6 explain each view and list a set of their facets for comparing and evaluating the component representation approach. Section 7 presents and illustrates eight of the most recent situational methods, then further analyses each SME approach according to these four different views of our framework. A conclusion is done in Section 8.

The Four-views Framework

The four views framework, originally proposed in [7], has proved its efficiency in enhancing the understanding of various engineering disciplines such as information systems engineering [7], requirements engineering [8], IS development process engineering [9] and method engineering [10].

In the original SE framework [7], the views where described as follows. -The subject view contains knowledge of the domain about which the proposed IS has to provide information. It contains real-world objects which become the subject matter for system modeling.

-The system view includes specifications of what the system does, at different levels of detail. It holds the modeled entities, events, processes, etc. of the subject world as well as the mapping onto design specifications and implementations.

-The usage view describes the organizational environment of the information system, i.e. the activity of agents and how the system is used to achieve work, including the stakeholders who are system owners and users.

-The development view focuses on the entities and activities which arise as part of the engineering process itself.

Our point of view is that this framework concept can be used to help in understanding the field of SME disciplines which consists of applying engineering approaches, techniques, and tools to the construction and representation of components. The purpose of this work is then to present a state of the art in Situational Method Engineering.

Component-based Situational Method

What is a component situational method ?

How is represented a component ? How can SME be developed and used ?

What is the rationale of SME ?

Fig. 1: The four views of SME For our purpose, we define the SME 4-dimensional framework as follows. -The subject view as the dimension which deals with the situational method definition, its nature.

-The representation of method component is described in the system view. -In the usage view, we will investigate the reasons, the rationale for SME and relate users needs to the situational methods that can best meet them.

-The development view deals with the process of constructing component-based situational methods. This process is a meta-process in that it supports the construction of components which will in turn support the development of methods. The way this process might be supported by a tool environment is also relevant in this view. This allows us to discuss in a focused manner the different concerns of SME: the definitions of components, their representations, the way of developing these representations, and the rationale for using these representations. This is done in the subject, system, development, and usage views respectively. Each view is described by a set of facets that allow a more detailed study of the situational methods. However, this set is not exhaustive and can be completed by other studies.

The Subject view

This view of SME deals with the notion of method nature.

In [11], I. Mirbel defines different objectives that are targeted by the approaches. Following this typology, we define a facet representing the nature of the SME methods.

-A first family of approaches aims at documenting methods through well-defined components [12,13]. This kind of method does not state precisely how to retrieve and reuse a component but offers a good effort of specification with regards to the elements a method is made of.

-The second category focuses on the retrieving of components to reuse them and evaluating their similarity [3].

-The third category focuses on method fragmentation with the definition of guidelines for reusing the different components in daily developer tasks by project team members [4,14].

The nature of SMEs can thus be classified as follows:

Nature: SET (ENUM {Documenting, Retrieving and evaluating, Reuse guiding})

The Usage view

The usage view concerns the objectives we try to achieve with SME methods as well as the means necessary to their implementation. The SME approaches use high flexibility and thus modify methods to adapt them to a given situation by taking account of its specificities. This leads us to see the usage view as imposing three strict requirements : how the methods must be constructed the nature of method components and how these components must be developed. It is in the usage view that the method objectives must be stated. These aspects depend on the components management policy. This policy is to build methods starting from components whose names and contents vary according to the design. The use of components allows capturing knowledge which changes with time. The use of a library allows capitalizing the experiments of prior projects. A particular policy may be formalised with the two following facets: Construction technique and knowledge representation.

Construction technique facet

This facet represents the various ways of building a method which are instantiation, assembly, extension and reduction.

-The instantiation approaches use an identification of the common and generic method characteristics and represent them by a system of concepts called meta-model. These approaches allow the creation of a whole set of methods sharing the same properties [3,15,16].

-The assembly approaches concentrate on the grouping of method components belonging to complementary methods [3,17]. They assemble separate selected method components with regard to the studied specific project to form a unique method. To be successful, it is necessary to have a modular process model.

-The extension approaches allow the transformation of a basic method into a new method adapted to the project's needs [18,19] with addition of new functionalities in a base method.

-The reduction approaches allow removal of basic method operators in order to transform it to match the engineer's needs [20,21].

A method can be classified according to its defined type of construction: Construction technique: SET (ENUM {instantiation, assembly, extension, reduction})

Knowledge representation facet

The question of the component retrieval is an important issue of the SME field. Three possibilities have emerged in the literature : (1) the project is globally characterized with use of contingency factors, (2) the components are described with use of descriptors and (3) patterns are used to instantiate the right componant following the project needs. We can then define three SME categories following the knowledge representation.

-An SME fragment based method consists in encouraging a global analysis of the projects while basing itself on contingency criteria. The projects and the situations are characterized by means of factors associated with the methods. [22] uses a contingency model based on 17 contingency factors which take value between Low and High as 'Importance of the Project', 'Knowledge and Experience', 'Stability' and so on. According to the authors, the characterization of the project allows them to select the method components appropriate to the project. Construction is supported by component assembly rules and constraints having to be satisfied by the created method.

-An SME chunk based method aim at associating these reusable components to their description in order to facilitate component research and extraction according to the user's needs. [3] uses the concept of descriptor [23] like a means to describe method components. The descriptors are organized in a contextual way: each one of them defines the situation in which the component can be employed and describe its usage intention.

-An SME pattern based method. A pattern describes a recurring problem with his associated solution [18]. It provides a solution which becomes reusable for any situation concerned with this problem. By developing patterns, the users condense part of their knowledge on the field of the problem and allow its availability for the other users.

The knowledge representation can thus be classified as follows: Knowledge representation : ENUM {fragment, chunk, pattern}

The System view

This specific view is focused on the component representation by defining what is represented, at what level of abstraction, how is it represented and what properties should have the representation. These aspects are captured by the following three facets : Dimension, Abstraction and Formalism.

Dimension facet

A component is not always viewed with the same dimension. The situational methods use various techniques to represent knowledge: fragments, chunks and patterns.

Although terminology between research groups differs, typically a chunk [3, 6] will encapsulate both a process and a product part whereas a fragment [24] can be either a product or a process fragment:

-product fragment relate to the structural and static aspects of methodologies (e.g.; deliverables, documents, models, diagrams, and concepts), whereas -process fragment capture the behavioral and procedural aspects of methodologies (stage, tasks, activities, and techniques to be carried out) [25]. Dimension can thus be classified as follows: Dimension: SET (ENUM {product-oriented, process-oriented})

Abstraction facet

In [24], this notion in SME is related to the abstraction level of a component that can be :

-conceptual, as in [20] where components are expressed with descriptions and specifications of methodology parts, or -technical as in [16,21] where there is an implementation of operational parts with tools.

Abstraction can thus be classified as follows:

Abstraction: ENUM: {conceptual, technical}

Formalism facet

Generally speaking, representation formalism is a set of syntactic and semantic natural language, semi-formal such as diagram [17] or completely formal [15,16].

A formal formalism is required to support the verification of the expected properties of the process model and validation of the process model using, for instance, simulation or enactment techniques. The use of informal notations has made it difficult for process models to be followed systematically. Formal or semi-formal formalism make these efforts considerably more effective as a formal formalism is necessary for providing automatic enactment support.

In the context of SME, the presented components have to be retrieved, assembled, tailored, and customized later and, hence, it is important that the representation approach will be formal or at least semi-formal.

The formalism facet helps classifying SME by one of the three values of the following enumeration:

Formalism: ENUM {formal, semi-formal, informal}

The Development view

The development view deals with two specific issues: the process of constructing component method, and the enactment of process as the SME methods are carried out with an aim of assisting the application engineers. The environment to offer assistance to the process in its execution course thus forms part of the problems whose solutions are provided by the development view. Three facets allow covering these aspects: Flexibility, knowledge construction, knowledge organisation.

Flexibility facet

Traditional methods (also named rigid methods) follow a static approach, which consist in prescribing entirely and statically the method, whereas SME methods use a contingency approach which consist in defining contingency factors defined on an application development. This is strongly related to the library of method components which must be enriched by the specific projects experiments.

[26] proposed a spectrum to organize the engineering methods approaches according to their degree of flexibility towards a new situation. The methods are organized on a scale of flexibility varying of "low" to "high". At the "low flexibility" level are the rigid methods while, at the "high flexibility" level, we find the SME methods. They are represented with the two last types of this spectrum: -either the method engineer performs operations that have to be carried out on the original methodologies in order to create a new one, process that we will call Customization, as in [21] or -he refers to methodology components, including their retrieval and assembly, process called Modularity, as in [3,15]. In this last case, each component is usually treated as a closed unit that cannot be modified, while transformation and gluing parts between the components can be added in order to create "consecutive" methodologies.

This typology may be captured by a facet called Flexibility witch classifies the methods in two distinct categories.

Flexibility: ENUM {customization, modularity}

Knowledge construction techniques facet

The traditional knowledge construction is the expression of the application engineer experience. As long as this experience is not formalized and that a basic available knowledge does not constitute an available part for the various applications, one can say that this knowledge is the result of a ad-hoc construction technique [21]. This has two major consequences: ignorance in the way in how was carried out the construction and dependence on the field of expertise. If this knowledge must be independent of the expertise field and rapid to built, it is then necessary for construction techniques based on the experiment to use more formalized techniques [20].

The techniques of knowledge construction can thus be classified as follows: Knowledge Construction: ENUM {formalised, ad hoc}

Knowledge organization techniques facet

The knowledge used during SME construction can be stored in library or repository to be reused later. Those provide the basic functions for the management of a components repository. As these libraries can contain a large number of components, they generally offer research techniques, as indexation techniques or the use of keywords.

Other approaches, in addition to the component extraction formalism, have an organisational process which helps to manage the knowledge coherence. The organization processes thus allow managing this problem in a more formal way [15,20].

The knowledge organization technique can be classified as follows:

Knowledge organisation: SET (ENUM {repository, organization process})

Figure 2 summarizes the views and facets of the framework presented: This framework is used in the following section to evaluate a panel of SME approaches.

Review of SME approaches according to the framework

We propose a review of eight component-based SME approaches. We choose our method panel in the set of the most recent approaches and with the intention to offer a more complete study of the different views and their facets. The aim is, firstly, to get a 'big picture' of the SME research area and to help understanding the achievements gained from currently developed SME based approaches in the literature. It is, secondly, to check the framework against eight SME approaches.

SME approaches

Method configuration approach

[20] proposed a meta-method called Method for Method Configuration, which is based on the concept of Configuration Packages and Configuration Templates. These concepts are used to configure methods following the specificities of a project while creating reusable assets. Method configuration uses a specific base method as a basis for creating specific configurations. The reusability advantage is obvious since pre-made configurations can be used over and over again. Hence, there is no need to perform a complete method assembly or method configuration for each new project. Experiences can be gathered and reused more efficiently since they can be attributed to coherent set of prescribed actions common in the organization, rather than to context-free actions.

Process Configuration approach

[21] proposes an approach called process configuration that tells how to create a projectspecific methodology from an existing one, taking into account the project circumstances.

The idea that lies behind is: for each individual project a specific process configuration (project-specific methodology) is create. This is done by selecting component from methodology that has been specifically designed for the organization and thus reflects the actual ways of working in the organization (base methodology). The configuration is done by processing the rules (in the engine) that are part of the base methodology. The rules define, for each methodology component, in what circumstances (project situations) its use is compulsory, advisable or discouraged.

Method extension approach

This approach [18] guides the method engineer by providing extension patterns that help identifying typical extension situations and provide advises to perform the required extension. In the extension-based, there is two ways to extend a method: directly through the pattern-matching strategy or by using some generic knowledge related to the domain for which the extension is to be done through the path select a meta-pattern, extend a method with the pattern-based strategy. The former help to match extension pattern stored in a library to the extension requirements whereas the latter select first, a meta-pattern corresponding to the extension domain and then, guides the method extension by applying the patterns suggested by the meta-pattern. Both way-of-working use a library of extension patterns but do it in different ways.

Method chunks approach

This approach [3] for assembly-based SME aims at constructing a method 'on the fly' in order to match as well as possible the situation of the project at hand. It consists in the selection of method components (called method chunks) from existing methods that satisfy some situational requirements and their assembly. This approach is requirements-driven, meaning that the method engineer must start by eliciting requirements for the method. Next, the method chunks matching these requirements can be retrieved from the method base. And finally, the selected chunks are assembled in order to compose a new method or to enhance an existing one. As a consequence, the three key intentions in the assembly-based method engineering process are: specify method requirements, select method chunks and assemble method chunks.

Application-based Domain Modeling (ADOM) approach

ADOM [17] is a domain engineering approach and uses the standard notation of UML 2.0 [27]. This approach is a visual methodology for managing representing, retrieving, customizing and tailoring situational method components. ADOM allows to express different types of methodologies and their components, their associated characteristics and values, their pre and post-condition and other component-related requirements, such as mandatory participants, recommended participants, triggers, etc. The structure and guidelines of components are described within the domain layer of ADOM, while their instantiations, which specify particular situational methodologies, are defined in the application layer.

Evolution-Driven (or Paradigm-Based) approach

This approach [15] uses meta-modelling as an underlying method engineering technique. The hypothesis of this approach is that the new method is obtained either by abstracting from an existing model or by instantiating a meta-model. Meta-modelling is known as a technique to capture knowledge about methods. It is a basis for understanding, comparing, evaluating an engineering method. A new methodology is then created by first constructing a product model and then a process model. There is different strategies available to construct both product and process model.

OPEN Process Framework (OPF) approach

The OPEN Process Framework [12] uses a meta-model to generate method components that are stored in a repository. OPEN offers a set of construction guidelines that are considered to be part of existing methodologies used to construct new methods. The OPF meta-model is composed of five main meta-classes [29] [30]: Stage, Producers, Work Units, Work Products and Languages; a method component is produced as soon as a metaclass is instantiated. An OPEN guideline helps method engineers both to instantiate the meta-model element to create method components and to select the best method components (from the repository) in order to create the situational method.

FIPA (Foundation for Intelligent Physical Agent) approach

FIPA [31] entered the IEEE computer Society Standards Committee with the mission of promoting agent-based technologies and the interoperability of agents with other technologies. FIPA defines the method fragment with a process meta-model [32,33]. In this model, a process is composed of a set of activities performed by some active entities whose task is to produce a well-defined state of an Artefact as input/output. A process is defined as strongly oriented to the production of products. As a result, a method component [34] is defined as a reuse part of a design process composed of two elements: the structure of the product and the necessary procedures to construct this product [28].

Review of component-based SME approaches according to the framework

In this section, we propose a review of eight component-based SME approaches. Table 1 evaluates these eight approaches with respect to the four view defined facets and the four following sub-sections give more details about it, each one corresponding to a specific view of the framework.

Subject View

The subject view contains only one facet concerning the SME objectives. We can notice that almost all the approaches aims at documenting methods through well-defined fragments. Their strength resides in the effort of specification with regards to the elements a method is made of (tasks, activities, resources, etc.). In the method chunks approach, the focus is on the operators provided to allow a new combination of existing process fragments and on mechanisms to evaluate the similarity among them. Finally, five over the eight studied approaches focuses on method fragmentation for project team members, to provide them with guidelines which are to be reused while performing their daily task. We see here that only the Method chunks approach is addressing the particular aspect of the component retrieving with a formalized evaluation strategy. However, we think that the retrieval and selection of a component is a very important issue of the SME field and that a particular attention had to be drawn on it.

Usage View

The objective for the methods engineers, in situational approaches, is to make methods completely flexible and situation adaptable. This is possible with the components that enrich method library or repository and are reused for method construction. Thus, method chunks use directives and signatures. Its method construction technique is done by instantiation and chunks assembly. The following methods use the same technique: Evolution-Driven, ADOM-UML and OPEN. Method configuration and processes configuration build their method through the technique of reduction and extension and they propose a combination of the cancellation and extension operators. All of this show that the construction techniques are often combined, which increase the flexibility of the SME approaches.

The components representation of these methods varies. Thus the method extension uses extension patterns and the FIPA method defines its components like a set of activities. As knowledge representation model, method configuration uses packages and templates as method components and process configuration uses process components which are then to enrich by a set of rules which define how the component has to be used. More than half the approaches studied use a chunk knowledge representation, which allows to describe more effectively the component.

System View

Six of the studied methods (chunks, extension, OPF, Evolution-Driven, FIPA, ADOM) integrate two aspects of the method fragment, the product and the process, so they represents a portion of process together with its related product(s). Process configuration tends to bring the construction process closer to its users by providing facilities for managing the rules. Method configuration is based rather on the product. Regarding the abstraction, we notice that some methods (Process Configuration, OPF, Evolution driven, ADOM) define their fragments as technical fragment i.e. in the form of tools. ADOM-UML has to develop a supporting CASE tool for managing the activities. On the same way, Evolution-Driven develop the LyeeALL CASE tool in order to generate programs, as a set of well-formatted software requirements are given. OPF use the tool OPENPC (OPEN Process Construction) that use the OPEN repository of methodological components (firstly conceived for the development of directed objects but used widely for other applications).

Three methods (configuration, chunks and evolution-Driven), have a formal representation approach. These approaches deals with the definition, the representation, the cataloguing of components according to different features, the retrieval of the most appropriate ones, and the customization and tailoring of them to complete methodologies that best fit a given situation. In these approaches, component representation and cataloguing are very important activities. The others approaches are semi-formal.

Development View

Regarding flexibility, four approaches (method extension, method configuration, process configuration) enable all their components to be specialized, adapted and customized. These operations create new components that can be modified as requested by allowing specification of gluing and transformation components, customization parts. They start with a particular basic method as initial point of departure, then configure them with different reusable components. In that case, there is no assembly but rather a configuration from different parameters or reusable components. In Method configuration, the configuration of a methodology is supported by configuration packages and configuration templates which present reusable assets that can be used in particular software development situation. In process configuration, each process component or components is supplemented by a set of rules that define when to use the component. Method extension uses the patterns as reusable components to configure the method. On the other hand, the other methods (ADOM-UML, OPEN, method chunk, Evolution-Driven, FIPA) use modularity construction strategy's which focus on consistent and congruent method modules. Project-specific methodology is created from fragments that might come from different methodologies. These approaches design their final approaches starting from a set of different and reusable modules to assemble them. This illustrates that authors do not favour one approach to the other, they either use customization or modularity.

All methods use a library to organize the components. Some of them also use an organization process to manage the coherence. Thus, method extension and Evolution-Driven use the process organization based on the "Map" process of [35] to organize their components. Method configuration proposes an organization based on three repositories of components (characteristic, configuration packages and templates). This is showing that the use of a library is required when using an SME approach, as all the components have to be stored somewhere. However, the use of an organization process is not always offered. This may be an issue that authors should work on.

Draft copy

Conclusion

Our study has shown that component-based SME approaches are very complex, multidimensional entities. They cannot be treated adequately with simple predicate based classification techniques. Rather, the need is for a 4-dimensional framework for a component-based approach to be well described.

Every view is itself multi-faceted. Some facets have been proposed by other researchers earlier, others have been introduced by us here. We believe that we have incorporated in our proposals a comprehensive set of facets which cover all the dimensions of our framework.

Through the notion of a view and a facet, we are able to successfully capture the global view and the more detailed view of a component-based SME approach. In this way, the individual characteristics of these approaches are captured within the larger view of SME nature, component management policy, component use and knowledge representation and construction.

Applying the framework on eight recent approaches shows that they all share some of the properties that characterise component-based SME methods. However, they differ in a lot of the selected parameters and their application to this framework allow a precise inventory of their differences.

One of our objectives for our further researches is to review more of the existing SME approaches in order to apply our 4-dimensional framework on a panel as complete as possible. This will allow us to test the validity of our framework and maybe to identify more facets to compare more effectively the methods. Moreover, discussion with other SME approaches authors will help to check the validity, or the invalidity, of our facets.

The main perspective of this work is to identify the real key facets of SME in order to identify reusable components from these construction approaches. As a result, components would be of two types, either a capture of method knowledge or a capture of method construction knowledge. This will offer the possibility to the method engineer to reuse them in order to create a new approach to construct SME methods, perfectly adapted to his way of working.

Fig. 2 :

 2 Fig. 2: Views and Facets of SME framework