A Recommendation Framework for Allocating Global Software Teams in Software Product Line Projects Thaís Alves Burity Pereira, Vinicius Souza dos Santos, Bruno Luna Ribeiro, Glêdson Elias COMPOSE – Component Oriented Software Engineering Group Informatics Department, Federal University of Paraíba, Brazil

{thais, vinicius, bruno}@compose.ufpb.br, [email protected]

ABSTRACT In order to improve software quality and reduce costs and deadlines, many companies are adopting Software Product Line approaches. As a consequence of globalization, another common practice is the adoption of Global Software Development approaches, which seek to find more qualified workforce and more attractive costs in companies distributed around the world. Taking into account the benefits of both approaches, the ramework proposed in this paper has the goal of aiding the management of global software teams involved in the implementation phase of an SPL project, providing recommendations on how to allocate the teams to the set of software components, which are initially specified in the SPL architecture and must be subsequently implemented.

Categories and Subject Descriptors H.4.2 [Information Systems Applications]: Types of Systems – Decision support (e.g., MIS).

General Terms Management, Human Factors.

Keywords Global Software Development, Software Product Line, Global Software Teams, Recommendation Systems.

1. INTRODUCTION The software development activity is a complex process that requires adequate use of technical, financial and human resources (HR). Due to that, software engineering focuses on how to reduce the complexity of and the effort required by software development activities. In such a direction, different approaches have emerged, making possible to improve software quality and to reduce costs, deadlines and bugs. Among them, the Software Product Line (SPL) approach has been adopted by software industry, promoting software reuse in a systematic and predictable way. In general, SPL approaches are composed of two phases: Domain Engineering (DE) and Application Engineering (AE) [1]. In the DE phase, a reusable infrastructure is built, which is encompassed by the reference architecture. In turn, during the AE phase, the reference architecture is refined to derive the application architecture and to instantiate software products. Despite the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. RSSE 2010, May 4, 2010, Cape Town, South Africa Copyright © 2010 ACM 978-1-60558-974-9/10/05 ... $10.00

benefits, SPL requires a high initial effort and the involvement of domain experts, which are not always available in a local team. In a complementary way, as a consequence of globalization and due to economic and technological reasons, software industry is increasingly adopting Global Software Development (GSD) approaches for conducting software projects on global scales [2]. GSD projects are highly dispersed, with experts from different companies and countries working together. Consequently, on the one hand, SPL approaches tend to support product development for global markets, making software industry more competitive and minimizing worldwide development costs [1]. On the other hand, GSD approaches would be seen as a method to find domain experts and most qualified teams to SPL development. However, GSD approaches have their limitations, mainly related to communication between dispersed development teams, as can be seen in [3], in which several discussed problems are caused by communication issues. In the GSD context, the nature of the tasks developed by different teams has a direct impact on the communication requirements. As a way of reducing such requirements, it is generally assumed that creating modular software can have the effect of reducing the dependencies among the tasks involved in designing and implementing the software components of a project [4]. Furthermore, communication issues can also be influenced by particular characteristics of the teams, for example, their native languages, time-zones and social-cultural principles. Traditionally, the HR allocation process of a software project is mainly based on the technical skills of the teams (or people) and the task requirements [5, 6, 7]. However, as mentioned before, in the context of GSD, it is also important to consider other nontechnical attributes, such as language, time-zone and cultural principles. In such a context, this paper presents a framework to provide recommendations for allocating global software teams involved in the implementation phase of software components of a SPL project. To accomplish such a goal, the framework analyzes technical and non-technical aspects of the SPL project and the available software development teams, especially those that emerge from the dispersion of teams around the world. The remainder of this paper is structured as follows. Section 2 presents a brief overview of the proposed framework. In section 3, more detailed aspects of the framework are described. Section 4 presents related work, evincing the main contributions of the proposed framework. Finally, Section 5 points out some conclusion remarks and future work.

2. FRAMEWORK OVERVIEW Considering that technical and non-technical features can impact on communication requirements, the framework intends to minimize the communication needs among global software teams

involved in the implementation phase of an SPL project, and so, represents a tentative solution to one of the main GSD challenges.

Dependences among modules are also captured, and, as result, the modules dependence model is generated as an output of the phase.

By exploring modular software design principles, the framework attempts to identify software modules as independent as possible, reducing dependencies among tasks performed by different dispersed teams, which are responsible for implementing the identified modules. Note that communication needs is always present, since the modules implemented by all teams must be subsequently integrated for generating the software systems that compose the software product line. Therefore, the challenge is to support the allocation of teams to tasks of implementing software modules, considering technical aspects of the SPL project, and besides, technical and non-technical aspects of teams.

During the teams non-technical description phase, the project manager ought to provide information about the participating teams T = { t1, t2, …, tx } in order to characterize them and identify the degree of difficulty they can be faced en terms of communication needs, such as location, language, time-schedule and other attributes that are relevant in the GSD context. This phase generates the teams non-technical description model.

In order to achieve its goal, considering the set of teams T = { t1, t2, …, tx } that can take part in a software project, the framework is segmented in three types of recommendations for identifying: (a) a set of software modules M = { m1, m2, …, mn } that can be independently implemented by different teams; (b) a mapping TM = { (m, st) | m ∈ M ∧ st ⊆ T } from each software module m to the subset of teams st that are technically capable of implementing the module; and (c) a set of allocations A = { (m, t) | m ∈ M ∧ t ∈ T ∧ (m, st) ∈ TM ∧ t ∈ st } each one supporting the project manager decision on how to assign each software module m to a specific team t. The proposed framework is organized in seven phases, which are illustrated in Figure 1. Jointly, such phases produce the aforementioned recommendations and also provide technical and non-technical feedback about the performance of the teams. Component-based architecture

Teams

Teams nontechnical description

Modules dependence model

Architecture analysis Module-based architecture

Teams technical description

Modules description

Teams nontechnical description model

Modules technical description model

Teams technical evaluation

Teams technical description model

Modules-Teams mapping model

Teams allocation Allocation model

Modules implementation Non-technical feedback

Teams performance evaluation

Technical feedback

Figure 1. The framework workflow. The framework starts from two independent phases: architecture analysis and teams non-technical description. It is important to highlight that the framework is designed as an aid, but the project manager is allowed to modify any recommendation at any phase. The architecture analysis phase takes as input the componentbased architecture of the SPL project, which also specifies the components that are already implemented. Such architectural description can represent the reference architecture of the product line or the architecture of a given derivable application. Its goal is to generate the module-based architecture, a new architectural description based on loosely dependent software modules, which correspond to the grouping of tightly dependent software components. In such a context, a software module represents the unit of task that must be implemented by a software development team. Note that the module-based architecture represents the recommendation of the set of modules M = { m1, m2, …, mn } that can be independently implemented by different teams.

Once the modules M and the teams T are identified, it can be recommended the mapping TM = { (m, st) | m ∈ M ∧ st ⊆ T }, which associates each software module m to the subset of teams st that are technically capable of implementing the module. This is achieved through the following phases: modules description, teams technical description and teams technical evaluation. Taking as input the module-based architecture of the SPL project, the module description phase generates the modules technical description model, which describes software modules in terms of technical requirements expected to implement them. At this point, it is clearly defined what should be implemented. Thereafter, the teams technical description phase generates the teams technical description model, describing each team in terms of its technical skills related to the technical requirements expected to implement all software modules, avoiding to gathering a large amount of unneeded information about the teams. Thus, such model should be constructed as soon as the project technical requirements are known and identified in the modules technical description model. The teams technical description model and the modules technical description model are taken as input to the teams technical evaluation phase, which is responsible for conducting the technical evaluation of the teams by matching the project technical requirements and the teams technical skills. As the output of this phase, the modules-teams mapping model represents the mapping TM = { (m, st) | m ∈ M ∧ st ⊆ T }, recommending the subset of teams st that are technically capable of implementing each software module m. By exploring the modules dependence model, first, the teams allocation phase categorizes the communication levels required by teams responsible for implementing software modules. Then, based on the modules-teams mapping model and the teams nontechnical description model, this phase estimates how adequate is each team for meeting the required communication levels. At this point, for each software module, the phase has the set of candidate teams that are technically capable of implementing the modules and also meet the required communication levels imposed by dependent modules. At this moment, based on a heuristic algorithm, the phase produces the allocation model, which represents the recommendation to the set of allocations A = { (m, t) | m ∈ M ∧ t ∈ T ∧ (m, st) ∈ TM ∧ t ∈ st } in which each one assigns a given software module m to a specific team t. Note that the set of allocations A is just a recommendation. The project manager is responsible for selecting the adopted allocation for implementing all software modules. After concluding the implementation, the teams performance evaluation phase assesses the performance of all allocated teams and derives feedback information to refine the technical and nontechnical description of participating teams.

3. FRAMEWORK’S PHASES IN DEPTH In this section, the framework’s phases and their associated artifacts are explained in more details.

3.1 Architecture Analysis The architecture analysis phase has two goals: (a) identifying the software modules that must be implemented and integrated by different teams; (b) measuring the dependence degree between such modules. As a consequence, this phase must derive the module-based architecture and the modules dependence model. In order to identify modules (goal a), the architecture analysis phase must receive as input the component-based architecture of the SPL project. Ideally, the input architecture should promptly represents: software components; relationships between components based on their provided and required interfaces; components type (mandatory, optional and variable); and components state (already implemented or not). However, since the architecture representation can greatly vary between different SPL development processes, usually some of the required information is not promptly available. Accordingly, the framework provides instructions to guide the software engineer on mapping the project component-based architecture to a generic architectural model. Such model is not specified yet, but it would be based on UML class diagrams and annotations that aggregate the required information mentioned before. Based on the generic architectural model, the software modules are identified by taking into account dependences among software components. Conceptually, dependence occurs when a given component depends on other one in order to perform its operations or when changes to the latter must be reflected on the former [8]. Thus, a software module consists of the grouping of a set of software components in which the internal dependence (among components in the same module) is greater than the external dependence (among components in different modules). Dependences can be identified based on the concepts of cohesion and coupling [9]. The reference architecture of an SPL project provides the means for deriving the application architecture in a principled manner, and so, the SPL architecture can be seen as a kind of architectural style. In turn, architectural styles propose solutions for structuring cohesive architectural elements. Thus, on the one hand, the framework assumes that cohesion is directly supported by the component-based architecture. On the other hand, the instantiation of the framework ought to provide instructions to the software architect to construct the modulebased architecture according to coupling criteria. For measuring the dependence degree among modules (goal b), since the objective is to indicate to which extent one module depends on other ones, the instantiation of the framework ought to provide metrics to address dependence measurement. Metrics are typically focused on one particular aspect of system quality, such as size, complexity, or reliability, and they are useful to provide information that can help to learn from past development experiences, evaluating present situations and sometimes even predicting future trends [10]. The framework is based on the principle that dependences among modules have a direct impact on the level of communication required by teams responsible for implementing them. Thus, the module-based architecture can provide information about communication needs among teams through the use of metrics applied to measure dependences among modules. Note that nonfunctional requirements, such as performance, security and reliability, can also influence on tasks dependence [4]. However, such requirements are not yet contemplated in the framework. Modules should be less dependent on other ones as possible in order to support the coordination of software development efforts. For example, consider two teams developing two dependent

modules. They need to carefully coordinate their work to make sure the modules are aligned and can properly interact. If the teams are collocated, the degree of difficulty they faces to communicate is probably less than if they are far apart. Although the literature on component-based development presents several component metrics, none of them seems to be an effective solution to identify modules [9]. The reason is that such metrics are generally applied to the code level, which means a too finegrained granularity at the architectural level. In the context of SPL projects, the optionality and variability properties dictate new dependence relationships and are not addressed by such component metrics. In addition, most metrics identified in the literature on software architecture and SPL architecture are based on ADL (Architectural Description Language) or they are focused in promote quality, such as reusability and complexity metrics [11]. Therefore, when instantiating the framework, it is needed to define new types of metrics that make possible to identify software modules and to measure their dependences.

3.2 Modules Description During the modules description phase, the software architect should provide information about the technical requirements of each module that has been identified in the module-based architecture. This is accomplished by the modules technical description model creation. The modules technical description model consists in a set of textual documents, each of them related to a specific module. For each module it should provides the detailed description of the module’s functionality, the needed technologies to implement it, the level of experience or knowledge in such technologies and in the SPL project domain.

3.3 Teams Technical Description The teams technical description phase gathers the necessary information in order to evaluate teams suitability in terms of technological knowledge to implement the modules. As an output it is generated the teams technical description model. As teams are involved in many projects over time, the teams technical description model is updated and refined every time a team engages in a different project. The framework considers the following initial set of technical attributes: experience in technology, domain expertise, certifications, technical capabilities and technical performance. All attributes, except the latter, are gathered in this phase and are provided by the teams themselves. The experience in technology attribute represents years of experience the teams have accumulated in a given technology. The domain expertise attribute reflects the amount of team’s knowledge in the project domain. The certifications attribute has two viewpoints: team and organization certification. The former consists in the total of certifications obtained by members of the team. The latter represents the certifications of the organization to which the team belongs. The technical capabilities attribute represent the current level of knowledge that the team has on the expected technologies to implement all modules. The technical performance attribute is obtained as a feedback in the teams performance evaluation phase, after the teams have implemented the modules. It indicates how well the teams performed the implementation of projects over time. Based on this attribute, the project manager is able to know if the teams are evolving and becoming more capable to develop modules.

3.4 Teams Non-Technical Description The teams non-technical description phase consists in gathering information about the teams that can influence on the communication between them. As an output, this phase generates the teams non-technical description model. The non-technical attributes can be classified into geographical, temporal, cultural and reputation attributes. Geographical attributes represent team’s localization on different perspectives, such as country, state, city or even continents. Temporal attributes are related to working hours per week and time zone, defining segments of work period. Temporal attributes can be employed to verify the possibility of synchronous or asynchronous communication. Cultural attributes designate the set of languages that the teams can use to communicate in terms of talking, listening, writing and reading. Reputation attributes specify the relationships between each pair of teams that worked together.

3.5 Teams Technical Evaluation The teams technical evaluation phase intends to evaluate the technical suitability of the teams to implement the modules. The artifacts needed to begin the evaluation process are the modules technical description model and teams technical description model. As an output, this phase generates the modules-teams mapping model that encompass a list of suitable teams to implement each module along with a technical metric that measures the suitability of each candidate team to each module. Taking into account that the technical attributes representing modules and teams cannot be precisely gathered, a fuzzy logic algorithm seems to be very adequate to deal with such imprecision. Thus, it is possible to evaluate attributes, such as technical capabilities, in terms of general words like good, average or bad, also called fuzzy terms. This is interesting because it is common to adopt such terms to refer to skill levels instead of quantifying with numbers. When instantiating the framework, the project manager should define how many and what terms to adopt on the modules and the teams descriptions. Based on such terms, the project manager defines the set of rules that match and evaluate the technical suitability of the teams to implement the modules according to specific project needs. The fuzzy terms that represent the result of the evaluation must be also defined by the project manager. The rules are defined as a rule matrix, where columns and lines represent expected skills for implementing the modules and teams capabilities, respectively. Each cell represents a technical ability of the team to implement the module based on the defined rules. For example, suppose that the project manager defines three terms for the expect skills levels for the modules and four terms for the technical capabilities of the teams. Such terms are subjected to the fuzzyfication process, which associates numbers between 0 and 1 for all terms. It is interesting to note that teams with different skill values (e.g. 0,81 and 0,90) can be categorized in the same fuzzy term without losing the real values that differentiates them. As mentioned, the project manager defines the set of rules to be adopted. If the project policy is to allocate more skilled teams to more complex modules, then teams with high capabilities is never a good choice for modules that demands low skill levels. If the project policy is to get the modules done fast, them the rules should be changed in a way that highly skilled teams can be a good choice for any module, even for the simplest ones. Whenever the evaluation matches the skills of teams and modules, the correspondent rules are triggered, generating the values for that association. Such an evaluation is done for each of the

modules. At the end, all teams are evaluated and the list of suitable teams to implement the modules is generated. The suitability level assigned to the teams serves as a metric to sort the teams by their technical ability to implement the module.

3.6 Teams Allocation The teams allocation phase aims to generate a set of recommended allocations that have the potential to reduce communication needs between teams. The recommended allocations are proposed based on non-technical attributes of the teams, specified in the teams non-technical description model, and the technical metrics, received from the modules-teams mapping model. Evaluating the set of recommended allocations, the project manager may choose one that best fits the project goals. The teams allocation phase is divided in three steps: GSD priorities definition, non-technical analysis and recommendation selection. During the GSD priorities definition, the project manager’s preferences about each GSD aspect (geographical, temporal and cultural) should be captured to be used on the nontechnical analysis. The manager defines levels of importance for each aspect using fuzzy terms as already described in Section 3.5. Next, in the non-technical analysis of the phase, it is created the set of recommended allocations. First, the communication needs among each pair of teams are identified based on the modules dependence model and the teams non-technical description model. Then, such needs are ranked based on the defined GSD priorities. Finally, based on the measured communication needs, the set of recommended allocations is created, but ranked according to technical aspects identified in the modules-teams mapping model. The non-technical analysis can consider several communication channels, including meetings, chat, synchronous and asynchronous conversation, mailing-list, telephone, video conferencing and so on. For example, if teams A and B are to be allocated to implement tightly dependent modules, the teams have their non-technical descriptions compared against the communication needs for the modules. In such a case, there is a great communication need, so if team A can communicate only in English and team B only in Spanish, they are not a good allocation choice. However, if team A also knows the Spanish language, but good enough only on writing and reading attributes, the teams might be good partners on synchronous chat conversation. Other information like temporal attributes and reputation also has to be verified. Temporal attributes verify if the teams have enough period of time to communicate, while the reputation verifies if the teams have good experiences working together in the past. Due to prohibitive computational efforts required to evaluate all possible allocations, the teams allocation phase can explore heuristic approaches based on genetic algorithms. In such a direction, it is not necessary to analyze all the possible allocations of teams and modules. A genetic algorithm approach creates a limited number of allocations, evaluates them and verifies if they are good enough and acceptable. If not, new allocations are tried to improve the quality of recommendations, concluding only when suitable allocations are found. At the end of this phase, the recommendation selection step consists in the project manager evaluating the set of recommended allocations and choosing one that best fits the project goals.

3.7 Teams Performance Evaluation After implementing all modules, the performance of the teams needs to be evaluated according to technical and non-technical criteria. Such evaluation is necessary to maintain updated both types of attributes, favoring better allocations in future projects.

Note that technical capabilities attributes have been provided by the teams themselves. Thus, the project manager can verify the accuracy and then update such capabilities after teams have concluded their work. Domain expertise and experience in technology attributes can be updated every time teams implement modules in a certain domain or employ a given technology. The technical performance attribute is updated to correspond to teams performance over time. For instance, consider two teams with similar technical capabilities levels, where the first started with high levels that decreased over time, while the other one was in an opposite situation. Supposing that their skills levels are now similar, it is difficult to decide which team is the best option. So, the performance of the teams in the recent past, represented by the technical performance attribute, can influence such decision. Once teams almost always need to interact, the interaction reputation attribute can be adopted to translate how well teams can work together. This information is represented as a pair-wised association. Hence, every time a team works with other one, their association is created or evaluated after concluding their modules.

4. RELATED WORK Taking into account resource capabilities, difficulty of implementing packages and communication overhead, Duggan [6] presents a staffing approach for allocating implementation activities of software projects. It makes use of genetic algorithms to provide a set of possible recommendations, each of them relaying on a specific aspect like cost or time-to-market. Another approach can be seen in [7]. Such an approach models the allocation problem as a constraint-satisfaction problem. It considers a set of activities, a set of professionals that can perform each activity and a set of constrains that represents desired aspects, such as most qualified or cheapest team formation. In [5], Collofello presents an approach for assessing the effects of resources allocation based on simulation. So, instead of recommending allocations from scratch, it gives support for mitigating changes of professionals during the project lifecycle. It is important to highlight that none of such proposals directly addresses SPL or GSD features, which represent the main contribution of the framework proposed herein. Communication needs and other aspects of GSD are addressed in [12]. It presents a paradigm to integrate and enhance existing formal and informal coordination strategies. Closer to the scenario considered in this paper, Paulish [1] proposes some guidelines on how to develop a product line using a centralized management team and distributed development teams. The guidelines are reasoned in practices for formal requirements engineering and architecture design, as well as agile processes. However, allocation of tasks to teams is not considered in such approaches. Thus, the main contributions of the proposed framework are threefold: a) grouping of software components in units of implementation, called modules, as a strategy to mitigate communication needs; b) categorization of global software teams in terms of language, time, culture and distance issues that can difficult communication among them; c) adoption of SPL features and concepts in modules identification and teams characterization.

5. CONCLUDING REMARKS In the GSD context, task allocation is too complex to be addressed by the project manager experience only, since a large number of solutions can be identified with few teams and activities. Therefore, any ad hoc decision-making process on such a context would be difficult, inefficient and error prone. Due to that, the

proposed framework provides a systematic way of recommending teams allocation based on the mitigation of communication needs among global software teams. By adopting the framework concept, the approach proposed herein can be seen as an ongoing guideline that must be instantiated and customized for each SPL project and GSD context, including the detailed specification of technical and nontechnical attributes, and besides, the reasoning techniques and algorithms for automating the decision-making process. Note that the evaluation of the proposed framework is out of the paper scope. Despite that, as a future work, it is under negotiation the instantiation and application of the framework in a real world problem of the software industry. Besides, after concluding some case studies, it is planned to develop a toolkit for automating all phases of the framework.

6. ACKNOWLEDGMENTS This work was supported by the National Institute of Science and Technology for Software Engineering (INES)1, funded by CNPq, grants 573964/2008-4.

7. REFERENCES [1] Paulish, D.J. 2003. Product Line Engineering for Global Development. International Workshop on Product Line Engineering: The Early Steps. [2] Gumm, D.C. 2006. Distribution Dimensions in Software Development Projects: A Taxonomy. IEEE Software. vol. 23, issue 5, pp. 45-51. [3] Carmel, E. 1999. Global Software Teams – Collaborating Across Borders and Time-Zone. Prentice Hall. [4] Herbsleb, J.D. 2007. Global Software Engineering: The Future of Socio-technical Coordination. International Conference on Software Engineering. [5] Collofello, J., et al. 1998. A System Dynamics Software Process Simulator for Staffing Policies Decision Support. 31st Annual Hawaii International Conference on System Sciences. [6] Duggan, J., et al. 2004. A Task Allocation Optimizer for Software Construction. IEEE Software. vol. 21, issue 3, pp. 76-82. [7] Barreto, A., Barros, M., and Werner, C. 2008. Staffing a Software Project: A Constraint Satisfaction and OptimizationBased Approach. Computers & Operations Research vol. 35, issue 10, 2008, pp. 3073-3089. [8] Vieira, M.R.E. 2003. A Compositional Approach for Analyzing Dependencies in Component-Based Systems. Information and Computer Science. Doctoral Thesis. University of California, Irvine. [9] Blois, A.P.B. 2006. Component-Based Architectural Design Approach in the Domain Engineering Context. Doctoral Thesis. Federal University of Rio de Janeiro, Brazil. [10] Fenton, N.E., et al. 1998. Software Metrics: A Rigorous and Practical Approach. 2nd Ed. PWS Publishing Co. [11] De Souza, C.R.B., Redmiles, D. 2005. An Interdisciplinary Perspective on Interdependencies. Institute for Software Research, University of California, Irvine, UCI-ISR-05-7. [12] Redmiles, D. et al. 2007. Continuous Coordination: A New Paradigm to Support Globally Distributed Software Development Projects. Wirtschaftsinformatik, vol. 49, pp. S28–S38.

1

http://www.ines.org.br/