A Multicriteria Approach to Support Task Allocation in Projects of Distributed Software Development

Organizations are increasingly investing in Distributed Software Development (DSD) over the years. A typical decision-making problem in the distributed scenario consists of deciding which team should be allocated each task. That decision takes into account a relative degree of subjectivity. That setting is suitable for applying Verbal Decision Analysis (VDA). This paper introduces an approach to support the allocation of tasks to distributed units in DSD projects, structured on the hybridisation of methods of Verbal Decision Analysis for classification and rank ordering applied to influencing factors and executing units. Firstly, a review of the literature was conducted aiming to identify the approaches to support the allocation of tasks in DSD contexts. Then, an approachwasdevelopedbyapplyingVDA-basedmethodsforclassificationandordering.Bibliographicresearchandtheapplication ofsurveyswithprofessionalsallowedidentifyingandcharacterisingthemainelementsthatinfluencetaskassignmentinDSD projects.Afterwards,experienceswerecarriedoutinfivereal-worldcompanies.Intheend,theproposedapproachhasbeen submittedtotheevaluationbytheprofessionalsoftheparticipatingcompaniesandbysomeprojectmanagementexperts.The proposedapproachcomprisesaworkflowcontainingresponsibleactorsanddescriptionsoftheactivities.Automatedtoolsare alsoemployedinautomatingtheimplementationoftheapproach.Afterapplyingtheapproachinfivecompanies,taskassignment recommendationsarepresentedingroupsforeachcompany,accordingtothetasktype,i.e.,requirements,architecture,coding, andtesting,rangingfromthemosttotheleastpreferableoffice.Resultsoftheexperiencesandevaluationsheldduringthiswork presentevidencethattheproposedapproachisflexible,adaptable,andeasytounderstandandtouse.Moreover,ithelpstoreduce decisionsubjectivityandtothinkofnewaspects,supportingthetaskallocationprocessinDSD.


Introduction
Software development can be structured in several activities, such as requirements, design, architecture, and programming.Companies that have a mature and organized development process can direct activities to be developed in different locations, taking advantage of the skills of local teams.
A typical decision-making problem in the distributed scenario consists of deciding which team should be allocated each task.The specific literature mentions some methodologies and models that address the decision problem on the division of tasks in distributed projects using diverse strategies.Some approaches consist of simple tools whereas others consist of complex systems.Some solutions define simple procedures while others comprise whole processes.The granularity of the object to be allocated also varied widely, from single tasks to full stages (sets of tasks).
However, few models use multicriteria approaches and, when they do, they usually focus on quantitative or numerical aspects, often requiring a heavy mathematical framework.Furthermore, only a small set of criteria was usually used to decide on the allocation of tasks, especially the job costs.Team skills and experience, and cultural issues, among other relevant factors, have been often neglected [1].In practice, what happens is that, most times, the professional responsible for the project takes into account only their experience and

Task Allocation in Distributed Software Development.
Organizing tasks is one of the main assignments of a project manager.He or she is responsible for determining which tasks are essential to the completion of each step of the process and for allocating those tasks to the team members of different backgrounds and experience.Workload, expertise, maturity, and profile of each team member are criteria commonly taken into account in the task allocation process.
In this research, we adopt the PMBOK (Body of Knowledge in Project Management [4]) definition of "task", which is a responsibility that can be allocated within the project management plan in such a way that the designated resource is subject to the obligation to perform the task requirements.PMBOK also defines task assignment in software development as an activity that settles the way in which the tasks will be carried out and how and which professionals will be assigned the tasks, considering the imposed restrictions [4].These tasks set out what should be done to achieve not only the project goals but also the organization's objectives [5].
When we identify tasks in distributed projects, we usually think of the constraints, whether technical, social, or professional, related to assigning tasks to distributed groups.In other words, the task allocation planning should consider people's characteristics (such as personal skills, for example) as well as the characteristics of relationships among distributed teams (such as cultural differences and communication issues).In addition, the characteristics of the project or the product to be developed, such as complexity, dependencies, and abilities necessary for its development, cannot be ignored.[1].
The task allocation is a crucial step for project management, mainly if it is a distributed project.The allocation of tasks to distributed teams should simultaneously match the right task with the right team in the correct order while defining the way to carry out the tasks.Moreover, assuming that every project deals with limited resources, such as people and time, to accurately plan, project managers must take into account (a) the attributes of the teams, (b) the features of the products that will be build, (c) the properties of the tasks and the relationships between them, and, finally, (d) the organization's objectives [5].Thus, it is critical to map the main aspects that influence the assignment of tasks in distributed projects.We will call such aspects "influencing factors", and we will deal with them later.

Verbal Decision Analysis.
Decision-making is an everyday activity in people's and companies' lives.To make an assertive decision, we evaluate a problem by judging a set of characteristics or attributes; i.e., our analysis addresses many factors, which we call criteria.Decisions can have a considerable impact on the business context, as choosing the wrong alternative can lead to loss of time, money, and resources, causing detrimental effects for the company.Such management decisions usually take into account several factors.For these cases, it is advisable to adopt methodologies to support the decision-making process.
The decision-making process involving the analysis of alternatives from various points of view is called multicriteria decision analysis.There are many methodologies that support multicriteria decision analysis [6].Such methodologies help to increase the confidence of the decision-maker as they promote the generation of knowledge about the decisionmaking context [7].
There are many studies describing the application of VDA methods in real-world problems.Some of them are provided next.Machado et al. [12] used VDA to help the selection of specific CMMI practices.Mendes et al. [13] and Tamanini et al. [14] applied VDA in digital TV scenario.Machado [15] developed a hybrid model of VDA for selecting project management approaches and, in [16], Machado et al. employed VDA for helping to choose the best SCRUM practices.Tamanini et al. [17] created a VDA-based model to cashew chestnut industrialization process.Tamanini et al. ([18,19]) and ) carried out studies using VDA to support the diagnosis of the Alzheimer's disease.Gomes et al. [23] applied VDA in the marketing business.Barbosa et al. [24] described the use of VDA to prioritize software requirements.Finally, Simão Filho et al. [25] employed VDA in project portfolio ranking.
ORCLASS (ORdinal CLASSification) is a method of the VDA framework that aims to classify the alternatives in a set.For this, it is necessary that these alternatives be classified by the decision-maker in a small number of decision groups or classes, often two.The first group will contain preferable alternatives, and the second group will include nonpreferable alternatives [3].In addition, a set of criteria and their respective values should be established to allow the evaluation of alternatives.
Some advantages are associated with the ORCLASS method, which we highlight below [3].First, the comparison of the values is performed verbally since the preferences elicitation is performed in the native language of the decisionmaker.Second, the classification rule is organized according to the presentation of the most significant combinations of criteria for the decision-maker.Such strategy decreases the number of questions that the decision-maker would be required to answer during the preferences elicitation.Third, it is possible to check the preferences consistency of the decision-maker.Finally, it is possible to formulate a verbal explanation for the decisions from the classification rules obtained.Such advantages motivated its choice for this study.
In order to make the application of the ORCLASS method easy, the tool ORCLASSWEB was developed and then described by Machado et al. [26].It can be accessed through the link http://www2.unifor.br/OrclassWeb.ORCLASSWEB aims to make the process of alternatives comparison automatic, providing a result for the problem to the decision-maker, following the ORCLASS method specification.Another factor that favoured the choice of ORCLASS for this study was the existence of an automated tool to run the model.
The ZAPROS III-i method also belongs to the VDA framework.It integrates the ZAPROS family, and its function is to rank alternatives to problems with a small set of criteria and criteria values and a high number of alternatives.The ZAPROS III-i method adopts the same idea of criteria and criteria values employed by the ORCLASS method to assess the alternatives.The method uses values representing the distances between judgments on the scale of the same criteria or between two criteria to elicit the preferences of the decision-maker.A scale of preferences is then built in such a way that allows the alternatives comparison.
The main advantages of the ZAPROS method are emphasised next [27].First, during the preferences elicitation stage, the model exposes issues that are apprehensible to the decision-maker, according to the criteria values.This process has psychological validity since it accepts the limitations of the human information processing system.Such property consists of the most significant benefit of the method.Besides, the method can detect contradictory inputs from the decision-maker and request a solution for them.Finally, the ZAPROS provides all qualitative comparison information in a language that is natural to the decision-maker.Such advantages influenced its choice for this study.
To facilitate the application of the ZAPROS III-i method and to allow it to be executed consistently, the ARANA Ú tool was implemented ( [28][29][30]).Although initially ARANA Ú has been built for the ZAPROS III method, an updated version for the ZAPROS III-i method was used in this work.As in the previous method, the existence of an automated tool to run the model contributed to its choice.

Related Work
Today, more and more companies are conducting projects in a distributed way.Assigning tasks is a crucial activity for projects in general, especially in a distributed environment.Much research on the distribution of tasks in DSD has been conducted recently in order to clarify this issue, its difficulties, and its challenges.In this perspective, some approaches, methodologies, and models for distributing tasks considering remote teams were created.
Aiming to identify the related works to the present research, we have developed a systematic review of the literature, which is described in detail in [31].Our main objectives in conducting the systematic review were (i) to discover which approaches were used to allocate tasks in projects of DSD; (ii) to know whether the approach was based on qualitative multicriteria decision-making methods; (iii) to find out if the approach was based on VDA methods; and (iv) to identify if the study mentioned some factor or criterion that influenced the assignment of tasks in DSD scenarios.
To guide the literature review, based on the objectives cited above, we formulated a series of questions, for which we seek answers in the studies researched.Table 1 shows the research questions."PQ" identifies primary questions, and "SQ" identify secondary questions.
As a result of the literature review, some relevant papers were selected, which are briefly described next.Some of the most relevant works are those of Lamersdorf and his colleagues.In [1], Lamersdorf et al. analysed different approaches to the distribution of responsibilities.The analysis included various approaches in the areas of distributed development, distributed generation, and distributed systems.As a conclusion, they pointed to the Bokhari algorithm as a high applicability model in DSD.Lamersdorf and Münch [32] presented TAMRI (Task Allocation based on Multiple cRIteria), an approach structured on the Bokhari algorithm and Bayesian networks that adopts various criteria and influences factors to assist the systematic assignment of tasks in DSD projects.
Ruano-Mayoral et al. [33], in turn, proposed a methodological framework to distribute work packages to professionals in global software development (GSD) projects.The proposed approach was composed of two stages: definition and validation.The paper also provided the results of the application of the proposed approach.In [34] Is the approach based on qualitative multi-criteria methods of decision-making?PQ3 Is the approach based on any method of Verbal Decision Analysis framework?PQ4 Does the study mention any factor or criterion that influences the assignment of tasks in distributed software environments?SQ1 Does the approach describe a process?SQ2 Does the approach have any automated support tool? SQ3 Does the approach apply influencing factors extracted from the specific literature?SQ4 Can the approach be instantiated from an organisation standard?SQ5 Does the approach reuse knowledge?SQ6 Does the approach presuppose consensus meeting?SQ7 Does the approach presuppose feedback of results?SQ8 Does the approach allow using a subset of the whole process?SQ9 Does the approach allow modifying the main parameters (allocation object and executing unit)?SQ10 Has the approach been applied in real-world situations?SQ11 Has the approachbeen evaluated by users or professionals?SQ12 Has the approachbeen evaluated by knowledge area experts?36,37]) introduced DIMANAGER, a tool integrated to DiSEN environment (Distributed Software Engineering Environment) ( [38,39]) whose goal is to assist the choice of team members according to their skills, knowledge, and availability.DIMANAGER used Fuzzy Logic to quantify the identified criteria.
Another model was developed by ), who described an approach that identifies dynamic and discrete factors of a DSD domain and produces data regarding the dedicated resources, productivity, coordination, and communication throughout the project.By using the model, it is possible to configure several remote sites and their procedures involving several steps and assignment policies, enabling make the best choice to the assignment systematics.
Prikladnicki et al., in their turn, introduced MuNDDoS ( [43,44]) a Reference Framework for DSD.The authors created a project allotment flow that selects projects to be conducted in each remote office, taking into account the allocation strategy established by the company.
In [45], Jalote and Jain described a 24-hour Development Method that adopts a Directed Acyclic Graph (DAG).In such a DAG, the vertices symbolise the tasks, and the edges denote the current operational dependencies.Besides, the method involves three sets of resources, denoting professionals from each remote office related to each fraction of 8 hours of work.By using the critical path model, the method performs the attribution aiming to shorten the duration of the project.
Mullick et al. [46] introduced the Global Studio Project, a distribution model designed to optimise the work allocation.
In such a model, groups of professionals from several universities worldwide execute distributed development methods and techniques.All development work is divided into related work packages along with the background needed to perform them and their temporal dependencies.From this data and the professionals' knowledge, the packs are allocated manually.
In [47], Mak and Kruchten developed NextMove, an approach structured on object-oriented process modelling and project management practices to support the coordination and task assignment for remote professionals in an agile development scenario.NextMove applies the AHP (Analytic Hierarchy Process) approach to indicate the most suitable professional to receive a task according to their abilities.
Barcus and Montibeller [48] presented a real case study wherewith they constructed a multicriteria approach to assist the distributed tasks assignment decision for a global software company.The approach was formulated with the support of several software development project managers, combining decision conferencing and value assessment of several factors.The approach encompasses software engineering factors as well as strategic and non-strategic issues such as professionals' motivation and possibilities for education.
Finally, dos Santos et al. [49] proposed a recommendation framework for assigning development teams in distributed projects of software product lines.The framework consists of an activity flow that, in the end, indicates the best recommendation for the allocation.They reported the application of the framework in real situations.
After analysing the works in detail, we elaborated Table 2, which provides an overview of the papers as well as the answers to the research questions.Cells marked with "✓"  - indicate that a positive answer to the corresponding question was found in the investigated works.Cells filled with "-" denote that we could not conclude anything about the research question in the works consulted.It is worth emphasising that our evaluation considered the information that was published and accessible throughout this research.Also, the author made his interpretations when he did not find explicit information in the texts read.
From these studies, we have noted some variation in the granularity of the task to be allocated.Some approaches consider individual tasks, such as [38,45,47,48], while others focus on groups or packages of tasks ( [33,48]), or even entire projects, such as [43].
Some works have elaborated abstract models, such as reference models and frameworks ( [43,50]), while others implemented software tools from the proposed models ( [36]).
It is worth noting that considering the works analysed, only three presented approaches based on multicriteria decision-making methods ( [34,47,48]).
Nevertheless, only two studies used qualitative analysis as a basis, ( [34,48]), and none considered Verbal Decision Analysis methods.Besides the above-listed studies, other works did not present approaches but referred to some factors or criteria that influence or affect the allocation of tasks in DSD.Among them, we highlight [51][52][53][54][55][56][57].
Considering the fifteen objective questions assessed in this study (three primary questions, PQ2 to PQ4, and twelve secondary questions), PQ4 and SP3 questions, which concerned the influencing factors for task assignment in DSD projects, were successful for all the investigated approaches.Meanwhile, only one approach addressed the question SQ6 (consensus meeting), and no approach satisfied the question P3 (structured on some VDA method).Table 3 details the performance of the issues investigated.
From this analysis, we have noted that some works researched have developed multicriteria models, but generally considering the quantitative or mathematical approach.Moreover, in most cases, a small number of elements were applied to guide the attribution of tasks such as labour expenses, mainly.Thus, we could identify gaps in the set of existing approaches for task allocation in DSD that allowed us to drive some research to use multicriteria methods based on Verbal Decision Analysis.Moreover, many influencing factors were identified in the DSD task allocation decision process, which may be useful for future works.Besides, several aspects have been analysed in the existing approaches that have enabled us to think of some desirable features for a new approach in this field, such as the issues addressed in the secondary questions.

Influencing Factors for Task Allocation in DSD.
After the analysis described in the previous subsection, it was possible to establish the main factors that impact or influence the allocation of tasks in DSD projects.This work was mainly based on the studies of Lamersdorf et al., such as [1,58,59].They carried out literature studies regarding the distributed scenario and explored the criteria or factors that affect the activity of task allocation in GSD.Other works were also used as a basis for composing the relation of influencing factors in the allocation of tasks used in this approach, such as [5,[51][52][53][54][55][56][57].In the end, we have selected the fifteen most cited factors in these works.
Table 4 lists the fifteen factors selected.These factors will be an important part of the approach presented in this paper.

DiVA-An Approach to Support the Allocation of Software Development Tasks to Distributed Teams Based on Verbal Decision Analysis
In this section, we introduce DiVA, an approach to support the allocation of software development tasks to distributed teams based on Verbal Decision Analysis.The approach is based on Verbal Decision Analysis methods for classification and ordering.For the reasons discussed previously, the methods adopted are ORCLASS for classification and ZAPROS III-i for ordination.These methods work with some common concepts and have already proven successful in their hybridisation, as shown in previous works such as [16,60].Preliminary works on VDA application to the problem of task allocation in DSD context can be found in [61][62][63][64][65][66][67].
The approach is divided into four main stages, namely, context characterisation, ranking of the influencing factors, ranking of the executing units, and evaluation and decision.Context characterisation stage is responsible for the first definitions of the basic concepts, such as tasks, criteria, criteria values, and preference groups.In the second stage, ranking of the influencing factors, the VDA methods are employed to classify and order the influencing factors considering the selected criteria and criteria values, taking into account the types of tasks chosen.In the third stage, ranking of the executing units, the preferable influencing factors identified in the previous stage are now converted into criteria for evaluating the possible destination of the tasks, which may be offices, departments, or teams.Finally, in the last stage, evaluation and decision, restrictions, conditions, and limiting factors are identified, and the results are evaluated taking these issues into account.After the evaluation, the decision is made according to the process of each organization.Figure 1 shows a procedural view of DiVA with actors responsible for each activity.The process shows the activities grouped in their respective stages.Note that depending on the type of data the company already has, it may choose to start the process from stage 2 or stage 3, not necessarily from stage 1.Likewise, depending on the outcome of the evaluation of the data and the decisions made, it is possible to feedback the approach, returning to stage 1, 2, or 3.The company can also choose to instantiate the flow once each cycle (semiannual, annual), and then the company can only calibrate the model from the data feedback.A more detailed description of DiVA stages and activities is provided next.Has the approach been applied in real-world situations?6 SQ1 Does the approach describe a process? 5 SQ7 Does the approach presuppose feedback of results? 5 SQ8 Does the approach allow using a subset of the whole process? 5

SQ12
Has the approachbeen evaluated by knowledge area experts? 4

SQ11
Has the approachbeen evaluated by users or professionals? 3

PQ2
Is the approach based on qualitative multi-criteria methods of decision-making? 2 SQ6 Does the approach presuppose consensus meeting? 1

PQ3
Is the approach based on any method of Verbal Decision Analysis framework?0 (1) Context Characterisation: This stage comprises four activities, which are detailed below: (1.1) Definition of the Task Type(s): Define the work object of the approach, i.e., which tasks, type of tasks, or groups of tasks that will be analysed for allocation.(1.2) Identification of the Influencing Factors: Identify which factors influence the distribution of tasks in the context being analysed.

Knowledge in business
Knowledge of the teams about the area, domain or business of the clients.

Factor3
Project manager maturity Experience, background, and maturity of project managers in their profession

Factor4
Proximity to the customer The office whose team will perform the task is positioned geographically close to the client.

Factor5
Low turnover rate The turnover rate of office employees is low, that is, typically in the branch, there are few changes in teams.

Factor6
Team availability Teams seek to be free, available to perform tasks.

Factor7
Team maturity Teams are mature / experienced concerning the task being performed.

Factor8
Team personal trust Managers and colleagues believe and trust in themselves and each other.

Factor9 Same time zone
The various teams associated with the task execution work in the same time zone.

Factor10 Cultural similarities
The various teams associated with the task execution share the same cultural aspects.

Factor11
Team willingness Teams are motivated, excited and interested in the work.

Factor12 Low labour cost
The cost of professionals in the office is low/attractive.

Factor13 Maturity in the process
The teams are mature and experienced concerning the software development process adopted.

Factor14 Language fluency
The teams have fluency in the foreign languages commonly used in the office.

Good communication infrastructure
The office has a good communication infrastructure (speed, availability, redundancy, among others).
(1.3) Definition of Criteria and Preference Groups: Determine the criteria and their respective values to be used to assess the influencing factors in task assignment.Moreover, define the preference groups to categorize the influencing factors.The groups usually defined are (i) the preferable and (ii) the nonpreferable factors.(1.4) Characterisation of Influencing Factors: Characterise the influencing factors according to the criteria and criteria values, by task group or task.This means that the company must evaluate the factors against the criteria chosen.
( (4.1) Evaluation Meeting: The portfolio management team or equivalent meets to discuss the results of the approach, assessing any restrictions that may exist.Results may change as a consequence of this activity.(4.2) Allocation Decision: Finally, decisions about task allocation are made, and tasks are assigned to the responsible teams according to the organization's process or procedure.
The next section reports on the experiences of use carried out with the objective of evaluating the proposed approach.

Some Experiences with the Proposed Approach
5.1.Preparation.To evaluate DiVA and obtain indications about how it supports organizations in the allocation of tasks in DSD, we conducted some experiences.The application of DiVA was carried out in five real-world companies.After conducting the experiences of use, we chose to evaluate the application of the approach qualitatively, according to the stakeholders' perception, collected through questionnaires.
Note that the study scenarios can be classified as in vivo [68], that is, a validation carried out in real development environments with the supervision or participation of researchers and professionals.The purpose of the experiences of use was, for each company, to establish rankings of the most recommended executing units to assign a particular type of software development task.For this scenario, some assumptions have been made: (i) We considered the companies' offices as the executing units, that is, the entities that would perform the tasks themselves; (ii) Four different types of tasks were taken into account, namely: requirements-related tasks, architecture/ design-related tasks, implementation-related tasks, and testing-related tasks.
Due to time restrictions of the companies' professionals and to generate a knowledge base to be used in future instantiations of the approach, we chose to structure the application of the approach considering two phases.The first phase, which covered the stages "Characterisation of the Context" and "Ranking of the Influencing Factors", was common to all participating companies.At the end of the first phase, the approach generated four ordered lists of influencing factors, i.e., one list for each task type (requirements, architecture/design, and implementation/coding and testing).
The second phase involved the stage of "Ranking of the executing units" for the participating companies.In this case, the application was individualized per company.The stage "Evolution and Decision" was not carried out as part of these experiences of use due to the obvious difficulties of putting into practice within the companies.Table 5 shows the details of the strategy for the application of the approach.
We sought to select companies with different profiles, with subsidiaries in various cities, and even in several countries.The size of the companies ranged from medium to large.Figure 2 shows the geographic distribution of the companies' offices involved in the research.

Context Characterisation.
In order to perform Stages 1 and 2, the influencing factors previously identified and exposed in Table 4 served as alternatives for the classification and ordering VDA methods (ORCLASS and ZAPROS III-i).
For this activity, we followed the PMBOK's concepts [4] to help us choose the criteria because it has great acceptance in the software industry worldwide.Therefore, for our research, we decided to adopt the iron triangle, which is composed of time, cost, and quality, as the criteria for measuring success in project management.The factors were then characterised according to following criteria: time, cost, and quality of the task.These criteria have three possible values (high gain, some gain, and no gain) with the following interpretations (the adopted methods do not accept negative values): (i) High gain: The existence or presence of the factor causes a very positive influence on the time/cost/ quality of the task to be performed.
(ii) Some gain: The existence or presence of the factor provokes some positive influence on the time/cost/ quality of the task to be performed.
(iii) No gain: The existence or presence of the factor produces no influence on the time/cost/quality of the task to be performed.
To build the characterisation vectors for the alternatives of our problem, we needed to find out the impact of influencing factors regarding time, cost, and quality in tasks in DSD.For  this, we conducted a survey with 111 professionals who played the role of software project manager in several organizations spread throughout Brazil.The survey questions look like this: (1) Factor.Technical skills -knowledge and ability on techniques, programming languages, frameworks, tools, APIs, necessary for the professionals to carry out the task.( ) After conducting the survey, we were able to characterise the alternatives (in this stage, the influencing factors), which served as inputs for the VDA methods.An example of alternatives characterisation can be seen in Table 6, where the cells in bold represent the most voted criteria values and, therefore, the ones that were considered in the final characterisation vector (note the final vector column).The numbers in the cells represent the total votes each criterion value received for that factor.

Ranking of the Influencing Factors.
After defining the criteria and criteria values, alternatives (factors) and preference groups, we moved to the Stage of Ranking of the Influencing Factors.As explained, first, the ORCLASS method was applied with the support of the ORCLASSWEB tool, following the steps listed below: (1) Definition of the criteria and criteria values; (2) Definition of the alternatives; (3) Construction of the classification rule; and (4) Results generation.
We performed this stage once for each of the four task types determined initially.First, we introduced the problem's criteria into the ORCLASSWEB.In this step, we specified the criteria's names and their possible values.Next, we entered the problem's alternatives into the ORCLASSWEB.We provided the alternatives' names and their representations in terms of criteria values, considering the criteria established in the previous step (values in the column "final vector" in Table 6).The ORCLASSWEB then builds the classification rules by asking questions to the decision-maker.At that time, we got the support of five project management experts with more than ten years of experience in software development and that have a master's degree.They all lived in Fortaleza (Brazil) and worked for different organizations.They played the role of decision-makers and answered the questions of the method to classify the alternatives.The series of responses build the classification rule, which allows separating the alternatives into groups.Finally, the ORCLASSWEB classified all the alternatives and provided the results.For example, in our case, for requirement tasks, the A1B2C2 alternative fell in the group I while the A2B2C2 alternative was classified in group II.
At the end of ORCLASSWEB application, the factors were distributed between group I (the preferential factors) and group II (the nonpreferable factors) for each type of task (see Table 7).Factors from group I are the most relevant ones that project managers should take into account when assigning tasks in DSD projects, whereas factors from group II are the least relevant ones and should be less considered or even not considered when attributing tasks in DSD environment.
Once the preferable factors are identified by applying the ORCLASS method, we advanced to the step of ordering in the Stage of Ranking of the Influencing Factors.In this step, we employed the ZAPROS III-i method to order the preferable factors so as to establish a ranking of them.As already explained, the least preferable factors should be discarded in order to reduce our workspace.Like the previous step, this one was performed once for each of the four defined types of task.
As explained previously, the ZAPROS III-i method was performed with the support of the ARANA Ú software, following the steps described below: (1) Definition of the criteria and criteria values; (2) Elicitation of preferences; (3) Definition of the alternatives; and (4) Results generation.
Initially, we inserted the criteria into the ARANA Ú. Next, the same group of five project management experts from the previous step, in the role of decision-makers, decided the preferences in order to formulate the scale of preferences.The procedure happens in two steps: preferences elicitation for quality variation of the same criterion and preferences elicitation between pairs of criteria.After the preference scale has been formulated, the alternatives of the problem must be defined.The alternatives of the problem under study are the factors that constitute the group I, i.e., the factors that should be preferentially regarded in the allocation of tasks in DSD projects.
Once the data were entered and all the questions of the model were answered, ARANAU executed the process according to ZAPROS III-i, generating the outputs at the end, that is, an ordered list of the most relevant factors that the project managers should think about when distributing tasks in DSD projects.In our study, once we performed the model for all task types, ARANA Ú produced four ordered scales.The tool shows the alternatives of the problem, its representations in terms of criteria values and their rankings.
Note that, among the fifteen factors initially considered, for the tasks related to requirements, eleven factors were classified in group 1; that is, they were indicated as preferable, whereas another four factors were classified in group 2, that is, not preferable.The reasoning is the same for all other types of tasks.Table 8 shows the classification summary after the application of the ORCLASS method.The rank column indicates the position of the influencing factor on the preference scale generated by the model.For example, for requirement-related tasks, Factors 2, 4, 5, 6, 7, 11, 13, 14, and 15 were ranked at position 1; after all, they all have the best representation, i.e., A1B1C1.
The ARANA Ú also draw a graph showing the dominance relations among the alternatives.For all task types, we created the corresponding dominance graphs, which are exhibited in Figure 3.The arrow direction indicates dominance.It is important to emphasise that all such knowledge produced at this stage of the experiences of use can be reused in companies that intend to use the approach proposed in this research.Thus, a company may decide not to perform stage 1, Context Characterisation, and adopt the characterisation of the influencing factors generated by this work.Likewise, a company may also choose not to perform Stage 2, Ranking of the Influencing Factors, and thus make use of the ranking of influencing factors generated in this work.We understand that this ranking of influencing factors constitutes one of the significant contributions of this work since it is the result of very comprehensive research, which had the participation of more than a hundred professionals from the project management area in Brazil.

Ranking of the Executing Units.
Once we completed the stages that are common for all the companies involved and have selected the main influencing factors by task type, we moved to the individualized stage per company (Stage 3).In this step, the companies' offices served as alternatives for the VDA classification (ORCLASS) and ordering (ZAPROS III-i) methods.The set of the preferable influencing factors resulting from Stage 2 served as criteria to evaluate the offices.
For this study, we defined that each criterion could be evaluated as excellent, good, or regular.Thus, these were the criteria values adopted for this process stage.Once the criteria and their values have been defined, we proceeded to    the characterisation of the offices as regards the influencing factors, we mean; considering the influencing factors as criteria and the company offices as alternatives, we wanted to know how each company office was evaluated against the influencing factors.That characterisation will be useful for the next steps.The companies' professionals were then asked to rate all influencing factors for the offices of the company he or she works for, according to the following questions template.We replicated the questions to the other offices and factors.
(  After characterising the offices, we ran ORCLASS and ZAPROS III-I methods to get the ordered lists of recommended offices for each task type.Figure 4 shows the ORCLASSWEB screen for assembling the classification rule for the ORCLASS method.In this step, PMO staff, portfolio managers, or both should play the role of decision-maker and answer the questions posed by the model in order to classify the alternatives. They should respond "Yes" or "No" for all questions.The series of answers contribute to assembling the classification rule.Thus, it is possible to divide the alternatives (influencing factors) into preference groups.A positive response classifies that combination into the preferable group.Otherwise, the combination goes to the nonpreferable group.Thereby, the classification rule will be completed according to the decision-makers selections.At last, the ORCLASSWEB software processes the complete classification of the alternatives.
Figure 5 shows the ARANA Ú interface for the preferences elicitation between pairs of criteria as part of ZAPROS IIIi method application.In this scenario, the decision-maker should choose the best alternative, considering that the other values are at their best or worst degree.The choices set the scale of preferences among the criteria.

Results.
In the end, after applying DiVA for the five companies, we obtained the results (see Table 9).A detailed description of these experiences of use can be found in [69].

Evaluation of the Proposed Approach.
To evaluate the DiVA approach, we performed two types of analysis.The first evaluation sought to analyse the approach from the perspective of the five project management experts.The other analysis aimed to evaluate the approach by the companies'  professionals who participated in the experiences of use.Thirteen professionals from the companies participated in the experiences of use.However, three of them abstained from collaborating with the evaluation questionnaire.Table 10 summarizes the responses of both evaluations, which are briefly discussed in Section 5.5.

Discussion.
In both evaluations, most respondents agreed that the approach is easy to understand and to use.Furthermore, most of them also agreed that the approach helps reduce subjectivity and helps think of new aspects.Finally, most participants evaluated that it helps in task allocation in DSD.As points of attention, the assessment of the adaptability/extensibility and of the effort to use did not allow drawing precise conclusions.
Analysing the proposed approach based on the experiences of use conducted and the evaluations carried out, we have the following about DiVA: (i) It describes a process, providing a visual flowchart, which makes easy its understanding; (ii) It is supported by automated tools (ORCLASSWEB and ARANA Ú), facilitating its application; (iii) It uses influence factors extracted from the specialized literature, bringing global knowledge to the process; (iv) It can be instantiated from an organization standard; the experiences of use carried out followed this concept; that is, in the beginning, a common structure was defined, and, then, each company entered with its respective data.In the same way, this can be done within an organization, creating a common base and then customizing for each project.In addition, DiVA was applied in real-world situations, since the experiences of use were conducted with the collaboration of five software companies with distributed structure, and both knowledge area specialists and business professionals evaluated it.is the fact that the author of the work was the manager of the process executed in the experiences of use.Prior knowledge of the objectives proposed for DiVA may have had a positive influence on the obtained results.However, it was not possible to adopt an action capable of mitigating this bias, since ideally some professional from each company who had not been involved in this study should have executed DiVA.This was not possible due to staff restrictions and employees' workload in the companies.Thus, the directors requested that the author of the research conducted the experiences of use.

Threats and
For obvious reasons of time restriction of companies' employees, it was not possible to perform the entire approach within the companies.Thus, we have chosen to structure the application of the approach in two phases.This may have caused some confusion to the companies' professionals for not having participated in the selection of the influencing factors.We tried to mitigate this bias by explaining the whole approach in the questionnaires applied to professionals.The analysis of the results obtained with the application of DiVA by the author of this research can also be considered a threat.To mitigate that thread, the analysis of the results obtained with the execution of the DiVA and the evaluations made by companies' professionals and project management experts were discussed by two other researchers and by two project managers who were not involved with the research.Moreover, the analysis, although subjective, has taken into consideration only the answers regarding the agreement or not with certain statements related to the objectives of the research and can be easily verified from the results presented in the tables throughout the text of the paper.
Finally, another threat of this study concerns the generalization of the results.Once it has been performed in a limited way in a restricted group of companies, it is not allowed to generalize the results.It is only possible to observe indications about how the application of DiVA supports organizations in the task allocation process.5.6.2.Limitations.The user experiences have been developed partly in collaboration with the professionals of the participating companies.Better results could have been obtained if performed entirely by the companies' professionals.It was also not possible to obtain information on the time, cost, and effort of applying DiVA, due to the circumstances reported.Furthermore, another important limitation perceived was the lack of an integrated automated tool.Although there are specific automated tools for the VDA methods adopted, an integrated tool comprising the entire process would likely bring more benefits to the decision-making process as well as better results in approach evaluation.

Conclusion and Future Works
The software industry has a high level of competition, which requires IT companies to constantly search for innovative models of management, service supply and software development.On the other hand, the IT companies market, more than in any segment, is global; that is, customers can be spread all over the world.An increasing trend is to create subsidiaries around the world and deliver activities to them to benefit from the best features of each location and thus achieve the gains that the distributed model can provide.However, that solution presents challenges because many issues should be taken into consideration when distributing tasks to remote teams.The context exposed here is a typical decision-making problem that can be structured on multiple criteria.This problem can be tackled by using Verbal Decision Analysis.
In that scenario, this research introduced DiVA, an approach to support the allocation of tasks in DSD projects, based on the hybridisation of methods of Verbal Decision Analysis for classification and ordering applied to influencing factors and executing units.In this way, we intend to aid organizations in task allocation activity, which as presented throughout this work is very critical and involves many difficulties.
Aligned with this objective, a review of the literature was conducted to find out the approaches that support the allocation of tasks in DSD environment.Thus, it was possible to obtain an overview of the existing solutions that proposed to tackle the problem of task assignment in DSD.The literature review also allowed identifying some gaps that were addressed in the proposed approach, named DiVA.For example, the results of the review showed that few solutions proposed by other studies were based on multicriteria decision-making methods and even fewer studies were based on qualitative analysis.Furthermore, no approach based on Verbal Decision Analysis methods was identified.
Thus, for the development of the approach, we applied a hybrid model based on ORCLASS (for classification) and ZAPROS III-i (for ordering) methods, both from Verbal Decision Analysis framework, firstly regarding the factors that influence the task attribution in DSD, and, later, concerning the executing units (teams, offices, or branches).Bibliographic research and application of surveys with professionals allowed identifying and characterising the main factors that influence task assignment in DSD projects.
Experiences were carried out with the collaboration of professionals from five real-world companies that have a distributed structure.For that, tasks were gathered based on their type, that is, requirements, architecture/design, implementation, and testing.In the end, DiVA has been submitted to the evaluation by the professionals of the companies that participated in the experiences of use.In addition, DiVA has also been evaluated by project management experts with extensive experience in the knowledge field being studied.
Several conclusions can be drawn from the use of the approach, among which we can mention: it is supported by automated tools, it uses influence factors extracted from the specialized literature, and it proposes to be flexible and adaptable, since it is possible to use a subset of the whole process, besides allowing the modification of the main parameters (object of allocation and executing unit).Considering the evaluations of the approach, the results provided evidence that the approach is easy to understand and to use and helps to reduce the decision subjectivity and to think of new aspects.
According to [70], in research based on the Design Science Research (DSR), the research method adopted in this work, we seek to find a solution to a particular problem.This solution should not necessarily be optimal but at least satisfactory for the context it proposes.In addition, it is accepted that an actual problem and the artefacts that promote satisfactory solutions to it can share common characteristics that allow its generalization to a determinate category of problems.In this context, based on the results of the evaluations carried out by project management experts from different organizations and by professionals from the companies participating in the experiences of use, it is considered that DiVA approach can support software organizations in allocating tasks in DSD projects.
6.1.Future Works.The application of DiVA in real contexts and the evaluation of the results of the approach by professionals of the companies participating in the experiences of use, besides the evaluation of the approach by the specialists, allowed identifying some opportunities for improvement, which we suggest as future works (i) to develop an automated suite aiming the integration of the ORCLASSWEB and ARANA Ú tools in order to make its application easy and minimize the effort to adopt the approach; (ii) to hybridise other classification methods (NORCLASS or SAC) with other ordering methods (PACOM, SNOD, ORCON, or ARACE) to compose variants of DiVA; (iii) to create a knowledge base on factors of influence that would enable companies to select the most convenient factors depending on the context; (iv) to provide a guide or tutorial with information on applying the approach, describing "step by step" the execution of each activity; (v) to apply DiVA considering a reduced set of influencing factors, chosen as more appropriate for each company; (vi) to adapt DiVA to support the allocation of tasks for individual projects; and, finally, (vii) to adapt DiVA to consider dependency relations between tasks.
, 58]   An approach structured on the Bokhari algorithm and Bayesian networks and adopts various criteria and influence factors to assist the systematic assignment of tasks in DSD projects.39] A tool integrated to DiSEN environment to assist the choice of team members.It uses Fuzzy Logic as its basis.[40][41][42]An approach that identifies dynamic and discrete factors of a DSD domain and produces data regarding the involved resources, productivity, coordination, and communication throughout the project.] A method that adopts a DAG Directed Acyclic Graph) and uses the critical path model.It performs the attributions aiming to shorten the duration of the project.44] A reference model for DSD, which involves a project allotment flow that selects projects to be conducted in each remote office, taking into account the allocation strategy established by the company.] A distribution model designed to optimize the work allocation.All development work is divided into related work packages along with the background needed to perform them and their temporal dependencies.An approach structured on object-oriented process modelling and project management practices to support the coordination and task assignment for remote professionals in an agile development scenario.It uses AHP model as its basis.]A multi-criteria approach to assist the distributed tasks assignment decision, which combines decision conferencing and value assessment of several factors.teams in dist.proj.SPL[49] A framework that gives suggestions for team allocation in distributed Software Product Lines projects.

Figure 1 :
Figure 1: The process of the DiVA approach.

Figure 3 :
Figure 3: Dominance relations among the alternatives by tasks type.

Factor 3
. . .The survey continues with the other offices.

Figure 4 :
Figure 4: ORCLASSWEB's interface for construction of the classification rule.

Figure 5 :
Figure 5: ARANA Ú's interface for structuring the problem scale of preferences between pairs of criteria.

Limitations 5 . 6 . 1 . 1 R
Threats to Validity.Possible threats were identified during the execution of the experiences of use.The first point that may have influenced the results of the experiences of use Complexity Table 10: Evaluation of the approach by the project management experts (PME) and by the companies' professionals (CP). .E a s y t o u n d e r s t a Q 4 .L o w e ff o r t t o u

Table 1 :
Codes used in the data consolidation table.

Table 2 :
Mapping of approaches and research questions.

Table 3 :
Total approaches that scored for each question.

Table 4 :
Influencing factors on task allocation in DSD projects.
) Ranking of the Influencing Factors: This stage consists of two activities, which are described next: (2.1) Classification of Influencing Factors: Use the ORCLASS method to classify the influencing factors identified in Activity (1.2) into the preference groups defined in Activity (1.3).The preferable influencing factors, properly characterised (as a result of Activity (1.4)), will be processed by the ORCLASS method in this step.units: After identifying the main influencing factors in task assignment in DSD projects, the approach now considers the influencing factors as criteria and the executing units (company offices or teams) as the alternatives for the VDA methods.In this activity, relations must be

Table 5 :
Strategy for application of the approach.

Table 6 :
Example of alternatives characterisation for requirements tasks.

Table 7 :
Results of ORCLASS application separated by task types and preference groups.

Table 8 :
Detailed results of ARANA Ú application for each type of tasks.

Table 9 :
Results after applying DiVA.