Collaborative Software Engineering – Awareness and ConcurrencyAgam
Outline
Introduction to CSE
Brief overview of five recent papers
Synthesis with in-class discussion
Introduction to CSE
Seamless, fine-grained, real-time collaboration between geographically distributed software engineers
Example: Pair programming Refactoring Working on any part of the software
design/analysis process as a distributed team
Introduction to CSE (contd.)
Research Areas in CSE
Introduction to CSE (contd.)
Design space of CSE tools lies between two extremes (optimistic, pessimistic)
Brief overview of papers
“Interruptions on Software Teams: A Comparison of Paired and Solo Programmers” J. Chong, R. Siino CSCW 2006
“CVS Integration with Notification and Chat: Lightweight Software Team Collaboration” G. Fitzpatrick, P. Marshall, A. Phillips CSCW 2006
Brief overview of papers (contd.) “A User Evaluation of Synchronous Collaborative
Software Engineering Tools” C. Cook, W. Irvin, N. Churcher APSEC 2005
“Towards Synchronous Collaborative Software Engineering” C. Cook, N. Churcher, W. Irvin APSEC 2004
“Modelling and Measuring Collaborative Software Engineering” C. Cook, N. Churcher ACSC 2005
“Lightweight Software Team collaboration …”
Communication MediatedInformal
Idea: public awareness of CVS contents as a means of communication
Currently being performed (in a weak sense) by mailing lists
“Lightweight Software Team collaboration …” (contd.)
Most prevalent form of CSE – version control !!
Idea – combine this with informal communication
Result – mediated communication
“Lightweight Software Team collaboration …” (contd.)
Visualization of CVS a good idea ‘tickertape’ mechanism used to
broadcast recent CVS activity to team“publish/subscrive” system displays
<log entry/group/developer>Made users aware of “manipulation of
project artifacts” Studied interaction/discussion arising
from
“Lightweight Software Team collaboration …” (contd.)
Results of studyStimulated developer discussionPromoted ‘awareness’CVS log had better context, more infoHelps document “flow”
(commentary !)
“Lightweight Software Team collaboration …” (contd.)
Results of study (contd.)‘commit’ operation – public act (as it
should be, marking transition of code from private workspace to public workspace) – Awareness !
Knowing that other developers are ‘tracking’ makes a difference – interruptibility management !
“Modelling and Measuring CSE …”
CSE demands a little more than typical CSCW (E.g. shared whiteboards)Longer lifetimesHigher conflict resolution costMore complexity
Currently rely on “social protocols”
“Modelling and Measuring CSE …” (contd.)
CAISE architecture• Server based• Semantic model maintained• Requires parsers/analysers• Events – input/change/feedback
Supports visualization
“Modelling and Measuring CSE …” (contd.)
Editor Panel User Tree Client Panel
“Modelling and Measuring CSE …” (contd.)
“Modelling and Measuring CSE …” (contd.)
ObjectivesBuilds at different temporal
granularitiesFine-grained integritySemantic-based awareness and
feedbackPrivate work and re-integration
“Modelling and Measuring CSE …” (contd.)
CAISE and CSEProvides Taskwork-oriented features
(as do traditional systems)But also -- Teamwork-oriented
features
Different modes reflecting different approaches to conflict resolution
“Modelling and Measuring CSE …” (contd.)
Private (traditional) mode – similar to cvs
Independent – simultaneos work (CAISE monitors semantic relationship)
Melee – active conflict resolution by developers (communicate using out-of-band channel)
WYSIWIS – “tour of the code”
“Modelling and Measuring CSE …” (contd.)
Server allows awareness of Code dependenciesDeveloper relationships
Visualization – see changes to code base over time
“User evaluation of synchronous CSE …” (contd.)
User StudyTwo modes
• Conventional• Collaborative
Two types of tasks• Inter-file• Intra-file
Measured task-completion times
“User evaluation of synchronous CSE …” (contd.)
Results Collaborative
mode twice as fast
Subjective survey results approved (tools rated 14-15 on a scale of 1-20)
“Interruptions on Software Teams …”
Studied interaction in the workplace, more specifically knowledge-intensive work
Developers take breaks from workSocial natureFunctional natureFrequently interrupt each other
“Interruptions on Software Teams …” (contd.)
User study of two situationsProgrammers working as a “pair” (co-
located)Programmers working “solo”
(remotely)
“Interruptions on Software Teams …” (contd.)
ObservationsInterruptions – both functional + social
for solo, largely functional for pairPair was harder to interrupt‘interruptibility’ for pair easier to
assessResumption of task/switching tasks
faster for pair
“Interruptions on Software Teams …” (contd.)
ObservationsAwareness of interruptiblity => Can
handle interruptions better !‘Team pair’ – partner helps maintains
state
“Interruptions on Software Teams …” (contd.)
ConclusionsDesign Implication – make
programmers ‘aware’ of multiple tasks to get same benefit for remote collaboration
Actively maintain context
Awareness and Concurrency Awareness
Know what other users are doing• Helps avoid major conflicts
Awareness of interruptibility Similar to mailing lists Conflict Resolution
Concurrency Control Helps avoid developers making conflicting
changes
Awareness and Concurrency (contd.)
ConclusionExplored three different areasIssue of ‘collaboration’ in software
engineeringAugmenting CVS with simple tool –
trasforms developer relationshipsCAISE – awareness of relationships -
> conflict resolutionAwareness related to interruptibility
Thank you !
(Questions ?)