and philosophy of our understanding of awareness
support. When facing difficulties in software
development, some previous work tends to offer all-
in-one solutions. That is why their tools
automatically inform users of their inference and
give exact instructions. While our philosophy is that
since most mistakes and failures are made by human
(Sandom, 2007), it is more appropriate to let human
make the final judgment. We believe that informal
awareness information helps formal processes to
work (Grinter, 1995). Hence, Team Radar takes an
informal and qualitative approach, and simply
visualizes extracted awareness information without
distracting developers from their main work.
Another important issue of designing awareness
supporting systems is whether the system is intended
for retrospective analysis of historical data, or it is
used to analyze a project currently in progress. Of
course, each approach has its own advantages. Most
previous work, however, focuses more on either
aspect of the project over the other. In our solution,
we attempt to offer users a consistent and coherent
team memory by unifying both past and present
information in one visualization. Developers can use
Team Radar to monitor coworkers’ activities and
coordinate collaboration, while managers may
review and analyze the project by replaying the
event scripts stored in Team Rader.
Figure 1: Team Radar Architecture.
3.2 Architecture
Figure 1 shows the architecture of Team Radar,
which adopts the design of previous work (Sarma
and van der Hoek, 2002). The system is an extension
of Qt Creator. The client is a collection of Qt Creator
plug-ins. Qt Creator relies on signals to propagate
events. The collector is such a plug-in that connects
to its interested signals, and is notified when these
signals are emitted. The viewer is the visualization
component that presents awareness information to
users with animations. On the server side, which
resides on a separated site, the receiver listens and
accepts events from clients’ collectors, stores them
into an extra repository, and then asks the distributor
to broadcast them to other clients’ viewers. The
viewer can also retrieve the event scripts in the
repository and replay them offline. Offline playback
enables managers to inspect daily activities, review
the process and analyze collaboration issues.
3.3 Capturing Local Events
Based on Gutwin’s knowledge elements of
awareness (Gutwin, 1998), workspace should track
several types of awareness information, categorized
by “how, when, who, where, and what” questions. In
addition, a survey conducted in Microsoft shows that
the majority of information needs are about
discovering, meeting, and keeping track of people,
not just code (Begel et al., 2010). Hence, our work
focuses more on tracing what developers are
working or have worked on, rather than what
specific changes they have made. In more detail, we
address these aspects of collaboration:
Working mode. As a typical software development
scenario, developers switch back and forth
among several activities, or working modes in Qt
Creator, including designing, coding, testing,
debugging, reading documents, etc. Working
mode could also label current progress of the
project. No matter what process model the
project follows, in different phases of the project,
developers carry out each type of activity with
various emphasis and intensity. In earlier phases,
developers take more time in designing and
coding mode, while in later phases, more effort
will be put to testing and debugging.
Current changes. It is important that developers
have the notion of who else is working on the
same artifacts or those artifacts closely related.
Failing to acquire such information may lead to
duplicated work, merge conflicts, and perhaps
build failure (Hattori, 2010). Showing developers
what artifacts others are changing gives them an
early warning of potential conflict.
Past changes. In a software project, knowledge of
others' activities, both past and present, has equal
value for assisting the overall cohesion and
effectiveness of the team. Observation of the
evolution of a project helps to understand the
history and rationale behind the code. Knowing
who has worked most often or most recently on a
particular file aids to identify members’
contribution and locate expert assistance
(Schneider et al., 2004).
Though the significance of fine-grained information
in tracing and coordinating activities is largely
accepted, the granularity still needs to be tuned
based on its particular application. In our case, we
Collector
Viewer
Receiver
Distributor
Repository
signals
Client
Server
Qt
Creator
ENASE 2011 - 6th International Conference on Evaluation of Novel Software Approaches to Software Engineering
116