Collaborative Software Engineering Awareness and Concurrency

1
Collaborative Software Engineering Awareness
and Concurrency

• Agam

2
Outline

• Introduction to CSE
• Brief overview of five recent papers
• Synthesis with in-class discussion

3
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

4
Introduction to CSE (contd.)

• Research Areas in CSE

5
Introduction to CSE (contd.)

• Design space of CSE tools lies between two
  extremes (optimistic, pessimistic)

6
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

7
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

8
Lightweight Software Team collaboration

• Communication
• Mediated
• Informal
• Idea public awareness of CVS contents as a means
  of communication
• Currently being performed (in a weak sense) by
  mailing lists

9
Lightweight Software Team collaboration
(contd.)

• Most prevalent form of CSE version control !!
• Idea combine this with informal communication
• Result mediated communication

10
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 entry/group/developer
• Made users aware of manipulation of project
  artifacts
• Studied interaction/discussion arising from

11
Lightweight Software Team collaboration
(contd.)

• Results of study
• Stimulated developer discussion
• Promoted awareness
• CVS log had better context, more info
• Helps document flow (commentary !)

12
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
  !

13
Modelling and Measuring CSE

• CSE demands a little more than typical CSCW (E.g.
  shared whiteboards)
• Longer lifetimes
• Higher conflict resolution cost
• More complexity
• Currently rely on social protocols

14
Modelling and Measuring CSE (contd.)

• CAISE architecture
• Server based
• Semantic model maintained
• Requires parsers/analysers
• Events input/change/feedback
• Supports visualization

15
Modelling and Measuring CSE (contd.)

• Editor Panel
• User Tree
• Client Panel

16
Modelling and Measuring CSE (contd.)
17
Modelling and Measuring CSE (contd.)

• Objectives
• Builds at different temporal granularities
• Fine-grained integrity
• Semantic-based awareness and feedback
• Private work and re-integration

18
Modelling and Measuring CSE (contd.)

• CAISE and CSE
• Provides Taskwork-oriented features (as do
  traditional systems)
• But also -- Teamwork-oriented features
• Different modes reflecting different approaches
  to conflict resolution

19
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

20
Modelling and Measuring CSE (contd.)

• Server allows awareness of
• Code dependencies
• Developer relationships
• Visualization see changes to code base over time

21
User evaluation of synchronous CSE (contd.)

• User Study
• Two modes
• Conventional
• Collaborative
• Two types of tasks
• Inter-file
• Intra-file
• Measured task-completion times

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

23
Interruptions on Software Teams

• Studied interaction in the workplace, more
  specifically knowledge-intensive work
• Developers take breaks from work
• Social nature
• Functional nature
• Frequently interrupt each other

24
Interruptions on Software Teams (contd.)

• User study of two situations
• Programmers working as a pair (co-located)
• Programmers working solo (remotely)

25
Interruptions on Software Teams (contd.)

• Observations
• Interruptions both functional social for
  solo, largely functional for pair
• Pair was harder to interrupt
• interruptibility for pair easier to assess
• Resumption of task/switching tasks faster for pair

26
Interruptions on Software Teams (contd.)

• Observations
• Awareness of interruptiblity Can handle
  interruptions better !
• Team pair partner helps maintains state

27
Interruptions on Software Teams (contd.)

• Conclusions
• Design Implication make programmers aware of
  multiple tasks to get same benefit for remote
  collaboration
• Actively maintain context

28
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

29
Awareness and Concurrency (contd.)

• Conclusion
• Explored three different areas
• Issue of collaboration in software engineering
• Augmenting CVS with simple tool trasforms
  developer relationships
• CAISE awareness of relationships - conflict
  resolution
• Awareness related to interruptibility

30
Thank you !

• (Questions ?)