global software development Distribution Dimensions in Software Development Projects: A Taxonomy

focus global software development Distribution Dimensions in Software Development Projects: A Taxonomy Dorina C. Gumm, University of Hamburg A literature-based taxonomy identifies four distribution dimensions in distributed software development. A case study illustrates their application in a real-world development project. For many economic and technological reasons, companies are increasingly conducting projects on a global level. 1,2 Global projects are highly distributed, with experts from different companies, countries, and continents working together. Such distribution requires new techniques for project coordination, document management, and communication. 3 Distribution complexities include various project types such as global, interorganizational, or open source software projects that are distributed in different ways and face particular challenges. Some researchers focus on problems of global distribution and related lessons learned, 4,5 whereas others emphasize distribution as an advantage in software development that speeds the development process for example, in OSS projects. 6 However diverse the project and whatever the perceived benefits or drawbacks, understanding the underlying distribution phenomenon is crucial to analyzing existing methods and tools for their applicability in distributed project settings. This understanding is also important when proposing new methods or tools. To negotiate distributed project requirements, for example, requires an understanding of distributed project stakeholders. Likewise, requirement document consistency might be related to distributed artifacts. In this article, I seek to explain the distributed software development phenomenon. My goal is to provide developers and other stakeholders a foundation for discussing specific challenges they might face in distributed software development projects. To this end, I present a taxonomy based on an earlier literature study. 7 Here, I continue this earlier work by using a case study to exemplify the taxonomy s use and substantiate its value. Distributed software development literature Understanding distributed project issues is a challenge not just for global software development, but also for software research areas such as OSS development and computer-supported cooperative work. In addition, several papers in the literature consider distribution from specialized software engineering fields, such as requirements engineering 8,9 and par- 0740-7459/06/$20.00 2006 IEEE September/October 2006 IEEE SOFTWARE 45

What is distributed (people, artifacts, tasks, power, skills, and so on) and in what way (physically, organizationally, temporally) Figure 1. The cycle of distribution challenges. ticipatory design. 10,11 Regardless of the differing viewpoints, in all areas technical solutions as well as social challenges are discussed. Most existing work reports on case studies that either faced special challenges of distributed people or artifacts or found solutions for specific problems. Some researchers aim at a broader view: J. Roberto Evaristo and Richard Scudder identify distributed project dimensions, 12 while Rafael Prikladnicki and his colleagues refine that work and provide a physical distribution typology. 13 In other work, Maria Paasivaara identifies types of distributed projects. 2 In my literature analysis, I found that researchers discuss distribution topics from several different perspectives, each of which entails specific issues: Distribution challenges (version control, cultural differences, communication, and so on) Solutions (tools, methods, and so on) Who or what is distributed? For example, when people are distributed, challenges include coordinating communications and workflow, and managing cultural differences. Distributed artifact challenges relate to who s responsible for various artifacts and their version control. In what way are people and other entities distributed? For example, in some projects, it s important to distinguish between stakeholders distributed among different geographical locations and those distributed among different companies. What are the distribution s specific challenges? Challenges might include the previously mentioned version control issues, cultural differences, or coordination of synchronous or asynchronous communication. How can distribution challenges best be solved? Developers address some challenges through social solutions (such as project management and mutual understanding) while others require technical solutions (such as tools for coordination and communication and for managing the programming process). This technology use can in turn create new distribution problems as well as create and support distributed project settings. Figure 1 shows the connections between these perspectives: distributed entities cause specific challenges which in turn are handled by specific solutions. Such solutions might then give rise to new challenges. For example, some solutions, such as Internet-based communication tools, can both create and support distributed project settings. Dimensions of distribution: A taxonomy To clarify the distribution phenomenon and thus create a preliminary taxonomy I distinguish issues that describe distribution itself from issues that distribution creates in the project setting. The dimensional description refers to distribution itself and so to the questions of who or what is distributed and in what way. I don t include individual challenges and solutions because they result from distribution rather than being part of the phenomenon itself. The taxonomy uses dimensions to describe the ways in which people or artifacts are distributed. According to the Merriam-Webster Online Dictionary, dimension typically refers to a physical property and is the range over which or the degree to which something extends. The term distribution describes the position of occurrence (as of the members of a group) over an area or throughout a space or unit of time. Because distribution occurs in different degrees and, like space, seems to occur along a continuum, it seems adequate to describe distribution using the dimension concept. In software development projects, there are four basic distribution dimensions, each of which can range from lightly to heavily distributed. According to the literature, those dimensions are physical (or geographical) distribution, organizational distribution, temporal distribution, and distribution among stakeholder groups. Individuals and stakeholder groups can be distributed among physical space, organizations, 46 IEEE SOFTWARE www.computer.org/software

and time, whereas other entities can be distributed among physical space, organizations, and stakeholder groups. Figures 2 and 3 from the case study (p. 49) illustrate these findings. is one characteristic of distributed projects. 2 People and things can be distributed among different physical locations and to different degrees. In some projects, distributed people or objects among different floors in the same building can be a challenging distance. Other projects deal with location distributions in the same city, among different cities or countries, or even among different continents. of people is the literature s most discussed topic. Such distribution occurs both in global software development, where organizations from different countries work together as partners or suppliers, 4,5 as well as in large OSS projects with numerous international contributors. 6 Prikladnicki and colleagues have developed a detailed typology for physical distribution among users, customers, and project teams, as well as within project teams. 13 is another characteristic of distributed projects. 2 Organizational distribution is related to the structures people work in on the project, but these structures don t necessarily represent their everyday work or employer environments. Although the structure might refer to a company or noncommercial organization, it might also refer to any other project structure that describes the organized work s condition or state. The target organizations might be partners, subcontractors, suppliers, customers, or consultants. In customer-specific software development projects, the typical organizations involved are the software supplier, the customer s company, and a consulting firm. Developers in OSS development projects often simultaneously work for different companies. 6 However, these companies don t typically play a specific project role, but rather represent the developers background experience. Another example of organizational distribution is when several divisions of one company are involved in a project. 12 Finally, many research projects involve people from different institutions working together on a particular problem. 14 Temporal distribution Researchers have also identified temporal distribution as a primary characteristic of distributed projects. 12,15 This type of distribution refers to work-hour synchronicity 12 that is, the time during which project members are available for real-time interactions. 15 Time separations might be rooted in physical distribution across different time zones. It might also result from shift work or varying working rhythms, as when people work part-time on OSS projects. In the latter case, time separation is viewed as an advantage because it might speed development. 6 Distribution across stakeholder groups Artifacts, skills, and other entities can be distributed not only across locations and organizations, but also among stakeholder groups. Requirements specifications, for example, are often distributed among users, managers, analysts, and developers. Such distribution requires significant document management effort when requirements are documented from different viewpoints, at different detail levels, and with varying documentation tools. The literature discusses both artifact distribution 6,16 and task distribution. 5,12 Understanding distribution in a given project To analyze a project s distribution, you must first identify its distributed entities along the taxonomy s dimensions. You should base this analysis on observable project settings, such as organigrams or the locations of people and organizations. In addition, you must also account for the people s perceived distances, which might differ from their actual distances. Examples of distributed entities Software projects might deal with distribution within single stakeholder groups or among several stakeholder groups, as well as distributed entities such as software code, documentation, tasks, or power. If a company uses software experts from different countries on a global project, physical distribution within the developer group is likely the most important factor. Also, in OSS projects, the developer community is often distributed both physically and organizationally. 17 Distribution among stakeholder groups is given if developers and analysts reside in different countries, To analyze a project s distribution, you must first identify its distributed entities along the taxonomy s dimensions. September/October 2006 IEEE SOFTWARE 47

The perceiveddistance concept is applicable not only to physical distribution but also to organizational or temporal distribution. which often entails physical, temporal, and organizational distribution issues. In addition, the boundaries separating stakeholder groups are often blurred. In OSS projects, for example, users can join the development community even without having to actually program. 6 Furthermore, participatory design approaches aim to decrease user and developer distribution so that designers participate in users worlds, users participate in design activities, or both. 18 In a distributed project, if this happens successfully that is, the development team consists of users and developers distribution between two stakeholder groups changes to distribution within the developer group. As for artifact distribution, a requirements specification document example illustrates several issues. In one project, the document might be organizationally distributed among customer and supplier organizations. In another project, it might be distributed only within a customer organization, but among different stakeholder groups (users and managers, for example). In this case, the physical distribution is entailed in the organizational distribution. Still, the physical distribution level might vary from a few folders on a hard disk to numerous computers in different countries. In a third project, the document might be dispersed across all dimensions. Perceived distance You can easily analyze observable project settings using project documents, for example, that describe who s involved, where they re located, and so on. However, the perceived distance in each dimension also plays a major role in a project s dispersion. Evaristo and Scudder measure people s and stakeholder group s dispersion level by the perceived distance among the members sharing a particular role as well as by the perceived distance between this role group and all the others. 12 The perceived-distance concept is applicable not only to physical distribution but also to organizational or temporal distribution. Project members who are organizationally distributed but work closely together at the same place and during the same working hours might perceive the organizational distance as low, whereas members working in different locations and across organizations would likely perceive the organizational distance as high. The perceived temporal distance might vary according to the project s established communication mechanisms and culture. Team members who established a good asynchronous communication culture might perceive temporal distance as low, whereas people who prefer meetings or telephone calls might perceive temporal distance as high. The CommSy case study The University of Hamburg s CommSy project 19 offers a case study in how to apply the taxonomy, correlate dimensions, and relate specific challenges to those dimensions. Launched in 1999, CommSy is a Web-based community system (or groupware) developed to support education and networked project work. Although originally started to support university education, CommSy is now used in different contexts, including schools, freelancer networks, and small companies. The project setting has also changed several times: what started as an extracurricular project evolved into a research project and is now an open source project with several smaller subprojects. Project characteristics The CommSy project consists of different independent projects whose members maintain CommSy and further develop it for special contexts. However, the project s goal is to maintain one joint development, and I m referring to this joint development here. Although not a global project, CommSy is highly distributed and thus a suitable example for applying the taxonomy. One CommSy research topic is to analyze and improve the project s requirements engineering process. CommSy has an increasing number of users, application contexts, and usage locations. This distribution complicates the participatory process of requirements understanding, and the various independent projects complicate internal requirements management. Thus, one requirements engineering challenge is to understand the character and key issues of distribution within this project. When analyzing the CommSy project distribution, we can focus on individual subprojects or on the joint CommSy development efforts. As figures 2 and 3 show, distribution varies within the project. The physical distribution within the project team is rather small, as most members work in 48 IEEE SOFTWARE www.computer.org/software

the university s Department of Informatics. However, some distribution remains because team members are employed by different department sections and thus work in different buildings and on different floors. The perception of distance therefore varies by team member and his or her particular project role. Also, some members have moved to positions outside the university and have either maintained close contact with project members or withdrawn from the project. Finally, some project members temporarily work in other countries. This distance is indeed a challenge, but hasn t played a major role because it s temporary. Generally, physical distance within the project team causes problems in information exchange and process transparency. The physical distribution between the project team and the users, as well as among user groups, is on a higher level. Although the largest user group is in the Department of Informatics, the number of external users continually increases. Different organizations in Hamburg as well as in many other German cities use CommSy, and some user groups are even outside Germany. This physical distribution causes problems in the participatory design process. It might be that few users participate in the process because it s such a large user group and most users simply aren t interested. In any case, the distance hampers efforts to bring team members and users together. Other physically distributed entities include software code and requirements. To cope with the distribution, the team maintains the software code on the SourceForge open source platform. Requirements and their documentation are also physically distributed because the team manages and documents requirements and decisions about the implementation on SourceForge as well as in the CommSy project room software and at face-to-face meetings. This distribution of requirements and related documentation necessitates extra effort to keep the requirements engineering process transparent and traceable. U PT/U U/U Temporal distribution Most team members not only work in different locations within the Department of Informatics, they also belong to different research projects and handle the projects respective user groups. In addition, some team members work in different disciplines. This organizational distribution creates challenges, such as commitment difficulties: it s often hard for members to give commitments that others can count on. In PT High PT/U Figure 2. Distribution dimensions for individuals and groups in the CommSy project. Rectangles indicate a subproject, and ovals indicate the overall project. PT represents distribution within the project team; PT/U, distribution between project team and users; U/U, distribution among user groups; and U, distribution within a user group. Group internal Req Distribution among groups Among several groups Figure 3. Distribution dimensions for artifacts and other entities in the CommSy project. Rectangles indicate a subproject and ovals indicate the overall project. Req represents requirements and their documentation. PT Req September/October 2006 IEEE SOFTWARE 49

Among user groups, organizational distribution emerged as a bigger challenge than physical distribution. the past, this was particularly problematic during strategic planning. also means that team members have different views on what s important in the developing process. Team members perception of organizational distance varies according to individuals and by project phase. Among user groups, organizational distribution emerged as a bigger challenge than physical distribution. CommSy operates in many different contexts. Within the university, various disciplines from computer science to pedagogy to linguistics use the system. External organizations, such as companies and schools, also use CommSy. Given its wide application field, CommSy users have widely varying backgrounds and attitudes. Among the organizational distribution challenges we face are different (and sometimes contradicting) usability and functionality requirements that hamper the goal of a common system vision. Requirements are organizationally distributed because they emerge in different user organizations where they are discussed with the dedicated team members. This not only challenges process transparency, but requires extra effort to consolidate and negotiate requirements. Temporal distribution The project team s temporal distribution is rooted in members asynchronous working times, which is in turn rooted in the organizational distribution. In addition, most team members work only part-time on the project. Thus, common working hours are rare and make information exchange and transparent development difficult. Temporal distribution plays a minor role in interaction between the development team and users. Such interaction consists mainly of single workshop and interview meetings, along with extended user support, all of which involve only the typical coordination problems. Because the development team mediates the interaction between user groups, the temporal distribution between user groups plays a similar minor role. Distribution across stakeholder groups Requirements are dispersed among stakeholder groups because they appear in different user groups and must be transferred to the project team. In turn, the project team must send requirements-handling decisions back to user groups. So, the distribution among stakeholder groups and the challenges entailed are tightly connected to the organizational distribution. Decision-making power is also distributed among stakeholder groups. This distribution is rooted in the flat hierarchy and the project team s voluntary status, as well as in the existence of different customers. Such distribution creates challenges regarding project management, commitments, and requirements negotiation. Results The CommSy case study illuminates several challenges related to physical and organizational distribution, and how project teams can deal with them. Physical distance. Although physical distance is indeed a challenge, it is not a big one for two reasons. First, most team members are located close enough to enable regular meetings. Second, they have good, technology-based communication. The team copes with user group distance by providing personal support, organizing workshops, and conducting online surveys. Organizational distance. The project s organizational distance emerged as the major challenge, creating difficulties in maintaining a common product vision and in establishing process transparency. User group distribution challenges the team s desire to use participative design methods because users work in very different contexts and thus have different viewpoints, needs, and requirements. As a result, the CommSy team must invest extra effort to evaluate conflicting requirements, make decisions transparent, and maintain a common system vision. When improving the project s requirements engineering process, the team must therefore pay particular attention to organizational distribution. That is, they must consolidate requirements from different contexts to maintain a common system vision; negotiate conflicting requirements; and provide bidirectional feedback among project team members and user groups, and even among different user groups. Current endeavors to meet these requirements include providing mediated feedback to 50 IEEE SOFTWARE www.computer.org/software

improve our transparent participatory process 10 and explore commented case studies to support cross-contextual software development. 20 The CommSy case study analysis offers two primary benefits. First, it shows how the taxonomy can help team members understand their project s particular distribution issues and their scope. Second, it offers a real-world example in which organizational distribution is a bigger challenge than physical distribution. CommSy isn t a global project. However, it raises issues that global software projects must contend with, and shows how they might use the taxonomy to understand the nature of distribution in their own projects. That said, the literature study I based the taxonomy on could be expanded, either within the target areas or by consulting broader literature, such as that on virtual teams or project management. In addition, the selected literature reports mainly on case studies about distribution problems and practices and doesn t include social or organizational theories. This might be a weakness, because it likely creates an incomplete model. However, it might also be a strength, because it grounds the dimensions in practical challenges. In any case, there is further work to do. I plan a more detailed discussion of the correlations between the dimensions, as well as of individual challenges. References 1. H. Holz, S. Goldmann, and F. Maurer, Working Group Report on Coordinating Distributed Software Development Projects, Proc. 7th IEEE Int l Workshops Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 98), IEEE CS Press, 1998, pp. 69 72. 2. M. Paasivaara, Communication Needs, Practices and Supporting Structures in Global Inter-Organizational Software Development Projects, Proc. 3rd Int l Workshop Global Software Development (GSD 04), pp. 59 63; http://gsd2004.uvic.ca/docs/proceedings.pdf. 3. S. Goldmann and B. Kötting, Working Group Report of the 2nd Workshop on Coordinating Distributed Software Development Projects, Proc. 8th Workshops Enabling Technologies on Infrastructure for Collaborative Enterprises (WETICE 99), IEEE CS Press, 1999, pp. 9 14. 4. S. Krishna, S. Sahay, and G. Walsham, Managing Crosscultural Issues in Global Software Outsourcing, Comm. ACM, vol. 47, no. 4, 2004, pp. 62 66. 5. M. Turnlund, Distributed Development: Lessons Learned, Distributed Development, vol. 1, no. 9, 2004, pp. 26 31. 6. J. Feller and B. Fitzgerald, Understanding Open Source Software Development, Addison-Wesley, 2001. 7. D.C. Gumm, The Phenomenon of Distribution in Software Development Projects: A Taxonomy Proposal, About the Author Dorina C. Gumm is a scientific assistant in the Department of Informatics at the University of Hamburg where she s been involved in the CommSy project since 1999. Her research combines requirements engineering, distributed software development, community systems, and participatory design. Gumm has a diploma in computer science from the University of Hamburg. Contact her at gumm@informatik.uni-hamburg.de. Proc. European Mediterranean Conf. Information Systems (EMCIS 05), Information Inst., 2005; www.iseing. org/emcis/emcis2005/papers.htm. 8. D.E. Damian et al., An Exploratory Study of Facilitation in Distributed Requirements Engineering, Requirements Eng., vol. 8, no. 1, 2003, pp. 23 41. 9. D. Herlea and S. Greenberg, Using a Groupware Space for Distributed Requirements Engineering, Proc. 7th IEEE Int l Workshops Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 98), IEEE CS Press, 1998, pp. 57 62. 10. M. Finck, D.C. Gumm, and B. Pape, Using Groupware for Mediated Feedback, Proc. 8th Biennial Participatory Design Conf. Workshop Artful Integration: Interweaving Media, Materials and Practices (PDC 04), ACM Press, 2004, pp. 45 48. 11. A.M. Oostveen and P. van den Besselaar, From Small Scale to Large Scale User Participation: A Case Study of Participatory Design in Egovernment Systems, Proc. 8th Conf. Participatory Design (PDC 04), ACM Press, 2004, pp. 173 182. 12. J.R. Evaristo and R. Scudder, Geographically Distributed Project Teams: A Dimensional Analysis, Proc. 33rd Hawaii Int l Conf. System Sciences (HICSS 00), IEEE CS Press, 2000, pp. 7052 7063. 13. R. Prikladnicki, J.L.N. Audy, and J.R. Evaristo, Distributed Software Development: Toward an Understanding of the Relationship between Project Team, Users and Customers, Proc. 5th Int l Conf. Enterprise Information Systems (ICEIS 03), 2003, vol. 3, pp. 417 423. 14. E. Doerry et al., Participatory Design for Widely- Distributed Scientific Communities, Proc. 3rd Conf. Human Factors and the Web, 1997; www.grs.nig.ac.jp: 6070/zf_info/dbase/PAPERS/Web97/web97-final.html. 15. J.A. Espinosa and E. Carmel. Modeling Coordination Costs Due to Time Separation in Global Software Teams, Proc. Int l Workshop Global Software Development (GSD 03), pp. 64 68; http://gsd2003.cs.uvic.ca/ gsd2003proceedings.pdf. 16. W. Scacchi, Understanding the Requirements for Developing Open Source Software Systems, IEEE Proceedings Software, vol. 149, no. 1, 2002, pp. 24 39. 17. D. Čubranić and K.S. Booth, Coordinating Open- Source Software Development, Proc. 8th IEEE Int l Workshops Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 99), IEEE CS Press, 1999, pp. 61 65. 18. M.J. Muller, D.M. Wildman, and E.A. White, Taxonomy of PD Practices: A Brief Practitioner s Guide, Comm. ACM, vol. 36, no. 6, 1993, pp. 26 27. 19. I. Jackewitz et al., Teaching Social Informatics as a Knowledge Project, Informatics and the Digital Society, T.J. van Weert and R.K. Munro, eds., Kluwer Academic Publishers, 2003, pp. 261 268. 20. M. Finck, H. Obendorf, and B. Pape, Fallbeispiele der CommSy-Nutzung Eine Sammlung von Nutzungsberichten [Case Studies of CommSy Usage A Collection of Usage Reports], Berichte des Fachbereichs Informatik der Universität Hamburg, FBI-HH-B-261/040, 2004 (in German). September/October 2006 IEEE SOFTWARE 51