Visual Data Mining in Software Archives to Detect How Developers Work Together

Abstract

Analyzing the check-in information of open source software projects which use a version control system such as CVS or SUBVERSION can yield interesting and important insights into the programming behavior of developers. As in every major project tasks are assigned to many developers, the development must be coordinated between these programmers. This paper describes three visualization techniques that help to examine how programmers work together, e.g. if they work as a team or if they develop their part of the software separate from each other. Furthermore, phases of stagnation in the lifetime of a project can be uncovered and thus, possible problems are revealed.To demonstrate the usefulness of these visualization techniques we performed case studies on two open source projects. In these studies interesting patterns of developers' behavior, e.g. the specialization on a certain module can be observed. Moreover, modules that have been changed by many developers can be identified as well as such ones that have been altered by only one programmer.

113 times Tomcat: A dataset

“…Weissgerber et al [19] used Tomcat, among other systems, to describe three visualization techniques which help to examine how programmers work together, providing very interesting insights on what happens during the development process of a system. As already stated, few studies have investigated the test-production features of a system's code and the need to explore systems that have evolved is greater than ever and with this longitudinal dataset we encourage works in this direction.…”

Distribution and Continuity of Developers' Contributions in OSS Projects: A Case Study

“…Weissgerber et al [11] used a transaction visualization technique to show commit sequences in a project and used fileauthor matrix to visualize evolution history of a file in terms of developers. This approach stands on the file's point of view; by contrast, we use a line of code as basic change unit rather than a large-grained file, thus the result would be more accurate.…”

Triaging incoming change requests: Bug or commit history, or code authorship?

“…Ma et al [24] proposed a technique that uses implementation expertise (i.e., developers usage of API methods) to identify developers. Weissgerber et al [41] depicts the relationship between the lifetime of the project and the number of files and the number of files each author updates by analyzing and visualizing the check-in information for open source projects. German [14] provided a visualization to show which developers tend to modify certain files by studying the modification records (MRs) of CVS logs.…”