• Save
Using Formal Concept Analysis to Construct and Visualise Hierarchies of Socio-Technical Relations
Upcoming SlideShare
Loading in...5
×
 

Using Formal Concept Analysis to Construct and Visualise Hierarchies of Socio-Technical Relations

on

  • 1,305 views

The poster (in slide format) we presented at the New Ideas and Emerging Results track of the Int'l Conf. on Software Engineering (ICSE), 20-22 May 2009.

The poster (in slide format) we presented at the New Ideas and Emerging Results track of the Int'l Conf. on Software Engineering (ICSE), 20-22 May 2009.

Statistics

Views

Total Views
1,305
Views on SlideShare
1,299
Embed Views
6

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 6

http://www.slideshare.net 5
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Using Formal Concept Analysis to Construct and Visualise Hierarchies of Socio-Technical Relations Using Formal Concept Analysis to Construct and Visualise Hierarchies of Socio-Technical Relations Presentation Transcript

  • Using Formal Concept Analysis to Construct and Visualise Hierarchies of Socio-Technical Relations Michel Wermelinger, Yijun Yu The Open University, UK Markus Strohmaier Graz University of Technology, and Know-Center, Austria
  • 1. Motivation
    • Software engineering is socio-technical activity
      • Global and open source software development led to increased interest in and relevance of social aspects
    • Need for representing socio-technical relations
    • Bipartite graphs of software artefacts and people
      • Ad-hoc arc semantics, depending on relation
      • Ad-hoc flat layout, often hard to read
      • Relevant relations lost among many nodes and arcs
    • Sought improvements:
      • More compact, intuitive, and explicit representation
      • Distinguish ‘hierarchical’ importance of artefacts, people and their relations .
  • 2. General Approach
    • Obtain a bipartite socio-technical network
    • Compute socio-technical concept lattice
      • Apply formal concept analysis (FCA) theory
      • Use free tool ConExp (Concept Explorer)
      • Input: bi-partite network
      • Output: concept lattice (1 node per concept)
      • A concept clusters all artefacts associated to the same people
      • Hierarchy is partial ordering of clusters (arc semantics: subset)
    • Visualise hierarchy interactively using ConExp
    • Study different and evolving socio-technical relations
      • Repeat 1.-3. for various relations and system releases
  • 3. Example
    • Eclipse IDE
      • Has non-trivial social and technical structure
      • IBM lead allows social continuity to be traced
      • Bugzilla repository available
    • Bi-partite socio-technical networks
      • Nodes denote people p and Eclipse components c
      • Arc p -> c if p associated to k or more bug reports for c , for a given k
      • 3 associations with bug reports: reporter, assignee or discussant
    • Socio-technical concept lattice
      • Usually, person at level n from bottom is associated to n components
      • Hence ‘specialists’ at bottom, ‘generalists’ at top of lattice
      • Each node includes all its ancestors’ people and all its descendants’ components
  • 4. Eclipse 1.0, assignees, k = 10 only 4 ‘generalists’ (2 components each) the Swiss team USA coordinating 2 Canadian teams? most developers associated: is this largest or most complex component? only 1 developer associated: what if they leave project? the French team
  • 5. Eclipse 3.0, assignees, k = 100
    • Used higher k because bug reports accumulate over time
    • Geographical and workload distribution like release 1.0
    Common developers: highly dependent components? only 2 ‘generalists’ (3 components each)
  • 6. Eclipse 3.0, discussants, k = 100
    • Fewer people and components than in assignees lattice
      • Developers don’t discuss all reports they are assigned to
    Developers discuss more components than they are assigned to: due to dependencies?
  • 7. Conclusions
    • Novel application of Formal Concept Analysis
      • Clustering and ordering of socio-technical relations
      • General tool-supported approach
    • Some advantages over bi-partite graphs
      • More scalable: not one node per person and artefact
      • More explicit: related people & artefacts in same node
      • More intuitive: uniform vertical layout & arc semantics
    • Helps spot expertise and potential problems
      • Generalist and specialist people
      • Artefacts with too many or too few people associated
      • Undesired or absent communication/coordination
    • For more details, see our paper in Proc. ICSE’09 (companion volume), pp. 327-330.