Collaborative configuration approaches in software product lines engineering: a systematic mapping study

Collaborative configuration approaches in software product lines engineering: a systematic mapping study

Sabrine Edded ^a,c,∗ , Sihem Ben Sassi ^b,c , Ra´ ul Mazo ^a,d,e , Camille Salinesi ^a , Henda Ben Ghezala ^c

a

Centre de recherche en Informatique (CRI), Universit´ e Panth´ eon Sorbonne, Paris, France

b

MIS Department - CBA, University of Taibah, P.O. Box 344, Al-Madinah, KSA

c

RIADI Lab., National School of Computer Sciences, Manouba University, Tunisia

d

GIDITIC, Universidad Eafit, Medellin, Colombia

e

ULab-STICC, ENSTA Bretagne, Brest, France

Abstract

In the context of software product line engineering, collaborative configuration is a decision-making process where multiple stakeholders contribute in building a single product specification. Several approaches addressing collaboration during configuration have already been proposed, but we still have little hard evidence about their effectiveness and little understanding about how collaborative con- figuration process should be carried out. This paper presents a classification framework to help understand existing collaborative configuration approaches.

To elaborate it, a systematic mapping study was conducted guided by three research questions and 41 primary studies was selected out of 238 identified ones. The proposed framework is composed of four dimensions capturing main aspects related to configuration approaches: purpose, collaboration, process and tool. Each dimension is itself multi-faceted and a set of attributes is as- sociated to each facet. Using this framework, we position and classify existing approaches, structure the representation of each approach characteristics, high- light their strengths and weaknesses, compare them to each other, and identify open issues. This study gives a solid foundation for classifying existing and fu-

∗

Corresponding author

Email addresses: sabrineedded@gmail.com (Sabrine Edded),

Sihem.BenSassi@gmail.com (Sihem Ben Sassi), raul.mazo@univ-paris1.fr (Ra´ ul Mazo),

camille.salinesi@univ-paris1.fr (Camille Salinesi), henda.benghezala@ensi.rnu.tn

(Henda Ben Ghezala)

ture approaches for product lines collaborative configuration. Researchers and practitioners can use our framework for identifying existing research/technical gaps to attack, better scoping their own contributions, or understanding existing ones.

Keywords: Product lines, Collaborative configuration, Systematic Mapping Study, Framework

1. Introduction

Product configuration is a key activity in Software Product Line Engineer- ing (SPLE) that refers to choosing a set of characteristics from a product line model (Clements and Northrop, 2001). Selected characteristics must comply with product line model constraints and user requirements (Salinesi et al., 2010).

5

When the product line model is large, the number of possible configurations can be large too. Configuring this kind of models can be a hard, error-prone and time-consuming activity (Stein et al., 2014), which makes it a challenging ac- tivity for practitioners. Furthermore, it is hard to think of a single user solely responsible of a large number of configuration decisions (Mendonca et al., 2008).

10

Rather, teamwork is highly desirable in order to cope with the general complex- ity of the configuration process.

Feature models (FMs) are widely used to represent product lines (Kang et al., 1990). They commonly span over several technical and non-technical knowledge domains, which requires the participation of multiple stakeholders with different

15

knowledge and background (e.g. customer, product manager, software engineer, database administrator). Sharing the different configuration decisions by stake- holders is referred to as collaborative configuration process. It consists in three main activities (1) configuration role assignment, (2) the configuration itself and (3) conflicting situations management during the configuration (Mendonca

20

et al., 2008).

Collaborative configuration of product lines has appealed to several researchers

that addressed this topic differently where each approach focuses on a specific

collaborative configuration aspect. In fact, some approaches such as (Czar- necki et al., 2005; Mendonca et al., 2007, 2008; Rabiser et al., 2009; Hubaux.

25

et al., 2010) are interested in ensuring coordination of configuration activities through providing a pre-designed process. For some others such as (Junior et al., 2011; Stein et al., 2014; Ochoa and Gonzlez-Rojas, 2016) the goal is to allow a free-order configuration process where stakeholders can freely express their requirements. Other ones focus on proposing state-sharing mechanism to in-

30

crease stakeholders awareness and ensure global state consistency of distributed configuration. Finally, few approaches make a step forward to help stakeholders find a product that better meets their preferences by using recommendation techniques e.g. (Stein et al., 2014; Pereira, 2017).

This variety of approaches may indicate that collaborative configuration can

35

be carried out in different ways. Although quick overviews of collaborative con- figuration approaches are given in earlier papers, no extensive study has been re- ported so far for comparing collaborative configuration approaches within SPLE in a systematic way. We have little understanding of the different approaches, their salient characteristics and the differences between them.

40

The goal of this paper is to elaborate a classification framework to help understand existing approaches related to product line collaborative configura- tion through the identification of their current characteristics, shortcomings and challenges. To reach this overall goal, we defined three research questions:

• RQ1: What are the main characteristics of state-of-the-art approaches on

45

the field of collaborative product line configuration?

Rationale: By answering this RQ, we extract, classify and structure the characteristics of existing product line collaborative configuration approaches.

This helps researchers in better understanding the state-of-the-art and have a comprehensive overview of the research area.

50

• RQ2: What are the strengths and weaknesses revealed from the compar- ative analysis of the existing collaborative configuration approaches?

Rationale: by answering this RQ, we provide researchers with a strong

and effective means to position an existing approach or their own one with respect to other existing ones, and to identify strengths and weak-

55

nesses of one approach against other ones. Furthermore, the full analysis of existing state-of-the-art approaches allows researchers and practitioners to understand the difference between these approaches and to choose the one that meets their needs.

• RQ3: What are the major challenges of collaborative configuration in the

60

field of SPLE?

Rationale: by answering this RQ, we identify the open issues related to the area which helps researchers focus their future efforts in the challenging directions.

To deal with these research questions, a framework called PL2C capturing the

65

main characteristics of product line collaborative configuration approaches is elaborated. Some reports on comparative frameworks are published; e.g. to classify software product lines construction approaches (Ouali et al., 2011), to identify issues in scenario based approaches in requirements engineering (Rol- land et al., 1998), and to give a classification and a comprehensive overview of

70

collaboration approaches in e-learning (Al-Abri et al., 2017). The structure of the framework is inspired from these proposals. As for its enclosed information, it is obtained by carrying out a Systematic Mapping Study (SMS) according to the guidelines recommended by Peterson et al. (Petersen et al., 2015).

The rest of this paper is organized as follows: Section 2 gives a background of

75

product line collaborative configuration process. Section 3 presents the process followed in the systematic mapping study for PL2C framework elaboration.

Section 4 is devoted to the mapping study results, while Section 5 presents the framework proposed in this paper. Section 6 reports the framework-based analysis of the identified primary studies. Section 7 presents a description of the

80

identified challenges. Section 8 analyzes some comparative frameworks found

in literature and Section 9 discusses the threats to validity. Finally, Section 10

concludes the paper.

2. Background

Configuration of product line models can be achieved in many different ways.

85

Configuration can be progressive where the variability of the product line model is eliminated on several specialization steps (Czarnecki et al., 2005), or staged where the configuration is conducted in several stages in order to adhere to a change of constraints in each of these stages, such as the development cost per year(Rabiser et al., 2009; Hubaux. et al., 2010). Configuration can also be

90

carried in one shot where elements of the product line model, i.e. features, that meet the user’s requirements are simply selected in a single step from the prod- uct line model (Djebbi, 2011). The selection of features is quite straightforward when it relies on an individual interaction with product line model presented as tree-like structure where single user selects or deselects features (Junior et al.,

95

2011). However, it is observed that in real projects, product lines can contain up to 10,000 features (Batory et al., 2006). In such a case, the configuration process becomes an arduous task. Potentially, the larger the size of the feature model, the higher the number of constraints. These constraints define depen- dencies between features that should be carefully respected to efficiently derive

100

the desired product. Moreover, features have to be compatible with each other.

Otherwise, feature interaction issues could arise and affect the product, leading to unexpected behaviour. According to (Apel et al., 2013), the feature interac- tion occurs when a feature behaviour is influenced by the presence of another features. Feature interaction may be classified according to the order reflecting

105

the number of features involved in the interaction, and the visibility character- izing the interaction as external if the impact is visible by the user or internal if it is at system level. For a recent compilation on how feature interaction in SPLE is dealt with, the reader may refer to (Soares et al., 2018).

Therefore, handling the configuration process collaboratively is of major interest

110

to enhance configuration within SPLE. Collaboration is defined by (Roschelle

and Teasley, 1995) as “a coordinated, synchronous activity that is the result of

a continued attempt to construct and maintain a shared conception of a prob-

Conflict management Configuration role

assignment Configuration

1 2 3

Figure 1: Collaborative configuration process overview.

lem”. Similarly, within SPLE, collaborative configuration can be defined as a coordinated, synchronous activity where a set of stakeholders share the config-

115

uration activities based on their domain of expertise to decide about the set of features of the desired product. As highlighted in (Mendonca et al., 2008), a col- laborative configuration process consists mainly of three sub-processes, depicted in Fig. 1: role assignment, configuration and conflict management.

1. Configuration role assignment: it consists in specifying, for each stake-

120

holder, the aspect he/she supposed to configure. The assignment strategy is generally handled in clusters representing a particular functionality of the problem domain.

2. Configuration: it consists in selecting the features of the desired product by the involved stakeholders. Stakeholders can share the configuration

125

process according to the role assignment: they can either decide about the selection of the same set of features or each stakeholder decide about a specific set of features.

3. Conflict management: it can be carried out iteratively with the config- uration step as conflicts may occur during configuration and have to be

130

managed the time they happen. Another possible alternative is to manage conflicts at the end of the configuration after the stakeholders decide about desired characteristics. This still depends on the collaboration mode.

In the context of a collaborative configuration process, conflict management is of paramount importance. (Mendonca et al., 2007) indicate that, when config-

135

uring a FM, conflicts may occur when two or more features contain explicit or

implicit dependencies that make them rely on each other’s decision state. This

issue was also discussed by (Osman et al., 2009) who outlined the fact that a conflict occurs when two or more configuration decisions assigned to different configuration actors cannot be true at the same time. In practice, collaborative

140

configuration comes up with serious challenges including finding effective means to coordinate configuration tasks and make compromise between all stakehold- ers requirements in conflict situations. The coordination problem presents a critical issue when configuring FMs with large sizes and complex networks of constraints dependencies. Potentially, the higher the number of constraints,

145

the higher the effort required to put in place effective strategies for conflicts resolution is. Also, some technical issues can make collaborative configuration particularly challenging when involved people are distributed across different space and time dimensions. Therefore, aspects such as communication and group awareness become relevant in order to minimize decisions conflicts and

150

facilitate work coordination.

3. Review approach

In order to elaborate PL2C framework, we carried out a SMS with the iden- tified research questions. The purpose of a SMS is to investigate the literature on a field of particular interest to determine the nature, scope and number

155

of published primary studies (Petersen et al., 2008). It facilitates to obtain a broader view of wide and often poorly-defined research areas (Petersen et al., 2008) .

The PL2C framework elaboration process, depicted in Fig.2, consists of seven sub-processes: (1) manual search, (2) search terms and strings, (3) automated

160

search, (4) study selection, (5) categorizing papers, (6) framework construction, and (7) framework validation. The process was carried out with respect to (Petersen et al., 2015).

3.1. Manual search

Manual search sub-process consists in applying a snowballing process to a

165

start set of studies composed of papers describing the first different approaches

Exploratory search

Extend by related work

Quasi-gold-standard Retrieved

studies Evaluate Complement

Collect keywords

and concepts Cluster keywords

and concepts (6)Construct framework

(7) Validate framework with SPLE experts

(3) Conduct automated search

(5) Categorizing papers process (2) Define search terms and strings Research questions

Keywords and concepts

Search engines

Define inclusion and exclusion criteria Define quality assessment criteria

Retrieve documents (1) Manual search process

(4)Study selection process

Figure 2: PL2C framework elaboration process.

proposed by some known authors in the field, namely [S1, S3, S4, S11]. It was conducted in two steps: (i) exploratory search in which a forward snowballing was applied. An initial collection of 14 publications was obtained in this step af- ter following references and links to citing publications. (ii) extension by related

170

work in which a backward snowballing was applied on the initial collection of publications by scanning their references and picking out publications relevant to this study. This resulted in additional 8 publications [S9, S10, S20, S21, S22, S23, S25, S31]. In order to avoid redundancy, non-peer reviewed publications, such as technical reports, books and workshop descriptions were not included in

175

the set of retained studies. The results from manual search were used for estab- lishing a quasi-gold standard (QGS), which is a set of known studies representing the main contributions carried in the research domain (Zhang and Babar, 2009).

The QGS was then used to elicit the search strings for automated search.

3.2. Search terms and strings

180

To make sure that all works related to collaborative configuration of prod- uct lines were explored, we conducted an automated search based on terms and strings objectively elicited from the set of QGS. In the literature, search terms is a crucial step in the process of systematic mapping study. It consists on eliciting domain relative terms to retrieve relevant studies (Zhang and Babar, 2009).

185

We applied search terms process on the set of QGS to identify the most fre- quently occurring words or phrases in relation with collaborative configuration.

Search terms elicitation is done using text mining to statistically analyze the most frequently occurring words. To do so, we imported the title-abstract- keyword segment of each paper under QDA Miner and WordStat ¹ which are

190

analysis tools that can not only determine the most frequent terms but also reveal the underlying relationship among these terms. We chose the term fre- quency (TF) and inverse document frequency (IDF) using WordStat. The Jac- cards similarity coefficient allows to determine the terms importance by compar- ing the similarity and diversity of the imported segments of QGS. Fig. 3 shows

195

clusters of terms that were derived with high frequency and high Jaccard’s co- efficient. Colors represent the set of terms strongly linked to each other.

Generally, we can divide these terms into several groups which have a definite subject (c.f. Table 1). However, despite their low frequency, some words are closely related to collaborative configuration of product lines, e.g coordination,

200

resolution and detection. To expand the coverage of search results, we added these terms to the set of elicited terms as complement. Moreover, synonyms of the elicited terms, e.g. stakeholders and users, decision or decisions, model or models were considered in the final search strings. Finally, each group of terms defining the different subjects has been used to derive one or more of the

205

search strings presented in Table 2. In fact, the group of terms presenting the application domain has been considered in all the derived search strings, the second group of terms has been used to formulate the first search string (S1),

1

http://provalisresearch.com/products

Figure 3: Clustering result of high frequency terms.

the third group of terms to formulate the second search string (S2) and the last one, to formulate the third and the last search string (S3, S4).

210

Table 1: Group of terms.

Group Term Subject

1 Product line(s)/software product line(s), multi product line(s)

Application domain

2 Feature model(s), collaborative, configuration, derivation, business, process

Specific process

3 Stakeholders/users, multi Collaboration context

4 Approach, awareness, decision(s), support, conflicts Conflict resolution mechanism

3.3. Automated search

To conduct the automated search, a set of resources was selected among well known and most common digital libraries and scientific databases used in published SMSs according to (Petersen et al., 2015) guidelines namely, IEEE Xplore, ACM DL, Science Direct, Springer, Scopus and Web of science. The

215

Table 2: Derived search strings.

No Configuration process

Search String

S1

Process nature ((software product line

multiple product line)

(config- uration

derivation))

(collaborative process

col- laboration process

process collaboration).

S2

Multi user in- volvement

((software product line

multiple product line)

(config- uration

derivation))

(stakeholders

users

mul- tiple stakeholders

multiple users).

S3

Conflict resolu- tion

((software product line

multiple product line)

(con- figuration

derivation))

conflict detection

resolution of conflicts

detection of conflicts).

S4

Process coordi- nation

((software product line

multiple product line)

(con- figuration

derivation))

(coordination of decisions

decision coordination

supporting awareness

awareness support

support of awareness).

:

Table 3: Results of automated search.

Search engine Number of found papers

Total First round of papers selection

S1 S2 S3 S4

IEEE Xplore 29 10 0 1 40 14

ACM DL 41 15 23 9 88 14

Science Direct 5 5 0 3 13 3

Springer 15 10 4 8 37 5

Scopus 9 14 5 14 42 19

Web of Science 6 8 0 4 18 11

first author performed a search based on the derived search strings (c.f. Table 2) using search engines provided by these resources. Results were then checked by the second author.

After eliminating disagreement about considering or not some papers, results of automated search are recorded as depicted in Table 3. Column 2 gives the

220

number of studies returned for each search string. Column 3 shows the total

number of papers per search engine. Column 4 represents the number of retained

studies after eliminating the duplication per search engine.

3.4. Study selection

Study selection sub-process aims at identifying the most relevant studies to

225

product line collaborative configuration domain. Thus, the studies resulted from the automated search were subject to close scrutiny. Fig. 4 illustrates the study retrievement process of this SMS, which consists of four steps: At the first step, we collected 238 probable research. During the second step, duplicated papers per search engine and studies that do not address our research domain were

230

discarded. 66 out of 238 papers have been selected in this step. During the third step, studies were filtered according to identified inclusion and exclusion criteria presented in Table 4. The considered studies are those that were published between 2005 and 2018 (IC1). Actually, we collected papers from 2005 as the first approach in the field has been proposed by Czarnecki in 2005. Obviously,

235

any retained study had to have a clear focus on collaborative configuration of product lines, determined at this stage based on title, abstract and keywords (IC2). However, we note that when the criteria is not certainly satisfied, the research work was considered in order to not miss a relevant study. The final decision of its inclusion was postponed while assessing it against quality criteria.

240

Furthermore, papers that are not written in English (EC1) or duplicated from different databases (EC2) or non peer-reviewed (EC3) were excluded. As for extended studies, they were included as they may contain additional information characterizing the collaborative configuration of product lines.

At the last step, the set of papers retrieved from the previous one (50 papers)

245

was checked against quality assessment criteria presented in Table 5. For each quality question, three answers were assigned: “yes”, “partially”, and “no”.

Each study was checked against these criteria. If a study has “yes”as answer, then 1 is assigned to it, if it has “partially”, 0.5 is assigned to it, and a 0 is given to a study that received “no”as answer. Criterion Q1 ensures that the

250

paper deals with any subject related to collaborative configuration of product

lines and thus has a suitable context. On top of that, criterion Q2 ensures

that the paper potentially answers at least one of the research questions (e.g

papers presenting quick overviews, comparative analysis approaches). Criterion

Steps Activities No. of papers

Initially collected research studies

1 238

Elimination of duplicated papers per search engine and exclusion of papers not addressing the research domain

2 66

Filtering of studies according to identified inclusion and exclusion criteria

3 50

Checking against quality assessment criteria

4 41

Figure 4: Steps of document retrieval process.

Q3 demands that concrete collaborative configuration practices have been fully

255

or partly described. The combination of criteria Q2 and Q3 guarantees that works answering RQ1 actually propose collaborative configuration approaches or deal with one of collaborative configuration steps. Through criterion Q6, we include in our study extended works if they are presenting novelty compared to the original ones.

260

The quality assessment was carried by the first author by precisely studying the title, abstracts, and contents of each paper. Then, the obtained quality scores results have been reviewed by the other authors. To make sure of quality assessment findings reliability, only studies with a score equal or greater than 3 were included, which is half of the total points corresponding to the 6 quality

265

criteria. As result, 41 ² out of 238 research studies were selected as final retrieved studies to the research domain.

2

The result of the quality score for each selected study is available at: https://bit.ly/

31TfgE2 (Sheet 2)

Table 4: List of inclusion and exclusion criteria.

Inclusion criteria Exclusion criteria

IC1.

Research papers from 2005 to 2018

All research studies that are not written in English

IC2.

All research works focusing on col- laborative configuration of product lines based on the title, keywords and abstract of the papers

EC2.

Duplicate papers from different scientific databases: excluding multiple copies of the same study

EC3.

All papers which are not peer re- viewed (abstract, poster, proposal, tech- nical report, thesis)

Table 5: Quality assessment criteria.

Criteria Question

Q1

Does the study focus on collaborative configuration of SPLE domain?

Q2

Does the study include the potential answers to research questions?

Q3

Does the study refer to concrete collaborative configuration practices and not just deal broadly with it?

Q4

Is the objective of the study clear?

Q5

Does the study illustrate some collaborative configuration main characteristics

?

Q6

Does the study report original results that have not been published elsewhere?

In this SMS, data were extracted based on the RQs of this work. Each iden- tified study was carefully analyzed to obtain suitable information that can be

270

used to answer the defined RQ. The research studies that highlight information characterizing collaborative configuration of product lines were collected and carefully studied to answer RQ1. Then, the collected studies have been studied in depth to elicit concepts by following a systematic process called ”keywording”.

Details about this process are given in the next section. Afterward, the PL2C

275

framework has been built upon the extracted concepts. To answer RQ2, the

different collected primary studies have been analyzed through positioning in

the framework. RQ3 has been answered based on the research studies analysis,

where the challenges and current issues of the domain have been identified.

3.5. Categorizing papers

280

To efficiently elicit concepts related to PL2C framework, we followed a sys- tematic “keywording ”(Petersen et al., 2008) which is a concept study process that helps define classification framework so that it takes all the concepts of retrieved studies into account. This process has been adopted in several papers proposing classification frameworks such as (Franzago et al., 2018). Generally,

285

during this process, studies are screened in order to retrieve an overview of the area; in particular, frequently discussed challenges, commonly used classifica- tions and important keywords. As shown in Fig. 2, the keywording process consists of two steps:

1. Collect keywords and concepts: keywords and concepts have been identi-

290

fied by reading each primary study with a special core to sections contain- ing terms identified during the search terms process. When all primary studies have been analyzed, all keywords and concepts were combined to clearly identify the context, nature, and contribution of the research. This step output is the set of concepts deduced from the primary studies.

295

2. Cluster keywords and concepts: once keywords and concepts extracted, a clustering operation has been performed on them in order to have a set of representative clusters of keywords. We identified the clusters accord- ing to four dimensions: collaboration, purpose, process and tool. These dimensions were chosen as they cover the set of needed information to

300

characterize collaborative configuration within SPLE. Each dimension is further characterized by facets that help understanding and classifying different aspects of collaborative configuration. Faceted classification is based on defining attribute classes that can be instantiated with different terms, as initially proposed by (Prieto-Diaz and Freeman, 1987) to classify

305

reusable components. Therefore, each cluster represents one of the facets

under a specific dimension of our classification. After the clusterization

step, keywords and concepts within a cluster were structured in terms of

facets and attributes.

3.6. Framework construction

310

The structuring of PL2C framework was performed by two authors, and the results were double-checked by the two others. The output of this sub-process is the finalized classification framework containing all the concepts that were iden- tified earlier and criteria categorized into dimensions and facets representing a specific aspect of collaborative configuration of product lines. Several itera-

315

tions over intermediate versions of PL2C framework were required to provide a framework that is as well-defined and as comprehensive as possible. During each iteration, PL2C framework was reviewed by two of the authors who have more than ten years of experience on SPLE, and each disagreement was discussed and resolved. At the end of PL2C framework construction process only sufficiently

320

discriminating concerns and criteria were kept.

3.7. Framework validation

The validation of the PL2C framework is assessed in two steps. 1) Con- duction of systematic mapping study to collect information characterizing the collaborative configuration in SPLE domain. The set of keywords and concepts

325

extracted from primary studies have been used to construct the framework and evidence his completeness. 2) Classification of all found primary studies using the framework to illustrate its usefulness. During this step, the first author of this paper read the full text of each paper and extracted its data according to the classification framework with the support of the other co-authors. Details

330

of the full analysis are given in Section 6.

4. Mapping results

As aforementioned, 41 ³ research papers were selected as primary studies to be within the scope of this work. Fig. 5 shows that 10 research papers among the primary studies were published in journals; 29 research papers were presented

335

3

The list of included studies is available at: http://bit.ly/30vmtsh (Sheet 1)

in conferences and 2 research papers were presented in workshops. Studies are summarized according to their venues and the research step in which they were collected in Table 6. We notice that around one third of conference papers was published in SPLC which is specialized on SPLE domain.

Figure 5: Primary studies categorized by venue type.

340

Furthermore, Fig. 6 gives more details by presenting the publication years and types of the primary studies. As depicted in the histogram, the number of publications has increased from 2010 and almost 50% of papers were published between 2010 and 2013. We notice that 2010 had the highest number of pub- lished papers. In fact, from the first proposed approach in the field (2005) to

345

2007 only one paper per year was published. For the two years 2008 and 2009 two papers per year were published. The following years starting from 2010 wit- nessed the growth of interest in collaborative configuration within SPLE which can be deduced through the publications number.

Fig. 7 depicts a map of publications over our defined classification criteria. The

350

size of each bubble represents the number of publications in the corresponding

category pair. Research focus is shown on the Y axis, contribution type is shown

on the right X axis, and research type is shown on the left X axis.

Table 6: Primary studies venues and identification step.

Venue Manual

search

Automated

search Total List of conferences

International Symposium on Object-Oriented Programming S2 1

Systems, Languages and Application (OOPSLA )

Hawaii International Conference on System Sciences (HICSS) S3 1

ACM Symposium on Applied Computing (SAC) S4 S36 2

IEEE International Conference on Requirements Engineering (RE) S6 1

International Conference on Industrial Engineering and S7 1

Engineering Management (IEEM)

International Conference on Systems and Software Product S9, S10, S14, S18, S33, S35 9

Line (SPLC) S16, S20, S27

International Conference on Requirements Engineering: S11 S26 2

Foundation for Software Quality (REFSQ)

International Workshop on Automated Configuration and S12 1

Tailoring of Application (ACoTA)

International Conference on Information Management and S13 1

Engineering (ICIME)

International Conference on Automated Software Engineering (ASE) S15 1

IberoAmerican Conference on Software Engineering (CIBSE) S17 1

International Workshop on Variability Modelling of Software- S19 1

intensive Systems (VAMOS)

Asia Pacific Conference on Software Engineering (APSEC) S21, S22 2

IEEE International Conference on Services Computing (SCC) S23 1

International Conference on Software Engineering and S29 1

Knowledge Engineering (SEKE)

International Conference on Software Engineering (ICSE) S38 S30, S39 3 International Conference on Software Language Engineering (SLE) S32 1

International Workshop on the Move to Meaningful Internet S37 1

Systems (OTM)

Software Process: Improvement and Practice S1 1

Journal of Software (JSW) S5 1

Science of Computer Programming journal S8 1

Journal of China Universities of Posts and Telecommunication (JCUPT) S24 1

Software and Systems Modeling journal (SoSyM) S25 1

Requirements Engineering journal S28 1

Information and Software Technology journal (IST) S31 1

Computer and Industrial Engineering journal (CAIE) S34 1

Journal of Systems and Software (JSS) S40 1

Journal of Computer Languages, Systems and Structures S41 1

Total of papers

22 19 41

0 1 2 3 4 5 6 7

2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

Workshop paper

2

5 3

2 2

1 1

Conference paper

1 1 1

Journal paper

4

3 1

3 1

1

1

2

1

1 1

1

1 1

Figure 6: Primary studies distribution per year and publication types.

For the research type, we adopted the classification approach described by (Wieringa et al., 2006). This classification has been also used by (Petersen

355

et al., 2008). Research type is categorized as follows:

- Experience papers: papers explaining what and how something has been done in practice. It has to be the personal experience of the author.

- Philosophical papers: papers sketching a new way of looking at existing things by structuring the field in form of a taxonomy or conceptual framework.

360

- Validation research: papers investigating novel techniques that have not yet been implemented in practice. Techniques used are for example experiments, i.e., work done in the lab.

- Solution proposal: papers proposing solution for a problem. The solution can be either novel or a significant extension of an existing technique. The potential

365

benefits and the applicability of the solution is shown by a small example or a good line of argumentation.

- Evaluation research: papers presenting implementation of practical techniques along with their evaluation. That means it is shown how the technique is imple- mented in practice (solution implementation) and what are the consequences of

370

the implementation in terms of benefits and drawbacks (implementation evalu- ation). This also includes to identify problems in industry.

Research focus is classified into four main categories: (1) Requirements satisfac-

tion: approaches considering the satisfaction of stakeholders’ requirements. (2) Process flexibility: approaches proposing a mechanisms that are used to ensure

375

the flexibility of collaborative configuration process. (3) Activities coordination:

approaches that are used for coordinating configuration activities. (4) Conflict management: strategies used for the purpose of resolving conflicts in the col- laborative configuration approaches.

Finally, contribution type comprises four main categories: (1) Method: descrip-

380

tion of how to carry out a specific step of collaborative configuration (conflict resolution for instance). (2) Process: research that deals with the collaborative configuration process. (3) Tool: any tool designed to support collaborative con- figuration. (4) Metrics: metrics that are used for the purposes of configuration activities assignment, configuration, conflict resolution or satisfaction measure-

385

ment.

Some articles involve more than one contribution type. For example, (Junior et al., 2011) involves both method and tool contribution types and hence is con- sidered in each one of them. However, each paper is classified under only one research type: the one to which we feel the study belongs the most. With re-

Figure 7: Bubble chart map of research focus over research and contribution types.

390

gard to research type, the majority of the articles are of the evaluation research

type (43.9%) and solution proposal (43.9%) compared with the small number

of studies that were philosophical (7.3%), experience articles (2.4%) and valida- tion research (2.4%). A large majority of papers (75.6%) were about methods (46.3%) and processes (29.3%), and only 1/4 of studies is about metrics (17.1%)

395

and tools (7.3%). Activities coordination (50%) was the largest research focus area, followed by requirements satisfaction (29.5%).

A very small number of the studies focused on conflict management (11.4%), and process flexibility (9.1%), with a combined total of 20.5%.

Overall, the proposal and evaluation of activities coordination methods and

400

processes currently dominate the body of the literature on collaborative config- uration of product lines.

The different research focus have been studied in depth and considered in our framework elaboration, this is discussed in more detail in the following section.

5. The PL2C framework

405

The main objective of this paper is the elaboration of framework to pro- vide a generic and conceptual artifact containing knowledge about collaborative configuration within SPLE domain. This framework will provide support for classifying and analyzing existing and future approaches that address product line collaborative configuration. This should help researchers and practitioners

410

in better scoping their own contributions or understanding existing ones.

To elaborate this framework, we defined the three research questions highlighted at the beginning of the paper which are:

• RQ1: What are the main characteristics of state-of-the-art approaches on the field of collaborative product line configuration? PL2C framework

415

is composed of four dimensions as illustrated in Fig. 8. Features ex- tracted from the retrieved primary studies have been clustered accord- ing to these dimensions. We have chosen these dimensions as they cover the set of needed information to characterize collaborative configuration within SPLE. The four dimensions are:

420

– Purpose dimension: This dimension discusses the “why”angle of the collaborative configuration approach. In other words, it explains the objectives of collaborative configuration approaches.

– Collaboration dimension: This dimension discusses the “what”aspect in the framework. Defining what is collaboration in product line con-

425

figuration and what it is all about (e.g. collaboration mode, interac- tion and collaboration level).

– Process dimension: This dimension discusses how the configuration process is carried out.

– Tool dimension: A tool, or a combination of tools, is considered to

430

be the instrument which is necessary to complete the purpose of the task based on the method applied.

Dimensions are characterized by sets of facets that help understand and classify different aspects of collaborative configuration. As pointed in (Al-Abri et al., 2017), faceted classification is based on defining attribute

435

classes that can be instantiated with different terms. Facets are considered as viewpoints suitable to characterize configuration approach through a set of relevant attributes. These attributes are described by a set of values for measuring and positioning the observed aspect based on the extracted data. Some facets may depend on other facets belonging to the same

440

dimension across values that an attribute may have.

• RQ2: What are the strengths and weaknesses revealed from the compara- tive analysis of the existing collaborative configuration approaches? As dimensions are defined with multiple facets, the characteristics of each approach, including strengths and weaknesses can be identified through

445

the positioning of existing approaches in the framework.

• RQ3: What are the major challenges of collaborative configuration in the

field of SPLE? Likewise, shortcomings and challenges can be identified

through the positioning analysis of the different approaches.

Figure 8: PL2C framework for collaborative configuration approaches in SPLE.

5.1. Purpose dimension

450

Purposes can be discussed based on varied facets (c.f. Fig. 9) which are classified according to the role the collaborative configuration aims to play.

Purpose

dimension -User group: BOOLEAN

-Product manager & domain –experts: BOOLEAN -Domain- expert group: BOOLEAN

Collaboration scenario facet

Stakeholder

satisfaction facet -Satisfaction measurement: BOOLEAN -Method: (ENUM {Available, Not available}) Principle facet -Decision making: (ENUM {Shared decision,

Individual decision, Mix})

Figure 9: Purpose dimension overview.

5.1.1. Principle facet

The studied approaches show that decision making during configuration can be: either shared between two or more stakeholders (Mendonca et al., 2008)

455

where the selection of feature is decided by more than one stakeholder, or each

set of decisions is assigned to a single stakeholder according to his/her expertise

(Czarnecki et al., 2005; Mendonca et al., 2007, 2008; Hubaux. et al., 2010). The

principle facet is presented with a decision-making attribute as follows:

Decision making: ENUM {Shared decision, Individual decision, Mix}.

460

5.1.2. Collaboration scenario facet

Collaborative configuration can be carried out in different scenarios accord- ing to the involved team category (end users and/or domain experts). In fact, a collaborative configuration approach can be designed to allow a group of users collaboratively expressing their requirements towards a desired product (e.g. a

465

group of friends want to buy a tablet (Stein et al., 2014)). Moreover, a collabo- rative configuration approach can be designed to be adopted in a real industrial project (e.g. car manufacturing) where configuration process is carried out by a group of domain-experts. The different scenarios are presented as following:

• User group: The collaborative configuration approach is designed to allow

470

end users who do not have a background in SPLE domain (not expert) in expressing their requirements towards the desired product such as the approach proposed by (Dou et al., 2016).

• Product manager and domain-experts: collaborative configuration may be shared between a product manager who decides about product features

475

at a high-level and domain-experts who decide about product features at a technical level, as it is the case in industrial context (Mendonca et al., 2008).

• Domain-expert group: in this collaboration scenario, there is no role hier- archy, where configuration activities are fairly shared between stakeholders

480

according to expertise level as it is the case in the approach proposed by (Czarnecki et al., 2005).

In some cases, we can find approaches that are designed to support both user group and domain-expert group where end users express their requirements and domain-experts consider these choices in configuring the desired product (e.g.

485

(Bingliang et al., 2010)).

The different collaboration scenarios presented above are captured by the follow- ing three Boolean attributes: User group, Product manager and domain-experts, and Domain-expert group.

5.1.3. Stakeholder satisfaction facet

490

Stakeholder satisfaction is of paramount importance when collaboratively configuring a product within SPLE. It can be ensured by considering prefer- ences of stakeholders in deriving the desired product. Therefore, preferences have been differently considered in the existing collaborative configuration ap- proaches. For example, preferences can be expressed in terms of hard and soft

495

requirements as proposed by (Bagheri et al., 2010) , or in terms of functional and non-functional requirements as proposed by (Soltani et al., 2012) . Satisfaction can also be ensured during conflict resolution by finding the good compromise between the different requirements of stakeholders as proposed by (Stein et al., 2014; Ochoa et al., 2015).

500

The satisfaction measurement is captured by the Boolean Satisfaction measure- ment attribute, and by the Method attribute:

Method: ENUM {Available, Not available}.

5.2. Collaboration dimension

This dimension discusses the “what”aspect in the framework. Defining what

505

is collaboration in product line configuration and what it is all about (e.g. collab- oration mode, interaction and collaboration level). An overview of collaboration facets is depicted in Fig. 10.

5.2.1. Collaboration level facet

According to the studied approaches, collaboration can be present at two

510

different moments: (1) during configuration, where stakeholders actively share the configuration activities (Mendonca et al., 2008). They can either decide about the selection of the same set of features or each stakeholder decide about a specific set of features according to role assignment process. (2) during decision- support, where collaboration-based recommendation techniques (i.e., collabora-

515

Collaboration

dimension Collaboration

mode facet

- Space: (ENUM {Synchronous, Asynchronous}) - Time: (ENUM {Distributed, Collocated}) Collaboration

level facet - Type: ENUM {During configuration, During decision-support, Mix}

Interaction facet

- Mode: SET (ENUM {Direct communication, State-sharing})

Figure 10: Collaboration dimension overview.

tive filtering (Schafer et al., 2007)) are used to guide stakeholders in making the good configuration decision by recommending features for example (Pereira, 2017). It is possible that a configuration approach encompasses the two col- laboration levels such as (Mendonca et al., 2008; Junior et al., 2011). The collaboration level facet is characterized with a type attribute as follows:

520

Type: ENUM {During configuration, During decision-support, Mix}.

5.2.2. Collaboration Mode facet

Collaboration requires a collaboration space as an environment to facilitate the collaborative process. The characteristics and nature of this space depend on the form of collaboration. There are two forms of collaboration based on the

525

space: (1) collocated that occurs in the same place as the case in the approaches proposed by (Mendonca et al., 2007; Stein et al., 2014) and (2) distributed that occurs in different places. Several approaches proposed different methods to improve awareness and ensure global consistency when the configuration is ge- ographically distributed such as (Junior et al., 2011; Holl et al., 2012). There

530

are also two forms of collaboration based on the time. It can be either carried out in real time (synchronous) where stakeholders configure the product at the same time (e.g. (Bingliang et al., 2010)) or in different times (asynchronous) (e.g. (Hubaux. et al., 2010)) where the configuration states are communicated to ensure global consistency (Al-Abri et al., 2017; Camarinha-Matos and Afsar-

535

manesh, 2008).

Time: ENUM {Synchronous, Asynchronous}.

Space: ENUM {Distributed, Collocated}.

5.2.3. Interaction facet

During the configuration process, interaction is mainly required between

540

stakeholders. Stakeholders share configuration information to improve aware- ness and ensure global state coherence during configuration. Awareness im- provement has been mainly addressed in the context of Multi Product Line configuration where some approaches such as (Rabiser et al., 2010b; Holl et al., 2012) proposed a shared repository that allows stakeholders to share their de-

545

cisions in order to be aware about the decisions of other stakeholders. In some cases, stakeholders also need to communicate when a conflict arises (Mendonca et al., 2008). The interaction can be ensured with different means as character- ized with the following attribute:

Mode: SET (ENUM { Direct communication, State-sharing }).

550

5.3. Process dimension

This dimension discusses how the configuration process is carried out. It addresses seven facets as depicted in Fig. 11: configuration type, level, flexibility, guidance, role assignment, conflict management and decision-support.

5.3.1. Configuration type facet

555

In the studied approaches, different configuration types have been outlined:

the partial configuration, the total configuration and the staged one. In par- tial configuration, each stakeholder configures a part of the product such as in (Mendonca et al., 2008). In total configuration, each stakeholder configures the whole product then the different configurations are checked and merged accord-

560

ing to stakeholders’ requirements (Stein et al., 2014). In staged configuration,

as pointed by (Czarnecki et al., 2005), the configuration is refined from stage

to another through a set of specializations progressively applied on the feature

model. The configuration type facet is characterized with a Type attribute as

Figure 11: Process dimension overview.

follows:

565

Type: ENUM {partial, total, staged}.

5.3.2. Requirement-based facet

The configuration process can mainly be carried out at two different levels:

the intentional and the operational level. At the intentional level, stakeholders express their requirements regarding the desired product without being con-

570

strained to a model structure (e.g. feature model). At the intentional level, the configuration is non-model based. One of the first works proposing a non- model based configuration is (Djebbi and Salinesi, 2007) where stakeholders’

requirements are matched with product line requirements to derive a consistent configuration with respect to stakeholders’ priorities and company’s constraints.

575

Different collaborative configuration approaches have adopted the non-model

based configuration principle such as (Chen et al., 2009; Dou et al., 2016). As

for the operational level, the configuration is model-based where requirements are mapped with the corresponding FM to see which features meet them. At this level, requirements are translated and directly considered as decisions of

580

selecting/deselecting features from the FM. Most of the proposals found in the literature such as (Mendonca et al., 2007, 2008; Rabiser et al., 2009; Hubaux.

et al., 2010; Junior et al., 2011; Holl et al., 2012; Stein et al., 2014; Pereira, 2017) have proposed model-based configuration approach.

The requirement-based facet is characterized with a Type attribute as follows:

585

Type: (ENUM {Non-model based, Model-based}).

5.3.3. Selection order facet

Flexibility is widely recognized as one of the most important dimensions of a successful manufacturing strategy. As pointed by (de Groote, 1994) “A particular technology is said to be more flexible than another if an increase in

590

the diversity of the environment yields a more desirable change in performance (i.e. higher increase or lower decrease) than the change that would obtain with the other technology under the same conditions”. In a flexible configuration process (e.g. (Junior et al., 2011; Stein et al., 2014)), stakeholders can freely express their requirements without being constrained to prior decisions when

595

making new choices. When the configuration relies on pre-designed process with a predefined order (e.g. (Mendonca et al., 2007, 2008)), decisions made by some stakeholders constrain posterior ones made by other stakeholders. In such a case, backtracking may be occasionally required to cope with constrained decisions, which makes it difficult to reach a valid configuration agreed by all

600

stakeholders.

Selection order: ENUM {Free order, Predefined order}.

5.3.4. Guidance facet

The configuration process can be guided differently depending on the product line model, and on the requirements of the stakeholders. Usually, configuration

605

is driven by the feature model as it is broken down into different insulated

modules (also called views) and each stakeholder deals with the configuration of a module based on his/her expertise domain while respecting the domain constraints (Hubaux. et al., 2010). In some cases, the configuration can also be driven by a process model describing the configuration process that means

610

role assignment, configuration order, priority schema (Mendonca et al., 2007).

Moreover, configuration processes can be driven by stakeholder requirements independently of the FM hierarchy by scheduling the different configuration activities according to the importance of requirements. The guidance facet is characterized by the guidance attribute defined as follows:

615

Guidance: SET (ENUM {Feature model, Process model, User requirements}).

5.3.5. Role assignment facet

The assignment process takes into consideration two criteria: authority and knowledge of the domain (Czarnecki et al., 2005; Mendonca et al., 2008). Thus, the leader of the process (e.g. the product manager) configures the product at

620

high-level then other roles are assigned according to the expertise of stakeholders (Mendonca et al., 2007). A random assignment is also possible in some cases (Stein et al., 2014), according to the nature of persons involved (e.g. an academic prototype tested by a group of students, or a commercial online configuration tool used by a group of customers). The Role assignment facet is characterized

625

by an attribute called Role:

Role: ENUM {Expertise-based, Authority-based, Random}.

5.3.6. Conflict Management facet

Conflict can arise in any situation involving more than one person. During collaborative configuration, causes of conflict range from heterogeneous require-

630

ments to divergent points of view regarding how the desired product should be.

According to (Roschelle and Teasley, 1995), an agreed definition of conflict is that it results from a situation where two or more decisions cannot be taken into account at the same time during the ongoing decision-making process.

During collaborative configuration, conflicts are managed through different res-

635

olution methods and policies. The conflict management facet gives an under- standing on how the resolution process is carried out. It addresses the following attributes: Preference-based, Decidability, Resolution method and Resolution policies.

A conflict resolution strategy cannot be considered effective if it does not take

640

into account preferences of the different stakeholders and try to find a com- promise between the most of them (Stein et al., 2014). Moreover, resolution strategy should also be decidable in the sense that it must guarantee a finite state where conflicts are always resolved (Ochoa et al., 2015). The nature of resolution strategy is characterized through the following attributes:

645

Preference-based: BOOLEAN.

Decidability: BOOLEAN.

Different resolution methods have been proposed for collaborative configura- tion of product lines. Some works such as (Chen et al., 2009) resolve conflicts by inviting stakeholders to negotiate. Some workflow-based approaches such as

650

(Mendonca et al., 2008) proposed a merging sessions method to resolve decision conflicts. During the merge, domain-experts in charge of related configuration decisions reason about potential solutions to the conflict. The merge is required if two or more parallel interdependent configuration sessions contain decisions that together violate global configuration constraints. Otherwise, conflicts are

655

resolved by giving the priority to the feature placed first in the configuration workflow. Other works such in (Mendonca et al., 2007), propose a predefined priority scheme where conflicts are resolved according to stakeholders role im- portance or decision importance. Moreover, we find other resolution methods where a set of correction values called Range Fixes are either directly suggested

660

to stakeholders (Rabiser et al., 2009; Xiong et al., 2012) or recommended using a personal assistant metaphor (Junior et al., 2011).

Some other approaches were interested in increasing stakeholders satisfaction by proposing preference-based conflict resolution methods. In these methods, preferences are considered in different manners. (1)expressed through soft and

665

hard constraints (Stein et al., 2014), during the resolution, hard constraints are

mitigated by assigning preference degrees and maintaining the decision with the highest degree of preference expressed, (2) by using language-based criteria to consider stakeholders preferences expressed in terms of non-functional proper- ties (Ochoa et al., 2015).

670

The different collaborative resolution methods presented above are captured by a set of values characterizing the resolution method as follows:

Resolution method: SET (ENUM {Negotiation, Predefined priority schemes, Merging sessions, Range fixes, Personal assistant metaphor, Mitigating hard constraint, Language-based criteria resolution}).

675

These resolution methods can be executed according to different policies: (1) conflicts are manually resolved where stakeholders are involved in the resolution process either by revising their requirements or by expressing their preferences towards the conflicting ones, (2) conflicts are automatically resolved considering a set of criteria such as stakeholders role importance and requirements impor-

680

tance. In some cases, it is possible to combine both policies where stakeholders express their preferences toward conflicting requirements, then a preference- based resolution process is automatically launched.

The resolution policies is characterized with the following attribute:

Resolution policies: ENUM {Automatic, Manual, Mix}.

685

5.3.7. Decision-support facet

When configuring large feature models, guidance can be useful to support users in decision-making at different levels. Guidance can be ensured by different methods. For example, (Junior et al., 2011) propose an assisted user-guidance method provided by software agents to guide users during configuration pro-

690

cess. Moreover, recommendation techniques also represent an effective guid- ance mean: either during configuration, where features can be recommended to help stakeholders meeting their requirements (Pereira, 2017), or during conflict situations, where alternative feature-selection scenarios can be recommended to stakeholders to guide them in conflict resolution (Xiong et al., 2012). The

695

Decision-support facet is characterized by the following attributes:

Recommendation: BOOLEAN.

Guidance: BOOLEAN.

Support- level: ENUM {During configuration, During conflict, mix, not avail- able}.

700

5.4. Tool dimension

The final view in PL2C framework is the tool dimension (c.f. Fig. 12).

A tool, or a combination of tools, is considered to be the instrument which is necessary to complete the purpose of the task based on the method applied.

According to the studied approaches, some proposals are not supported by a

705

configuration tool (Czarnecki et al., 2005; Mendonca et al., 2007). Some others propose a tool that supports a step of the collaborative configuration (e.g. a tool for FM decomposition and role assignment (Mendonca et al., 2008)). Actually, the most of the developed tools mainly support the configuration step (Holl et al., 2012; Soltani et al., 2012). Some tools are still in experimentation level

710

(Junior et al., 2011; Stein et al., 2014), other ones are validated within industrial case studies and already deployed in some companies (Hubaux. et al., 2010;

Rabiser et al., 2010b).

The Tooling facet is characterized with the three following attributes:

Tool Support: BOOLEAN.

715

Coverage: SET (ENUM {Role assignment, Configuration, Conflict resolution, All steps, Not available}).

Version: ENUM {Experimental, Industrial}.

Tooling facet

-Tool Support: BOOLEAN

-Coverage: SET (ENUM {Role assignment, Configuration, Conflict resolution, All steps, Not available})

-Version: ENUM {Experimental, Industrial}

Tool dimension

Figure 12: Tool dimension overview.

6. Approaches analysis

According to framework-based positioning of the 41 retrieved studies ⁴ , works

720

can be categorized as follows:

• Studies proposing collaborative approaches that rely on a predefined pro- cess in which configuration tasks are coordinated and assigned to expert group where each of them is in charge of configuring a specific module (called view in some papers) of the feature model, such as [S1, S2, S3, S4,

725

S5, S6, S8, S11, S14, S20, S25, S40]. Some of these approaches [S4, S5, S8] permit sharing configuration decision making where a module can be configured by a team and not by only one expert.

• Studies proposing flexible collaborative approaches where configuration is carried out in a free order process without imposing a selection order on

730

stakeholders [S17, S26, S27, S32, S33, S34, S35, S37].

• Studies proposing collaborative approaches that do not provide explicit information about all the collaborative aspects and the selection order during the configuration [S7, S9, S10, S12, S13, S15, S16, S18, S19, S21, S22, S23, S24, S28, S29, S30, S31, S36 ]. However, each group of these

735

studies has a specific focus on one of the main characteristics of collabo- rative configuration. For example, [S12, S16, S19, S21, S22, S31 ] propose methods to ensure configuration consistency and increase awareness dur- ing configuration of multi product lines. As for [S7, S9, S10, S13, S15, S18, S23, S24, S28, S29, S30, S36], they propose various solutions permit-

740

ting the consideration of all stakeholders individual configurations while deriving a valid configuration that better consider their functional and non-functional requirements.

• Studies considering collaboration at a decision support level [S38, S39, S41]

where collaborative-based techniques are used to guide users in selecting

745

4

The full analysis is available at: https://bit.ly/31TfgE2 (Sheet 3)

features during configuration process. Here, the collaborative aspect is approached differently as it consists in learning about relevant features from other users’ configurations.

Moreover, according to the reported analysis, it was noticeable that only 14 studies among 41 consider the satisfaction of stakeholders in the different solu-

750

tions they propose [S9, S10, S13, S15, S18, S23, S24, S27, S28, S29, S32, S34, S36, S37]. These studies aim at improving the satisfaction of stakeholders in two different manners: (1) by taking into account the preferences of stakehold- ers during the configuration step. In other words, they consider their functional and non-functional requirements in the final derived configuration [S9, S10, S13,

755

S15, S18, S23, S24, S28, S29, S34, S36]. (2) by increasing the stakeholders’ sat- isfaction through preference-based strategies for conflict resolution [S27, S32, S37]. However, most of the other 27 studies do not provide information about conflict management, except [S2, S3, S4, S5, S7, S8, S11, S17, S22, S26] that propose resolution strategies without dealing with stakeholders’ preferences.

760

In terms of main results, the focus was generally on analyzing stakeholder’ re- quirements to derive consistent configuration, or on ensuring coordination dur- ing the configuration process. The collaboration was more aligned with the two first steps of the collaborative configuration process (role assignment, configu- ration) than the conflict management (e.g. resolution method or policy).

765

7. Challenges

According to the full analysis of the 41 retrieved studies, three challenges can be highlighted:

1. Configuration process coordination: the coordination represents one of the main challenges of collaborative configuration. The coordination issue can

770

be addressed in two different ways: (1) by following a pre-designed config-

uration process specifying the role and the intervention time of each stake-

holder. However, such a method constraint decisions of some stakeholders,

hence it limits the configuration process flexibility. (2) by allowing free