Proceedings

International Workshop on
Global Software Development
ICSE 2002

Orlando, Florida, USA

May 21, 2002

Edited by:
Daniela Damian
Frank Maurer
Nigamanth Sridhar

ISBN 1-86365-699-5
Publication sponsored by the University of Technology, Sydney.
Welcome
Welcome to Orlando and to the International Workshop on Global Software
Development.

The goal of this workshop is to bring together researchers and practitioners in trying to
understand the emerging phenomenon of global software development. As we witness an
increased globalization of software development, it is important that research addresses
the challenges of distributed software engineering, identifies the impact of geographical
and cultural differences on software engineering practice, and informs the development
of techniques and technologies to improve such practice.

The workshop is a continuation of the workshops held in the last four years at ICSE, on
the topic of "Software Engineering over the Internet". In particular, it intends to provide a
forum for discussion of the problems of software development in geographically
distributed structures, of the factors that contribute to the success or failure of virtual
corporations, and to ways in which Internet technologies can be used to overcome current
problems. Further, the workshop will discuss how standard software engineering practice
can benefit from open-source approaches and vice-versa. A major focus is on empirical
studies of global software development practices and of methods and technologies
employed to overcome geographical and cultural differences in multi-site projects.

We wish all participants a stimulating exchange of ideas, sharing of experience and

vision, and last but not least an enjoyable time at the Global Software Development
Workshop and in Orlando.

Finally we would like to thank the members of the Workshop Program Committee for
their effort and support in making this workshop possible.

Daniela Damian, Frank Maurer and Nigamanth Sridhar

Organizing Committee
Workshop Organization
Organizing Committee
Daniela Damian, University of Technology, Sydney, Australia
Frank Maurer, University of Calgary, Canada
Nigamanth Sridhar, Ohio State University, USA

Program Committee
John Grundy, University of Auckland, New Zealand
Ross Jeffrey, University of New South Wales, Australia
Filippo Lanubile, University of Bari, Italy
Heather Oppenheimer, Bell Labs, Lucent Technologies, USA
Walt Scachi, University of California at Irvine, USA
Didar Zowghi, University of Technology, Sydney, Australia
 Table of Contents
International Workshop on Global Software Development
May 21, 2002
Orlando, FL

Using peer-to-peer technology to support global software development – some

initial thoughts ………………………………………………….. 2
Bowen, S. and Maurer, F
The study of requirements engineering in global software development: as
challenging as important ……………………………………….… 5
Damian, D.
Supporting global software development with event notification servers ……. 9
De Souza, C.R.B, Basaveswara, S.D. and Redmiles, D.F.
Virtual software inspections for distributed software engineering projects …… 14
Hedberg, H. and Harjumaa, L.
Building awareness in global software engineering: using issues as context …. 18
Kobylinski, Creighton, O., Dutoit, A.H. and Bruegge, B. et al.
Coordination and collaboration for globally distributed teams: the case of
component-based/object-oriented software development …….………….. 23
Kotlarsky, J. M., Kumar, K. and Hillegersberg. J,
Preliminary evaluation of tool-based support for distributed inspection ……... 29
Lanubile, F. and Mallardo, T.D.
Managing a worldwide software process …….……………………….. 33
Maidantchick, C. and da Rocha, A.R.C.
Process support for distributed extreme programming teams …….……….. 39
Maurer, F. and Martel, S.
Project management issues in globally distributed development …….…….. 44
Oppenheimer, H.
Palantír: Increasing awareness in distributed software development …….….. 48
Sarma, A. and van der Hoek, A.
Does global software development need a different Requirements Engineering
process? ………………………………………………………. 53
Zowghi, D.
 Using Peer-to-Peer Technology to Support Global
Software Development – Some Initial Thoughts
Seth Bowen Frank Maurer
Department of Computer Science Department of Computer Science
University of Calgary University of Calgary
2500 University Drive N.W. 2500 University Drive N.W.
Calgary, Alberta, Canada T2N 1N4 Calgary, Alberta, Canada T2N 1N4
(403) 220-3531
[email protected]
[email protected]

ABSTRACT
Distributed software development typically uses a centralized
1. INTRODUCTION
Globally distributed software development has led to the creation
architecture, which has some drawbacks such as, the participants
of several applications that are in widespread use today. Examples
may experience lengthy delays if they are located far from the
include telecommunication software from Eriksson, Nortel and
central server, and the organization that runs the server must deal
others, and open source software, such as the Apache Web Server
with the security and privacy issues that come with being in
[1], the Linux operating system [7], the MySQL database [12],
charge of a central repository of information. We are investigating
and the CVS (Concurrent Versions System) [2]. Open-source
whether this centralized control can be relaxed by using peer-to-
software is created typically in a centralized distributed topology,
peer (P2P) technology. Adopting a P2P architecture includes
which involves people working in isolation and then releasing
some of the following benefits for software development: (1) the
their source code to a central repository. Any coordination and
peer (or group) is able to have complete control of its information,
communication that occurs between the members is done mainly
(2) groups can share and duplicate information to help users with
through message bulletin boards and email. There are industry
slow network connections, and (3) users can easily contribute
products available that developers can use over a network (e.g.,
their own resources to the project, such as hard drive space. The
Microsoft Project [10], Rational XDE [13]), and some tools
P2P architecture also has potential drawbacks, including the need
developed in educational institutions (e.g., TUKAN [14] and
for complex search and retrieval algorithms, and having to
CHIME [3]), however, most of these applications rely on a
coordinate the synchronization of duplicated stores of data. The
centralized architecture to aid the collaboration process. As a
objectives of our research are threefold: (1) to examine the design
result, software developers participating in a distributed project
issues related to the development of a P2P software development
(a) need to have a reliable and fast connection to the central server
application, (2) to alter an existing virtual software development
to access information and (b) need to trust the organization that
application (MILOS) from a client-server to a P2P application
runs the server.
using the Sun JXTA framework, and (3) to present empirical
evidence on the value of the P2P implementation based on data In our research project, we are investigating if this centralized
gathered during the development process, and during application control can be relaxed by using peer-to-peer (P2P) technology.
use (i.e., delays when searching and retrieving information). We see the following advantages compared to centralized
approaches:
Categories and Subject Descriptors The reliability of the overall collaboration environment is
D.2.9 [Software Engineering]: Management – programming increased because we replicate the information that is currently
teams; C.2.4 [Computer-Communication Networks]: maintained on a central server. As a side effect of the replication,
Distributed Systems – distributed applications we also expect performance improvements because we can bring
currently centralized information closer to each user.
General Terms Users have a tighter control over what information is accessible
Management by other developers. This is especially necessary in virtual
software enterprises, where the need for information sharing in a
Keywords project needs to be balanced with the needs of participating
Process Support, Peer-to-Peer Computing companies on protecting their intellectual capital.
Our project is in its starting phase. The work presented here
describes initial thoughts and should be seen as a means to start
the discussions that could provide us with feedback on the overall
idea.
The work presented in this abstract is based on our MILOS
system - which is described in the next section. The last section
presents our current thinking on a P2P extension of the MILOS Second, there is a greater importance on authenticating peers
approach. since the dynamic environment does not lend itself to easily
tracing peers, such as through static IP addresses or registered
2. BACKGROUND domain names because these may not be used. When dealing with
MILOS (Minimally Invasive Long-Term Organizational Support sensitive information, such as during the development of a
for software development) is an open-source project that provides medical information system, the authenticity of peers must be
support for the coordination and collaboration of virtual software without doubt. Third, there is the issue of the coordination of
engineering projects [8]. It includes the following developmental information in a P2P environment. For example, if information is
aids: duplicated then how often should the stores be synchronized with
- a workflow engine supporting the management of one another?
projects, which includes the coordination of the tasks
required for the completion of a project; 4. OBJECTIVES
- a bug-tracking system; The objectives for our research of P2P virtual software
development are threefold. First, to examine the design issues
- a metrics gathering utility; and, related to the development of a P2P virtual software development
- an experience base to store process models for future application, with specific attention given to the coordination of
use. data between different peers, and security concerns. Second, to
alter MILOS from a client-server to a P2P application using a P2P
MILOS also supports agile software development using some XP
framework. And third, to assess the value of the P2P
(eXtreme Programming) practices [9]. During the planning of a
implementation based on comparisons of the two implementations
project, user stories can be created and edited. As well, the
based on the differences in the quality and quantity of information
application supports the scheduling of communication and pair
available, and performance. An empirical evaluation of the
programming via Microsoft NetMeeting [11]. Although MILOS is
approach will involve gathering data on the development process,
geared towards software development, the application is general
measuring performance by measuring the delays when retrieving
enough to support the development of any type of project.
information, and having users complete questionnaires on their
3. ISSUES WITH MILOS AND P2P impressions of how the P2P architecture impacts the original
MILOS is based on a client-server model that has some potential application. This research will present some novel findings into
drawbacks for virtual software development teams. First, being the usefulness and issues related to applying the P2P architecture
dependent upon a central repository means that information may to virtual software development.
be brought together simply for the convenience of exchange or
access. The potential problem is that the singular group in charge 5. IMPLEMENTATION FRAMEWORK
of this information must deal with the security and privacy issues As MILOS is written in Java, we will be using the JXTA P2P
related to this intellectual property, when several groups could framework for our extensions. The JXTA model is a general
perhaps more appropriately manage it. Second, a virtual specification for describing a P2P architecture [4]. The
environment often means that team members are distributed specification is general in that it does not restrict the type of
around the globe. The distance of a user to the central server can language, service, or even network that is used. For example,
become a factor because team members may connect to the communication can be supported at the application layer by using
Internet via slow connections and so could be subjected to long HTTP, or even at the lower IP layer by using datagram packets.
delays. The JXTA specification is intentionally high-level to support the
interoperability of any P2P system. Data is structured in JXTA
The P2P networking model offers advantages in software
using XML (eXtensible Markup Language), which is a common
development over a client-server model because of the
method of structuring data for the communication between
independence from a central control. First, each peer, or group, is
different applications. Thus, any application can take advantage of
able to have complete control of its information, including source
the JXTA specification without having to be tied into a vendor.
code. The group could even be more cohesive because they can
Open-source implementations of the JXTA specification are
choose what information to filter from the outside. Second,
currently being developed in several languages, including Java,
groups can dynamically share and duplicate information with one
J2ME (Java Micro Edition), C, Perl, Python, Ruby, and Objective
another to allow for faster access to users who may have slow
C [6]. There is currently a stable build available in Java because it
network connections, or to support multiple projects that have
was the first programming language used to implement JXTA.
dependencies on the same artifacts. Third, the developers can
Java is an appropriate language for the implementation of a P2P
easily contribute their own resources, such as hard drive space and
specification because applications written in Java can run in
computing cycles, to an endeavor, which increases the robustness
several different operating systems, including Windows,
of the environment. This feature can be especially helpful for
Macintosh, Solaris, and Red Hat Linux [5].
projects with limited funding, such as open-source projects.
There are also potential drawbacks that must be considered when 6. REFERENCES
adopting a P2P design. First, searching for information is in [1] Apache HTTP Server Project. http://httpd.apache.org/.
general more complicated and time-consuming in a P2P
environment than in a client-server environment because the [2] Concurrent Versions System.
information is often more distributed, and can be more dynamic. http://www.cvshome.org/.
These characteristics could lead to longer development times.
[3] Dossick, S.E., Port, D., and Kaiser, G.E. Embedding [9] Maurer, F. and Martel, S. Process Support for
Model-Based Architecting in a Collaborative Distributed Extreme Programming Teams. University
Environment. Columbia University, New York, NY. of Calgary, Calgary, Canada.
http://www.psl.cs.columbia.edu/ftp/psl/CUCS-016- http://sern.ucalgary.ca/~milos/papers/2002/MaurerMart
99.pdf. el2002.pdf.
[4] Gong, L. JXTA: A Network Programming [10] Microsoft Project.
Environment. IEEE Internet Computing, 4 (May-June http://www.microsoft.com/office/project/default.asp.
2001), 88-95. [11] Microsoft NetMeeting.
[5] J2SE v 1.8 Download. http://www.microsoft.com/windows/netmeeting/.
http://java.sun.com/j2se/1.8/download.html. [12] MySQL. http://www.mysql.com/.
[6] JXTA Project. [13] Rational XDE.
http://core.jxta.org/servlets/ProjectHome. http://www.rational.com/products/xde/index.jsp.
[7] Linux Online. http://www.linux.org. [14] Schümmer, T. and Schümmer, J. Support for
[8] Maurer, F., Dellen, B., Bendeck, F., Goldmann, S., Distributed Teams in eXtreme Programming. German
Holz, H., Kötting, B., and Schaaf, M. Merging Project National Research Center for Information Technology.
Planning and Web-Enabled Dynamic Workflow http://www.darmstadt.gmd.de/concert/people/schuemm
Technologies. IEEE Internet Computing, 8 (May-June ePrivate/xp00.pdf.
2000), 65-74.
 ! " # $$% &'
() *+ , %* ,
- ' ' '

0 . ' 4
/ 1'
. / ! ' ' 5 . . 5 8 !
0 1' 20 3 1' ! 5
' 4 ! 5 / 5 5 ' 4 4
' 1' 5 1'
5 .' ! 5 5 ' . 6
5 .' 5 !
& 5 5 55 :%; 9 1' 5 '
1' . 5 5 8 ! 4'
5 5 & 0 6 ! 1'
' 4 5 / . . ' ' = . /
' 6 7 5 . ' . !
.' 1' . ! 1' 5 & '
5 5 ' ! 6 5
. ! 5
/ 7 ' '
4 4 1' .
!" #$% !#" & ' . ' 0
5 . ' 5 '
! ! 6 ! ' 5
4 5 / '
! . ! .
. 0 5 . ' 5 8 # .'
5 . ! & 9 :); ! 1' : ;
' & ' 5 : ; < . ! '
5 / 8 5 . ' . ' ' 4 / 1'
. ! >
5 :); <' 5 .' 5 5 '
. . ' ' ' .' ! . .
6 ! '. 1' 5 ! ' . 5
. ! 5 5 ! 1'
5 ' ! 5 . ! 5 8
5 ! '5 6 . ! 5 5 5 '
' 5 1' ' ' 5 ' ' 5 8
' !
. ' 5 &
5 6 7
5 .' 1'
. .
' 5 ! 5
 ' 5 . 5 & 5! 6 5
' ' ' ' 4 5
, / !
5 . ' .
& ' ' ( )'"$
0 1' 5 5
* + ',!-!" . /!"$!") / #-
/ ! 5 :+;:?; 9 ' %$.
6 ' ' ! 44 .' ' . ' ' 4
' ! 4' 6 '5 / 6
5 1' ' ' ' A 1' 2 5
/ . ' 9 5 5 . 6 5 3 5
' 6 ! ' ' &' ' '5 ! !
0 5 5 5 6 5 ' 5
. ' . ' 4
/ 1'
9 1' ! 6
@ ! 5 5 5 ' . !
1' . . 1' 5 ! . 9
' ' ' 5 ' 5 5
' 5 8 & 55 .' 1' !
5 5 '5 5 5
' ' ' . 5 . . . 9 5 2.'
/ 5 1' 1' 5 '
9 5 ' ' ' 1' 3 4
! . 5 5 '
1' 6 '5
6 ' ' ! ! '
5 ! ' 5 1'
' ' . &' 5
5 ' 55 . &' ' $$ '
. ' 2 5 ' . 1'
' 4 / 3 5 . 4 4
. 5 ' 5 5 ! ! 6
' ! ' ' . 5 B ' 5
1' C' '55 B
' . . ! 5 8 ! '
# ' ' . . 0 &' " ! D
5 . ! ' 5 ! . ' . 1' '
5 5 A E! '
. ! 5 5 . 0 1' .' FG E!
. ! 5 8 . 1' ' 5 FG
! ' E! ' FG
5 1' < .
& 5 . 5 5 8 &
! ' 5 ! 5 ' :); '
! 4 5 5 ' ' ' 6 !
' 5 5 5
0 5 . 5 8 . ! . 5 5 . 6
1' 5 . ' . ' 1' 5 8
5 ' 0 . . !A
• ' 5 . H '
. 4 4 ' ' . . 44 '
6 7 ' 5 ' 6 6 '
1' ' ' ' ! ! 6
' 9 ' . 5
'5 2 ' 6 5 5 ' ' 1'
5 3 ' ' 1' 5 /
6 5 ! ' B . ' :,; # 5
5 ' 5
! 6 5 ' . 6
• 1'
5 5
. ' 1' ' 5 '
' 55 5 0 ( ,,'")' !" #"$% !") (!
! 5 B . ' ' ' (
.' 1'
5 ' 6 6 5 #
! . 5 ' ! ' 5 '
5 5 ! ' 4 5 5 5
/ ' ! '

• 6 7 9 ' 1'
' ' ' . 5 ! ' .
' 5 1' 5 55 ' ! 6 6
' 5 / 1' 1' 4
' ' ' " 5 ' 5 1' '
! / ' ' .' ' 6 . ! . '
! 5 . ! ' 1' 5 ' ' !
5 / 2 6 .' 5 / .
5 3 ' = ' 5
! '
• 9 / 5'. ! '
.' 6 9 ' /
' 4/ ! / 5 . ' . 6 7
5 . ' . 5 .'
@ ' 5 5 1' 5 =
' 5 . ' 5 5
'
! !6! H ' ! 8
! E . !G
5 ! 6 ' ' 5 5
1' ! 1' 5 5 9 ' 4
' ' 5 / H 4 ! 5 5 !
! 1' ' ' H 5
5 ' ! 5 6 . 5
1' @ 5
9 5 . &' . 5
I ' 4 4 67 / 6 ' ' 0 5 . '
5 . 5 ' A ' ! 6
' 7 5 . ' 6 0 1' 4 6
5 ' 5 ' ' 1'
5 ' 5 5 / . 5
5 &' ' E G ' / 0 1'
& 5 0 . 5 ! ' !
5 . 9 . 5 0 ' ' ! 1'
' 4 ! 5 < ' ' 1'
 1' ' ! 6 ! 2"#3,'$)'-'"
1' . 5
! ' 5 5 5 B 6 5 5 ' 4
5 / ! ' .
' ! ' . " 0C
# ' / ! 5 4 ! 5
E G 5 &'
5 .' 5
. 5 /
' . ! ! ! ' !
' ! !
'/' '" '
6 ' 5 : ; C > . ! @ ***
.' ' 5 !
: ; . & > '5! '55
! 6 !
1' .' !
6 5
5 ! "
1'
# B C
<' ' 5 5 $$
' & ! .
: ; . & ! BJ> >
5 !
0 '
' ' = !
1' B KL' ?4
5 6 5 . ' .
) $$$
' '
5 ' 4 5 5 :,; D ! 5
! 6 7 5 .'
! ' .' E G 1' ' 4 /
5 / . 5 . $ " %&&% ' $$
.' . ! .
:+; > ' L& 0 1'
.'
' L 6 B
5 6 ' 4
> ' L 2 3A 0
1 #" ,% !#" & )+4 $$ **,
5 5 ' 1' :); @ . . L B > . !
5 .' 5 # #B K&5 )4 $ $$
! 5 5 5 :%; 0 M &0 .8 4
5 5 1' A ' . !
. 0 5 ( )* @ ! $$
5 5
5 ' . :?; 9 ! $
6 5 ! +,- # **%
' ! ' '
5 '
' 1' ' 4
5 /
 Supporting Global Software Development with
Event Notification Servers
Cleidson R. B. De Souza1,2 Santhoshi D. Basaveswara1 David F. Redmiles1
1 2
Information and Computer Science Department of Informatics
University of California, Irvine Federal University of Pará
Irvine, CA, USA Belém, PA, Brazil
{cdesouza,sdb,redmiles}@ics.uci.edu [email protected]

ABSTRACT Therefore, these companies need to adapt their processes, tools,

Along with the rapid globalization of companies, the and organizational culture to overcome the disparity between
globalization of software development has become a reality. the sites. In order to do so, they need to solve a wide variety of
Many software projects are now distributed in diverse sites problems. The most obvious is the physical distance between
across the globe. The distance between these sites creates the sites [13]. In this case, the sense of working in a team
several problems that did not exist for previously co-located decreases due to the lack of interaction between the members of
teams. Problems with the coordination of the activities, as well different sites. As a consequence, there is a lack of trust because
as with the communication between team members emerge. the members usually do not have knowledge about overseas’
This paper describes how event notification servers are a useful culture. Relatively simple activities like discussing
technology for supporting global software development. They requirements in meetings can not be performed. There are also
can facilitate the development of collaborative tools, which can strategic, cultural, knowledge management, project (and
be used to support distributed software development. In general, process) management and technical issues to be solved [15]. All
advantages of using event notification servers are described as these problems must be understood and properly resolved for
well as specific problems that they help solve. global software teams succeed.

Our position in this paper is that event notification servers can

Keywords be used as an infrastructure to support global software
Global Software Development, Distributed Software development. Several technical problems that arise can also be
Development, Cooperative Software Development, Event solved. For example, using these servers, the lack of informal
Notification Servers. communication can also be partially solved by building
collaborative tools, such as instant messenger systems. In
1. INTRODUCTION general, notification servers can be used as a framework on
Nowadays, globalization is a word that has been heavily which collaborative tools can be built to improve global
explored. Basically, it means that the economical, cultural and software development. Indeed, several popular applications
social boundaries of countries are disappearing. For example, in such as instant messenger systems, information tracking [3],
the United States you can buy the same products that you can application gauges [9], and workflow systems [7] have been
find in Brazil. Technology innovations are ubiquitous. The built with notification servers.
roaming feature of cellular phones allows people to travel and
keep in touch with friends and coworkers. Cultural barriers are In order to be able to use event notification servers, events
also becoming subtler. In Brazil, for example, you can watch (representing activities) must be captured. One way to capture
the same television series that are being presented in the US. these events is through instrumentation of applications. Another
Software is no exception to this rule. For example, Microsoft way is through event monitoring [17]. Others, such as MILOS
derived 55% of its sales from outside the US [19]. Due to [21], use a publisher-subscriber component in its architecture.
different government regulations, several companies, especially In this short paper we are not focusing on how these events are
in telecommunications, need development sites in different captured, but rather are assuming that events are captured and
countries to get a position in the local market [16]. therefore supplied to the notification server.

The rest of the paper is organized as follows. A short

description of event notification servers is presented. Then, the
next section presents the advantages that can be obtained using
notification servers. Finally, some conclusions and future work
are described.

2. EVENT NOTIFICATION SERVERS

There is a growing trend in creating distributed software
applications that run over the Internet. Since the Internet is not
reliable, a good way to think about how these applications work 3.1 Flexibility
is as loosely coupled autonomous objects. Instead of using Event notification servers can provide several advantages when
direct communication, these applications use an event- used to support distributed software development. The most
notification or publish-subscribe design style. Messages are not important is the decoupling between the sources and consumers
sent from an application directly to another, they are sent to an of the events. When coupling is decreased, the flexibility of the
event dispatcher, or notification server, which in turn distributes entire system is improved. For instance, an information source
them to the applications that need them. In this case, there are publishes their events without knowing which components are
two types of components: information sources and consumers. interested in them. Meanwhile, the information consumers
The information sources publish events, while the information subscribe to the events in order to be notified without knowing
consumers subscribe to particular categories of events. Events which component is the source of the event. In this manner, if a
are sent by the information sources to the notification server, new information producer is added to the system, no
which ensures the delivery of these events to all interested modification is necessary to it. Furthermore, if a new
information consumers. In general, in an event-based system, information consumer wants to be notified about an event, it
component interactions are modeled as events, which are simply needs to subscribe to it. The information source does
transmitted in the form of notifications [25]. and the other components of the system do not need to be
modified. In short, the event technology enables a “plug and
play” approach to support introduction of new service
components [7].

Since wide-area networks are often slow and unreliable, this

flexibility is important because it might help to avoid problems
in one site because of other sites since there is no strict
dependency between them. It also easily supports the addition
of new components, therefore allowing the interconnection of
new sites and their tools.

3.2 Integration
An event notification server can also be used to support
integration among software development tools [22]. Therefore,
these tools will be able to communicate with each other and
cooperate despite incompatible data formats. In fact, event
based integration is one of the most prevalent integration
Figure 1. A generic event notification server. approaches to support loose integration [1]. A loose integration
approach occurs when tools have little or no knowledge of one
A notification server usually provides a subscription service another reducing the coupling between tools. This advantage is
that allows consumers to subscribe to different types of events particularly important in distributed software development
using, for example, boolean (logical) connectors, regular because, often, each site uses different tools as they became part
expressions, sequence matching, and so on. There are many of the company due to acquisitions and merges [16], i.e. the
event notification servers in existence and they are surveyed event-based framework can be used as a mechanism to integrate
elsewhere [7]. Three representative examples are CASSIUS tools and therefore support cooperation amongst distributed
[18], Elvin [11] and Siena [4]. CASSIUS was developed sites. Frequently, sites also have their own organizational
tailored to provide awareness information for groups. Elvin was culture that encompasses the unit’s norms and values, and also
originally developed to gather events for visualizing distributed the culture of system development, such as the use of
systems, but it evolved later to a multi-purpose event methodologies and project management practices.
notification system. Finally, Siena emphasizes scalability in
distributed environments. 3.3 Internet-scale Notifications
Another important advantage is the possibility of Internet-scale
3. ADVANTAGES OF EVENT event notification. Although this feature is not implemented in
all notification servers it has becoming increasingly more
NOTIFICATION SERVERS common. Siena [4] is an example of a server supporting wide-
Herbsleb and Moitra [15] classify the dimensions of the
are event notification. Basically, this means that those
problems encountered in global software development: strategic
notification servers enable the construction of Internet-scale
issues, cultural issues, inadequate communication, knowledge
distributed applications [3]. This feature is necessary to support
management, project and process management issues, and
integration among tools, since these tools are used in distributed
technical issues. Each one of these problems demands different
sites. Furthermore, it is also useful because it enables the
approaches. In this paper, we argue that event notification
communication and exchange of information (through the
servers can be used to support global software development
exchange of events) among the distributed different sites.
because they help resolve the technical issues, they help to
minimize the inadequate communication between developers,
and they provide support for some organization issues such as 3.4 Support for Informal Communication
role support. The physical distance between sites makes it harder for
distributed team members to locate remote colleagues and to be
aware of their actions. This lack of awareness implies in fewer architecture to communicate with the information consumers,
interactions since they can not tell what people are up to and if i.e. they poll the notification server to check for new events, in
it is appropriate to interrupt [2]. In fact, one of the main our scenario, at intervals of five seconds.
problems in distributed software development is the lack of
informal communication [14], i.e., since the teams are not On the other hand, in a push architecture the component that
physically together, they can not meet around the water cooler, wants to send the events “pushes” these events onto the others.
in the hallway or in other public areas. Empirical studies In other words, the second component is “called” by the one
suggest that informal communication is very important to that is sending events. In this case, these components need to
coordinate teams in uncertain tasks such as software implement some kind of standard interface to be invoked by the
development [8][20]. In other words, software developers rely other components.
also on informal, ad-hoc communication to fill in details, handle
exceptions, correct mistakes and bad predictions, and manage To the best of our knowledge, current notification servers
the effects of all these changes [14]. As this type of implement one of the two architectural models. However, in
communication is absent in global software development the order to support distributed software development both
coordination of these tasks is much more difficult. architectural models should be supported due to the different
Portholes systems were one approach to give geographically roles involved in a software development activity. For example,
distant co-workers a sense of mutual awareness [10]. More a push model is important in order to inform the manager of an
recently, researchers have tried displacing porthole’s invalid or problematic state. In real-time scenarios, it might be
information in time to compensate for differences in time zones. imperative to receive a notification of events as soon as they
Another possible approach to this problem is to use Instant occur. On the other hand, a pull model is important in a mobile
Messaging (IM) to stimulate informal communication environment where the information sources can be
(opportunistic interactions) among workers at different sites. disconnected. In this case, the events would be lost if they were
Usually, IM systems provide awareness information about the not recorded for later delivery.
presence of others. For example, if the other members of the
team are connected at the moment, the last time they connected 3.6 Network Problems
and so on. Notification servers have been used as infrastructure In order to support global software development, networks
to build IM systems [3], in so doing they can indirectly support spanning across several sites are necessary. However, these
informal communication. networks are often slow and unreliable, i.e., network packages
are lost due to problems in the transmission. For several
3.5 Role Support applications, this is not a problem, however in global software
In general, software development is essentially a cooperative development the events flowing in the network encapsulate
activity performed by a team. This is also true for distributed critical data necessary to improve coordination of activities,
software development where developers are dispersed in communication, etc.
different sites and even countries. Roles are used to help the
coordination of a large number of developers. Examples of Event meta-information could be used to avoid networks
roles are: project managers, team leaders, senior analysts, problems. By meta-information, we mean any additional
designers, programmers and so on. Each role has its own duties: information about an event that is recorded by the information
e.g., the project manager is responsible to ensure that the project source or notification server and sent alongside with the event.
is completed within budget and on time, while the reviewer has Therefore, this meta-information is available to the information
to ensure that the components being implemented do not have consumers, in addition to event information. Typical examples
defects. These formal roles need different types of information of meta-information are the type of the event being sent, the
to be properly played. In fact, according to [24] a collaborative information source that sent the event, the timestamp when the
system should be able to direct particular information to event was sent by the information source and so on. A flexible
particular people based on their roles. mechanism to support event meta-information could be used to
support additional services such as guaranteed delivery and
Fuchs [12] argues that the same event can be highly important security, therefore alleviating the problems of the wide-area
for one user and completely uninteresting for another user in the networks.
same situation, or similarly, an event may be important for a
user in some situation and irrelevant for the same user in
another. Fuchs’ work is about public administration, but the
4. EXAMPLE SCENARIO
The following scenario illustrates how a notification server
similarities to software projects is sufficient that we believe
might be used to support distributed software development. It is
similar conclusions apply.
similar to the scenario developed by [23] while describing
Palantír. Palantír’s goal is to support developers with advanced
In general, in an event-based system there is communication:
graphical views that keep them continuously aware not only of
between the information source and the notification server and
which artifacts are changing, but also of the impact and severity
between the notification server and the information consumers.
of those changes. We are currently working with the developers
There are two types of architectures to implement this
of Palantír to implement the following scenario.
communication: pull and push. In a pull architecture, the
component interested in receiving the events is responsible for
In this scenario, several distributed users are working on
contacting the other component to check for new events.
different, but dependent, parts of the system. For example, John
Usually, it is necessary to specify how often one component
is developing a component called “Note.java” in Los Angeles,
wants to poll the other. For example, CASSIUS uses a pull
USA. This component depends on another component strong coordination and communication among developers.
“Main.java” being developed by another developer, Simon, in When performed in a distributed setting, software development
Kerala, India. The dependency between these components becomes even more challenging. In global software
implies that John needs to be notified when component development, several problems arise due to the physical, social
“Main.java” is modified. Otherwise, changes in Main.java may and cultural difference between the developers. For example,
“break” his code. In other words, John adds this component to communication is much more difficult because of language
his private workspace in Palantír; therefore this system will barriers, informal communication among the team members
send a subscription to a notification server specifying that John cannot happen and trust is more difficult to achieve.
be notified about changes (events) for that component. This
subscription is sent to the notification server located in Los The goal of this paper was to present event notification servers
Angeles, which forwards it to all other notification servers of as an important and useful technology to support global
the company including one in India. Meanwhile, Simon, who software development. They are able to do so because they
has been working in India to complete his task, checks in provide a good framework to the development of collaborative
“Main.java” into the Configuration Management (CM) system. tools. For examples, technical problems that collaborative tools
face in widely distributed scenarios can be solved using these
The CM system is instrumented in a manner such that it sends servers. Indeed, we presented some common problems in global
events to the notification server, when components are checked software development and how event notification servers could
in or checked out. In this case, a new event viz. "component solve them.
Main.java checked in by Simon at 5:03 PM" would be
generated. The notification server in India adds information Finally, it is important to note that event notification servers are
about the current location to the event and then forwards it to one mechanism to distribute events across the sites. They
the server in LA. The next morning, John’s workspace would provide the infrastructure for a variety of tools to be built upon,
have an indication of changes to the component “Main.java”. such as process visualization [6] or event reasoning [5].
Using Palantír [23] John would be able to figure out the
appropriate action to be taken: change his code, contact Simon,
etc.
6. ACKNOWLEDGMENTS
Effort sponsored by the Defense Advanced Research Projects
Agency (DARPA) and Air Force Research Laboratory, Air
Similarly, say John’s component also depends on another
Force Materiel Command, USAF, under agreement number
component, “Connection.java,” being developed by Susan in
F30602-00-2-0599. Effort also partially funded by the National
New York, USA. In this case, due to the small difference
Science Foundation under grant number CCR-0205724 and
between the two time zones, John could be working on his
9624846. The U.S. Government is authorized to reproduce and
component at the same time that Susan is working on hers. In
distribute reprints for governmental purposes notwithstanding
this case, John would be notified about changes in this
any copyright annotation thereon. The views and conclusions
component accordingly and he might contact her to avoid
contained herein are those of the authors and should not be
possible problems and inconsistencies.
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Defense
There are several important points in this. First, the notification
Advanced Research Projects Agency (DARPA), the Air Force
server must support Internet-scale notifications in order to
Laboratory, or the U.S. Government. The first author was also
deliver the information among the distributed sites. Second, the
supported by CAPES (grant BEX 1312/99-5).
notification server must support push and pull. A pull
architecture is necessary to store events and deliver them when
necessary as in the first part of the scenario. Push is used in the 7. REFERENCES
second case to deliver information in near real time. Third, in [1] Barret, D. J., Clarke, L. A., Tarr, P. L. et al. A Framework
this scenario, events are being treated as strings without any for Event-Based Software Integration, ACM Transaction
formal structure. However, in reality, events should be semi- on Software Engineering, vol. 5, n. 4, pp. 378-421,
formally structured in order to (1) facilitate their processing, October 1996.
and (2) provide support for error detection. It is also necessary
to have some mechanism for defining event structure and type. [2] Bellotti, V. and Bly, S. Walking away from the desktop
For example, events being sent by a configuration management computer: distributed collaboration and mobility in a
system are different for those provided by project support tools product design team. In Proceedings of the ACM
such as MILOS [21]. Finally, it is important to mention that, to Conference in Computer Supported Cooperative Work, pp.
the best of our knowledge, there is no current implementation of 209-218, Cambridge, MA, ACM Press, 1996.
a notification server that supports all the features described [3] Cabrera, L. F., Jones, M. B. and Theimer, M. Herald:
above. We are currently building a more complete server and Achieving a Global Event Notification Service, In
plan to deploy it in a real organization with other collaborative Proceedings of the Eighth Workshop on Hot Topics in
software engineering tools in order to investigate whether the Operating Systems (HotOS-VIII), Elmau, Germany. IEEE
advantages described in this paper can be obtained. Computer Society, May 2001.
[4] Carzaniga, A., Rosenblum, D., and Wolf, A.. Design and
5. CONCLUSION AND FUTURE WORK Evaluation of a Wide-Area Notification Service. ACM
Software development performed by traditional co-located Transactions on Computer Systems, 19(3), 332-383, 2001.
teams is an intrinsically difficult task. It is difficult because of
the complex nature of the activities being executed requiring [5] Cohen, D., Feather, M. S. and K. Narayanaswamy. An
 Event-Based, Reactive, and Extensible Infrastructure for IEEE Software, vol. 18, Issue 2, pp. 16-20, March/April
Distributed Collaboration, In Proceedings of the Workshop 2001, Special Issue in Global Software Development.
on Coordinating Distributed Software Development
Projects, IEEE Intl. Workshops on Enabling Infrastructure [16] Herbsleb, J., Mockus, A. Finholt, T. A. and Grinter, R.
for Collaborative Enterprises, June 1998. Distance, Dependencies, and Delay in a Global
Collaboration, In Proceedings of ACM Conference in
[6] Cook, J. Internet-based Software Engineering Enables and Computer Supported Cooperative Work, pp. 319-328,
Requires Event-Based Management Tools, Proceedings of Philadelphia, Pennsylvania, 2000.
the 3rd Workshop on Software Engineering over the
Internet, At International Conference on Software [17] Hilbert, D., Redmiles, D. Extracting Usability Information
Engineering, Limerick, Ireland, June 2000. from User Interface Events. ACM Computing Surveys,
accepted and to appear, Vol. 32, No. 4, December 2000.
[7] Cugola, G.; Di Nitto, E.; Fuggetta, A. The JEDI event-
based infrastructure and its application to the development [18] Kantor, M., Redmiles, D. Creating an Infrastructure for
of the OPSS WFMS. IEEE Transactions on Software Ubiquitous Awareness, Eight IFIP TC 13 Conference on
Engineering, 27(9), pp. 827 –850, Sept. 2001. Human-Computer Interaction (INTERACT 2001), Tokyo,
Japan, pp. 431-438, July 2001.
[8] Curtis, B., Krasner, H. and Iscoe, N. A Field Study of the
Software Design Process for Large Systems. [19] Karolak, D. W. Global Software Development. Chapter 1,
Communications of the ACM 31(11):1268-1287, “What’s Driving Global Development?”, IEEE Press,
November 1988. 1999.

[9] De Souza, C. R. B., Basaveswara, S. D., Redmiles, D. F. [20] Kraut, R. E., Streeter, L. A., Coordination in software
Lessons Learned Using with Notification Servers To development, Communications of the ACM, 38(3), pp.69-
Support Application Awareness, In progress. 81, March 1995

[10] Dourish, P. and Bly, S. Portholes: Supporting Awareness [21] Maurer, F., Dellen, B., Bendeck, F., Goldmann, S., Holz,
in a Distributed Work Group. In Proceedings of the ACM H., Kotting, B., and Schaaf, M. Merging Project Planning
Conference on Human Factors in Computing Systems, and Web-Enabled Dynamic Workflow Technologies, IEEE
Monterey, CA, pp. 541-547, 1992. Internet Computing, pp. 65-74, May/June 2000.

[11] Fitzpatrick, G., Mansfield, T. et al. Augmenting the [22] Reiss, S. P. Connecting Tools Using Message Passing in
workaday world with Elvin, In Proceedings of 6th the Field Environment, IEEE Software, pp. 57-66, July,
European Conference on Computer Supported 1990.
Cooperative Work, pp. 431-450. Copenhagen, Denmark, [23] Sarma, A. van der Hoek, A., Palantír: Increasing
Kluwer, September 12-16, 1999. Awareness in Distributed Software Development, In
[12] Fuchs, L.. AREA: A cross-application notification service Proceedings of the International Workshop in Global
for groupware. In Proceedings of the Sixth European Software Development, At International Conference on
Conference on Computer-Supported Cooperative Work, Software Engineering, Orlando, Florida, May 2002.
pp. 61–80, Copenhaguem, Denmark,. Kluwer, September [24] Steinfield, C., Jang, C.Y., and Pfaff, B. Supporting Virtual
12-16, 1999. Team Collaboration: The TeamSCOPE System. In
[13] Grudin, J. CSCW: History and Focus. IEEE Computer Proceedings of ACM GROUP Conference, pages 81–90,
27(5):19-27, May 1994. Stockholm, Sweden, Nov. 1999.

[14] Herbsleb, J. and Grinter, R. Architectures, Coordination, [25] Sutton, P., Arkins, R., Segall, B. Supporting
and Distance: Conway’s Law and Beyond, IEEE Software, Disconnectedness – Transparent Information Delivery for
September/October, 1999. Mobile and Invisible Computing. In Proceedings of IEEE
International Symposium on Cluster Computing and the
[15] Herbsleb, J. and Moitra, D. Global Software Development, Grid (CCGrid’01), 2001.
 Virtual Software Inspections
for Distributed Software Engineering Projects

Henrik Hedberg Lasse Harjumaa

Department of Information Processing Science Department of Information Processing Science
University of Oulu University of Oulu
P.O.Box 3000 P.O.Box 3000
FIN-90014 Oulun yliopisto, Finland FIN-90014 Oulun yliopisto, Finland
[email protected] [email protected]

ABSTRACT properly, distributed teams lost nothing as compared with co-

Traditional software inspection is recognized method, but is located teams.
poorly suited to modern distributed software engineering projects.
Research lasting almost ten years has led to the construction of
Arranging inspections in a distributed and asynchronous manner
computer support for software inspection and proved its
is not a straightforward matter. Over and over again, researchers
feasibility. Until now, different tools have been produced with
have constructed tools with unique sets of features to support
conventional inspections in mind, with unavoidable differences in
paper-based inspections. Now the concept of virtual software
paper-based approaches having to be reasoned out separately each
inspection is introduced to overcome that problem. This is based
time. The concept of virtual software inspection is meant to help
on three important aspects – computer tools, flexibility and
to overcome this and provide a basis of all inspections to be
integration – and can be used as a reference model in distributed
performed in a distributed manner.
software projects. This paper briefly describes the concept, the
tool supporting it, and ongoing experiments to evaluate these. In this paper we first define virtual software inspection and then
introduce a new tool supporting it. Finally, we will also consider
1. INTRODUCTION the utility of the idea and the tool in the light of experiments
The idea of peer reviews is over 30 years old and the original carried out with students. The results are used to develop the
concept of egoless programming put forward by Weinberg [13] concept and tools futher with future uses in mind.
and the more formalized inspections proposed by Fagan [3] have
gained well-deserved positions in software engineering research. 2. VIRTUAL SOFTWARE INSPECTION
IEEE Software, for example, lists reviews and inspections among Although the purpose of inspection tools is to provide assistance,
the factors having the best influence on software engineering [10]. they have reshaped the whole process to some extent. Inspector
Traditional software inspections are often considered too roles, tasks and phases in the process have been adapted to match
laborious and time consuming to arrange, however, as up to distributed working. Thus, computer-supported software
development teams are geographically distributed and team inspection is counted as a method of its own, separate from
members are involved in many projects simultaneously. Finding a traditional software inspection. We have introduced the concept of
time and place for inspection meetings is often impossible. To virtual software inspection to emphasize this difference.
overcome the problem, a variety of software tools for inspection
collaboration have been developed. Virtual software inspection is a process that conforms to a defined
workflow and is performed in a distributed manner with the aid of
As Porter and Johnson state, face-to-face meetings do not make an inspection tool. The process can be lightweight or all-inclusive,
the defect detection process significantly less effective [11], and comprising both asynchronous and synchronous phases. It is
several other sources [8, 9] show that there should be no usually carried out through network techniques, but traditional
substantial differences in efficiency between traditional and meetings can be included if necessary. Geographical distribution
computer-supported inspections. Thus, if tools are implemented is typically achieved through the World Wide Web. An inspection
The work carried out at the University of Oulu was supported tool is a software package particularly designed for inspection
by the Academy of Finland under grant 74780. collaboration, and it should be capable of at least managing and
delivering the inspection documentation on-line, enabling the
effortless recording of defects and automatic gathering of metrics.

Some organizations wish to carry out inspections exhaustively,

while others desire simple, yet efficient inspections, such as pair
inspection [12]. Instead of a fixed process model, virtual
inspection tools should provide capabilities for customizing the
process for an individual organization or project.
In addition to the process, flexibility should encompass the 3. THE XATI TOOL
documents reviewed. Code is not the only type of document that Computer tools are the essence of the virtual inspection process.
has to be inspected. Artefacts from every phase of development There are a number of tools and prototypes available for
should be reviewed. Thus, inspection tools must deal with inspection support. Each research group has implemented a tool of
requirement documents, designs and other content-rich its own, and some – like us – have implemented a whole bunch of
documentation including text, images and possibly hyperlinks. tools, each stressing a specific aspect of the distributed inspection
Clearly, emphasis must be given to complex sets of process. The Internet-Based Inspection System (IBIS) [1] and
documentation. As checklists, metrics and even annotating Web-based Inspection Process Support Environment (Web-IPSE)
methods may vary depending on the characteristics of the [6], for example, illustrate the fact that this area is still subject to
documents, managing them and the attached annotations is not active research. These tools utilize the modern technologies
straightforward from the point of view of the tool. provided by current web infrastructure and the later also supports
version management. However, there is still a need for a
As well as numbers and metrics, inspections always include
comprehensive inspection environment that combines the good
implicit information to some extent. Although discussions about
ideas from several sources and supports the flexibility and
technical details and possible solutions to problems are
integration aspects of the virtual software inspection.
discouraged in the original software inspection method, it must be
acknowledged that such improvement ideas often emerge in the As a start for an extensible inspection tool platform, we have
course of inspection meetings and that they are often useful. A implemented a new XML-capable annotation tool, XATI (XML
straightforward way is to establish a general support system for Annotation Tool for Inspection) to support virtual software
virtual meetings in conjunction with the inspection tool. inspections. Emphasis in the development of this new tool has
been placed on ease of use and deployment in addition to
An easy-to-use inspection tool is not a synonym for an easy
interoperability. XATI is based on experiences gathered during
inspection process. In fact, making the reviewing procedure as
the development and use of our earlier tools, such as WiP [4],
easy as possible for the individual inspection team members may
WiT [5] and SATI.
result in an extraneously troublesome form of tool and process
administration, thus shifting the difficulties from the inspectors to The present web browser infrastructure provides a solid and
the moderator or system administrator. Administration of an extensive foundation for Internet-based tools, with a number of
inspection tool may require a great deal of manual work: copying feasible features such as XML parsing, network transaction
files, granting user access across servers and systems and cleaning support and means for building graphical user interfaces. The
them up after the inspection is completed. The manual handling of Mozilla browser, for example, which is actually the open source
data exchange between several repositories is error-prone and version of Netscape Navigator 6, is an interesting and flexible
strenuous. [5, 7] collaboration tool platform that enables browser-based
applications that are independent of the underlying operating
The inspection tool must exchange information with other tools
system to be developed rapidly. A new tool can be installed as a
through a number of connection points. Document management is
browser module directly from a developer’s home page, for
an obvious example of the interoperability need. The inspection
example, merely by clicking a given link [14].
tool must be aware of how the documents are produced, where
their revisions are located and how they can be accessed. The XATI tool uses Mozilla as a generic application environment
and as a viewer for a variety of document types. Actually, many
There must be a mechanism for workflow control. As inspection
formats are evolving towards XML, enabling the viewing and
tasks and resources (people, time) are initiated in the project plan,
modifying of documents in web browsers. XATI accesses the
they should be imported from a project management system.
document under inspection through DOM (Document Object
Accordingly, the project plan should be updated as the inspection
Model) [2] and can operate with any format that is supported by
tasks are completed. Inspections also usually produce new action
Mozilla. The focus is on document structure, which means that
points (for reworking), which it would be convenient to read off
annotations are linked to the logical elements of the document,
directly from the inspection tool database and insert into the task
which also makes it possible to gather data on defect locations.
list in the project management tool.
This enables advanced analysis of the actual origins of defects in
In summary, there are three important aspects to virtual software addition to the normal quantity-based calculations and metrics. It
inspection: is possible, for example, to track the annotations in the
ª Tools that enable efficient running of the process.
requirement documentation that are attached to items of highest
priority while defects attached to requirements of lower priorities
Independence of time and place, on-line recording of issues
are postponed. Initial work is needed, of course, to specify the
and data management can be achieved through networked
structure of the document being inspected, but this is achieved by
tools.
ª Flexibility of the process and supporting tools, to ensure
constructing a document template, which benefits the software
development process in general.
tolerable adoption effort and acceptance of the method.
ª Interoperability of the processes and tools, to enable The document under inspection, which contains hyperlinks to
convenient everyday use of the method and improves the related material, is presented in the main browser window.
effectiveness of inspections. Findings are reported using a simple dialogue, and after
These characteristics should make inspections more attractive and submission they are stored in a centralized database, thus allowing
widely used by easing the implementation effort required. their distribution to all participants. Each annotation is connected
 Single
interconnectivity project
point management
data

versioned
file
XSQML repository
XML + XSLT

annotations,
Xfi metric
database

Figure 1. Integrating the XATI inspection tool with other development tools by means of Xfi.

to a logical element in the document, or to an individual word. An that almost all of them already had software engineering
inspector can decide on the scope while making a comment. experience in industry.

Integration with other software development tools and repositories Over a period of one month, 74 students evaluated the XATI tool
is carried out with an interoperability framework called Xfi and filled in an on-line questionnaire. The material to be
(eXtensible framework for interoperability) [7]. This consists of inspected was a fictional requirements definition document
an XML-based query and data manipulation language XSQML containing UML diagrams and many defects. It was structured
together with drivers and schema transformers for adapting the using XML and visualized with a CSS stylesheet.
general interface to different situations. This prototype framework
allows the inspection tool to fetch the necessary data from other The questionnaire was based on research by Laitenberger and
applications and minimizes administrative and out-of-core tasks. Dreyer [9] with only slight modifications, chiefly that the middle
No separate server is needed to support it, because the tool alternative “neither” was omitted, as suggested in the original
operates in co-operation with a generic interoperability framework paper. The resulting item scale is shown as a table in Figure 2.
configured to serve inspection-related data, taking advantage of The questionnaire also included additional statements about new
the Xfi's feature of supplying data from a variety of sources features provided by XATI and free form questions, which,
through a simple XML-based interface and just one among other things, provided us with important feedback about
interconnectivity point. Data on inspection tasks are derived from the user interface and some feature requests.
the project plan, documents under inspection are fetched directly
from a file repository, and annotations are referred back to the When analyzing the results, the students were divided into two
shared databases for the collection of metrics (Figure 1). groups based on their working experience with inspections or
technical reviews. 35 students were marked as experienced and 39
4. EVALUATION as inexperienced (had performed inspections only once or not at
all). The ratio is suitable, as the two groups can be interpreted as
Although the concept of virtual software inspection was
implying that the inspection was introduced either as a new
formulated in co-operation with our partner companies, we are
process or else merely as a new tool to support an already familiar
transferring the generalized results back to the industry by
process. On the other hand, the numbers unfortunately indicates
experimenting with the virtual software inspection tool.
that inspections and reviews are still unpopular in industry.
We started with a student experiment that focused on the
Figure 2 depicts also the relative frequencies of answers to the
usefulness and ease of use of the XATI tool. The students were
four most interesting questions. These consisted of the following
taking a course in reviewing and testing at the University of Oulu,
statements:
and they were all familiar with inspection techniques and had
ª Usefulness: I would find XATI useful in my job.
performed a conventional paper-based inspection as an exercise.
In addition, they were 3rd year students or higher, which meant ª Ease of use: I would find XATI easy to use.

Figure 2. Relative frequencies (%) of answers to the four most interesting questions.
ª Future usage: Assuming that XATI were available on my The initial results of our evaluations of the key aspects of virtual
job, I predict that I would use it on a regular basis in the software inspection were encouraging, as the students felt our first
future. virtual inspection tool, XATI, to be both useful and easy to use.
ª Preference over paper-based forms: I would prefer using An obvious majority preferred it to paper-based forms for
XATI to paper-based forms for performing inspections. performing inspections and predicted that they would use it on a
The answers to these questions summarise the general trend regular basis in the future if available. We are now testing the tool
among the test users. 74% found XATI useful, and the same in a partner company, and focusing on integration and flexibility
percentage found it easy to use, the mean values being 3 (slightly aspects. In addition, we intend to define the subprocesses of
likely) and 4 (quite likely). When predicting future usage, 69% virtual inspection in more detail, although still expressing them in
said that they would like to use the tool and 72% were ready to a tailorable manner.
replace paper-based forms with on-line inspection. The mean
value for both statements was 3. The role of virtual software inspection will be even more
important in the future. To meet the challenges inherent in modern
It was interesting to note that the experienced students were a little software development environments, the arranging of virtual
more sceptical than unexperienced ones when predicting future reviews would seem to be the only competent solution. More
usage of the XATI. Only 60% of the students making inspections research will be required, however, to refine distributed inspection
or reviews in their job were ready to employ the new tool, in order to exploit its full potential.
whereas 77% of the inexperienced students predicted that they
would use it on regular basis. It is not clear whether this is only a REFERENCES
consequence of bugs in the tool or whether it represents natural [1] Caivano, D., Lanubile, F. and Visaggio, G. Scaling up
resistance to change. Luckily, there was no difference when the distributed software inspections. Proceedings of the Fourth ICSE
students were asked whether they preferred using XATI to paper- Workshop on Software Engineering over the Internet, 2001.
based form for performing inspections, the proportions being 71% [2] Document Object Model Working Group,
and 72% respectively. It seems that tool support is quite well http://www.w3c.org/DOM/
accepted, but individual tools need more finishing before they can [3] Fagan, M.E. Design and code inspections to reduce errors in
be adopted without resistance. program development. IBM Systems Journal, vol15, no 3, 1976,
182-211.
The next step will be to evaluate the XATI and Xfi tools in [4] Harjumaa, L., and Tervonen, I. A WWW-based tool for
industry projects to obtain feedback from real users. We are software inspection. Proceedings of the 31st HICSS conference,
especially interested in how feasible the aspects of virtual vol III, 1998, 379-388.
inspections are and whether we have succeeded in implementing [5] Harjumaa, L., and Tervonen, I. Virtual software inspections
them in our tool. We thus aim to seek answers to at least the over the internet. Proceedings of the Third ICSE Workshop on
following questions:
ª How efficient and easy to use is our tool? Especially, how
Software Engineering over the Internet, 2000.
[6] Hazeyama, A. and Nakano, A. Web-based Inspection Process
well are the annotation, linking and commenting capabilities Support Environment for Software Engineering Education.
implemented?
ª
Proceedings of the Fourth ICSE Workshop on Software
Are the virtual inspection process and tools supporting it as Engineering over the Internet, 2001.
flexible as they should be? Especially, what changes should [7] Hedberg, H. Integrating software engineering tools and
be made to the processes when using our tool?
ª
repositories with XML and XSLT. Proceedings of the Fourth
Is the organization able to make efficient use of the ICSE Workshop on Software Engineering over the Internet, 2001.
interoperability of the processes and tools? Especially, [8] Johnson, P.M., and Tjahjono, D. Does every inspection really
where are the bottlenecks when creating seamless operation need a meeting? Empirical Software Engineering, no 3, 1998, 9-
between inspection and other phases? 35.
The experiment will be carried out during 2002, and will include [9] Laitenberger, O., and Dreyer, H.M. Evaluating the usefulness
couple of cycles in which opinions on virtual inspection and the and the ease of use of a web-based inspection data collection tool.
tool itself are evaluated using questionnaires. Proceedings of the Fifth International Software Metrics
Symposium, 1998, 122-132.
5. CONCLUSIONS [10] McConnell, S., The Best Influences on Software
Distributed software engineering projects cannot make use of the Engineering, IEEE Software, January, 2000.
same traditional methods as do co-located teams, although their [11] Porter, A. A., and Johnson, P.M. Assessing software review
communication and quality assurance needs are the same. This is meetings: Results of a comparative analysis of two experimental
especially apparent in software inspections that have a heavy studies. IEEE Transactions on Software Engineering, vol 23, no 3,
accent on teamwork. 1997, 129-145.
[12] Tervonen, I., Iisakka, J., and Harjumaa, L. Software
It is not feasible to construct computer support for paper-based inspection – a blend of discipline and flexibility. Proceedings of
inspections, but rather distributed working, which has its own the ESCOM-ENCRESS conference, 1998, 157-166.
needs as fas as the roles, tasks and phases involved in the process [13] Weinberg, G., M., The Psychology of Computer
are concerned, should be counted as a method of its own. We call Programming, Van Nostrand Reinhold Company Inc., New York,
this method virtual software inspection. Its characteristics, notably 1971.
flexibility and integration, are important factors when introducing [14] XPToolkit project, http://www.mozilla.org/xpfe/
software inspections and new tools into organizations.
 Building Awareness in Global Software Engineering:
Using Issues as Context

Rafael Kobylinski, Oliver Creighton, Allen H. Dutoit, Bernd Bruegge

Technische Universität München, Institut für Informatik
Munich, Germany
{kobylins,creighto,dutoit,bruegge}@cs.tum.edu

ABSTRACT Curtis et al. [4] observed that documentation does not re-
In this paper, we propose an awareness system that en- duce the need for communication, in particular, during the
ables participants to monitor the activities of others over early phases of the project, when stakeholders coordinate
a wide range of artifacts (e.g., system artifacts, organiza- their conventions and create informal communication net-
tional charts, or rationale models). Participants can sub- works. They also observed that obstacles in informal com-
scribe to be notified when specific system artifacts are mod- munication (e.g., organizational barriers) can lead to mis-
ified, when specific participants trigger an activity, or when understandings in conventions and rationale. Kraut and
participants trigger activities related to specific issues. Re- Streeter [15] note that formal communication (e.g., formal
lationships among the system, organizational, and rationale specifications, inspections) is useful for routine coordination
models are then used to provide observers a context to inter- while informal communication (e.g., hallway conversations,
pret the activities of others. By providing context in terms telephone) is needed in the face of uncertainty. Grinter et
of issues (as opposed to only system or communication ar- al. [12] studied distributed projects using different organi-
tifacts), we hope to disseminate richer and more targeted zational models and confirmed these findings in distributed
awareness information, hence creating more opportunities projects.
for informal information exchanges and for distributed col-
laboration. Several approaches have been proposed to support distributed
communication. In the software process community, dis-
1. INTRODUCTION tributed process support systems have been proposed [14].
In researching distributed software engineering, we have taken Detailed models of the software development process and of
the approach of “learning-by-doing.” We have taught sev- the organization are developed and enacted with the help of
eral distributed project courses in which teams located in a distributed tool. Participants are automatically notified of
Pittsburgh, PA and in Munich, Germany collaborated on the completion of other participants tasks and are told what
developing a system for a single industrial client [2, 9]. We to do next. Assuming a realistic process model, the strength
have observed that the most critical issues related to distri- of process enactment environments are that responsible par-
bution are actually not technical, but social: ticipants are notified in a timely manner, regardless of their
location and independent of their counter parts. However,
current challenges posed by such environments include the
• Participants not knowing each other resulted in low difficult adaptation of the workflow during exceptions, the
awareness of each site and little daily collaboration. interleaving of process modeling and process enactment, and
• Lack of daily collaboration made it more difficult to user acceptance [11].
accurately communicate team and project status, re-
sulting in many crises detected late. In computer supported collaborative work, groupware and
videoconferencing have been proposed and evaluated with
• Lack of status information and informal contacts be- mixed results [13], especially in informal communication,
tween sites made it difficult to manage crises once they as they require that participants are aware of each others
were identified. activities. This, in turn, triggered substantial research in
improving group awareness [7]. Awareness systems are usu-
Researchers have already noted the importance of commu- ally integrated with a groupware system and provide their
nication in software development [4, 12, 15]. In a field study, project participants some indication of who is currently us-
ing their computers and hint about their communication
activity. Knowledge of what others are doing enables par-
ticipants to find their counter parts and to initiate conver-
sations about impending crises.

We are researching comprehensive solutions for supporting

collaboration in distributed software engineering projects,
including supporting informal meetings [1], capturing and
maintaining rationale [10], and the travel of small groups of
developers [9]. In this paper, we focus on group awareness. code, and test cases are system models. System mod-
We propose to adapt and generalize the results from the els are usually put under configuration management,
awareness and design rationale communities to global soft- as any changes need to be tracked and reversible.
ware engineering. We see three critical issues when defining
an awareness system: • Organizational models represent managerial infor-
mation related to the system under development, in-
cluding process, participants, teams, roles, and resources.
1. Monitoring activities. Information about activities
should be automatically constructed from events gen- • Rationale models represent the reasoning behind de-
erated by communication and development tools. To cisions. While system and organizational models rep-
make the awareness system usable, there should be resent the end point of the decisions and their conse-
few constraints on the tools monitored, so that partic- quences, a rationale model represents the individual
ipants can continue using familiar tools. For example, decision making elements that lead to a decision, in-
events monitored include checking new versions into a cluding problems addressed, alternatives considered,
configuration management system or posting a mes- quality criteria used for assessments, arguments, and
sage in a discussion tool. justifications. This information is usually not rep-
resented explicitely and scattered across a variety of
2. Providing context for activities. Raw events gen- communication media. Rationale-based approaches of-
erated by communication and development tools are ten represent this information as a semi formal graph
too low level for a remote observer. We propose that of nodes, called an issue model. An issue model pro-
decision making information (i.e., rationale [16]), in- vides for a structured overview of the various decisions
cluding issues, alternatives, quality criteria, and deci- that are made in the course of a project: Every de-
sions be captured and related to other system artifacts. cision to-be-made in a project, no matter by whom,
In addition to making issues under discussion visible corresponds to one or more issues.
to other sites, issues can also be used to enrich the
context of awareness events.
Issues can be classified by several inherent properties, such
3. Filtering awareness information. In a distributed
as
project, the number of participants, activities, arti-
facts, and issues that can be monitored is too large for
any single participant. Moreover, participants are not • project phase: Requirements Elicitation, Analysis,
interested in seeing all events that occur in the project. System Design, Object Design, Implementation, or Main-
Instead, participants should be able to express their in- tenance
terests by rating the importance of specific artifacts,
specific project participants, or specific issues. • category: a spectrum ranging from technical to man-
agerial

An awareness system enables participants to receive a stream • dependency: a collection of references of other issues
of events that inform them about the activities of others, that need to be resolved first
in real time. Although our primary objective is to create
opportunities for participants to initiate informal commu-
nications, we see other longer term uses for this stream of In our environment, we store issue models in a repository
events. For example, a variety of process and system met- shared across all tools manipulating issues.
rics can be derived from awareness events over time, hence
informing a project manager of the direction of the project.
Since issues are used as a main context element, these met-
rics could also be based on the issue models, hence providing Issue
a rationale centric view of the software life cycle, as opposed Argument
to an entity centric or a process centric view. Rationale
Element Proposal
Criterion
In the rest of the paper, we describe in more detail our * * Decision
awareness system, our plans for its experimental evaluation,
and future directions.

2. META-MODEL * *
Participants use many different sources of information to
Organization
Element
* * System
Element

stay informed about the current status. For building an

awareness system, we need to represent these various sources
of information. We identify three types of models:
Task Person Use Case Subsystem

• System models represent the system under develop- Team Resource Domain Class Solution Class

ment from a variety of perspectives. A requirements

specification, an architecture, a detailed design, source
In our meta-model we introduce the linkage across models. happen there, rather than in the physical environment.
The semantics of these links depend on which elements are
linked. These relationships among system, organizational, To support awareness in the virtual work environment we
and rationale elements are used as context for awareness need a system which gathers awareness information in form
events. Usually, these links are not explicitly represented of events from the tools used by the developers and dis-
or represented only in an ad hoc manner. For example, the tributes them as notifications to interested parties. These
login name of a user can be used to link the authorship of events must include at least the originator of an action, the
system models to corresponding address book entries in an tool used, the artifact manipulated and the tool command
organizational model, when login names are generated from used to manipulate the artifact. After receiving, the system
the first and last names of a user. has to assess how important this event might be for others
and either filter the event out or deliver a weighted notifi-
We postulate that the value of these cross-model links is cation about the event to the recipients. Notifications for
high for providing context information in an awareness sys- recipients who are not available need to be stored persis-
tem and, in general, for ensuring consistency among models tently for later delivery.
manipulated by different tools. Our approach so far has
been to make it easier to create these types of links. For Our approach for gathering awareness information is to pro-
examples, REQuest [10], a tool for writing specifications in vide an open interface for existing tools rather than to create
terms of use cases, enables users to create and attach issues new tools. The awareness system has to augment the exisit-
to specific use cases. The issues and the links are stored in ing development infrastructure instead of replacing it. This
the issue repository, however, users view the issue models in approach imposes restrictions on the granularity of informa-
the context of the specification. tion we can get from the tools. For example while it is quite
easy to get notified by a CM system like CVS about a check
Following the same principle, we are developing a meet- in operation on a file, getting a notification about a method
ing manager tool as an extension of our communication in- modification in an IDE can require elaborate customization,
frastructure, which enables users to create meeting agendas which often is not possible at all due to the lack of APIs to
from a set of issues, create a set of action items as a result the IDE.
of a meeting, and assign action items to participants. While
users view issues in the context of meeting agendas and min- To assess the importance of events, the awareness system
utes, the meeting manager enables the creation of linkages needs to know about the interests of the individual develop-
between the organizational (action items, participants) and ers. The developers should be able to explicitly state their
rationale (issues, decisions) models. interest level in events related to a person, to an artifact, to
a tool, to a command or to a combination of all these ele-
The elements of the meta model and their linkages can then ments. Because an awareness system based solely on explicit
be traversed by the awareness system, both for monitoring, interests would require substantial ongoing configuration by
subscribing, and providing context. We describe the aware- each individual developer, awareness systems based on flex-
ness system in more detail in the next section. ible rules have been proposed in the past [3]. Given a set of
rules, such systems can create interest representations im-
plicitly by processing the events originated by the user. One
3. BUILDING AWARENESS
such rule could state that when a developer starts to manip-
Group awareness can be described as “an understanding of
ulate an artifact, an interest representation for that artifact
the activities of others, which provides a context for your
is created.
own activity” [6]. This understanding allows to answer ba-
sic qustions like who is around, what is happening and where
When developers state (explicitly or implicitly by means of
it is happening. In an environment where colloborating in-
rules) their interest level for certain event types, they usu-
dividuals are colocated, this understanding is aquired easily
ally are also interested in events which are closly related
through direct audio-visual perception and informal com-
to those events. One example of related events are events
munication. However in environments where the collabora-
about artifacts that are strongly coupled in some way, e.g.
tors are distributed in time and space, most of the available
a file containing the interface of a class and a file containing
awareness information is usually lost.
another class that uses this interface. Another example of
such related events are events about developers belonging
A software developer can be considered working in two dis-
to the same team.
tinct work environments in parallel: the physical work en-
vironment and the virtual work environment. The physical
Artifact relations can usually be derived from the internal,
work environment consists of offices, furniture, computers
often hierarchical, models used by the tools. We belive that
and other tangible assets, while the virtual work environ-
using these models to derive distance metrics for tool-specifc
ment usually consists of project artifacts stored in files or
artifacts is necessary for the importance assessment in an
databases and tools used during the development to manip-
awareness system. However, these models are not sufficient
ulate those artifacts.
when the developers want to express interest in all events
belonging to a particular process task, such as requirements
Early general purpose awareness systems [7, 17] focused on
analysis, or a specific abstract set of artifacts, such as those
the physical environment and allowed mediated access to au-
related to a subsystem. Those events might not have ele-
dio and video from a remote site. We chose to focus on the
ments which are related directly to each other, e.g. a file
virtual work environment, believing that, in terms of con-
containing a class and a posting on a Bulletin Board might
text, the most interesting activites in software development
be coupled only because they are related to the same sub- In a nutshell, the engineering methods that we intend to
system. support with our infrastructure are:

To satisfy this requirement, we propose the addition of a

service to the issue repository introduced in Section 2 that • Issue-based Project Modelling: Applying the is-
allows to map events to the elements of the meta-model. sue paradigm to every decision should create a uniform
Using this meta-model, we can then express couplings be- and routine method for problem solving
tween artifacts coming from different tools and thus unre-
• Participatory/Democratic Management: The issue-
lated on the tool level. Incoming events are then passed
base is open to every participant. Decisions on ev-
first to service which assigns the event a set of abstract ra-
ery level are made transparent and can benefit from a
tionale, organization and system elements before any further
larger decision-making population.
processing with rules and interests is done. Thus, rules and
interests can contain references to the elements of the meta- • Shared Project Knowledge: As the issue-base is
model, and interests in a particular element can be easily captured electronically, decision rationale can be shared
expressed. among participants over time. The project gains a
long-term memory that is externalized from experts.
4. TOWARDS AN ISSUE-BASED LIFE-CYCLE • Design Rationale Capture: Design decisions can
We think that a non-linear process for software engineering
be captured from designer communication and feed
projects is needed; one that is not modelled after waterfalls
into the documentation.
or spirals, but rather in the style of concurrent distributed
execution in modern operating systems. Additionally, we • Total Quality Management: Generation of meet-
assume that the support infrastructure should be process ing agendas & minutes, and management of action
agnostic, and should therefore be able to support any pro- items.
cess model that project managers choose to adopt.
• Active Awareness: The infrastructure augments the
We therefore propose to introduce a sub-model, or a layer participants’ project perception by raising “red flags”
underneath the usual process models, which enables us to at issues that are important for the respective partici-
evaluate, compare, and ultimately execute process models. pant.
Issues – as described in section 2 – are our atoms of larger
structures, and represent all artifacts that need to be shared
between project participants. For these, a project requires an artifact repository as shared
memory, a communication infrastructure, a project manage-
Managers of team-based projects face the challenge of keep- ment component for prioritizing and scheduling of issues,
ing track of project progress and health. Even when the and development teams that solve their alloted issues.
process model is clear and simple, the overall project sta-
tus depends on many variables that are often buried deep 5. EVALUATION
inside the artifact and communication repositories; excep- While an awareness system that satisfies the requirements
tional states that are outside the scope of the applied model stated in Section 3 can be designed in a domain agnostic
can cause substantially skewed perspectives. way, it’s benefits for distributed software engineering de-
pend on how well the implementation fits into the exisiting
Our goal is to instrument all parts of our collaboration in- development infrastructure, and on how well its concepts,
frastructure to allow for the capture of events needed for namely interests, rules and models are calibrated to satisfy
building group awareness as described in section 3. But the needs of its users.
beyond the peer-to-peer benefits we expect from this, a con-
solidated view onto the project status could be generated We believe that this has to be done through empirical re-
by appropriate heuristics. For example, such status indica- search, and therefore we have designed and are currently
tors could include communication metrics [8, 5], component implementing such a system - Awareness Builder - that we
metrics, quality metrics, scheduling metrics, or integration are going to start using this fall. The system will provide
metrics. a XML-RPC interface for collecting events from the tools
our developers use (CVS, Lotus Notes and REQuest), and
Another challenge for successful projects is the reduced project a graphical notification system.
duration time, which forces the infrastructure to be setup
as mechanically as possible. Due to its high complexity, the To get enough events from CVS we need to make sure that
risk for omission errors increases with increasing number of changes in the working copies are frequently promoted to
tools. We therefore intend to automate as much of this task the central repository. We will therefore introduce a con-
as possible and additionally provide an initial set of open figuration management policy which asks for promotions of
issues, possibly even per project phase, which will populate changes at least once a day. This policy will be supple-
the issue base with a collection of issues that were identified mented by a set of criteria to which the new code has to
as recurring in previous projects. Through this we intend comply.
to enable a big-bang project startup by not only providing
an ad-hoc infrastructure, but also an issue-based represen- This summer, after the implementation is completed, we
tation of multi-phase, multi-project management check-lists plan to perform a series of short studies with a limited num-
and best-practices guidelines. ber of students to calibrate the system.Those studies will
have three goals: to find suitable rules, define meaningful G. Teubner. Transatlantic project courses in a
distance metrics for both the tool-specific models and the university environment. In Asian Pacific Software
meta-model and to evaluate the user interface. Engineering Conference, Dec. 2000.
[3] M. Bürger. Unterstützung von Awareness bei der
The calibrated system will then be used by the participants
Gruppenarbeit mit gemeinsamen Arbeitsbereichen.
of our next distributed project course (August 2002 - March
PhD thesis, Institut für Informatik der Technischen
2003), where we will study the impact of increased awareness
Universität München, 1998.
on project communication.
[4] B. Curtis, H. Krasner, and N. Iscoe. A field study of
Once the awareness system and its relationship with the the software design process for large systems.
issue repository are sufficiently well tuned, we plan to in- Communications of the ACM, 31(11), Nov. 1988.
vestigate further uses of the stream of awareness events. As
mentionned in Section 4, issues can play a central role in the [5] D. Damian. An empirical study of requirements
software life cycle, by providing both a tool for establishing engineering in distributed software projects: Is
context and for making explicit information that is usually distance negotiation more effective? In Asian Pacific
stays implicit in single site projects. We will use the date Software Engineering Conference, Dec. 2001.
generated by the awareness experiments to identify how is- [6] P. Dourish and V. Bellotti. Awareness and
sue models support this view of development and to elicit coordination in shared workspaces. In Conference
requirements for issue-based management tools. Proceedings on Computer-supported Cooperative Work,
1992.
6. CONCLUSION [7] P. Dourish and S. Bly. Portholes: Supporting
In this paper we propose a technology-driven approach, as
awareness in a distributed work group. In Conference
opposed to a business administration-driven approach, for
Proceedings on Human Factors in Computing Systems,
enabling software engineers to build better software through
1992.
rationale capture and knowledge management. We investi-
gate the use of group awareness to create opportunities for [8] A. H. Dutoit and B. Bruegge. Communication metrics
informal communication and for longer term uses, such as for software development. IEEE Transactions on
process and communication metrics. Software Engineering, 24(8), Aug. 1998.
[9] A. H. Dutoit, J. Johnstone, and B. Bruegge.
Key challenges in group awareness include identifying incen-
Knowledge scouts: Reducing communication barriers
tives for developers to accept the monitoring of their actions
in a distributed software development project. In
and addressing privacy concerns.
Asian Pacific Software Engineering Conference, Dec.
2001.
When identifying potential incentives, we note that lack of
sharing of information among sites leads to adverserial re- [10] A. H. Dutoit and B. Paech. Rationale-based use case
lationships and lack of trust. We anticipate that sites can specification. Requirements Engineering Journal, 2002.
benefit from the system by offering a greater transparency
into their activities. Such transparency can then lead, for [11] S. Goldmann and B. Koetting. Software engineering
example, to certification frameworks for supplier sites and over the internet. IEEE Internet Computing, pages
reinforce long term relationships among sites. 93–94, July 1999.
[12] R. E. Grinter, J. D. Herbsleb, and D. E. Perry. The
When addressing privacy concerns, we avoid common prob- geography of coordination: Dealing with distance in
lems occurring in other monitoring systems by ensuring that R&D work. ACM, 1999.
only information that is already public (e.g., CVS events) is
broadcast. Moreover, the exchange of information is sym- [13] J. Grudin and L. Palen. Why groupware succeeds:
metric, as users can only view awareness events if they ac- Discretion or mandate? In European Conference on
cept to produce awareness events. In general, awareness Computer Supported Collaborative Work, 1995.
events should comply with the access control mechanisms [14] P. J. Kammer, G. A. Bolcer, R. N. Taylor, A. S.
already in place. Hitomi, and M. Bergman. Techniques for supporting
dynamic and adaptive workflow. Computer Supported
In general, the above issues are difficult to predict and antic- Cooperative Work, 9(3):269–292, 2000.
ipate, as they relate to complex organizational and human
processes. Only an experimental approach will enable us to [15] R. E. Kraut and L. A. Streeter. Coordination in
assess the impact of the system with respect of these issues software development. Communications of the ACM,
and design solutions to address them. 38(3), Mar. 1995.
[16] T. Moran and J. Carroll. Design Rationale: Concepts,
7. REFERENCES Techniques, and Use. Lawrence Erlbaum Associates,
[1] A. Braun, B. Bruegge, and A. H. Dutoit. Supporting Mahwah, NJ, 1996.
informal requirements meetings. In 7th International
Workshop on Requirements Engineering: Foundation [17] R. I. Sara Bly, S. Harrison. Media spaces: Bringing
for Software Quality., June 2001. people together in a video, audio and computing
environment. Communications of the ACM, 36(1),
[2] B. Bruegge, A. H. Dutoit, R. Kobylinski, and Jan. 1993.
 Coordination and Collaboration for Globally Distributed
Teams: The Case of Component-Based / Object-Oriented
Software Development
Julia M. Kotlarsky1, Kuldeep Kumar1,2, Jos van Hillegersberg1
1
Department of Decision & Information Sciences, Erasmus University
P.O. Box 1738, 3000 DR Rotterdam, The Netherlands
E-mail: {jkotlarsky, jhillegersberg}@fbk.eur.nl
Phone: +31-10-4081757, Fax: +31-10-4089010
2
College of Business, BA 356, Florida International University,
University Park, Miami, Florida 33199, USA
E-mail: [email protected], Phone: +1-305-3483156, Fax: +1-305-3486331

1. Motivation and Theoretical Background interest is to explore and improve the practice of
development of CB/OO software systems in a
Global distribution of software development has
globally distributed setting.
become widespread over the last decade. There are
a number of economical and technical trends that 2. Research Objectives and Questions
are likely to further accelerate the growth of
distributed software development. On the The main research question we address is what
technological side, ongoing innovations in support (technical, methodology, and social) is
information and communication technologies, needed for coordination and collaboration of
made by eliminating the perception of distance, distributed teams in Component-Based/Object-
make it possible to cooperate in software Oriented software development?
development projects in a distributed mode. Our first objective is to elicit Coordination and
However, currently there is limited research and Collaboration (C&C) patterns for distributed
experience in this emerging area. The few existing teams developing CB/OO software. Following
studies ([1-3]) report numerous problems in traditions of software development community (e.g.
distributed projects. The time, governance, [5], [6]) by patterns we mean “best practices”
infrastructure, and culture gaps, associated with the explicitly represented by means of templates
geographical dispersion of work, make it more (models or working instructions) that could be used
difficult to manage inter-site work dependencies for coordination and collaborations of distributed
and to coordinate and control the distributed work. teams in well-defined (easily identified/recognized)
Furthermore, traditional coordination and control situations or for resolving well-defined issues.
mechanisms are less effective in global software − C&C patterns are to be based on issues and
projects. Carmel ([1] and Van Fenema [3] suggest problems distributed teams face in practice.
that these traditional mechanisms will be effective − They will provide solutions/ways that are based
for dispersed projects only with appropriate on “best practices” or existing successful
Information and Communication Technology (ICT) practices.
support. However little is known of the success of − C&C patterns will incorporate the following
current ICT and methodology support within elements: Activities, Actors (roles),
globally distributed software development projects. Technology, Artifacts and guidelines regarding
Furthermore, current development methods do not human issues.
accommodate the distribution of development
activities across multiple sites. Recent trends in the The second objective is to develop a (meta)-model
software development industry in the use of Object of coordination and collaboration for distributed
technology and a modular or component-based teams. This meta-model will provide the overall
architectures allow distribution of development framework (architecture) for the socio-technical
activities over multiple sites. However knowledge support for globally distributed software teams.
is lacking on how to effectively distribute To study existing practices and elicit C&C patterns
Component Based (CB) / Object-Oriented (OO) we have defined three sub-questions:
development over multiple sites and what Q1 What are the collaboration issues for distributed
“collaboration patterns” to use for the various teams? What problems do they face?
activities and tasks. Therefore, our research
In greater details - we are interested in learning - Documentation & Records – paper-based or
how distributed teams developing CB/OO software digital documents and records that provide
collaborate and coordinate their work: what information on the project and sites involved
issues/problems do they face? What successful and (from corporate and public sources).
non-successful practices could be identified? What - Direct observation – attending meetings (e.g.
procedures, methods and tools are used (when-in video and phone conferences, net meetings) and
which situations and for which activities)? What other communications between sites as far as
does matter for members of distributed teams feasible.
(regarding their counterparts)?
- Interviews – face-to-face semi-structured
Q2 How teams collaborate at present - “good” and interviews of project managers, team leaders and
“bad” practices? Why they work and Why project team members, in particular people
don’t? Are there alternatives? cooperating across project locations (selected to
Q3 How can existing solutions/ways be improved provide a heterogeneous perspective on the
and under which conditions? project). We interview about 5 people from each
project. In three out of four companies we have
3. Research Methodology interviewed people involved in two-three different
Research methodology we have followed is a projects, therefore in total we have about 15
qualitative case study methodology [7]. interview per each of theses three companies.
We are conducting case studies in four different While collecting empirical data we follow iterative
companies (each company is a “case study”), at approach – after each case study we come back to
each company we study in depth one to three the initial theory-based categorization and modify
projects. For the moment we have finished data and expand on issues and patterns based on our
collection in two companies and collecting data in observations and data collected. Appendix 1
two other companies in parallel. The first case describes the overall research design.
study was conducted in the company developing
software between USA and Europe. Other three 4. Initial Empirical Findings
case studies are in companies (projects) distributed Based on the conducted case studies we have
between India, Europe and USA. identified several factors that influence ways
During the case studies we are collecting input and distributed teams collaborate. These factors could
gaining the perspective of two (or more) remote be distinguishes as flexible factors (those could be
groups participating in the overall project from changed) and fixed factors (those cannot or hardly
their dispersed locations. Project is unit of analysis. ever possible to change). The factors are presented
Criteria for choosing projects – project distributed at Figure 1 (fixed factors are in green and flexible
between at least two locations, preferably: factors are in blue). Furthermore, some of the
completely new CB/OO development, factors are intra-organizational (internal) factors
specification-design and/or integration stage, (they appear within the circle) and some are out of
current project. We collect data from the following organizational scope (external) factors (they are
sources: outside the circle).
Software Engineering
Boundaries/ gaps
Process (SEP) Team B - geographical distance
- Software methodology - time zone differences
- Modeling languages Organizational factors - cultural differ. (norms for
- CASE tools - organiz. culture - infrastructure dif. behavior, values, language)
Project Mgmt - team-building - governance dif.
(PM) tools - rewarding -methodology dif
Environmental Groupware &
factor (Uniqueness Human factors Team C Internet
Team A
of the situation) - if people worked technology
Smth. outstanding or or met f2f before
Support synchronous and
unpredictable, making - motivation
- trust asynchronous activities
the situation unique

Figure 1: Factors that influence ways distributed teams collaborate.

We will explain how these factors influence way summarizes Groupware capabilities (grouped based
teams collaborate: on synchronous and/or asynchronous mode of
Some of boundaries/gaps – geographical distance support they provide for distributed parties - teams
and time zones differences – are external and fixed or individuals).
factors. Studying distributed teams means that
Synchronous Asynchronous
distance is a pre-condition – there is always
distance between sites. Regarding time differences ! video-conference ! e-mail
– time window when working hours overlap ! phone-conference ! voice-mail
defines when synchronous communications are ! e-chat ! video-mail
possible. In the case of Australia and New York or ! e-whiteboard ! calendar/scheduling
India and San Francisco – there is no overlap is ! discussion list
working hours. Therefore teams working with half- ! e-workspace
day overlap (e.g. India and The Netherlands) will Synchronous & Asynchronous
collaborate differently from those where there is
twelve hours time difference. ! application/document sharing
Cultural differences are rather fixed then flexible ! (remote access, file transfer, bulletin board)
factor. On both - individual and national levels – ! workflow management
norms of behavior are difficult to change, however
Table 1: Groupware capabilities
often people who work closely with other countries
somehow adjust to the “culture” of their Software Engineering Process (SEP) that cover
counterparts, specifically if they did spend a long software methodology, modeling languages and
time (at least a couple of months) in the country CASE tools, and Project Management (PM) tools
they collaborate with. However values and are flexible external factors. Similarly to the
language are very difficult to change (if possible at previous factor (Groupware and Internet
all). Therefore cultural differences is very technology), tools and methodologies available
important factor that influences ways people from within project organization limit choice of what can
different cultures collaborate. be used for collaboration between distributed
Some of gaps are internal – these are gaps teams. At the same time this “limited” choice could
between remote sites involved in the same be changed by acquiring tools from the variety
project. These are differences in methodologies available at the market, by developing internal tools
(or processes followed), governance (differences and/or adopting or developing new
in management structure, rules, implicit methodologies/techniques.
practices) and infrastructure gaps that include Two of the four companies we are studying
access to basic facilities like electricity and developing CB software using OO approach, other
telecommunications (capacity), also different two companies develop CB but not OO software.
(versions of) hardware, platforms, and Therefore we will be able to analyze if teams
applications. Gaps in technical infrastructures developing OO software coordinate and collaborate
and methodologies could be reduced, even differently from those not using OO approach (and
eliminated, governance differences also possible if yes – what are the differences).
to reduce however it is quite difficult.
Within project organization we have distinguished
Next factor is Groupware1 and Internet between two (internal) factors they apply on
technology. This is flexible external factor – different levels - organizational and individual
because on the one hand there are a lot of tools and levels - Organizational and Human factors
technologies available on the market. On the other respectively, both factors are flexible.
hand – availability of tools within project sites limit
On the individual level we have seen that people
choice of people involved in remote collaboration.
who met their remote counterpart face-to-face at
The goal of Groupware is to allow remote
least for a short period of time and have some
communications and to support collaboration
history of working jointly from different locations –
between people at remote locations. Table 1
they collaborate more closely and more
successfully then team members who never met
1
By Groupware we mean concept of Groupware face-to-face. Personal contact and joint working
technology and not any specific tool or vendor. There experience help to build trust between remote
are many different tools by different vendors that parties. Furthermore, motivation on the individual
provide same capabilities/features.
level is very important for successful collaboration negative - like September 11th events created a lot
between distributed teams. of tensions in multi-national teams.
On the organizational level organizational culture, For each project we study as part of empirical data
team-building activities (e.g. if they are taking collection, we cover all the above mentioned
place, what kind of activities, if they are part of factors in order to understand better when (under
organizational culture), rewarding (not about which scenarios) the collected practices could
money but rather personal recognition etc.) are very apply. Furthermore, we are tracking variables such
important for successful collaboration between as size of company and project, experience level of
remote team members. team members and other factors that can influence
Methodology, infrastructure and governance gaps success or failure of a project and necessary for
(appear within the circle at the Figure 1) could be conducting cross-case analysis.
considered as organizational factors as well because
5. Background for Data Analysis and
these are gaps on the organizational level between
the sites involved in the same project.
Further Steps
To study and benchmark globally distributed
One more factor that should be taken into account
projects (as a theoretical background), we have
while studying how distributed teams work is
developed a Framework of Global Software
Environmental factor (i.e. Uniqueness of the
Development Project (Figure 2) that identifies
situation) – something outstanding, unpredictable,
functional areas on which distributed teams
making the situation (project) we are studying
collaborate during various stages of a project [4].
unique or exceptional. It can be something related
We use these functional areas as a base to group
to product, e.g. very special (important for
issues, coordination and collaboration patterns and
organization) product or something completely
tools we identify during empirical data collection.
unpredictable, out of control (e.g. September 11th
events). These factors affect a way teams work, in a The Framework identifies and ties together
multinational team it might have either positive or different elements of global software projects -
negative influence. Positive – for instance unite product, methodology, project organization (i.e.
remote team members if they feel ownership of the people) and plans, and relevant coordination and
product and developed it as it is their “child”. Or control activities.

Coordination
mgmt

Configuration Constraints
mgmt mgmt
Common
Version Workspace
mgmt Product Methodo Planning,
logy scheduling,
Plan allocation
Reuse
mgmt Project
organization
Monitoring

Risk
mgmt
Progress
measurement and
ensuring quality

Figure 2: The Framework of Global Software Development Project

As for now, we have finished data collection in two model and coordination and collaboration patterns
companies and “half way” in two other companies. will be our scientific contribution.
We have visited one of two remote sites at each of
7. Expectations from the Workshop on
two other companies. The two sites left will be
visited in May-June 2002.
Global Software Development
At the moment we are transcribing the collected We are very interested in meeting people involved
interviews. After all cases are completed and in global software development and researched
interviews transcribed, we will analyze the working in these fascinating and quite new area.
collected practices - each case separately and cross- From practitioners we are interested to hear about
case analysis [8]) and available theories in order to their experience of working in distributed teams -
elicit Coordination and Collaboration patterns for what problems do they face, success and failure
distributed teams. stories (and why it is succeeded or failed) etc.
From other researches – what interesting
While analyzing existing practices we are
observations did they come across while studying
collecting, we group them based on two following
distributed software teams and findings. How are
categories:
they researching a topic – theories and research
1) Which activity (functional areas) and/or
methodologies used.
elements of global software projects does it apply
(based on the Framework, Figure 2). 8. References
2) State (i.e. scenario) of each of the factors 1. Carmel, E., Global Software Teams: Collaborating Across
presented at Figure 1. This is important in order to Borders and Time Zones. 1st ed. 1999, Upper Saddle
analyze which practice/pattern applicable at which River, NJ: Prentice-Hall P T R.
situation. 2. Karolak, D.W., Global Software Development: Managing
Virtual Teams and Environments. 1st ed. 1999.
3. Van Fenema, P.C., Coordination and Control of
During the workshop we will present some of the Polycontextual, Geographically Dispersed Temporary
practices that we have observed during data Systems: The Case of Global Software Projects., in
collection and describe how and under which Department of Decision and Information Sciences. 2002
circumstances (scenarios) they are working. (forthcoming), Erasmus University, Rotterdam School of
Management: Rotterdam, The Netherlands.
6. Implications of the Research 4. Kotlarsky, J., J. Van Hillegersberg, and K. Kumar.
Towards a Global Software Development Architecture. in
Our research is relevant for both research and 2001 IRMA International Conference. May 2001. Toronto,
management practice. Canada.
In terms of practical contribution, we will provide 5. Fowler, M., Analysis Patterns. 1996: Addison Wesley.
guidelines for distributed software teams based on 6. Gamma, E., et al., Design Patterns. 1994: Addison
Wesley.
“best” or “successful” practices. 7. Yin, R.K., Case Study Research: Design and Methods.
Tool vendors - commercial or academic (e.g. Vol. 6. 1994, Newbury Park, CA: Sage.
OPEN [9], [10]) – we will provide with 8. Miles, M.B. and A.M. Huberman, Qualitative Data
requirements of distributed software teams - what Analysis. 2nd ed. 1994, Thousand Oaks, CA: Sage.
capabilities teams need, what is missing in the 9. Firesmith, D. and B. Henderson-Sellers, The OPEN
Process Framework. 2001: Addison Wesley.
existing tools they use now. 10. Graham, I., B. Henderson-Sellers, and H. Younessi, The
For scientific community our research will be an Open Process Specification (Open Series). 1997: Addison
exploratory study of quite a new research area - Wesley.
global teams developing CB/OO software. Meta-
 Appendix 1

Research design

Literature review

SEP1: Boundaries Organizational

Groupware
- SD2 methodology between and human
& Internet
- modeling languages distributed factors
Technology
- CASE tools teams
PM3 tools

Building a
theoretical Priliminary categorization of (meta)
framework coordination and collaboration modeling
issues/areas of distributed teams techniques

Collecting data
(best/existing
practices) Case 1 Case 2 Case 3 Case 4
Comp A Comp B Comp C Comp D

Thesis - towards
collaboration Coordination and collaboration
framework patterns for distributed teams

Comments:
1
SEP – Software Engineering Process
2
SD – Software Development
3
PM – Project Management
 Preliminary Evaluation of Tool-based Support for
Distributed Inspection
Filippo Lanubile Teresa D. Mallardo

University of Bari
Dipartimento di Informatica
Bari, Italy
[email protected]

ABSTRACT first experiences with using IBIS for distributed software

Software inspections are a software engineering “best practice” inspections.
for defect detection and rework reduction. In this paper, we
describe our initial empirical evaluation with using a tool aiming 2. THE UNDERLYING MODEL OF
to provide Internet groupware support for distributed software
inspections. The tool is based on a restructured inspection process
SOFTWARE INSPECTION
Software inspections were developed first by Michael Fagan at
to reduce synchronization and coordination problems.
IBM [4] and then adopted with many variants [7] for the purpose
of defect detection and process improvement. Software
inspections are distinguished from other types of peer reviews in
that they rigorously define:
1. INTRODUCTION
Global software development [6] is a phenomenon started in the - a phased process to follow (e.g., planning, overview,
early 1990s, whose main drivers are the access to government preparation, meeting, rework, follow-up);
contracts in foreign countries, the integration of groups from - roles performed by peers during review (e.g., moderator,
alliances and acquisitions, and the difficulty of staffing new author, recorder, reader, and inspector);
projects with adequately skilled people. These forces are
contrasted by negative factors such as higher costs and time - a reading toolset to guide the review activity (e.g., defect
delays, because distance causes overheads for management and taxonomies, product checklists, or scenario-based reading
affects teamwork cooperation, thus resulting in reduced techniques);
productivity and higher development time [5]. - forms and report templates to collect product and process
data.
Distributing software projects across multiple, geographically
separated teams questions established best practices of software Recently, a reorganization of the inspection process has been
engineering and asks for new solutions. For example, focusing on proposed [9] to shorten the overall cost and total time of the
verification activities in a global telecommunication company, the inspection process, on the basis of behavioral theory of group
authors of a repeated case study reported that collocated peer performance and the results of many independent empirical
reviews outperformed distributed peer reviews with respect to studies that argue the need for traditional meetings [1, 8].
efficacy and efficiency [3]. We claim that traditional software
The alternative design for software inspections mainly consists of
processes, including peer reviews, should be significantly
replacing the preparation and meeting phases of the classical
reenginered for being distributed across multiple sites, using the
inspection process with three new sequential phases: defect
Internet as a collaborative infrastructure.
discovery, defect collection and defect discrimination (see Figure
The focus of our work is on software inspection, an industry- 1).
proven type of peer review for detecting defect and reducing
The first, defect discovery, reflects the historical shift of goal for
rework. Because of its roots on manual activities and face-to-face
the preparation phase, that has changed from pure understanding
meetings, the software inspection is an excellent example of a
to defect detection, and so inspectors have to individually take
traditional software process that might benefit from
notes of defects. The other two inspection phases are the result of
geographically distribution, on condition that it is reorganized to
separating the activities of defect collection (i.e., putting together
reduce synchronization and coordination, and then supported by
defects found by individual reviewers) from defect discrimination
some Internet-mediated environment.
(i.e., removing false positives), having removed the goal for team
In [2], we described an ongoing project to develop a tool, called activities of finding further defects.
the Internet-Based Inspection System (IBIS), aiming to provide
groupware support for distributed software inspections. After one
year, IBIS has become ready for use and this paper reports our
 and roles, categories for defect types and severity, and reading
Planning support items (at the current date, checklist questions are
Overview Individual examination supported). In addition, a determination is made on whether to
hold an overview and a list of contacts is invited by email to be
Discovery part of the inspection team.

Individual task Collection 3.2 Overview

Discrimination In the Overview stage, the inspection team can access to
background information on the inspection process or the product
Rework
Very small team being inspected. This stage may not be necessary if the team is
examination (optional) Follow-up already familiar with both the process and product.

Figure 1. The reengineered inspection process 3.3 Discovery

In the Discovery stage, members of the team perform individually
the review task and record potential defects on a discovery log.
Checklists can be used for guidance on typical types of defects to
Defect collection independent of defect discrimination only be found in the product being inspected. An inspector can add,
requires either the moderator or the author himself. Defect modify or delete defects while as they are discovered. If it is the
discrimination may be skipped either entirely, passing all the first access of the inspector to the discovery stage, the discovery
collected defects directly to the author for rework, or partially form is shown with an empty defect list, otherwise it is shown
skipped, excluding from the discussion any duplicate defects with the defect list from the last session. When an inspector has
found during collection. Another change for saving time and declared the end of discovery, a notification message is sent to the
diminishing coordination is introduced by reducing the number of moderator. The moderator can browse the discovery logs of all the
discussants to those that can be recognized as experts, on the basis inspectors to determine whether team members have adequately
of the analysis of individual findings. The behavioral theory and performed the reviews, and eventually invite inspectors for
empirical findings suggest that a single expert reviewer paired additional discovery.
with the author may be as effective in the discrimination task as
larger groups. 3.4 Collection
In the Collection stage, all the discovery logs are collapsed into a
By reducing the need for synchronous communication between unique defect inspection list. Either moderator or the author can
reviewers and the overload of coordination on the moderator’s set as duplicates identical defects from multiple inspectors.
shoulders, the reengineered inspection process provides the model Looking for duplicates is helped by the ability to sort the merged
upon which to build an automated support for running distributed defect list with respect to location fields and checklist questions.
inspections. Duplicates are excluded from the discrimination stage and go
directly to the rework stage. Looking at the inspection defect list
3. IBIS without duplicates, the moderator may select which defects are
The IBIS architecture adopts a lightweight approach to achieve worth to be discussed in the discrimination stage and which
the maximum of simplicity of use and deployment. Since it is inspectors have to participate to the discussion. This decision is
mainly a web application, IBIS uses technologies based on web supported by the display of individual findings statistics, such as
standards, as specified by the World Wide Web Consortium total number of reported defects and number of unique defects.
(W3C).
3.5 Discrimination
All persistent data related to inspections are stored as structured In the Discrimination stage, discussion takes place
XML documents, programmatically accessed via the DOM API, asynchronously as in a discussion forum. Each defect in the
and automatically manipulated by XSL transformations. Thus, discrimination list is mapped to a threaded discussion. Invited
IBIS does not require any DBMS for accessing the data inspectors may add their comments inside the threads and, when a
repository, except for archival purposes. All groupware consensus has been reached, either the moderator or the author
functionalities are developed from dynamic web pages on the can remove false positives.
basis of scripts and server-side components. Event notification is
achieved by generating email messages. Clients only need to use a 3.6 Rework
browser and, optionally, an email reader. IBIS does not require In the Rework stage, the author is invited to correct defects found.
any additional installation, neither manual nor automatic, and can He fills in defect resolution entries including information on how
be used throughout a company firewall. the defect has been fixed or, if not, the explanation. At the end,
In the following, we describe the use of the tool during the seven the author can upload the revised document and a notification
phases of the reengineered inspection process. message is sent to the moderator.

3.1 Planning 3.7 Follow-up

In the Planning stage, the moderator determines whether the In the Follow-up stage, the moderator determines if defects found
product to be inspected meets the entry criteria and tailors the have been corrected by the author and that no additional defects
template inspection process: inspection goal, names for phases have been introduced. In order to decide whether exit criteria have
been met or another rework cycle is needed, the moderator may Table 1 shows the main descriptive statistics of individual
invite additional reviewers among inspection team members. Once reviewers’ performance. Individual findings varied a lot between
the inspection is closed with a final recommendation, the system reviewers, particularly for the first inspection. In the requirements
sends a notification mail to the team members including a inspection, there were a couple of outstanding reviewers which
summary and a detailed report as a feedback for participants. reported 24 defects both, with very few duplicates (respectively
one and four). On the other hand there were also poor reviewers
who contributed with only three recorded defects or no unique
4. FIRST EXPERIENCE WITH IBIS defects. In the second inspection (checking for style
We have done two types of inspections enacted by IBIS with the
conformance), there were more defects recorded by each reviewer
goals of testing the tool itself and gather a first feedback from
but most defects overlapped rather than being unique
users. In the first inspection, ten reviewers had to find defects in
contributions.
the IBIS requirements document (19 pages long). In the second
inspection, eight reviewers had to detect programming style
violations in a dynamic web document (694 lines of markup
elements mixed to scripting code), which was part of the IBIS Table 1. Descriptive statistics of individual findings
configuration. Inspection 1 Inspection 2
(requirements (programming
Participants were graduate students in the computer science
inspection) style compliance)
department at the University of Bari. All participants had received
one lecture on software inspection and had practiced with the tool Defects recorded
by using the demo version. The elapsed time of inspection was by each reviewer
unusually long (one month, including Christmas vacations), but Mean 9.1 19.2
this allowed participants to work not only from the university but Min 3 12
also from home, thus simulating the conditions of geographically Max 24 26
dispersed teams. SD 8.2 5.5
Unique defects by
The following quantitative data were measured from the key each reviewer
inspection stages:
Mean 6.0 5.2
- from Discovery: for each reviewer, number of defects Min 0 0
recorded, number of unique and duplicate defects; Max 23 14
- from Collection: number of defects recorded, number of SD 8.4 5.4
unique defects, number of duplicates, number of merged Duplicate defects
defects, number of defects selected for discrimination; by each reviewer
Mean 3.1 14.0
- from Discrimination: number of discussants (other than
Min 1 2
moderator and author), number of messages posted, number
of resolved false positives; Max 8 23
SD 2.0 8.8
- from Rework and Follow-up: number of unresolved false
positives, number of true defects.
Table 2 summarizes the measures for both the inspections.
From the above direct metrics, the following indirect metrics were
Looking at the results we highlight the following differences
derived:
between the two inspections:
- Duplication: ratio of recorded defects to merged defects; a
- There were more much more reviewers discovering
ratio of one means no overlapping of collected defects, while
independently the same programming style violation than
a high ratio would mean that many defects were discovered
detecting individually the same requirements defect;
by multiple inspectors;
- The “interesting” defects (i.e., worth to be selected for
- Discussion Filtering: ratio of defects selected for
discrimination) were much more for the requirements
discrimination to merged defects: a ratio of one means that
document than for the dynamic web document.
there were no filtering while a low ratio would mean that
only few defects were considered of interest for discussion; - Discussants were more active when raising comments about
requirements defects than programming style deviations.
- Discussion Intensity: number of posted messages per
discussion thread (a thread corresponds to a defect selected - Discriminating among potential requirements defects was
for discrimination); much more effective than discriminating among potential
style violations.
- Discrimination Efficacy: ratio of resolved false positives to
total number of false positives; a ratio of one means that the Finally, qualitative data were collected from a questionnaire
author may concentrate on fixing true defects in the rework submitted to the participants at the end of the two inspections.
stage. Apart from reporting some problems with the tool, students stated
that the IBIS tool was easy to use and practical because they could
work at a time and a place of their favor. A student complained
about response time but he said that this happened only at times,
when working at home, and cannot be considered a tool fault.
 Table 2. Measures from the two inspections contribution of the discussion for discriminating between false
positives and true defects was important for the inspection of the
Inspection 1 Inspection 2
requirements document but not for the verification of style
(requirements (programming
conformance. These results can be explained with the different
inspection) style
depth of understanding required to perform a careful review of the
compliance)
two products.
Inspectors 10 8
Defects recorded 91 154 Result of this preliminary evaluation of IBIS represents both a
Unique defects 60 42 tool beta test and an empirical contribution to which inspection
Duplicate defects 12 26 characteristics work best under certain project conditions. As IBIS
Merged defects 72 68 will continue to be used and improved, we intend to run
Duplication (recorded / 1.3 2.3 controlled experiments and field studies to investigate the
merged) mechanisms that determine costs and benefits of distributed
Defects selected for 34 9 software inspection.
discrimination
Discussion filtering 0.47 0.13 6. ACKNOWLEDGMENTS
(selected / merged) Our thanks to students who volunteered for using IBIS and
Discussants (excluded 6 4 providing feedback to improve the tool.
moderator-author)
Messages 78 16 REFERENCES
Discussion intensity 2.3 1.8 [1] Bianchi, A., Lanubile, F., and Visaggio, G. A controlled
(messages / selected) experiment to assess the effectiveness of inspection meetings.
False positives resolved 21 6 Proceedings of METRICS 2001 (London, United Kingdom,
False positives not 7 8 April 2001), 42-50.
resolved
Discrimination Efficacy 0.75 0.43 [2] Caivano, D., Lanubile, F., and Visaggio, G. Scaling up
(FP resolved / all FP) distributed software inspections. Proceedings of the ICSE
True defects 44 54 Workshop on Software Engineering over the Internet
(Toronto, Canada, May 2001).
[3] Ebert, C. , Parro, C. H., Suttels, R., and Kolarczyk, H.
All students who had been invited into the discrimination stage
Improving validation activities in a global software
found useful the discussion with respect to learning purposes, but
development. Proceedings of ICSE 2001 (Toronto, Canada,
most acknowledged that discussing about programming style
May 2001), 545-554.
deviations was not so worthwhile. When asked if they would have
preferred to discuss in a face-to-face meeting or in a chat, the [4] Fagan, M. E. Design and code inspections to reduce errors in
answers were of two types. Some answered that they would program development. IBM Systems Journal, 15, 3 (1976),
choose a chat or a face-to-face meeting, because they would feel 182–211.
less alone and more active in the discussion. Others answered that [5] Herbsleb, J. D., Mockus, A., Finholt, T. A., and Grinter, R.
they liked the asynchronous discussion because, not being in a E. An empirical study of global software development:
hurry, they had time to think about each other messages and could Distance and speed. Proceedings of ICSE 2001 (Toronto,
write better comments. Canada, May 2001), 81-90.
[6] Herbsleb, J. D., and Moitra, D. Global software
5. CONCLUSIONS development. IEEE Software, 18, 2 (2001), 16-20.
We have developed IBIS, a tool to support distributed software
inspections over the Internet. The underlying process model has [7] Laitenberger, O., and DeBaud, J.M. An encompassing life
been summarized, as it provides the basis to cut down cycle centric survey of software inspection. The Journal of
synchronous communication among inspectors and the Systems and Software, 50 (2000), 5-31.
coordination overhead of the moderator. The design of the system [8] Porter, A., Siy, H., Mockus, A., and Votta, L. Understanding
has been outlined together with a description of its use within the the sources of variation in software inspections. ACM Trans.
inspection stages. on Software Engineering and Methodology, 7, 1 (1998), 41-
We have presented two distributed inspections enacted by the 79.
tool. In analyzing the results, we were interested to see how the [9] Sauer, C., Jeffery, D. R, Land, L., and Yetton, P. The
inspection performance may vary with respect to a very distinct effectiveness of software development technical reviews: A
type of product being reviewed. While an inspection team of ten behaviorally motivated program of research. IEEE Trans. on
reviewers was cost-effective for requirements defect detection, the Software Engineering, 26, 1 (2000), 1–14.
opposite was true when an eight-person team looked for violations
of programming style. Furthermore, we observed that the
 Managing a Worldwide Software Process
C. Maidantchik A. R. C. da Rocha
COPPE - Federal University of Rio de Janeiro COPPE - Federal University of Rio de Janeiro
Caixa Postal 68.504 CEP 21945-970 Caixa Postal 68.511 – CEP 21945-970
Rio de Janeiro - Brazil Rio de Janeiro - Brazil
+55 21 2562-8207 +55 21 2562-8698
[email protected] [email protected]

ABSTRACT virtual enterprise may be formed by huge corporations or by

In this paper, we present a software process management model to individuals that work in an independent way [3]. What is
a worldwide collaboration. A standard process is defined necessary to start a virtual enterprise is a common objective, a
according to ISO/IEC 12207 directives and geographically shared information base, tasks coordination and people
dispersed software process requirements. Then, it is specialized management [4].
according to the CMM maturity levels. The specialized processes In this paper we present the experience on managing a software
are also instantiated for each project. A Web tool supports the process in a world wide collaboration, acquired through the
enactment of process instances. Fault detection supports the project between CERN (European Laboratory for Particle
enhancement of the process instances and, in consequence, the Physics, Switzerland) and UFRJ (Federal University of Rio de
standard process improvement. As the standard process is Janeiro, Brazil). Our proposal is defining a standard software
enhanced, their specialized processes and instances are also process that respects the organization characteristics. This unique
improved, through a gradual change, which avoids impacts on the process is then, specialized according to different maturity levels
way people works and, at the same time, supporting a continuous and instantiated to the various projects. The main advantage of
process improvement. The project is under a collaboration this approach is that each developing group follows its own
between the European Laboratory of Particle Physics (CERN) and process, at the same time that this process respects the general
the Federal University of Rio de Janeiro (UFRJ). procedures defined by the organization.
In the next section, some aspects of the evolution of software
Keywords engineering are discussed. Section 3 presents an example of a
Software process management and improvement, capability geographically distributed software project. In section 4, the
maturity models. requirements of a software process in a worldwide collaboration
are described. The proposed process management model is
1. INTRODUCTION presented in section 5. In section 6 the prototype developed to
Geographically distributed collaborations are arising due to the support the process management enactment is presented. Finally,
recent social-economic changes and to the wide use of the in section 7, we expose our conclusions.
Internet. Several software projects involve people that do not
work in the same place. Even though the computing network 2. SOFTWARE ENGINEERING
allows a fast, efficient and reliable communication, the
professionals may use different hardware and methods. Therefore, EVOLUTION
most of the time, distributed teams are heterogeneous with several It can be perceived that investments on information systems have
cultural and technological differences. Through the analysis of evolved over the past 30 years. The electronic data processing era
these characteristics, it can be concluded that the usage of a of the 1960s can be characterized as a centralized and efficiency
unique software process by all may not be suitable. As software oriented era, where the focus was on large-scale transactional
projects are becoming larger and more complex, the need of being processing. The 1970s were pushed by management information
executed by geographically dispersed working groups is factual. systems through the generation of information reports. The advent
The knowledge and the capacity to develop some projects are not of the PC in the 1980s shifted from mainframes to desktops,
necessary placed in the same working environment, which brings where computing systems supported individual decision making.
to task distribution among several departments of an organization In the mid-1980s, strategic information systems that support
or, at most, even more than one enterprise [1]. Professionals from competition in the marketplace raised [5]. In the 90's, much effort
distinct domain areas (law, financing, economy, computing, etc) has been invested in process standardization (ISO directives) and
work in different places in order to achieve the goals of the same improvement (capability maturity models as CMM, Trillium,
organization. Nevertheless, the development of a geographically Bootstrap and SPICE). The software process has been elected an
distributed work encompasses several problems related to cultural important factor to improve productivity and product quality and
differences, languages, time, ethics, software and computing so, it has been necessary to define consistent and suitable software
platforms [2]. Although these problems have social reasons, some processes to then select tools and methods to support the
of them can be minimized, or even, eliminated through advanced execution of a process activity [6], [7]. The search for quality and
technologies. Information share, independently from its location, productivity improvements has encouraged organizations to focus
brought to a new kind of organization: the virtual enterprises. A on their processes. This approach comprises defining a process
and setting improvement goals by taking into account good particle accelerators used as tools for such research activity in a
practices. center that allows physicists to work cost effectively and to
collaborate more fruitfully than if each country would maintain its
Process control was defined in the 30s, used by the Japanese
independent programme. CERN is one of the world’s largest
industry after the Second World War and, nowadays, is applied in
scientific laboratories and an outstanding example of international
almost all industrialized countries. A software process can be
collaboration of its 19 member states and some observer states.
considered stable and under control when its performance is
There are many technological opportunities a scientific center of
predictable, in conformance to predefined statistical limits. This
excellence like CERN can offer to industry. Such a characteristic
corresponds to total quality management. A controlled software
contributed to the WorldWide Web conception, whose initial goal
process must guarantee that defective products cannot be
was to allow high energy physics access to data anywhere in the
delivered to customers. The first step is to consider all
world in a uniform way [9]. As the Web is a multimedia,
engineering tasks as something to be controlled, measured and
distributed, heterogeneous and cooperative information system,
enhanced. The main goals are to improve deliverables' quality,
nowadays, its scope is much larger than its initial concept.
enhance the productivity and minimize the development time.
In 1994, the CERN Council approved the development of a new
Process management can be defined as the application of
project: the Large Hadron Collider (LHC), an accelerator, which
concepts, techniques and practices to explicitly monitor, control
will bring protons into head-on collision at higher energies than
and improve a process [6]. Well defined and managed software
ever achieved before. Around the collision points at LHC, a
processes allow not only the quality improvement of their
complete set of sophisticated detectors will be placed, so that a
products but also the enhancement of productivity through a
detailed description of the resulting interactions can be provided.
series of factors as, for example: definition of a sequence of
One of such complex laboratories under design is ATLAS (A
process activities, support to task management, support to quality
Toroidal LHC ApparatuS) [10]. The ATLAS coordination has to
control and data collection for further validations.
consider that more than 1,700 collaborators from 144 universities
Process improvement specifies a comprehensive set of processes and research centers spread around the world will use different
that an organization ought to have, as well as a framework, which packages for simulation, data acquisition and analysis in different
specifies how to improve the processes interactively, over time. platforms. Therefore, the software engineers have to produce
An important first step in addressing software problems is to treat reliable products and the introduction of new features to the
the entire project tasks as a process that can be controlled, existing computing systems has to be an easy task. The detector
measured, and improved. In order to improve a project capability, development will require approximately 1,000 professionals per
organizations must take six steps. The first step refers to year, where 85% corresponds to small groups that do not work at
understanding the current status of their development process. CERN [10]. Therefore, to improve the product quality, assure an
Then, it is necessary to develop a vision of the desired process, easy maintenance and minimize needed resources, it is important
establish a list of required process improvement actions in order to model a well-defined software development process respecting
of priority, produce a plan to accomplish the required actions, the specific characteristics of this environment.
commit the resources to execute the plan, and start over at the first
Like is clearly observed at the multidisciplinary environment of
step. The primary benefit of an improved - more disciplined -
LHC development at CERN, within large international
software process is improved visibility of the process. This
collaborations, the interaction of specialists from different domain
visibility makes the process more manageable during the
areas is highly significant. These professionals have to
development and maintenance phases, thus reducing costs and
communicate their decisions and coordinate their activities.
making schedules more predictable. An improved process also
However, in heterogeneous and geographically distributed
allows easier acquisition and adoption of new technology. When a
environments, the working groups usually have different
process is well defined, it is easier to analyze what tools and
properties, knowledge and technology. It is very hard to manage
methods best support the creation of products and systems within
the activities that are being performed, the deliverables that are
a software organization.
being constructed and the entire development process itself.
Nowadays, the Internet is used worldwide and allow software
development among distributed areas. The communication is 4. SOFTWARE PROCESS FOR
electronically supported and data are easily shared. The existence WORLDWIDE COLLABORATIONS
of a world network that allows accessing information placed at When several people work cooperatively on a common project,
different locations contributed enormously to the enhancement of they need a way to coordinate their work. For relatively small or
the communication means. A Web platform has transformed itself simple tasks, this can often be done informally, but with larger
from a mere marketing presence to a platform that can support all numbers of people or more sophisticated activities, more formal
aspects of a software engineering project. The Web has the arrangements are needed. Unfortunately, few teams work out their
potential of reaching a much wider audience than systems based roles and activities in advance, even though they know the key
on proprietary networks. problems they will encounter. For some reason they act as if late
requirements, changes or implantation problems will not persist
3. GEOGRAPHICALLY DISTRIBUTED [11].
SOFTWARE PROJECTS Many difficulties on developing software in geographically
The primary aim of CERN is to probe the structure of matter and distributed environments are also noticed in other contexts.
reach a better understanding of the way the Universe is made and However, the problems are more critical when people are not in
works [8]. Specifically, it has built and operates a number of the same place. Taking into account the characteristics of
distributed software development environments we have should be able to view, retrieve and modify the information
identified some problems, grouped into the following classes: creating a new version, which can be afterwards committed
into the repository.
1. Coordination of the working groups: refers to the
relationships among dispersed groups and their supervision, • Support dynamic evolution of the software system. Once a
considering that several professionals can form multi- document changes, three levels of inconsistency may occur:
disciplinary and heterogeneous teams. This involves defining inconsistency in the document itself; inconsistency between
the capacity of each group and delegating activities, existing documents and the modified document;
according to their characteristics and restrictions. incompatibility between the application and related
information. The handling of incremental changes must
2. Coordination of the activities: refers to the workflow control,
assure the coherence of the information.
identifying concurrent activities, tasks that demand
cooperation among groups and how to solve synchronism • Provide recording mechanism. For many developers, the
problems. representation of ideas into discrete nodes, with distinctive
names and types seems to impede the flow of thought, and
3. Artifact control: involves the problems of components
moreover, the resulting structure is hard to change. A
integration, distributed authoring, results visibility, change
computational support for annotating decisions, questions,
notification and configuration management.
and, comments must structure problems, maintains
4. Communication support: refers to all aspects of the software consistency in decision-making, keeps track of decisions,
development that requires for information exchange, in order provides a way of communicating decisions to other
to guarantee an effective software process management. It is developers, and chronologically records information.
applied to problem resolution, decision notification, register,
The standard software process for distributed working groups
access and data sharing, and general information publishing.
should respect the previous requirements. It defines a unique
These problems can be minimized when a software process is structure to be followed by all software teams. The standard
well defined, according to the peculiarities of dispersed process was defined based on ISO/IEC 12207 [12], which
environments. From the identification of the previous class of software life cycle processes were redefined through the
problems, we could classify the following requirements for a introduction of specific distributed development activities.
geographically dispersed software process:
• Define an underlying software process that guides developers 5. THE SOFTWARE PROCESS
along the software life-cycle activities by specifying an MANAGEMENT MODEL
ordered set of tasks. The range of software engineering In order to support software development by geographically
activities is so broad that no single tool can support all of dispersed groups, we have established a model for software
them. To support all tasks during a software development, it processes. Figure 1 presents a schematic view of the software
is necessary to state each step to be followed and to allow process model for distributed groups.
that the resulting deliverables can be associated with its
In this model, from the initial standard software process
corresponding activities.
(Standard SP), four specialized processes (Special.ML2,
• Support distributed software development environments. In Special.ML3, Special.ML4 and Special.ML5) are set for the
large distributed development teams, where software and different maturity levels of CMM [6] to support specific
related documents are produced at various sites techniques characteristics of the software teams, including activities to
that enhance communication among developers should be address the key process areas of each level.
provided. The availability of networked resources offers
After the identification of the maturity level of a working group,
extensive possibilities for software development support. The
using CBA-IPI (CMMSM-Based Appraisal for Internal Process
entire organization can have online access to the software
Improvement) [13], the most suitable of the specialized software
documentation through a wide-area hypermedia information
processes is set to the group and instantiated to the project. This
retrieval system.
instance addresses the specificity of software development in each
• Support the integration of different types of data and provide group (for example, methods and tools commonly used by the
a powerful configuration mechanism, allowing adaptations of group). Consider, for example, that at a specific moment, four
the software process activities and documentation. Within projects are beginning, and each one should be assigned to a
cooperative working groups, each software application task different dispersed working group. According to this approach,
is assigned to a group of developers, which assumes the maturity level in software engineering practices of these
responsibility for its analysis, coding, testing, and groups was previously evaluated: three groups were considered to
documentation. The results of each activity probably be in level 2 and one in level 3. The project manager creates one
produced by different CASE tools, editors, etc, should be instance of specialized process of maturity level 2 for each of the
added to the documentation structure. first three projects (ML2-Prj.1, ML2-Prj.2 and ML2-Prj.3). The
• Support concurrent and collaborative activities. It may be fourth project is assigned to one instance of the specialized
necessary for several users to have coordinated access to the process of maturity level 3 (ML3-Prj.4).
same information. To support simultaneous development of During software development, information about the process
software by several people, a mechanism for version control usage is collected to ascertain whether the process is being
should be provided. A fixed entry point or a central correctly used. At the end of the project, an action list describing
repository for documentation is defined. Then, each user better practices is delivered to the working group. This list
supports the continuous software process improvement at each hierarchical hypertext nodes. The system templates are well
location. The evaluation can also show evidence that the structured in order to be able to be automatically converted to
capability in software engineering practices of a group has HTML and connected via links to other documents of the project.
enhanced. Therefore, when developing a new project, a Each template contains some instructions on how the template
specialized software process of a higher maturity level will be should be completed, which represent the online help.
assigned to the team. The templates are available as ASCII files. When the user
performs an action - e.g. selecting a node - scripts are executed in
ISO/IEC definition
12207 order to convert the ASCII files into HTML fill-out forms. The
Standard SP
configuration file is a text file that contains user options to set up
CMM the template files. There is only one configuration file for each
specialization
project. The original template itself is write-protected so users do
Special.ML2 Special.ML3 Special.ML4 Special.ML5 not edit it accidentally. A copy of the master templates may be
Particu -
larities of edited directly through a text editor. When modifying the master
instantiation
each
group
templates, the developer can name and save the new version for
future use. In following projects, users can load and reuse the
ML2 -Prj.1
suitable configuration files.
ML2 -Prj.2
Through the Internet, the working groups can communicate
ML2 -Prj.3 ML3 -Prj.4 ... among themselves and any kind of data can be easily accessed.
The information recorded during a project is used to validate the
Figure 1: Software Process Model for Distributed Groups. working groups and the adequacy of the development process.
The prototype is a set of information management mechanisms
The model supports gradual and controlled software process where data are stored in a net of nodes, connected among them.
maturing. The main benefit of this approach is that various The navigation mechanism allows a fast access to different
dispersed working groups can have their own software processes, detailed levels of a software project. The user understanding
with different maturity levels, according to their characteristics enhances due to high quality interface, which integrates the
and restrictions, but respecting a standard and unique software project components. Within a software project, the amount and
process defined for the organization. complexity of data complicates the identification and creation of
The task of improving a process is integrated to the software relationships among several documents.
process itself, stimulating professionals and allowing a greater The developed prototype is composed by several modules to link
comprehension of the need of enhancing processes. Therefore, our any kind of information with the process definition, register all
proposal aims at a continuous process improvement, which is decisions taken and the items to still be implemented, store
reached by management levels. The definition level specializes project components and related links to their representations at
the process in different maturity levels and creates instances from different abstract levels. An electronic mailing mechanism is
the resulting specialization for each project. The monitoring level integrated to the other modules, allowing messages to be sent to
stores information about the process activities and collects data. all members of the working groups and automatically registering
The evaluation level performs the measurement and analysis the mails.
tasks, and the improvement level defines an action plan to
Figure 2 presents the workflow of the Prototype modules. The
enhance the current state.
Projects Record module contains registered projects and the
6. THE PROTOTYPE working group. The main prototype module is the Process
We developed a prototype using the Web technology to Configuration module, which presents the specializations of the
implement the proposed system. This prototype has the following standard process and allows the instantiation of the suitable
goals: validate the chosen technology, document decisions taken process for a group. The Activities Record presents all tasks that
during its utilization and identify the restrictions of the conceptual should be performed and the deliverables to be constructed
model. The system runs in a UNIX environment and uses according the chosen specialization process. The Decisions
WorldWide Web that merges the techniques of networked Taken and the Components Record modules support the
information and hypertext to make an easy but powerful global enactment of the processes activities. The Communication
information system. The architecture is composed by a relational module provides data exchange features among a project member.
database and a set of mechanisms to structure, create and modify All data is stored in databases, allowing the search for a particular
components. The system was developed using the advantages information among all modules through the Data Search module,
offered by the browsers. The server interfaces with the database notifying incomplete tasks through the Inconsistencies Report
through CGI programs, which are implemented in C language and module, and producing hypertext files of the overall process by
shell scripts under a Unix platform. The user interface includes the Documentation Generator module. These modules stand for
HTML forms and JavaScript programs to locally validate input mechanisms to coordinate and support software tasks among
data and avoid unnecessary network communication traffic. individuals spread worldwide.
The Web system provides templates, implemented as hypertext Within the system, the activities of a software process and the
forms, to integrate the project information generated during the resulting products are linked together through a hypertext
software development. These templates are typed, such as system guideline. A component representation can be textual or
events, system services, code heading, and design activities, graphical, horizontal (same level of abstraction) or vertical (from
thereby carrying semantic data. The information is organized as the concept to its implementation). The Web system supports a
conceptual transformation chain that progresses from initial the structure of the process, easy links to templates and examples,
artifacts to intermediate ones and then to the final product itself. a mechanism for feedback and discussion, and mechanisms to
The designer can use cross reference information to make sure assist tailoring and project task definition.
that the interactions at a particular level of abstraction meet the
requirements and constraints imposed by the higher levels of 7. CONCLUSIONS
abstraction. The maintainer can use the information to see how a The complexity of software projects and the availability of
change in representing or implementing a concept will interact support technologies have allowed the growing of cooperative and
with other concept representations and implementations. The distributed projects. The ATLAS Experiment is an example of
project manager can use cross-reference information to certify worldwide collaboration, involving the areas of physics,
that all requirements were respected and not forgotten. engineering and computer science. The specialists from different
places and cultures work together to achieve the success of the
project.
Projects Commu- The proposed process management for worldwide collaborations
Record nication
presents the advantage that the process improvement approach is
integrated with the process definition. Within this model, a unique
software process is specialized to each heterogeneous group,
Data according to its capability. The project was based on the premise
Search that the quality of software products is strongly influenced by the
quality of the software process used to produce it. Enhance
Decisions process in order to achieve better quality products seems to be a
Taken
good idea but it is essential to first verify whether the software
Process Activities
Configu- Record process is adequate to the working groups that will use it.
ration
The standard software process was based on the ISO/IEC 12207
Compo-
directives redefining its process categories and introducing new
nents
Record ones in order to respect the peculiarities of disperse working
Docu- Inconsis-
ments tencies
teams. The CMM was adapted to point out software development
Report needs, which resulted on a reference model to specialize the
standard software process.
When an organization does not have an effective project-planning
Figure 2: The Prototype Workflow. system, it may be difficult or even impossible to introduce
The management process approach, implemented through a Web advanced methods and technology. Poor project planning
system, provides several facilities already described in similar generally leads to unrealistic schedules, inadequate resources, and
researches. The Activities Record module allows the assignment frequent crises. In such circumstances, new methods are usually
of team members to tasks within the process configuration. In this ignored and priority is given to just constructing and testing. This
way, it is possible to allocate activities to people with the right proposal has been applied to two different projects in a
skill sets [14]. The evaluation level that performs measurements Telecommunication Company. The first project defined a single
and analysis could indicate the maturity of a certain working model of integrated processes to reach a standardization of
group to then decide whether it could take a specific procedures and then, to support a continuous improvement [17].
responsibility within the software development. When starting a The second one modeled operational processes to extract
project and once the corresponding software processes is defined measurements, which were used to support these processes
or improved (definition and improvement levels), it is vital that improvement according to the company commercial strategies
the resulting process is effectively communicated to the [19]. As the telecommunication company is geographically spread
geographically spread project participants [15]. The action plan over several Brazilian states, in both projects, the results could
defined at the improvement level is disseminated through the just be reached by using the process management approach
Web system, which facilitates the understanding by hypertext described here.
links among the actions and the used software process. The The existence of a world network that allows accessing
monitoring level collects data and provides hypertext links information placed in different servers, independently of their
among activities and the documents produced during the hardware, contributed to the enhancement of the communication
development of a software product. As the set of documents means. In addition to that, the changes in the global economy and
related to a software development process are many, of different the evolution of the information technology imposed conceptual
formats, hypertext functionalities [16] can be used to put together redefinition of the social structure of professional working and
the diversity of resulting process products. employment. For that reason it is also necessary to redefine some
Our prototype can be classified as an Electronic Process Guide software engineering methods and practices. Software product
(EPG), it means, a process guide available in an electronic format, quality is not the only obstacle to surpass through modern
which could also be a strategy to an incremental introduction of equipment, advanced computing tools or revolutionary
process support technology into organizations [17]. Scott et. al. techniques. The quality of a software system corresponds to an
[15] suggests a list of six “must have” features of an EPG, and effort that involves professionals, organizations and technology
among them our proposal already respects the following five: linked to a continuous software process improvement.
good content, templates and examples, a navigation tree reflecting
8. REFERENCES In: Proceedings of ICSE Workshop 'SE over the Internet',
[1] 2nd Workshop on Coordinating Distributed Software Limerick, Ireland, June 2000.
Development Projects, IEEE 8th International Workshops on [18] C. Maidantchik, K. M. de Oliveira, H. V. Teixeira, M. L.
Enabling Technologies: Infrastructure for Collaborative Masiero, A. R. C. da Rocha, Applying Management Model
Enterprises, 1999. and Ontology on a Telecommunicatin Company, 13th
[2] Maurer, F., Dellen, B., An Internet Based Software Process International Conference on Software & Systems
Management Environment, ICSE 98 Workshop on Software Engineering and their Applications, Paris, France, November
Engineering over the Internet, 1998. 2000.

[3] Fielding, R. T., Whitehead-Jr., E. J., Anderson, K. M., [19] C. Maidantchik V. Costa, C. Rocha, A. P. Wauke,
Bolcer, G. A., Oreizy, P., Taylor, R. N., "Web-Based “Achieving Process Improvement through Modeling and
Development of Complex Information Products", Measurements”, The 5th World Multi-Conference on
Communications of the ACM, Vol..41, No. 8, 1998. Systemics, Cybernetics and Informatics (SCI 2001),
Orlando, Florida USA, July 2001.
[4] M. G. Mendonça, V. BASILI et al, “A Prototype Experience
Management System for a Software Consulting
Organization”, In: Proceedings of the 13th International
Conference on Software Engineering and Knowledge
Engineering, pp. 29-36, Buenos Aires, June, 2001.
[5] V. Grover, J. T. C. Teng, K. D. Fiedler, "IS Investment
Priorities in Contemporary Organizations", Communications
of the ACM, Vol. 41, No. 2, 1998.
[6] Software Engineering Institute (SEI) (1997), The Capability
Maturity Model: Guidelines for Improving the Software
Process, Addison-Wesley Longman, Inc.
[7] B. Curtis, M. I. Kellner, J. Over, "Process Modelling",
Communications of the ACM, vol. 35, no. 9, 1992.
[8] CERN, http://www.cern.ch/
[9] World Wide Web Consortium,
http://www.w3.org/hypertext/WWW/TheProject
[10] ATLAS Collaboration, ATLAS Computing Technical
Proposal, CERN/96-43, Geneva, Switzerland, 1996.
[11] W. Humphrey, M. Kellner, Software Process Modeling,
Technical Report CMU/SEI-89-TR-002, February 1989.
[12] ISO/IEC 12207: Information technology - Software Life
Cycle Processes, International Standard Organization, 1995.
[13] D.K. Dunaway, S. Masters, CMMSM-Based Appraisal for
Internal Process Improvement (CBA IPI): Method
Description, Software Engineering Institute, CMU/SEI-96-
TR-007, Pittsburgh, Pennsylvania, USA, 1996.
[14] Boris Kötting, Frank Maurer: Approaching negotiation
automation for software development companies, In:
Proceedings of ICSE Workshop 'SE over the Internet',
Toronto, Canada, May 2001.
[15] L.Scott, R.Jeffery and U.Becker-Kornstaedt: Preliminary
Results of an Industrial EPG Evaluation, In: Proceedings of
ICSE Workshop 'SE over the Internet', Toronto, Canada,
May 2001.
[16] Luca Bompani, Paolo Ciancarini, Fabio Vitali: Sophisticated
hypertext functionalities for software engineering, In:
Proceedings of ICSE Workshop 'SE over the Internet',
Limerick, Ireland, June 2000.
[17] Ulrike Becker-Kornstaedt, A Strategy for the Integration of
Software Process Support Technology into Organizations,
 Process Support for Distributed Extreme
Programming Teams
Frank Maurer Sebastien Martel
University of Calgary University of Calgary
Department of Computer Science Department of Computer Science
Calgary, Alberta, Canada, T2N 1N4 Calgary, Alberta, Canada, T2N 1N4
+1 (403) 220 3531
[email protected] [email protected]

ABSTRACT are often delivering huge amounts of documentation (for example

requirements specifications, system architecture descriptions,
Extreme programming (XP) is arguably improving the productivity software design documents, test plans) instead of delivering
of small, co-located software development teams. In this paper, we useful functionality to the client. Sometimes, projects are
described an approach that overcomes the XP constraint of co- cancelled before the system is deployed – wasting all the effort
location by introducing a process-support environment (called that was already spent on analysis and design.
MILOS) that helps software development teams to maintain XP
practices in a distributed setting. MILOS supports project XP, on the other hand, focuses development effort on activities
coordination, information routing, team communication, and pair that deliver high-quality functionality to the end user as fast as
programming. possible. Deliverables usually are restricted to high-level use
cases (user stories), source code and test code. XP has in its
original form proposed by Beck [3] two severe limitations. First,
it does not scale well to larger teams. Second, it requires the XP
Categories and Subject Descriptors team to be collocated. Overcoming the collocation requirement
D.2.9 [Software Engineering]: Management – programming while preserving the high productivity and quality of XP
teams. processes is one goal of our approach and the focus of this paper.
In Section 2 we give an overview on our MILOS approach.
Section 3 and 4 provides a detailed usage scenario while section 5
General Terms describes the state of implementation. We conclude with a
Management summary and a look on future work.

2. THE MILOS APPROACH

Keywords The overall goal of the MILOS approach is to support process
execution and organizational learning for virtual software
virtual software development teams, distributed extreme development teams. In this paper, we focus on how MILOS
programming, process support supports Distributed XP (DXP). [8] describes the knowledge
management aspect in more detail.
The support provided by MILOS should be minimally intrusive to
1. INTRODUCTION reduce overhead: MILOS stands for “Minimally Invasive Long-
Extreme programming (XP) [3, 4, 9] is one of the most innovative
term Organizational Support”. The MILOS approach can be
software development approaches of the last years. The XP
applied for open source projects as well as for commercial teams
movement seems to be driven by disappointment with current
that are distributed over the world. It was adapted to support
software development practice: low productivity and low user
Distributed XP.
satisfaction are seen as commonplace. Software development teams
We now describe requirements that were underlying the
development of MILOS. Then we explain the overall structure of
Permission to make digital or hard copies of all or part of this work for the approach.
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, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
Copyright 2002 Frank Maurer & Sebastien Martel.
2.1 Requirements on Tool Support for Virtual Team members access the Internet with a Web browser and
connect to the MILOS server. First, they login to the MILOS
Teams system to access their workspace. From their workspace they may
Using XP and open source processes as a baseline, the work retrieve the list of current projects, user stories, currently
process of virtual software teams can be improved in several ways. available tasks, task estimation, and pair programming facilities.
Project coordination: XP teams are usually much more closely Pair programming is supported via NetMeeting. We now
coordinated than open source projects. Hence, project coordination illustrate MILOS using an example taken from [3].
support is strongly required for DXP. This should allow the team
to assign tasks to developers, set deadlines and get an overview on 3.1 Creating User Stories
the current state of the project. Team members on the other hand After the creation of an initial project and the assignment of a
should be able to access their to-do lists and retrieve relevant project manager to it, the customer is ready to enter story cards
information for performing their tasks easily. into the MILOS system (see Figure 1).
Synchronous communication: XP replaces documentation by
synchronous, face-to-face communication. Face-to-face
communication is not feasible in a distributed team and needs to be
replaced by technical means. Besides using e-mail for
communication, synchronous communication like audio and video
calls or text chat may be helpful. If two developers want to do pair
programming, application sharing is needed.
Active notifications and information routing: Instead of merely
making information available for pull access, it would be useful
push to important information to the users as soon as it becomes
accessible. This may help to overcome the missing informal
communication that happens in coffee breaks & lunches or by
simply overhearing conversations in the pair programming area of
an XP project. This push approach should include notifications
when important events occur in a project. For example, a manager
needs to be notified when a task gets delayed or a developer needs Figure 1. Story Card
to be notified when an update of another component becomes The top part of the main screen displays a menu that allows
available that she is using. The change notification mechanism of accessing all components of MILOS (Workflow Engine,
MILOS is discussed in [7]. Resource Pool, Process Model, etc). Below that a menu is
Integrate process execution with knowledge management: In displayed that allows for manipulating the selected component
virtual teams, members frequently change. Hence, there is a high (here, is allows to access the workflow execution support
demand on bringing new members up to speed on their tasks and in component). The left side shows the hierarchical task
preserving good sources of knowledge for the organization. As decomposition of all projects. Selecting a task in the task
software development often has to struggle with fast changing decomposition will display detailed task information on the right
technology, keeping the contents of an experience base up to date side. The programmers can then contact the customer, either
is a demanding task and needs to be integrated as much as possible through the MILOS framework or by conventional means, and
with the everyday processes of executing processes. While XP discuss the story with them if need be. They can revise the
relies primarily on face-to-face communication for knowledge description of the user story – creating a new version of the
exchange, the MILOS approach to DXP includes means for existing card. In addition, they can then add notes to the story
building a process centered experience base for the team. card pertaining to implementation details and split up the story
MILOS provides overviews on the current state of all tasks of a into several smaller stories if the scope is too large. They would
project as well as project management queries to find late tasks. then proceed to decompose the story into specific programming
MILOS also allows accessing the information produced as the task that will be needed to satisfy the next build. The workflow
output of a task easily. engine of MILOS handles the creation and changes of tasks.

Team members are able to access the project plans and the 3.2 Task Creation
information related to each task using a standard Web browser. For each user story, the MILOS system automatically creates a
top-level process “Design and implement user story <story
number>”. The input of this process is the newly created user
3. USING MILOS DXP FOR DISTRIBUTED story. Then the programmer can decompose the user story into
smaller and more concrete tasks. A possible decomposition of the
EXTREME PROGRAMMING above user story could have two separate sub-tasks (see Figure 2).
The following scenario illustrates the infrastructure provided by the
MILOS framework to support distributed extreme programming.
Given the user story, the programmer may create a sub-task called be met. After having signed-up for some task, a programmer can
“create m/frame” and another one called “create RM boundary”. pair with another programmer through the MILOS framework.

Figure 4. Estimating effort needed

Figure 2. Task Decomposition 4. PAIR PROGRAMMING

After having decomposed user stories into concrete programming Using Microsoft NetMeeting, MILOS provides an audio and
task, the programmer may describe the task in more detail using the video link between two developers and the ability to share the
workflow engine user interface. Tasks are associated with specific desktop between them. These capabilities are used to support pair
projects and can be assigned to various team members. For each programming in a distributed setting. The MILOS system keeps
task, the manager enters planned start and end dates. In addition, track of who is logged on to the system and provides the
the users are able to define the inputs and outputs of processes. The possibility to contact the responsible team member for a task or
story card automatically becomes an input of all subtasks. any other team member that is currently logged in. Figure 5 is a
Furthermore, the users are able to specify the information flow screenshot of shared desktop using NetMeeting. The screen
between tasks by defining the output of one process to become the shows the MILOS environment in the back, NetMeeting on the
input of another (see below). top right and a VisualAge for Java window at the top left. The
programmer (sitting at a remote machine) just enters a method
definition. The local team member inspects the code and can
comment on it using audio/video conferencing. The local
programmer may also take over and edit the method from his
machine.

Figure 3. Defining the inputs of a task

Specifying the information flow allows the MILOS system to
provide access to input information that was created as the output
of another task: the output of a task, e.g. a source code file, is
transferred to the MILOS server and stored in a version
management system. From there, any successor task may access the
current version as well as older versions. As this is done via HTTP
requests, tunneling through a firewall usually is not a problem.
The programmer is able to estimate the effort and the forecasted
end dates (see Figure 4). The effort simply consists of the total Figure 5. Pair programming with NetMeeting
number of workdays needed to complete the task (measured in The screen might seem cluttered at first. However, we tried to
ideal engineering time). To set the forecasted end date, the show as much features as possible. Normally a programmer
developer takes the required effort as well as his overall workload would only look at the other desktop, see the top left corner, and
into account. switch between screens when needing to look up a function
The team lead can keep a close eye on the progress of each task by definition or when video conferencing. After the pair
watching the “percentage complete” values and steer the team in programming team has completed a task, they can update the task
the correct direction if the requirement for the next build will not status and mark it as completed. They can also upload any output
files to the MILOS server that, in turn, would route them to other 5. STATE OF IMPLEMENTATION
team members who would need them. MILOS is Web-based and accessible as a web service on the
MILOS web site1 from any machine connected to the Internet
4.1 Initial Results and Lessons Learned using a standard Web browser. MILOS DXP uses the EJB-based
We were using MILOS for our own development processes over
version as its basis and adds its extensions.
the last time. Although we do not yet have statistical valid data, we
can provide some initial results. Even though we did not All the core functionality described in the paper is implemented
quantitatively measure the gain in productivity offered by so far that we were using MILOS for our own development
distributed extreme programming at this time, we can provide the processes. Nevertheless, the system still has some bugs and we
following insight as to its advantage. are currently (April 2002) stabilizing the implementation as well
as improving its usability by using feedback from our
• Overall, we were able to apply XP in a distributed development team.
setting.
MILOS and MILOS DXP are open source software that can be
• Having the computing power of two machines while downloaded from the MILOS Web site.
having the impression of only using one is sometime
useful. Since NetMeeting is only bandwidth intensive 6. RELATED WORK
and does not use much CPU time the person receiving Related work comes mainly from two areas: Software Process
the shared desktop can use their CPU to regenerate code Support and (Distributed) Extreme Programming. As we already
or compiling a new build. discussed XP and DXP, we focus here on related work in process
However, we also ran into some problems attributed to various support.
hardware and software technologies. Most process improvement approaches, e.g. capability maturity
• Due to network latency, it is better for the programmer model, SPICE, QIP, require describing the development
that is typing to share their desktop. This even holds for processes more or less formally. Within the framework of
high-bandwidth connections. When switching position, software process modeling, several languages were developed that
the other programmer can share their desktop. This allow for describing software development activities formally [1,
allows smoother programming since there is no delay for 6, 11]
the programmer who is actually typing. Software process models represent knowledge about software
• When pair programming with different screen size and development. They describe activities to be carried out in
resolution the pair should find a resolution that is software development as well as the products to be created and
comfortable for both developers. If the two resolutions the resources & tools used. These models can be a basis for
differ by a too great amount, one of the programmers will continuous organizational learning as well as the actual basis for
need to use the scrollbars extensively. the coordination and the management of the software engineering
activities.
• Using video conferencing AND audio on a dial up
modem (56K) is not practical. The team should use Software process modeling and enactment is one of the main
broadband access or only audio conferencing with team areas in software engineering research. Several frameworks have
members that only have access to dial-up Internet. been developed (e.g. procedural [11], rule-based [10, 12], Petri
net based [2], object-oriented [5]).
• The video link is often unnecessary if the pair
programming together is already acquainted. Process modeling and enactment approaches usually are used to
rigorously define heavy-weight processes. They are weak
• Color, fonts and sound scheme needs adjustment in order concerning light-weight approaches like XP and do not directly
to be properly viewed when sharing desktops. For support key XP practices. They also are not good at providing a
example, unless having access to a high bandwidth good communication and collaboration infrastructure for virtual
connection enabling “sharing in true color mode” is not teams.
practical.
• There is no need to acquire video equipment able to 7. CONCLUSION AND FUTURE WORK
capture 40 frames per second in 600x800 resolution In this paper, we described our approach for supporting virtual
when the link to your teammates can only sustain a software teams in distributed extreme programming. The MILOS
bandwidth of 40KB/sec. system is an Internet-based process-centered process support
environment that supports communication, collaboration and
• NetMeeting is restricted to 1 to 1 audio/video coordination of DXP teams.
communication. Using tools like the Microsoft
Conference Server would provide the necessary support With MILOS DXP, we are aiming at an improved efficiency of
for multiple client videoconferencing. virtual teams. Whereas undoubtedly the introduction of new tools

1 http://sern.ucalgary.ca/~milos
at first results in an increased workload, we argue that, in the long 8. ACKNOWLEDGEMENTS
run, the proposed approach will improve productivity of virtual The work on MILOS DXP was supported by the NSERC
software development teams (although it will most probably not (National Science and Engineering Research Council of Canada),
reach the same productivity levels as collocated teams). ASERC (Alberta Software Engineering Research Consortium),
Our future work will focus on four aspects: The University Of Calgary, and Nortel Networks with several
research grants.
• Stabilizing the MILOS implementation and usability
improvements We specifically would like to thank Sandra Barlot, Subhendu
Chattopadhyay, Darryl Gates, Christine Jia Li, Raul Nemes,
• Formal evaluation of the approach
Philip Nour, and Jay Wallace for implementing and testing the
• Extreme federations MILOS DXP system.
• Knowledge management for DXP
9. REFERENCES
Stabilizing the MILOS implementation and usability [1] Armitage, J., and Kellner, M. (1994). A conceptual schema
improvements: After porting MILOS to WebSphere Server 4.0, we for process definitions and models. In D. E. Perry, editor, Proc. of
encountered some bugs and instabilities. As we were using MILOS the Third Int. Conf. on the Software Process, IEEE Computer
for our own process support, we were experiencing some sub- Society Press.
optimal user interaction. We are planning to fix these this summer
[2] Bandinelli, S., Fuggetta, A., and Grigolli, S. (1993). Process
(Summer 2002). MILOS is offered as a Web-based service to the
Modeling-in-the-large with SLANG. In IEEE Proceedings of the
software development community. We expect to get valuable
2nd Int. Conf. on the Software Process, Berlin (Germany).
feedback from MILOS users to determine future improvements.
[3] Beck, K.: Extreme Programming Explained: Embrace
Formal evaluation of the approach: We would like to set up
Change, Addison-Wesley Pub Co, 1999, ISBN: 0201616416
controlled experiments to evaluate the feasibility and the benefits
& problems of distributed extreme programming. In addition, we [4] Kent Beck, Martin Fowler: Planning Extreme Programming,
would like to compare the productivity and quality of XP teams Addison-Wesley Pub Co, 2000, ISBN: 0201710919
and DXP teams to determine the influence of collocation on [5] Conradi, R., Hagaseth, M., Larsen, J. O., Nguyen, M., Munch,
productivity. B., Westby, P., and Zhu, W. (1994). Object-Oriented and
Extreme federations: One of the problems of XP is scalability Cooperative Process Modeling in EPOS. In PROMOTER book:
concerning team size: XP works for small teams of five to ten Anthony Finkelstein, Jeff Kramer and Bashar A. Nuseibeh (Eds.):
people but there is some doubt that it works with even a mid-sized Software Process Modeling and Technology, 1994. Advanced
team of twenty people. One way to scale it up could be to have Software Development Series, Research Studies Press Ltd. (John
loosely coupled federations of XP teams that work together on a Wiley).
single project. This poses several interesting research questions: [6] Curtis, B., Kellner, M., and Over, J. (1992). Process
• How can we preserve XP productivity and quality in multi- modeling. Comm. of the ACM, 35(9): 75–90.
team environment? [7] Dellen, B.: Change Impact Analysis Support for Software
• Do we need additional documentation and, if so, how Development Processes, Ph.D. thesis, University of
much more? And what needs to be documented to enable a Kaisersalutern, Germany, 2000
smooth work of the Extreme Federation. [8] Holz, H., Könnecker, A., Maurer, F.: Task-Specific
• Do Extreme Federations needs a component architecture to Knowledge Management in a Process-Centred SEE, Proceedings
work? of the Workshop on Learning Software Organizations LSO-2001,
Springer, 2001.
• How fixed need the interfaces between components of
individual XP teams be? How much flexibility and/or [9] Jeffries, R., Anderson, A., Hendrickson, C.: Extreme
adaptability of requirements do Extreme Federations loose Programming Installed, Addison-Wesley Pub Co, 2000, ISBN:
compared with “normal” XP teams? 0201708426
Knowledge management for DXP: XP is very weak in conserving [10] Kaiser, G. E., Feiler, P. H., and Popovich, S. S. (1988).
the knowledge gathered by the development team. It’s focus on Intelligent Assistance for Software Development and
verbal communication for knowledge exchange makes it difficult Maintenance, IEEE Software.
to preserve information in a storable format. As a result of keeping [11] Osterweil, L. (1987). Software Processes are Software Too.
development knowledge primarily in the heads to the people, XP In: Proc. of the Ninth Int. Conf. of Software Engineering,
will run into trouble when the members of the development team Monterey CA, pp. 2-13.
change frequently or when the development on the system stops for [12] Peuschel, P., Schäfer, W., and Wolf, S. (1992). A
some time and is then resumed. Hence, an approach is needed that Knowledge-based Software Development Environment
integrates knowledge management and DXP. Supporting Cooperative Work. In: Int. Journal on Software
Engineering and Knowledge Engineering, 2(1).
 Project Management Issues
in Globally Distributed Development
Heather L. Oppenheimer
Bell Laboratories, Lucent Technologies
345 Resor Ave.
Cincinnati, OH 45220 USA
+1 513.751.0927
[email protected]

ABSTRACT This paper summarizes some of the key challenges of

This paper summarizes some of the key project distributed software engineering that have been
management challenges of distributed software identified during internal project management audits
engineering that have been identified during internal over the past five years. Factors that have contributed to
project management audits in Lucent Technologies over success in this environment are also addressed.
the past five years. Factors that have contributed to
success in this environment are also addressed. The paper describes the procedures used in the audits,
the methodology used to summarize data across the
Data from project management assessments indicate audits, and the issues that appeared in a majority of the
that, with respect to issues that affect project results, projects. It suggests areas for future work, but does not
there is little difference between co-located and propose or evaluate detailed solutions to any of the
geographically distributed projects consisting of 20- issues raised. (Note: Detailed procedures and specific
500+ people. Many of those issues are related directly data are proprietary to Lucent Technologies.)
to information management, an unclear definition of
roles, accountabilities and authorities, and a lack of
relationships based on common goals, processes, and
2. BACKGROUND
tools. Since 1995, members of the Software Technology
Center in Bell Laboratories have provided assessments
In a large company, any solution for project of the overall health of Lucent Technologies
management issues has to take into account that many development projects by offering project management
projects cannot be co-located. Industry needs tools and reviews or audits called “HealthChecks”. Each
technologies that facilitate information management, HealthCheck is led by a member of the Software
relationship building, and the interfaces between Technology Center and includes 2-4 subject matter
different functional roles. experts who have hands-on management experience in
project management, software, and/or hardware
development. The subject matter experts are generally
1. INTRODUCTION line managers in Lucent Technologies Business Units
Although conventional wisdom emphasizes that having with responsibility for project or program management
a small, co-located team is the most efficient and of other products.
effective way to develop software, companies like
Lucent Technologies primarily have large, complex Each HealthCheck follows the same procedure:
software development projects distributed across - Pre-review: The HealthCheck team gathers and
multiple organizations and locations. Product reviews project management, process, and
development in Lucent Technologies typically involves development artifacts related to the project (e.g.
at least 100 people in globally distributed locations and meeting notes, architecture specifications, process
different organizations. In addition, many products are descriptions, requirements documents, schedules,
part of one or more integrated offers, which requires project plans).
collaboration among several organizations. - Background Interviews: The HealthCheck team
leader does one on one structured interviews with
executives responsible for the project
- Presentations: Relevant project members present
an overview of the project for the HealthCheck
team
- Interviews: HealthCheck team members do one
on one structured, but very informal one-hour
interviews with 25-40% of the project team
members. The interviews include representatives
 of all functional areas, both experienced and new
staff, and both management and technical staff The information below is based on proprietary data
(occasionally including administrative staff.) gathered in 49 HealthChecks delivered between 1995
- Caucus: The HealthCheck team shares and 2000. Projects ranged in size from about 20 to 250
information gathered and puts together a report staff. Very small teams (fewer than 10 staff) do not
summarizing “What We Heard”, “Project request separate HealthChecks, although they might be
Strengths”, “Concerns”, and “Recommendations” reviewed as a component of a larger integrated offer.
- Initial Readout: The HealthCheck team presents Below this threshold, we would expect a different set of
the report to the project team (usually the project issues. Slightly over one third of the projects assessed
team leaders and executives) for discussion. were multi-site.
- Action Plan and Final Readout: The project · 3-6 sites – 11 projects
team leaders, with assistance from the · 2 sites – 8 projects
HealthCheck team leader if requested, put together · 1 site – 30 projects
a plan to address some or all of the concerns and
share both the readout and the action plan with the
rest of the project team.
- Six Month Follow-up: The HealthCheck team 4. RESULTS
leader contacts the project team leader to find out Before we began to evaluate the information, we
which, if any of the recommendations were expected co-located groups to have significantly
implemented, and if so, what were the results. different issues than distributed development
organizations. However, there was actually little or no
difference in the key project management-related issues
3. METHODOLOGY between distributed projects and those with co-located
development. We saw no identifiable patterns based on
HealthChecks are primarily intended as a mechanism - the size of projects (again, taking into account that
for evaluating a particular project and providing a “small” project in this case has more than 20
recommendations on how to make it more effective. people),
They are not designed for specific data gathering.
- whether the projects were developing standalone
- They are done at customer (executive) request so
assets or products that were part of integrated
the data is not a random sample of Lucent
offers,
Technologies projects.
- Each HealthCheck is customized and might focus - whether the project was working on a new release
on different areas of concern at the request of the of legacy code, a new product, or a new product
customer. using legacy code,
- The HealthCheck review team members vary from - or the planned duration (6-12 months, 13-18
project to project, based on the areas of concern months) of the release being evaluated.
and availability of subject matter experts and team
leaders. The majority (more than 50%) of the projects assessed
- The interviews vary based on the audit focus, the had very strong technical teams, were consistent in their
individual being interviewed or the subject matter application of appropriate methodologies such as
expert: different questions may be selected or reviews and inspections, had strong software
others added. There is no specific scale for scoring configuration management processes and tools in place,
or categorizing responses. and were using automated tools to manage and/or
- Information gathered during the one on one execute their tests. Distributed teams made use of off
interviews is private and confidential to the the shelf and proprietary tools and technologies to
individual and the reviewer, so the atomic data has facilitate their work in those areas.
already been aggregated before it is summarized in
the readout. The majority of the projects, however, also had two
- Readouts focus only on those strengths and issues major problems: a less than crisp understanding of roles
likely to impact the success or failure of that and the interfaces between the roles, and “too much
project. As a result, some issues may not be data, but not enough information.” Both of these
documented if a particular project has others that problems tend to be exacerbated when projects were
are considered to be more critical. large and/or distributed. Many distributed projects also
had issues related to relationships and culture. All other
However, the HealthCheck teams consistently use the issues and concerns were related to these three areas.
same interview question templates, readout templates,
and process checklists. As a result, we have been able 4.1. Issues in Roles and Responsibilities
to look at several years’ results and identify some Many projects have lists of “roles and responsibilities”,
recurring themes and concerns. Each of the issues
but few specify the accountabilities, authorities, and
listed below was identified in at least 33% of the
interfaces related to the roles. Therefore it was hard for
projects surveyed. Many were identified in more than
team members to determine a clear owner for major
half of the projects.
project-affecting jobs. This resulted in overlaps and in place tended to identify the risks, but not their
conflicting directions. Without a clear understanding of likelihood, cost, mitigation plans and triggers for
the authorities associated with each role, decisions contingencies. Risk plans were also not continuously
weren’t made at the lowest possible level. reviewed and updated.

4.2. Issues in Information Management 4.4.2. Estimation

and Organization Resource and schedule estimation was frequently a
We saw information management problems in three concern. In particular, when projects were part of a
areas: data overload, pull models based on the larger offer or had legacy code to support, estimations
expectation that “everyone should know it’s there” and made by project managers and the development team
push models that weren’t timely. Projects use intranets, for a particular delivery did not include adequate
personal websites, email, databases, and configuration resources for maintenance of previous releases or
management systems to manage the information they development of concurrent releases. People in different
create. There was a lot of useful information available, functional groups or from different locations or
but often no easily accessible and understandable high organizations often didn’t use the same estimation
level or big picture view to help team members processes and tools. Estimations were not consistently
understand strategy, priorities, key decisions, critical based on the same assumptions in all segments of a
risks, the current status and how their own work relates project. As a result, even when the schedules of
to each of those areas. Web sites were scattered, some different groups appeared to be in synch, since
were only accessible to part of the team, and others held expectations of what a particular milestone meant
redundant and/or outdated information. When varied between the different groups, the overall team
information was pushed to the team, it was often not at underestimated the project cost and interval.
a time when it was useful, so as a result it was ignored
or lost. Decisions were made slowly and not 4.4.3. Project Management Meetings
communicated effectively to all affected team
members. Customers and team members complained, Most projects held regularly scheduled project
“Don’t just tell me it’s on the Web – I can‘t find it!” meetings as a means of exchanging status information
and escalating issues. In multi-site organizations the
meetings tended to be held with the majority of
4.3. Issues in Relationships & Culture participants attending in person (in one or more central
As mentioned above, we did not see any significant locations) and other stakeholders attending via
difference between multi-site organizations and single conference call. This mechanism was successful in
site organizations in the key project-affecting concerns some organizations. In others, we saw problems such
raised during a HealthCheck. However, during the as
interviews, one difference was apparent. In projects - some stakeholders regularly missed meetings
that did not make an effort to build relationships - some materials were not available to remote
(usually by setting up face to face interactions), the participants
interview teams heard many more comments that - side talk among on-site participants
indicated a “we vs. they” culture and a lack of trust and
- little or no communication of discussions and
respect for team members in other functions or at other
decisions to those who had not attended the
locations. In this case, even when decisions were made
meeting
and communicated adequately, people didn’t always
support them or act on them.
4.5. Issues in Training
During the 1990’s, when the economy was booming
4.4. Issues in Project Management and technology companies were hiring, we frequently
Many of the issues categorized as “project
saw concerns related to training. (This has been much
management” were directly related to the information
less of an issue in the past two years.) Two concerns
management and organization issues listed above: appeared repeatedly:
- no high level view of project or offer-level risks - The plan did not include adequate time to train
and status new team members on the project domain,
- project team members had no clear view of the processes, tools and technologies.
project strategy - Training of new team members took critical time
- excessive detailed tracking of “inch-pebbles” from experienced staff.
rather than critical project milestones Some projects had implemented training programs for
- individual projects that were part of an overall their new staff, primarily in the areas of process
offer release had little visibility into each other’s definitions required for ISO 9000/9001 certification and
risks, and status in the architecture and design of the current product.
All relied heavily on mentoring by experienced staff.
4.4.1. Risk Management This was particularly a problem for projects that were
hiring new staff at one location and had experts at
Many projects needed to improve their risk assessment another.
and management processes. Those that had processes
 - Integration: phased testing made integration more
4.6. Issues in Requirements difficult.
Engineering
Many of the issues categorized as “requirements
engineering” were also directly related to the 5. FUTURE WORK
information management and organization issues listed We will continue to assess Lucent Technologies
above: software development projects and identify recurring
- It was hard to find all the details needed to develop issues and trends. We also intend to refine the
a feature. HealthCheck process so that we are able to capture data
- Time was wasted trying to find and interpret more consistently without compromising the privacy of
requirements. the participating individuals and the proprietary nature
of the projects. As members of the Software
4.6.1. Document Control and Integration Technology Center, we are working to define and
implement solutions to many of these issues.
Most projects had some form of document versioning
and management. Some had mechanisms for tracing There is ample opportunity for research into potential
requirements to test cases and vice versa. However, solutions to some of the problems identified during
most did not have any automated mechanisms for these HealthChecks. In particular, we would be
artifact flowthrough that would facilitate linking interested in collaborating on software engineering
information created in one function, such as solutions incorporating tools and technologies that
requirements, with information needed in another, such address the issues of information management and
as architecture, design or test. organization, clarify roles and responsibilities and
interfaces, and help build an organization culture that
4.6.2. Requirements Churn includes facilitating relationships among team members
Not surprisingly in a high-tech industry, the who are not geographically or temporally co-located.
requirements for many of the projects evolved as the To help with the roles and responsibilities and
customer needs changed or were more completely information management issues, we are also very
identified. In several projects, slow turnaround interested in solutions that address the integration and
between customers and systems engineers and between flowthrough of information among software
systems engineers and developers impeded progress. development groups responsible for different functional
Developers complained that the requirements weren’t areas.
baselined, systems engineers complained that product
management and sales weren’t providing the
information they needed, and product management and 6. CONCLUSIONS
sales complained that development was going off and
There was little or no difference in the key project
building products without knowing what the customer
management-related issues between distributed projects
wanted.
and those with co-located development. Many of the
issues are related directly to information management,
4.7. Issues in Testing an unclear definition of roles, accountabilities and
In the multi-site projects, some testing was co-located authorities, and a lack of relationships based on
with development and some was located at other sites. common goals, processes, and tools. In a large
Even when testing for a particular product was co- company, any successful solution to those issues will
located, there was usually additional integration or take into account that many projects cannot be co-
network level testing done at another site when the located.
product was included in a larger offer. Some of the
issues we saw were
- Roles & Responsibilities: no end-to-end owner for
test strategy and full coverage. 7. ACKNOWLEDGEMENTS
- Information Management & Organization,
Training: testers not co-located with developers Ann Martin and Ellen Herrick, both formerly of Lucent
and had difficulty finding out the product details Technologies, gathered much of this data during the
necessary to test the system. years that they were responsible for the HealthCheck
- Schedule: short test intervals, reduced even more process in the Software Technology Center. We miss
because development interval was underestimated, them and wish them well in retirement. Thanks are also
entrance criteria waived to get “something” into due to all the HealthCheck leaders and reviewers since
test early. 1995, who gathered this information and summarized it
in the individual project readouts.
 Palantír:
Increasing Awareness in Distributed Software Development
Anita Sarma André van der Hoek
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425 USA
{asarma,andre}@ics.uci.edu

control loop of the program. While each change individually

ABSTRACT does not lead to problems, the fact that the behavior of the
Distributed software development, just like regular software main loop of the program depends on the value of the global
development, typically involves developers working in par- variable may lead to an overall failure of the program. Thus,
allel on the same set of artifacts. Unlike regular software while both changes are syntactically and semantically cor-
development, however, distributed software development is rect in their own right, they indirectly conflict by influenc-
limited since developers are unable to easily coordinate ing the overall semantics of the program in an undesirable
their efforts in person due to the presence of physical manner.
boundaries. While configuration management systems pro-
vide some automated coordination support in the form of Typically, a configuration management (CM) system [2] is
locking and merging, the high cost of conflict resolution in used to help coordinate the activities of developers such that
distributed software development requires even higher lev- the number of conflicts resulting from parallel change is
els of support to ensure as few integration problems as pos- reduced. By providing capabilities that either avoid parallel
sible. In this paper, we introduce Palantír, a system that development altogether (e.g., locking) or assist in resolving
complements existing configuration management systems conflicts (e.g., merging), these systems certainly have suc-
by providing distributed awareness of project progress. In ceeded in reducing the number of conflicts [3]. Nonetheless,
particular, Palantír provides each developer with a graphical merge conflicts do occur and often must be manually re-
display that not only shows which remote artifacts are solved, a time-consuming and sometimes difficult task.
changing, but also presents them with a measure of both the Furthermore, the issue of indirect conflicts remains unad-
severity and the impact of the changes. As a result, develop- dressed by CM systems [4]. At best, they provide a histori-
ers are provided with an increased level of awareness that cal trace of changes. While useful in identifying what
allows them to detect and resolve problems much earlier. changes may have caused a problem and which developers
may have been involved, no further information is provided
and the problem has to be manually resolved. Especially
1. INTRODUCTION when the developers involved reside in geographically dif-
A large number of software development organizations have ferent locations, this may be a rather unpleasant exercise.
subsidiaries or branches located in different geographical
locations. In these settings, work tends to be carefully parti- As a complement to existing configuration management
tioned to minimize the number of conflicts. Nonetheless, it systems, we are developing Palantír, a system that is spe-
is often unavoidable that, at times, developers have to si- cifically designed to provide distributed project awareness
multaneously change the same set of artifacts. As a result of targeted at reducing both direct and indirect conflicts.
such parallel development, conflicts [1] arise both directly Palantír is based on the observation that it is not only perti-
and indirectly. Directly, parallel changes to the same artifact nent for developers to know what artifacts are being
may lead to conflicts if the changes involve modifications to changed by other developers, but also what the severity and
the same parts of the artifact. Indirectly, mutually exclusive impact of those changes are with respect to the specific task
changes can individually be working properly, but com- at hand. Palantír provides each developer with a graphical
bined lead to a non-working version of the system under display that shows the relevant set of artifacts, illustrates
development. which artifacts have already been and are being modified by
other developers, and, based on an analysis of the changes,
Consider, for example, a situation in which one change in calculates and highlights the severity and impact of each
the program logic leads to a different value of a global vari- change. In doing so, Palantír deliberately but non-
able and a second change modifies the behavior of the main intrusively breaks the isolation that currently exists when a
developer is performing a task in their CM workspace. As a
result, a developer can proactively resolve potential prob-
lems and thereby reduce the number, and significance, of
direct and indirect conflicts.
In the remainder of this paper, we discuss the details of
Palantír. We first describe its architecture in Section 2. Sec-
tion 3 discusses our implementation thus far. In Section 4
we present related work and we conclude the paper in Sec- ferent times. Some of the measures that we intend to explore
tion 5 with an outlook at our future work. are the following.
• Relative number of lines of code that has been
2. Conceptual Architecture changed. Although a remarkably trivial measure, it can
Figure 1 shows the conceptual architecture of Palantír, be important to understand how many lines of code ac-
which consists of four different types of components inter- tually have been altered by a developer. The rationale
linked via a generic event notification service [5]. The first is simple: the more lines of code that have been
component is the CM system, which serves as the source of touched, the more faults that could have been intro-
all information used by Palantír. To drive updates to its duced [6]. There are two drawbacks to using this meas-
visualizations, Palantír assumes that the CM system sends ure. First, an action such as renaming a variable
out notifications upon check-out or check-in of an artifact. throughout a file may indicate a severe change whereas
A check-out represents the beginnings of a change activity. in reality it is a rather simple change that deserves little
Since it is important for developers to be aware of which to no attention. The other drawback is that the measure
other developers are changing which artifacts, Palantír re- is language dependent, and means much more for, for
cords this fact and displays it in its visualizations. A check- example, a Cobol program than a Prolog program.
in signals the end of a change activity (or, at least, a check-
point that is being made by a developer). Again, it is impor- • Relative number of token-based differences. Some
tant for other developers to be aware of this fact and Palantír algorithms used to detect and report similarities be-
updates its visualizations accordingly. In addition, it calcu- tween two files are token-based and replace each key-
lates and shows the severity of the change (e.g., the differ- word and variable name throughout a file with a unique
ence according to some measure between the old version token before applying a differencing algorithm. The
and the new version of the artifact) and the impact of the advantage of this kind of measure is that it takes into
change (e.g., the potential conflict according to some meas- account such simple changes as renaming a variable.
ure between the change and the artifacts that another devel- The disadvantage is that the token replacement algo-
oper has in their workspace). Whereas the severity can be rithm is dependent on the implementation language and
calculated once for all developers, it is important to note requires specific language plug-ins.
that the impact is calculated per developer since each devel-
• Relative number of changes in the abstract syntax
oper may have a different set of artifacts in their workspace tree. It is possible to analyze the differences between
and the impact of the change can vary accordingly.
the abstract syntax trees of the two different versions of
an artifact. This has the distinct advantage that the
measure is as closely as possible related to the imple-
mentation language, which results in a rather accurate
assessment of the severity of the change. At the same
time, however, this approach is extremely language
dependent and requires the construction of abstract
syntax trees before the measure can be calculated.
While a severity analysis can be performed solely based on
artifacts in the CM repository, the change impact analysis is
dependent on the artifacts that a developer has in their
workspace. The measures that we intend to explore, there-
fore, are different from those used in the severity analysis.
• Relative number of overlapping lines of code that
have changed. A crude measure of impact, this meas-
Figure 1. Conceptual Architecture of Palantír. ure basically attempt to assess the impact by calculat-
It is important to note that the architecture is purposefully ing the number of lines of code that have changed in
generic. Not only do we want Palantír to interoperate with the artifact and are present in the workspace of a de-
many different CM systems, we also want to experiment veloper. The more overlap exists, the more impact the
and understand the effectiveness of different severity and change is likely to have.
change impact analysis algorithms as well as of different • Relative number of interfaces that have changed.
visualizations. It is also important to note that the architec- This measure is based on the assumption that changes
ture is inherently distributed. Different components can (and that do not change the interface of an artifact have no
sometimes must) execute in different locations since they further influence beyond the realm of the artifact itself.
are all connected via a distributed event notification service. While certainly accurate if the information hiding prin-
The heart of Palantír is formed by the severity analysis ciple is strictly followed, the measure certainly does
component, the change impact analysis component, and the not apply to all software artifacts.
visualization component. The severity analysis component • Relative size of dependency analysis graph. This
basically attempts to answer the question of how much has measure adapts established dependence analysis tech-
changed between the newly checked-in and previous ver- niques [7] to basically calculate the “reach” of a
sion of an artifact. Different measures can be useful at dif- change (e.g., how much of the code in the workspace
 Figure 2. Palantír Main Visualization.
might be affected). The larger the reach, the higher the of the interface. Clearly, large graphical displays can con-
impact. A drawback of this method is that computa- vey more information, but are much more intrusive than, for
tionally it can be very expensive. example, a small ticker tape. The ticker tape, on the other
hand, can only convey a minimal amount of information.
It should be noted that none of the severity or change impact We intend to develop a range of visualizations from which
measures is completely accurate. Rather, most provide a each developer can choose the one they prefer.
conservative estimate of severity or impact. This is by de-
sign since it is neither necessary nor possible to provide
completely accurate severity or change impact analyses. 3. Implementation Details
Nonetheless, it is useful for any developer to have a “feel” We are currently implementing Palantír. Our focus, thus far,
for the severity or impact of a change, allowing them to has been on creating one of the main visualization compo-
make a judgment call and undertake preventive action as nents. Shown in Figure 2, the visualization presents a devel-
they see fit. oper with a hierarchical view of a compound artifact and its
constituent artifacts. Each constituent artifact itself may
It should also be noted that these algorithms should not only consist of other artifacts, and each artifact in the view may
operate on single artifacts, but also have to be adapted to consist of multiple versions (as indicated by a stack of arti-
operate on compound artifacts. Many a time, Palantír will facts). For example, in the figure, developer Anita is view-
show a set of compound rather than individual artifacts. The ing the artifact “par.c” version 1.0, which consists of the
severity and change impact of these compound artifacts has artifacts “foo.c” and “bar.c”. Since Anita started monitoring,
to be communicated to the developer as much as those of the artifact “bar.c” has been checked out by Andre (as indi-
individual artifacts. In fact, often Palantír will be used in a cated by the question mark). The artifact “foo.c” version 1.0
setting in which a developer monitors several compound has been checked in by Anita (as indicated by the exclama-
artifacts and only when the severity or change impact of one tion mark), version 1.1 is currently checked out by Anita,
of those rises above a certain threshold will the developer and version 2.0 has been checked in by Andre. The artifacts
examine the individual artifacts that make up that com- are labeled such that changes made by other developers are
pound artifact to understand the reason for the high severity discernable from those made by the user of the workspace.
or change impact. Color coding (green for changes made by the user of the
The last component in the Palantír architecture is the visu- workspace and red for others) further enhances this separa-
alization component. This component is responsible for tion (though not visible in this black and white print).
presenting to the developers, the information that is gener- The two vertical bars indicate severity and change impact.
ated by the CM system and the analyzers. At a minimum, Note that atomic artifacts (artifacts that are not partitioned
the visualization component will show which artifacts are into smaller artifacts) that have not been checked in yet do
being checked-out and checked-in and the severity and im- not have any severity or change impact, since the potential
pact of each change. In doing so, developers are presented changes are still “hidden” in the workspace.1 Compound
with an increased level of awareness of other developers’ artifacts that are not checked in yet, on the other hand, will
activities.
We intend to develop different visualizations that each 1
Typically, however, a developer will periodically create
strikes a different balance among the amount of information snapshots, which will lead to new versions that exhibit se-
that is displayed, usability of the interface, and intrusiveness verity and change impact.
have severity and change impact since their constituent reducing the number of occurrences of both direct and indi-
artifacts already may have been changed and checked in. rect conflicts. As such, it represents a departure from current
philosophy in configuration management in breaking the
The visualization allows for zooming in and zooming out. traditional notion of isolated workspaces. Although changes
Double-clicking on a particular version of an artifact makes can still be made in isolation and developers are not imme-
that the primary artifact being viewed. A back button allows diately influenced by other changes, they most certainly
a developer to go back up the hierarchy to view the artifacts must be aware of the changes in order to avoid problems
from a higher point of view. Note also that more detailed when they check in their artifacts. Especially in a geo-
information on an artifact can be requested and that “hid- graphically distributed setting, such awareness allows them
den” artifacts can be brought to the foreground with a sim- to avoid and resolve conflicts early, which has the potential
ple click. of saving a tremendous amount of cost and effort.
The next step of our implementation effort involves creating Clearly, we are not finished developing Palantír. Now that
several of the severity and change impact components and we have nearly completed the visualization component, our
linking those to the visualization component using the Siena focus is shifting to implementing the severity and change
event notification service [5]. We have chosen to use Siena, impact analysis components. Once those components are
because it operates in a distributed setting and allows filter- completed, we intend to experiment significantly in a case
ing of notifications. Specifically, a visualization component study involving an Open Source project to understand the
can register the artifacts they are interested in, and Siena effectiveness of a tool like Palantír in supporting distributed
will only deliver those events that are of pertinence to those software development. We specifically want to determine
artifacts, thereby optimizing much of the network traffic. which analyses and visualizations are most effective in
which situations. In addition, we would like to explore the
4. Related Work potential role of Palantír in project management. For that
Most configuration management systems ignore awareness purpose, we are looking into the possibility of extending
altogether [2, 8]. At best, developers can query the CM Palantír with a graphical view of all artifacts (rather than the
system for new changes and synchronize their workspace small subset it currently supports) and using a movie-like
with those changes. Other than that, a developer is com- capability in which we replay events from a CM archive to
pletely isolated from the changes being performed by oth- visually show project progress.
ers. One exception is Coven [9], which requires developers
to specify beforehand which artifacts they will be modify- 6. Acknowledgements
ing. Unfortunately, only direct conflicts are avoided this This research is supported by the National Science Founda-
way and, furthermore, developers usually do not know be- tion under grant number CCR-0093489. The authors would
forehand the complete set of artifacts they will be changing. like to thank David Redmiles and Paul Dourish for their
The area of software visualization has produced a number of valuable input that shaped the project in its early phases.
visualizations, including matrix views [6], 3-D colored
graphs [10], bar graphs [11], and ticker tapes [12], that pro- 7. References
vide insight in the way a software system evolves over time. [1] Easterbrook, S.M., et al., A Survey of Empirical Stud-
As compared to Palantír, these systems tend to focus on ies, in S. M. Easterbrook (ed) CSCW: Cooperation or
project management rather than awareness among develop- Conflict? 1993: London,Springer-Verlag. p. pp. 1-68.
ers. As a result, the visualizations are not dynamic (e.g.,
they only provide a view of the system evolution at one [2] Conradi, R. and B. Westfechtel, Version Models for
particular moment in time) and focus on severity, not Software Configuration Management. ACM Comput-
change impact. ing Surveys, 1998. 30(2): p. 232-282.

Hill et al. [13] created an extension to the Zmacs editor that [3] Perry, D.E., H.P. Siy, and L.G. Votta. Parallel
shows how often a particular section in a document has Changes in Large Scale Software Development: An
been read or modified. Similar to Palantír, this extension Observational Case Study. in Proceedings of the 1998
provides developers with an increased level of awareness. International Conference on Software Engineering.
Unfortunately, the visualization only provides an indication 1998.
of change severity, not change impact. Moreover, use of the [4] Grinter, R., Supporting Articulation Work Using Con-
system requires developers to know a-priori who is chang- figuration Management Systems. Computer-Supported
ing which artifact and, more importantly, requires continu- Cooperative Work, 1996. 5(4): p. 447-465.
ous network connectivity, something that is simply not fea-
sible in a geographically distributed setting. TUKAN [14], [5] Carzaniga, A., D.S. Rosenblum, and A.L. Wolf, De-
another collaborative editor that augments the editor’s inter- sign and Evaluation of a Wide-Area Event Notification
face with an indication of changes being performed by other Service. ACM Transactions on Computer Systems,
developers, suffers from similar drawbacks. 2001.
[6] Lanza, M. The Evolution Matrix: Recovering Software
5. Conclusion Evolution using Software Visualization Techniques. in
Palantír is a system that we are currently developing to Proceedings of the Fourth International Symposium on
bring project awareness to developers. Palantír is explicitly the Principles of Software Evolution. 2001.
designed to operate in a distributed setting and is aimed at
[7] Dwyer, M. and L.A. Clarke, A Flexible Architecture [11] Baker, M.J., and Eick,S.G., Space-Filling Software
for Building Data Flow Analyzers, in Proceedings of Visualization. Journal of Visual Languages and Com-
the Eighteenth International Conference on Software puting, 1995. 6: p. 119-133.
Engineering. 1996, ACM. p. 554-564.
[12] Fitzpatrick, G., et al. Instrumenting and Augmenting
[8] Burrows, C. and I. Wesley, Ovum Evaluates Configu- the Workaday World with a Generic Notification Ser-
ration Management. 1998, Burlington, Massachusetts: vice called Elvin. in Proceedings of the Sixth European
Ovum Ltd. Conference on Computer Supported Cooperative
Work. 1999. Copenhagen, Denmark.
[9] Chu-Carroll, M.C. Supporting Distributed Collabora-
tion through Multidimensional Software Configuration [13] Hill, W.C., Hollan, J. D., Wroblewski, D., and McCan-
Management. in Proceedings of the Tenth Interna- dless,. Edit wear and read wear. in Proceedings of the
tional Workshop on Software Configuration Manage- 1992 ACM Conference on Human Factors in Com-
ment. 2001. puter Systems. 1992.
[10] Jazayeri, M., C. Riva, and H. Gall. Visualizing Soft- [14] Schümmer, T., and J.M. Haake. Supporting Distributed
ware Release Histories: The Use of Color and Third Software Development by Modes of Collaboration. in
Dimension. in Proceedings of the International Con- Proceedings of the Seventh European Conference on
ference on Software Maintenance. 1999: IEEE Com- Computer Supported Cooperative Work. 2001.
puter Society.
 Does Global Software Development Need a Different
Requirements Engineering Process?
Didar Zowghi
Faculty of Information Technology,
University of Technology, Sydney,
P O Box 123 Broadway
NSW 2007 Australia
+61 2 9514 1860
[email protected]

ABSTRACT that process. In some cases, RE process is defined at a very fine

level of details and the steps in the process must be carried out
exactly as described [5]. However, this form of process
Global software development exhibits certain features that make description usually applies to very simple processes, for more
it fundamentally different from traditional co-located software complex processes, the description is usually less detailed and it is
development. These characteristics have an impact on the up to the person or team who are executing the process to carry it
requirements engineering process. The traditional requirements out (enact the process) in their own environment.
engineering processes do not cater for the peculiarities of
developing software over distance and across different time zones We have recently investigated RE practices in global software
with different cultural boundaries. This paper advocates the development through conducting a field study in a geographically
development of a different RE process for global software distributed organisation [6]. We have found that some of the
development outlining some preliminary suggestions on what fundamental problems associated with various activities making
such process model would include. up the requirements engineering process are exacerbated when the
software development teams are geographically distributed [6].
This is due to the fact that global software development (GSD)
1. INTRODUCTION possesses certain distinguishing characteristics that challenge and
directly impact the RE process activities. According to Carmel [7]
Requirements Engineering (RE) plays a very important role in the distinguishing features of global software development teams
software development. For some years now, it has been are distance, time-zone differences, and cultural differences. In
recognized that problems associated with requirements this paper, I briefly discuss the impact of these characteristics on
engineering are among the major reasons for software project the RE process and argue that because of their impact on RE and
failures where the end product does not meet the real needs of the hence on software development there is a need to fully investigate
problem owners [1][2][3]. Errors in requirements specifications and develop RE processes that specifically support and are
can have a major impact on software costs. One estimate given tailored to global software development.
states that 40% of requirements need rework during the course of
the software development project [4]. It is evident that early
detection and correction of potential problems during requirement
stage may alleviate many much larger problems later on during 2. Impact of GSD on RE Process
testing and maintenance. Despite this, in comparison with the rest
of software development activities, relatively little time and effort RE is one of the most important phases because it is at this stage
is expended during the requirements phase. Furthermore, while where purpose, functionality and boundaries of the software are
much research has been conducted for supporting, improving and meant to be fully identified, analysed and defined. RE is also the
automating many of the different activities making up the most communication rich activity of software development since
software development process, elicitation, analysis, specification, it is at this stage of development that most of the interactions
validation and management of requirements remain one of the between the problem owners and problem solvers take place.
least explored and have the least satisfactory scientific Geographical distance between development sites has a direct
foundations. impact on all forms of communication. That is, communication is
usually less frequent and more constrained [7]. If the customers
A process is an organized set of activities that transforms inputs to
and developers are not co-located, clearly distance impacts the
outputs. It is difficult to write down a sequential plan of activities
communication between the problem owning and problem solving
that adequately describes the RE process as suggested by activity-
communities who are the two essential groups of stakeholders in
oriented approaches to process modelling such as the Waterfall
RE. Global software teams often deal with distance through using
model. It is generally believed that RE has its own life cycle. In
different media such as video conferencing, phone, email and
the RE literature many different definitions have been given for
groupware. It is important to identify the differences between
the RE process as well as for the activities that take place during
communication during requirements engineering and other stages
of software development. Why is using email alone (for example) delay in requirements negotiation and prioritisation. Once more,
not effective enough to facilitate the necessary communication? traditional RE processes (for nonglobal software development)
The issue here is not just facilitating asynchronous obviously do not pay particular attention to this issue. In many
communication among stakeholders but ongoing management of organizations project planning and management is often linked
the discussions and ultimate requirements decisions made by with the RE process since all software development projects
email (i.e. the management of the RE process as well as RE commence with RE activities. Hence a new RE process for global
product). Given the communication intensive nature of RE software development must accommodate different time zones in
process, it is surprising that none of the existing RE process such a way that managers can then capitalise on the information
models (e.g. [8][9][10]) make systematic or rigorous mention of provided in the RE process for their project planning.
synchronous or asynchronous tools in their process descriptions.
Finally, issues related to cultural difference have been partially
Clearly, there is a need to include tool support in RE process to
addressed in the RE literature (see for example [12][13][14]).
global software teams when developing requirements. Such tools
Macaulay [12] argues that any RE process model depends to a
not only provide the usual traceability and record keeping
large extent on the customer-supplier relationship. This
functionality that the commercially available requirements
relationship becomes even more important when we deal with
management tools1 offer but are specifically suited to integrate
differences in national and ethical traditions, customs, norms of
well with the type of tools that are commonly used by global
behaviour, as well as language. It has been observed [7] that
software teams. The expectation from such an integrated toolset
cross-cultural teams (as opposed to a more uniform cultural
would be a seamless flow of requirements information among
groups) have more potential for productivity as well as more
stakeholders that are geographically distributed.
potential for problems. Moreover, differences between functional
Distance also affects all levels of team coordination and control, cultures in the same organization (i.e. marketing versus
which are the main ingredients for effective team management. developers versus engineers) often cause major problems in RE
Usually, managing software teams depends little on controls and process. This is mainly due to lack of effective communication
commands, relying instead on informal means of coordination and lack of trust between diverse groups (with different
(such as face to face contact), which is very communication backgrounds) in organisations. These are the so-called “soft”
intensive [7]. Furthermore, managing the RE process is hard issues of requirements management that mostly necessitate
enough when development teams are co-located let alone when changes in organisational and project culture. These issues cannot
they are geographically dispersed. During RE process the be adequately addressed by computer science or software
participants have to work towards coming up with a common engineering research alone and should more appropriately be
vision of the requirements for the system to be built. Distance not studied using research methodologies and theories originating
only slows down this process but also prevents congruence to be from management and social sciences discipline. There is,
achieved by consensus and consultation. however, an opportunity to investigate these issues with respect to
global software development and propose a set of guidelines to
Another challenge for RE that is impacted by distance is
alleviate these problems in practice. In contrast there is much
knowledge management. The sheer volume of requirements
more scope to do something about providing tools, methods and
information from multiple sources needs to be shared with all the
techniques to assist practitioners in more effective management of
stakeholders. Much of this form of knowledge remains tacit and
requirements artifacts and the RE process over distance.
undocumented particularly at earlier phases of requirements
engineering process such as elicitation, negotiation and
prioritisation. This problem is magnified further when
3. Conclusion
stakeholders are geographically distributed and are not able to
communicate informally with one another in order to pass on the In this paper I have briefly discussed the impact of global
knowledge. Once again, the existing RE processes do not take this software development over RE process and identified some of the
factor into account in order to develop RE techniques and issues that can be addressed by investigating and devising a new
methods that would address the issue of knowledge management RE process model for geographically distributed requirements
over distance. engineering. Because social issues are at the heart of many of the
problems in RE and because they cannot solely be addressed by
Time differences are known to exacerbate the communication the currently available technical methods, novel approaches and
related issues especially when there is no natural overlap of paradigms need to be sought. Furthermore, the relative
working hours for voice or video conversations [7]. In this way, immaturity of the RE field suggests an eclectic approach to RE
one side almost always has to compromise. Time difference process issues especially those related to distance, communication
affects elicitation, negotiation and prioritisation activities of RE and coordination problems. The answer to the question: “Does
process. It hinders appropriate participation from stakeholders Global Software Development Need a Different Requirements
such as system users and field personnel. Speed is regarded as one Engineering Process?” is clearly “yes”. To this end, we are
of the critical success factors in information technology and is of commencing a research project to develop an integrated RE tool
major concern in global software development [11]. RE process is environment that addresses the challenges of communication and
often considered to be time consuming because of its total coordination identified in [6] with an existing industry partner
reliance on communicating the requirements from one group of who is engaged in global software development. Another two
people to the other. Time differences thus introduce a further related important question that needs to be investigated are:
“Should we really be doing distributed RE?” and “Does the cost
of doing RE in distributed settings is justifiable?” Many
1
Tools such as DOORS or Rational’s RequisitePro etc. geographically distributed systems development organizations try
to elicit and specify requirements in one location where the REFERENCES
customers physically are using the traditional face-to-face
[1] Jackson, M., The meaning of requirements, the annals of
meetings. They then pass the specifications to the rest of the
software engineering, special issue on requirements
development team to be designed and implemented in a different
engineering, 3:5-21, 1997.
location. What is not clear, however, is that how does the
organization manage the requirements throughout the software [2] Sawyer, P., Sommerville, I., and Viller, S., Improving the
development lifecycle. To be able to answer these questions and requirements process, Proceedings of the 4th International
address any of the related issues that is influenced by GSD further workshop on Requirements Engineering: Foundation of
research is needed. Software Quality (REFSQ’98), Pisa, Italy, July 1998.
[3] Thayer, R.H., and Dorfman, M., Software requirements
engineering, IEEE Computer Society Press, Second Edition
1997.
[4] Hutchings, A., and Knox, S., Creating products customers
demand. Communications of the ACM, 38(5), 1995.
[5] Zowghi, D. A logic-based framework for the management of
changing software requirements, PhD thesis, Macquarie
University, Sydney, Australia 1999
[6] Damian, D. E., Zowghi, D. The impact of stakeholders’
geographical distribution on managing requirements in a
multi-site organization, Department of Software Engineering
Technical Report, 2002.1. University of Technology,
Sydney, Australia.
[7] Carmel, E. Global software teams, Prentice Hall, 1999
[8] Kotonya, G., and Sommerville, I., Requirements
Engineering, processes and techniques, Wiley, 1997
[9] Houdek, F., and Pohl, K., Analysing requirements
engineering processes, a case study, Proceedings of the 2nd
International Workshop on Requirements Engineering
Process (part of DEXA 2000), England, September 2000.
[10] Zowghi, D., A requirements engineering process model
based on Defaults and revisions, Proceedings of the 2nd
International Workshop on Requirements Engineering
Process (part of DEXA 2000), England, September 2000.
[11] Herbsleb, J., Mockus, A., Finholt, T.A. and Grinter, R.E. An
empirical study of global software development: distance
and speed, International Conference on Software
Engineering, Toronto, 2001
[12] Macaulay, L. Requirements Engineering, Springer,1996
[13] Al-Rawas, A. and Easterbrook, S. Communication problems
in requirements engineering: a field study, Proc. of Conf. on
Prof. Awareness in Software Engineering, London, 47-60,
1996
[14] Jirotka, M., and Goguen, J., Requirements Engineering
social and technical issues, Academic Press, 1994.