focus
are distributed in different ways and face par-ticular challenges. Some researchers focus on problems of global distribution and related lessons learned,4,5 whereas others emphasize
distribution as an advantage in software de-velopment that speeds the dede-velopment process—for example, in OSS projects.6
However diverse the project and whatever the perceived benefits or drawbacks, under-standing the underlying distribution phenom-enon is crucial to analyzing existing methods and tools for their applicability in distributed project settings. This understanding is also im-portant when proposing new methods or tools. To negotiate distributed project require-ments, 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
distrib-uted software development phenomenon. My goal is to provide developers and other stake-holders a foundation for discussing specific challenges they might face in distributed soft-ware development projects. To this end, I pres-ent a taxonomy based on an earlier literature study.7 Here, I continue this earlier work by
using a case study to exemplify the taxon-omy’s use and substantiate its value.
Distributed software development literature
Understanding distributed project issues is a challenge not just for global software devel-opment, but also for software research areas such as OSS development and computer-sup-ported cooperative work. In addition, several papers in the literature consider distribution from specialized software engineering fields, such as requirements engineering8,9 and
par-Distribution Dimensions in
Software Development
Projects: A Taxonomy
F
or many economic and technological reasons, companies are
in-creasingly conducting projects on a global level.
1,2Global projects
are highly distributed, with experts from different companies,
countries, and continents working together. Such distribution
re-quires new techniques for project coordination, document management, and
communication.
3Distribution complexities include various project types—
such as global, interorganizational, or open source software projects—that
global software development
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.
ticipatory design.10,11 Regardless of the
differ-ing 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 distrib-uted 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 dimen-sions,12while Rafael Prikladnicki and his
col-leagues refine that work and provide a physi-cal distribution typology.13 In other work,
Maria Paasivaara identifies types of distrib-uted projects.2
In my literature analysis, I found that re-searchers discuss distribution topics from sev-eral different perspectives, each of which en-tails specific issues:
■ Who or what is distributed? For example,
when people are distributed, challenges in-clude coordinating communications and workflow, and managing cultural differ-ences. Distributed artifact challenges re-late to who’s responsible for various arti-facts and their version control.
■ In what way are people and other entities
distributed? For example, in some proj-ects, it’s important to distinguish between stakeholders distributed among different geographical locations and those distrib-uted among different companies.
■ What are the distribution’s specific
chal-lenges? Challenges might include the pre-viously mentioned version control issues, cultural differences, or coordination of syn-chronous or asynsyn-chronous 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 commu-nication and for managing the program-ming process). This technology use can in turn create new distribution problems as well as create and support distributed proj-ect settings.
Figure 1 shows the connections between these perspectives: distributed entities cause specific challenges which in turn are handled by spe-cific solutions. Such solutions might then give rise to new challenges. For example, some so-lutions, 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 dis-tinguish issues that describe distribution itself from issues that distribution creates in the proj-ect 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 be-cause 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 dis-tributed. 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 ex-tends.” 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 de-scribe distribution using the dimension concept. In software development projects, there are four basic distribution dimensions, each of which can range from lightly to heavily dis-tributed. According to the literature, those di-mensions are
■ physical (or geographical) distribution, ■ organizational distribution,
■ temporal distribution, and
■ distribution among stakeholder groups. Individuals and stakeholder groups can be dis-tributed among physical space, organizations, Distribution challenges (version control, cultural differences, communication, and so on) Solutions (tools, methods, and so on) Cause Cause Cause What is distributed
(people, artifacts, tasks, power, skills, and so on) and in what way (physically,
organizationally, temporally)
Cause
Figure 1. The cycle of distribution challenges.
and time, whereas other entities can be dis-tributed among physical space, organizations, and stakeholder groups. Figures 2 and 3 from the case study (p. 49) illustrate these findings.
Physical distribution
Physical distribution is one characteristic of distributed projects.2People and things can be
distributed among different physical locations and to different degrees. In some projects, dis-tributed people or objects among different floors in the same building can be a challenging dis-tance. Other projects deal with location distribu-tions in the same city, among different cities or countries, or even among different continents.
Physical distribution of people is the litera-ture’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, cus-tomers, and project teams, as well as within project teams.13
Organizational distribution
Organizational distribution is another char-acteristic of distributed projects.2
Organiza-tional distribution is related to the structures people work in on the project, but these struc-tures don’t necessarily represent their everyday work or employer environments. Although the structure might refer to a company or noncom-mercial organization, it might also refer to any other project structure that describes the organ-ized work’s condition or state.
The target organizations might be partners, subcontractors, suppliers, customers, or con-sultants. In customer-specific software devel-opment projects, the typical organizations in-volved are the software supplier, the customer’s company, and a consulting firm. Developers in OSS development projects often simultane-ously work for different companies.6However,
these companies don’t typically play a specific project role, but rather represent the develop-ers’ background experience. Another example of organizational distribution is when several divisions of one company are involved in a project.12 Finally, many research projects
in-volve people from different institutions work-ing together on a particular problem.14
Temporal distribution
Researchers have also identified temporal distribution as a primary characteristic of dis-tributed projects.12,15This type of distribution
refers to work-hour synchronicity12—that is,
the time during which project members are available for real-time interactions.15 Time
separations might be rooted in physical distri-bution 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 separa-tion 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 or-ganizations, but also among stakeholder groups. Requirements specifications, for ex-ample, are often distributed among users, managers, analysts, and developers. Such dis-tribution requires significant document man-agement effort when requirements are docu-mented from different viewpoints, at different detail levels, and with varying documentation tools. The literature discusses both artifact dis-tribution6,16and 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 distribu-tion within single stakeholder groups or among several stakeholder groups, as well as distributed entities such as software code, doc-umentation, 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.17Distribution
among stakeholder groups is given if develop-ers and analysts reside in different countries,
To analyze a
project’s
distribution,
you must first
identify its
distributed
entities along
the taxonomy’s
which often entails physical, temporal, and or-ganizational distribution issues.
In addition, the boundaries separating stake-holder groups are often blurred. In OSS projects, for example, users can join the development community even without having to actually pro-gram.6 Furthermore, participatory design
ap-proaches aim to decrease user and developer dis-tribution so that designers participate in users’ worlds, users participate in design activities, or both.18In a distributed project, if this happens
successfully—that is, the development team con-sists of users and developers—distribution be-tween two stakeholder groups changes to distri-bution within the developer group.
As for artifact distribution, a requirements specification document example illustrates sev-eral 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 or-ganization, 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 differ-ent countries. In a third project, the documdiffer-ent 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 lo-cated, and so on. However, the perceived dis-tance 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 per-ceived 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 applica-ble not only to physical distribution but also to organizational or temporal distribution. Project members who are organizationally dis-tributed 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 lo-cations and across organizations would likely perceive the organizational distance as high. The perceived temporal distance might vary according to the project’s established
commu-nication mechanisms and culture. Team mem-bers who established a good asynchronous communication culture might perceive tempo-ral 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 project19offers a case study in how to apply
the taxonomy, correlate dimensions, and re-late 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 main-tain CommSy and further develop it for spe-cial contexts. However, the project’s goal is to maintain one joint development, and I’m re-ferring to this joint development here. Al-though not a global project, CommSy is highly distributed and thus a suitable example for ap-plying the taxonomy.
One CommSy research topic is to analyze and improve the project’s requirements engi-neering process. CommSy has an increasing number of users, application contexts, and us-age locations. This distribution complicates the participatory process of requirements under-standing, 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 dis-tribution, we can focus on individual subpro-jects or on the joint CommSy development ef-forts. As figures 2 and 3 show, distribution varies within the project.
Physical distribution
The physical distribution within the project team is rather small, as most members work in
The
perceived-distance
concept is
applicable not
only to physical
distribution but
also to
organizational
or temporal
distribution.
the university’s Department of Informatics. However, some distribution remains because team members are employed by different de-partment sections and thus work in different buildings and on different floors. The percep-tion of distance therefore varies by team mem-ber and his or her particular project role. Also, some members have moved to positions out-side the university and have either maintained close contact with project members or with-drawn 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 ex-change and process transparency.
The physical distribution between the proj-ect 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 In-formatics, the number of external users con-tinually 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 distribu-tion causes problems in the participatory de-sign process. It might be that few users partic-ipate in the process because it’s such a large user group and most users simply aren’t inter-ested. 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 soft-ware code on the SourceForge open source platform. Requirements and their documenta-tion 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.
Organizational distribution
Most team members not only work in dif-ferent locations within the Department of In-formatics, 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
dis-tribution creates challenges, such as commit-ment difficulties: it’s often hard for members to give commitments that others can count on. In
Low Medium High
Organizational distribution Physical distribution Low Medium High Temporal dis tribution PT/U U/U PT U PT PT/U High
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.
Among several
groups
Group internal
Low Medium High
Organizational distribution Physical distribution Low Medium High Distribution amo ng groups Req Req
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.
the past, this was particularly problematic dur-ing strategic planndur-ing. Organizational distribu-tion also means that team members have differ-ent views on what’s important in the developing process. Team members’ perception of organi-zational distance varies according to individu-als and by project phase.
Among user groups, organizational distri-bution 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. Exter-nal organizations, such as companies and schools, also use CommSy. Given its wide ap-plication field, CommSy users have widely varying backgrounds and attitudes. Among the organizational distribution challenges we face are different (and sometimes contradicting) us-ability and functionality requirements that hamper the goal of a common system vision.
Requirements are organizationally distrib-uted because they emerge in different user or-ganizations 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 organiza-tional 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. Be-cause the development team mediates the in-teraction between user groups, the temporal distribution between user groups plays a simi-lar minor role.
Distribution across stakeholder groups
Requirements are dispersed among stake-holder groups because they appear in differ-ent 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 organi-zational 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 dif-ferent customers. Such distribution creates chal-lenges regarding project management, commit-ments, and requirements negotiation.
Results
The CommSy case study illuminates several challenges related to physical and organiza-tional 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. Sec-ond, they have good, technology-based commu-nication. The team copes with user group dis-tance by providing personal support, organizing workshops, and conducting online surveys. Organizational distance. The project’s organiza-tional distance emerged as the major challenge, creating difficulties in maintaining a common product vision and in establishing process transparency. User group distribution chal-lenges the team’s desire to use participative de-sign methods because users work in very dif-ferent contexts and thus have difdif-ferent viewpoints, needs, and requirements. As a re-sult, the CommSy team must invest extra effort to evaluate conflicting requirements, make de-cisions transparent, and maintain a common system vision.
When improving the project’s requirements engineering process, the team must therefore pay particular attention to organizational dis-tribution. That is, they must
■ consolidate requirements from different con-texts 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 require-ments include providing mediated feedback to
Among user
groups,
organizational
distribution
emerged as a
bigger
challenge than
physical
distribution.
improve our transparent participatory process10
and explore commented case studies to support cross-contextual software development.20
T
he CommSy case study analysisof-fers two primary benefits. First, it shows how the taxonomy can help team members understand their project’s par-ticular distribution issues and their scope. Sec-ond, it offers a real-world example in which organizational distribution is a bigger chal-lenge 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 stud-ies 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 correla-tions between the dimensions, as well as of in-dividual challenges.
References
1. H. Holz, S. Goldmann, and F. Maurer, “Working Group Report on Coordinating Distributed Software Development Projects,” Proc. 7th IEEE Int’l
Work-shops Enabling Technologies: Infrastructure for Collab-orative Enterprises (WETICE98), 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
Work-shop 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 Soft-ware Development Projects,” Proc. 8th Workshops
abling Technologies on Infrastructure for Collaborative En-terprises (WETICE99), 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 Soft-ware Development Projects: A Taxonomy Proposal,”
Proc. European Mediterranean Conf. Information Sys-tems (EMCIS05), Information Inst., 2005; www.iseing.
org/emcis/EMCIS2005/papers.htm.
8. D.E. Damian et al., “An Exploratory Study of Facilita-tion in Distributed Requirements Engineering,”
Re-quirements 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: Infra-structure for Collaborative Enterprises (WET ICE 98),
IEEE CS Press, 1998, pp. 57–62.
10. M. Finck, D.C. Gumm, and B. Pape, “Using Group-ware for Mediated Feedback,” Proc. 8th Biennial
Par-ticipatory 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 Distrib-uted Project Teams: A Dimensional Analysis,” Proc.
33rd Hawaii Int’l Conf. System Sciences (HICSS00),
IEEE CS Press, 2000, pp. 7052–7063.
13. R. Prikladnicki, J.L.N. Audy, and J.R. Evaristo, “Dis-tributed Software Development: Toward an Understand-ing of the Relationship between Project Team, Users and Customers,” Proc. 5th Int’l Conf. Enterprise
Informa-tion 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
Devel-opment (GSD 03), pp. 64–68; http://gsd2003.cs.uvic.ca/
gsd2003proceedings.pdf.
16. W. Scacchi, “Understanding the Requirements for De-veloping Open Source Software Systems,” IEEE
Pro-ceedings—Software, vol. 149, no. 1, 2002, pp. 24–39.
17. D. ˇCubrani´c 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, “Taxon-omy 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
Soci-ety, T.J. van Weert and R.K. Munro, eds., Kluwer
Aca-demic Publishers, 2003, pp. 261–268.
20. M. Finck, H. Obendorf, and B. Pape, “Fallbeispiele der CommSy-Nutzung–Eine Sammlung von Nutzungs-berichten” [Case Studies of CommSy Usage–A Collection of Usage Reports], Berichte des Fachbereichs Informatik der Uni-versität Hamburg, FBI-HH-B-261/040, 2004 (in German).
About the Author
Dorina C. Gummis a scientific assistant in the Department of Informatics at the Univer-sity 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 [email protected].
