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