A Framework for Integrating ESL Tools - IRIT

We take the MDE (Model-Driven Engineering) approach, and build a metamodel
suited to the description of ad-hoc collaboration practices, which extends
SPEM. This paper shows, on an example taken from a real world project, how
appropriate our conceptualization is for actual software projects. It should be
noted that our effort is not restricted to face to face or synchronous interactions,
but covers any collective work that escapes the plan-and-execute scheme.
The rest of this paper is organized as follows. Section 2 characterizes adhoc
collaboration to build an understanding which we formalize in Section 3
as a metamodel. Section 4 describes and represents a real world collaboration
scenario with the proposed concepts. Section 5 summarizes some related works.
2 Ad-hoc Collaborative Processes
Collaboration happens whenever two or more individuals work on the same
task or interact with the same work product. Collaboration has been defined
as “a collective effort to construct a shared understanding of a problem and its
solution” [16].
Various concerns such as power sharing, responsibility assignment, appropriate
recognition, giving credit, coordinating actions, trust, etc., can easily undermine
collaborative efforts, by incurring to much cognitive overhead on participants,
and taking the focus away from their actual tasks. In software engineering,
these problems are further complicated by worldwide distribution of teams, the
amount of knowledge sharing required, communication among people with different
expertise, and high complexity and interdependency of artifacts [9].
Thus, people usually collaborate only when the need arises. While there
can be some prior planning, collaboration, especially in software engineering,
is mostly ad-hoc [3, 15]. Whereas planned collaboration happens because it was
on the agenda, ad-hoc collaboration is prompted by a new issue or new considerations
in an existing issue. A field study found ad-hoc collaboration to amount
to as much as 69% of all collaborative work in software development [15].
Any tool that seeks to support collaboration had better speak the language
of its users, so as to not increase the cognitive overhead they are already fighting
with, and provide a frictionless surface for development [2]. When ad-hoc
collaboration occurs in software engineering, the concepts involved for the practitioners
are the actual people doing the job, what each of them is doing, and
which artifacts they are manipulating.
However, the central concepts used in process models like SPEM (role, product,
task) are at a much higher level of abstraction than those used by practitioners
to understand collaboration, thus hiding needed information:
– Role. How do we describe interactions between people playing the same role,
but still doing different things like coding two dependant components, when
the very need for two people surfaces only in the middle of the project?
– Tasks. When we find out that more than one person is needed for a task
(which is the very definition of collaboration), how can we, for example,
2