2011 Sixth IEEE International Conference on Global Software Engineering Workshops
A Decision Support System for Global Software Development Sarah Beecham, John Noll, Ita Richardson Lero, The Irish Software Engineering Research Centre Email:{sarah.beecham,john.noll,ita.richardson}@lero.ie
The decision support system (DSS) is based on the Global Teaming Model (GTM) [11–13], which in turn draws on the GSD literature in general. The GTM is a process model that comprises a set of 20 global software development practices drawn from case studies and the wider literature. The GTM recommends practices aimed at resolving problems associated with global distance: geographical distance where team members and management are physically separated [14], temporal distance with limited opportunity for synchronous communication [15], and linquistic and cultural distance that impedes understanding of remote colleagues and teams [16– 20]. The GTM organizes empirical evidence into Goals, Specific Practices and Sub-Practices, and recommendations. But, not all practices and recommendations apply to all situations at all times. Also, there is an ideal sequence in which the practices should be applied: some are useful only at the beginning of a project, while others are most effective if they follow certain other practices. An automated mechanism for selecting GTM recommendations has several advantages: 1) Bookkeeping - some conditions affect more than one rule, and some rules involve several conditions. Keeping track of these relationships is error prone, and time consuming. 2) “What-if” analysis - the environment determines not only what should be done, but also what can be done. What would be the outcome if the environment were changed? 3) Sequence of implementation - whereby a recommendation follows on from a previous recommendation in a logical order. The remainder of this paper is organized as follows: in Section II we give a background to the Global Teaming Model, and in Section III we describe the Decision Support System for Global Teaming (GT-DSS), including the development the methodology. Section IV gives a background to the evaluation exercise involving a group of experts. Results and evaluation of the GT-DSS are discussed in Section V. We conclude the paper in Section VI with our key contributions and future work.
Abstract—Global Software Development (GSD) research has reached a level of maturity. Paper-based solutions and guidelines are readily available to solve many known distributed software development problems. The large number of recommendations can present a confusing picture to the practitioner. The Global Teaming Model (GTM), captures key global software processes and recommendations by drawing on the large and growing corpus of empirical research on GSD. This paper introduces the Global Teaming Decision Support System (GT-DSS), that is designed to help software managers navigate through the many recommendations in the GSD literature and the GTM. The interactive GT-DSS captures details about the development organization, and tailors GTM practices to fit specific business and organizational needs. A prototype of the GTM-DSS has been evaluated by industry experts in GSD, with favorable results. Keywords-Global Software Development, Distributed Software, Decision Support System, Software Process, Global Teaming Model
I. I NTRODUCTION In today’s global economy, organisations are looking across geographic boundaries to expand their customer base, to work more closely with new customers, to employ programmers with new skills, and to take advantage of cheaper labour. However, the benefits of globalization can be lost if organisations do not mitigate the risks associated with global distance [1, 2]: processes that work in a collocated setting do not necessarily scale up to suit a distributed environment [3]. Fortunately, there is a wealth of information about how to manage the complexities of Global Software Development (GSD)1 , as evidenced by the growing number of systematic literature reviews that deal with different aspects of GSD [1, 4– 10]. However, organizations may not have the time or experience to wade through and interpret the thousands of pages of research to find appropriate recommendations for their specific situation. A software project manager confronted with a growing list of guidelines needs to know, “given my situation, what should I do now?” This paper introduces a practical solution to this problem of information overload and decision making in the form of an automated decision support tool that selects and prioritises solutions to suit a given organisational context.
II. T HE G LOBAL T EAMING M ODEL (GTM) The Global Teaming Model is organized hierarchically, c [21]. following the structure and nomenclature of the CMMI Starting at the highest level with two broad goals, Figure 1
1A
variety of terms exist: Distributed Software Development, (DSD), Global Software Development (GSD), or Global Software Engineering (GSE). We will use the term/acronym GSD in this paper.
978-0-7695-4558-5/11 $26.00 © 2011 IEEE DOI 10.1109/ICGSE-W.2011.20
Deepak Dhungana ¨ Siemens AG Osterreich Corporate Technology, Vienna, Austria Email:
[email protected]
47 48
Global Teaming Model
Practice Area 1.1 Global Task Management
Determine team and organisational structure between locations Determine the approach to task allocation between locations
GOAL 1:
GOAL 2:
Define Global Project
Define Management
Management
Between Locations
Practice Area 1.2 Knowledge and Skills
Identify business competencies required by team members in each location
Practice Area 1.3 Global Project Management
Practice Area 2.1 Operating procedures
Identify GSE project management tasks
Define how conflicts & differences of opinion between locations are addressed & resolved
Assign tasks to appropriate team members
Identify cultural requirements of each local sub-team
Establish cooperation and coordination procedures between locations
Implement a communication strategy for the team
Identify communication skills for GSE
Ensure awareness of cultural profiles by project managers
Establish communication interface points between the team members
Establish relevant criteria for training
Establish reporting procedures between locations
Implement strategy for conducting meetings between locations
Practice Area 2.2 Collaboration between locations
Identify common goals, objectives and rewards Collaboratively establish and maintain work product ownership boundaries Collaboratively establish and maintain interfaces and processes Collaboratively develop, communicate and distribute work plans
Establish a risk management strategy
Fig. 1.
The Global Teaming Model: Goals, Specific Practices and Sub-Practices
shows how the goals are decomposed into Specific Practices, and Sub-Practices. Figure 2 shows how a specific practice is further decomposed into Sub-Practices and recommendations. In total, the GTM has five Specific Practices, twenty SubPractices, and sixty recommendations. The first GTM goal - Define Global Project Management recognizes that global project management, while encompassing the expected tasks of any project management setting, must also include new tasks related to managing a virtual software engineering team composed of multiple distributed teams. As such, the Define Global Project Management goal comprises three Specific Practices: Global Task Management, Knowledge and Skills, and Global Project Management. The Define Management Between Locations Goal (Goal 2) focuses on project management between locations. This is achieved through two Specific Practices: Operating Procedures and Collaboration Between Locations. The first ensures that operating procedures are set up correctly, while the second practice focuses on collaboration between locations. An example Specific Practice—Collaboration Between Locations— under Goal 2 is detailed in Figure 2: this specific practice defines four Sub-practices, which in turn are decomposed into recommendations.
system in GSD process management. We continue with a description of how we developed the Global Teaming Decision Support System (GT-DSS).
III. T HE G LOBAL T EAMING D ECISION S UPPORT S YSTEM
The design of the GT-DSS was motivated by three overarching requirements: 1) The GT-DSS should provide useful guidance.
A. Decision Support System Background A Decision Support System (DSS) is defined as “a system under the control of one or more decision makers that assists in the activity of decision making by providing an organized set of tools intended to impose structure on portions of the decision-making situation and to improve the ultimate effectiveness of the decision outcome” [22]. A DSS couples the intellectual resources of individuals with the capabilities of the computer to improve the quality of decisions [23]. Such a system typically consists of 3 components: information store (knowledge base), inference engine, and the user interface [24]. A DSS improves the human decision-making expertise because human decision making deteriorates with complexity and stress. The use of a DSS allows its users to conceive solutions and respond to situations quickly. It promotes learning or training, generates new insights into problems and prevents tunnel vision [24]. B. Decision Support System Development
In this section we give a brief background to the Decision Support System, and discuss the suitability of this type of 49 48
questions in any order, and the recommendations are provided incrementally, updated after each question is answered, giving a sense of how the interview is progressing. C. Architecture The system architecture comprises three components (see Figure 3): the User Interface, the Knowledge Base, including questions, rules, and explanations, and the Inference Engine. The user interface has three functions: capture essential facts about the environment, display recommendations and detailed explanations, and provide a real-time trace of the reasoning process. Figure 4 shows the layout of the user interface. The list of questions, each identified by a short summary statement, is shown in the leftmost panel. The question text is presented in the panel on the upper right, below which are buttons for the interviewee to submit a “yes” or “no” answer to the question. The lower right panel displays the continually updated list of recommendations as they are generated and updated. Finally, a “status bar” at the very bottom provides a window into the internal functioning of the inference engine, displaying facts asserted and rules fired. The knowledge base is a set of rules and questions Figure 3 that enables the inference engine to make recommendations based on the answers provided by the interviewee, which are translated into facts asserted into the inference engine’s working storage. Rules relate conditions (facts) to actions; usually, actions are recommendations, although sometimes they may be additional facts. The conditions and actions are written in prolog syntax. For example, the following rule expresses the need to Identify Common Goals, Objectives, and Rewards as depicted in Figure 2.
Fig. 2. Global Teaming Model: Example Specific Practice, sub-practices and Recommendations (Detail taken from Figure 1)
rule culture1: [1: cultural_diff, 2: not(reasons_for_gsd)] ==> [ assert(recommendation(id_common_goals)) ].
Fig. 3.
The first line - rule culture1: - gives a name to the rule, primarily for debugging purposes. The statements labelled 1 and 2 are conditions that must be true for the rule to fire; the ‘assert’ statement adds the recommendation to the working storage. So, this rule expresses the relationship between the answers to two questions and a resulting recommendation: If there are cultural differences, and the reason for embarking on a GSD project has not been articulated, then the Identify Common Goals practice should be implemented. The knowledge base also contains the interviewee questions. Questions are the primary point of interaction with the decision maker, and are designed to capture facts that the inference engine uses to make recommendations. Every rule has a set of conditions that must be true for the rule to fire; these conditions reflect the ‘yes’/‘no’ answers to questions.
DSS Architecture
2) The GT DSS should allow what-if analysis. 3) The GT-DSS should be easy to use. The GT-DSS starts with the concept of an interview, in which the system asks a set of questions and provides a set of recommendations based on the answers. Unlike a conventional verbal interview, however, the DSS presents the entire set of questions at the beginning; the interviewee can answer
50 49
Fig. 4.
Fig. 5.
Result of answering “No” to the Reasons for GSD question.
expert with minimal Prolog expertise can enhance the rule set without the need to modify the engine itself. The current rule set was specified by the authors based on the Global Teaming Model and associated empirical research. Figure 4 shows the user-interface after four of the questions have already been answered: the “Project start-up” question was answered “no” as indicated by the ‘X’, the “Multiple cultures” question was answered “yes”, as indicated by the check mark, and the “Cultural Differences” question has been answered “yes.” The interviewee has just responded “no” to the “Reasons for GSD” question; this question is thus marked with an ‘X’ and asserting fact (reasons_for_gsd, no) is reported at the bottom of the window. Answering “No” to the “Reasons for GSD” question results in a fourth recommendation: “Identify common goals, objectives, and rewards.” By selecting this recommendation, the interviewee can see a detailed explanation of the recommendation (5).
DSS Recommendation details.
IV. E VALUATION We conducted a system evaluation with a group of experts in GSD. We created a questionnaire to reflect each of requirements of the GT-DSS described in Section III, focusing on the usability and usefulness of the tool. We first piloted the questionnaire to ensure that all questions were relevant and clear, and covered the areas needed to gain useful feedback. We kept the number of questions down to four, plus six demographic questions. Open system questions comprised: 1) What do you think about using a Decision Support System to create a list of tailored recommendations to support you in GSD? (i.e. is it the right kind of tool?). 2) What extra features and practices would you like to see included in this system? 3) Is the granularity of the model/tool at the correct level of abstraction?
The knowledge base also includes explanations, that translate recommendations asserted when rules fire into humanreadable summary statements. The summary statements have detailed descriptions of their recommendations, which are presented to the interviewee on request. The inference engine makes recommendations by matching facts asserted by the interviewee (as answers to questions) to rules in the knowledge base. It uses a simple forwardchaining reasoning algorithm that selects the most appropriate combination of outputs from an otherwise intractable set of possible solutions [25]. The inference engine is implemented in Prolog, comprising barely 200 non-comment lines of code. The inference engine itself contains no knowledge of the Global Teaming Model; this knowledge is captured entirely in the knowledge base as rules, which means that a domain
51 50
Mean Years of experience in the software industry Years of experience in GSD Organization size Countries Organization works with in GSD
be used by people from different cultures and countries, the clarity of the language is of paramount importance. These responses helped us to focus on the type of user that would benefit from interacting with the GT-DSS. While it seems unlikely that the GT-DSS will provide someone with 17 years experience in Software Engineering and an average of 8 years GSD management with a lot of new information and direction, what may appear obvious to those experienced in GSD, is not always obvious to organizations who are embarking on a GSD project for the first time. Therefore, it appears that the current system is suited to organizations relatively new to GSD, and can be used as a training tool, for example as an aid in analyzing example case studies in a training course. Even though the system is in early stages of development, the response was generally positive, as summarized by this response “It is a beginning and needs to be enhanced significantly but I think it’s a step in the [right] direction”. To summarise, the GT-DSS contributes to the field of GSD by creating a tailored set of recommendations to support managers in creating a cohesive team across global distance, where all stakeholders are working to the same processes and goals. The system seems particularly suited to those new to GSD and we have launched the GT-DSS as a GSD training tool. We have resolved many of the issues identified by the experts and plan to make the current practices more specific, more complete, and more detailed and will continue to validate the system to ensure that all recommendations can be clearly understood. We plan to run a follow-up evaluation of the current version with an expanded set of participants to include those new to GSD who constitute our target user. By validating the GT-DSS directly with organisations involved in GSD we ensure that practitioner needs are met.
17.4 8.4 48,687 11.8
TABLE I R ESULTS OF DEMOGRAPHIC QUESTIONS (#5)
4) The current system is just a subset of practices; given that this is just a prototype, did you get any useful feedback from using the system? We enlisted a group of five experts including delegates from the 2010 ICGSE IEEE conference as well as industry colleagues, with an approximate mean of 17 years SE experience and 8 years experience in GSD (see Table I). The experts represented a cross section of roles: Architect, Process Design, Agile Coach, Senior Project Manager, Research Analyst, Technical Director and Consultant. Each expert used the system unaided. They took around 40 minutes to complete the exercise. Results of the questionnaire are given in the next section where we also consider how the feedback from the experts determines the future direction of model development. V. R ESULTS AND D ISCUSSION The experts felt that a Decision Support System (DSS) could provide a much needed synchronicity of process across locations thereby reducing the negative effects of global distance. Ideally, knowledge could be captured and combined across locations and stored in the GT-DSS. It was felt that the system would lead to less dependence on external experts and would be particularly suited to new recruits. The system could also guide managers involved in project start-ups to form global teams, and could reaffirm decisions made during project initiation or planning stages. Several evaluators felt that the system’s answers were high level and perhaps a little obvious, especially to those with many years experience in the field: “. . . the system must be more expert than me” and “having been doing GSD for many years, recommendations are already in place.” All respondents wanted more detail in the system: “The practices need greater detail at more granular levels of the SE process”. Two participants observed that the system focused on a subset of project engagement types and needed to be expanded for a larger range of models. Another reviewer observed, “it would be useful if the system could more explicitly cross reference industry best practices / papers”. The GT-DSS is ideally suited to this form of additional aid, and we will include this feature in a future release. The experts also gave us feedback on the usability of the tool; in particular, the initial sequential interview-style question presentation has been replaced with the interface described in Section III. The phrasing and wording of questions in the system is also being refined. Since the system could
VI. T O C ONCLUDE The GSD community has published many recommendations on how to effectively manage Global Teams. Researchers aim, in one way or another, to suggest ways to reduce the negative effects of global distance. Software practitioners are now equipped to solve many of their problems should they have the time to sift and digest the available material. In our previous work we have simplified this process through the introduction of our Global Teaming Model that standardizes recommendations specific to GSD. In this paper we present a Decision Support System automated tool that builds on and utilizes these standardized processes and contextualizes them according to individual organizational needs. Practitioners were able to identify processes that are important to successful GSD, and, can now go one step further; through interacting with the GT-DSS, they will create their own tailored list of recommendations, suited to their own particular circumstances. Managers in need of support no longer need to look at material that does not relate to their situation, and will be able to make informed decisions about how best to manage their global, virtual teams based on tried, tested, and validated techniques.
52 51
ACKNOWLEDGMENTS We thank Edwin Rabbitte for helping us with the evaluation analysis of an early version of the GT-DSS, and the experts in GSD who participated in the evaluation of the GT-DSS. This work was supported, in part, by Science Foundation Ireland grant 03/CE2/I303 1 to Lero - the Irish Software Engineering Research Centre (www.lero.ie).
[11]
[12]
R EFERENCES [1] J. S. Persson, L. Mathiassen, J. Boeg, T. S. Madsen, and F. Steinson, “Managing risks in distributed software projects: An integrative framework,” IEEE Transactions on Engineering Management, vol. 56, no. 3, pp. 508– 532, 2009. [2] A. Lamersdorf, J. Munch, A. F. del Viso Torre, C. R. Sanchez, M. Heinz, and D. Rombach, “A rule-based model for customized risk identification in distributed software development projects,” in Proceedings of the Fifth IEEE International Conference on Global Software Engineering (ICGSE). Limerick, Ireland: IEEE Computer Society, 2010, pp. pp.209–218. [3] S. Sahay, “Global software alliances: the challenge of standardization,” Scandinavian Journal of Information Systems, vol. 15, pp. 3–21, 2003. [4] R. Prikladnicki, J. L. N. Audy, and F. Shull, “Patterns in effective distributed software development,” IEEE Software, vol. 27, no. 2, pp. 12–15, 2010. [5] R. Prikladnicki, S. J. Audy, and F. Shull, “Process models in the practice of distributed software development: A systematic review of the literature,” Information and Software Technology, vol. 52, no. 8, pp. 779–791, 2010. [6] M. Jime´nez, M. Piattini, and A. Vizcai´no, “Challenges and improvements in distributed software development: A systematic review,” Advances in Software Engineering, no. 2, 2009, article ID 710971. [7] T. Ebling, J. L. N. Audy, and R. Prikladnicki, “A systematic literature review of requirements engineering in distributed software development environments,” in Proceedings of the 11th International Conference on Enterprise Information Systems (ICEIS ’09), Milan, Italy, 2009. [8] S. Khan, M. Niazi, and R. Ahmad, “Critical success factors for offshore software development outsourcing vendors: A systematic literature review,” in Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE ’09). Limerick, Ireland: IEEE Computer Society, 2009, pp. 207–216. [9] D. Smite, C. Wohlin, T. Gorschek, and R. Feldt, “Empirical evidence in global software engineering: A systematic review,” Empirical Software Engineering, vol. 15, no. 1, pp. 91–118, 2010. [10] E. Hossain, M. A. Babar, and P. Hye-Young, “Using scrum in global software development: A systematic literature review,” in Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineer-
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21] [22]
[23]
[24]
[25]
53 52
ing (ICGSE ’09). Limerick, Ireland: IEEE Computer Society, 2009, pp. 175–184. S. Beecham, J. Noll, I. Richardson, and N. Ali, “Crafting a global teaming model for architectural knowledge,” in Proceedings of the Fifth IEEE International Conference on Global Software Engineering (ICGSE). Limerick, Ireland: IEEE Computer Society, 2010. J. Noll, S. Beecham, and I. Richardson, “Global software development and collaboration: Barriers and solutions,” ACM Inroads - SIGCSE Journal Bulletin, vol. 1, no. 3, pp. 66–72, 2010. I. Richardson, V. Casey, J. Burton, and F. McCaffery, “Global software engineering: A software process approach, in collaborative software engineering,” I. Mistrik, J. Grundy, A. van de Hoek, and J. Whitehead, Eds. Springer-Verlag/Computer Science Editorial, 2010. E. Carmel, Global Software Teams: Collaboration Across Borders and Time Zones. Saddle River, NJ: Prentice Hall, 1999. ˚ P. J. Agerfalk and B. Fitzgerald, “Flexible and distributed software processes: old petunias in new bowls?” Communications of the ACM, vol. 49, no. 10, pp. 26–34, 2006. A. F. Rutkowski, D. R. Vogel, M. V. Genuchten, T. M. A. Bemelmans, and M. Favier, “E-collaboration: The reality of virtuality,” IEEE Transactions on Professional Communication, vol. 45, no. 4, pp. 219–230, 2002. V. Casey, “Leveraging or exploiting cultural difference?” in Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE ’09). Limerick, Ireland: IEEE Computer Society, 2009. S. Krishna, S. Sahay, and G. Walsham, “Managing crosscultural issues in global software outsourcing,” Communications of the ACM, vol. 47, no. 4, pp. 62–66, 2004. E. Carmel and P. Tjia, Offshoring Information Tecnhnology: Sourcing and Outsourcing to a Global Workforce. Cambridge, U.K.: Cambridge University Press, 2005. J. D. Herbsleb, “Global software engineering: The future of socio-technical coordination,” in Future of Software Engineering (FOSE’07). Minneapolis, MN, USA: IEEE, 2007, pp. 188–198. CMMI Product Team, “Capability Maturity Model c for Development,” Tech. Rep., 2006. Integration G. M. Marakas, Decision support systems in the 21st century. Upper Saddle River, New Jersey, USA: Prentice Hall Inc, 2003. P. G. W. Keen and M. S. Scott-Morton., Decision Support Systems: An Organizational Perspective. Reading, MA: Addison-Wesley, 1978. C. Holsapple and A. Whinston, Decision Support Systems: A Knowledge-Based Approach. Minneapolis/St. Paul, MN: West Publishing, 1996. D. Merritt, Building Expert Systems in Prolog (On-line Edition). Amzi!, Inc, 2000.
