collaborative software engineering – awareness and concurrency

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 ?)