Davor Cubranic

Hipikat: recommending pertinent software development artifacts

A newcomer to a software project must typically come up-to-speed on a large, varied amount of information about the project before becoming productive. Assimilating this information in the open-source context is difficult because a newcomer cannot rely on the mentoring approach that is commonly used in traditional software developments. To help a newcomer to an open-source project become productive faster, we propose Hipikat, a tool that forms an implicit group memory from the information stored in a projects archives, and that recommends artifacts from the archives that are relevant to a task that a newcomer is trying to perform. To investigate this approach, we have instantiated the Hipikat tool for the Eclipse open-source project. In this paper we describe the Hipikat tool, we report on a qualitative study conducted with a Hipikat mock-up on a medium-sized in-house project, and we report on a case study in which Hipikat recommendations were evaluated for a task on Eclipse.

Hipikat: a project memory for software development

Sociological and technical difficulties, such as a lack of informal encounters, can make it difficult for new members of noncollocated software development teams to learn from their more experienced colleagues. To address this situation, we have developed a tool, named Hipikat that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This project memory is built automatically with little or no change to existing work practices. After describing the Hipikat tool, we present two studies investigating Hipikats usefulness in software modification tasks. One study evaluated the usefulness of Hipikats recommendations on a sample of 20 modification tasks performed on the Eclipse Java IDE during the development of release 2.1 of the Eclipse software. We describe the study, present quantitative measures of Hipikats performance, and describe in detail three cases that illustrate a range of issues that we have identified in the results. In the other study, we evaluated whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. We describe the study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

On the use of visualization to support awareness of human activities in software development: a survey and a framework

This paper proposes a framework for describing, comparing and understanding visualization tools that provide awareness of human activities in software development. The framework has several purposes -- it can act as a formative evaluation mechanism for tool designers; as an assessment tool for potential tool users; and as a comparison tool so that tool researchers can compare and understand the differences between various tools and identify potential new research areas. We use this framework to structure a survey of visualization tools for activity awareness in software development. Based on this survey we suggest directions for future research.

Anchored conversations: chatting in the context of a document

This paper describes an application-independent tool called Anchored Conversations that brings together text-based conversations and documents. The design of Anchored Conversations is based on our observations of the use of documents and text chats in collaborative settings. We observed that chat spaces support work conversations, but they do not allow the close integration of conversations with work documents that can be seen when people are working together face-to-face. Anchored Conversations directly addresses this problem by allowing text chats to be anchored into documents. Anchored Conversations also facilitates document sharing; accepting an invitation to an anchored conversation results in the document being automatically uploaded. In addition, Anchored Conversations provides support for review, catch-up and asynchronous communications through a database. In this paper we describe motivating fieldwork, the design of Anchored Conversations, a scenario of use, and some preliminary results from a user study.

The emergent structure of development tasks

Integrated development environments have been designed and engineered to display structural information about the source code of large systems. When a development task lines up with the structure of the system, the tools in these environments do a great job of supporting developers in their work. Unfortunately, many development tasks do not have this characteristic. Instead, they involve changes that are scattered across the source code and various other kinds of artifacts, including bug reports and documentation. Todays development environments provide little support for working with scattered pieces of a system, and as a result, are not adequately supporting the ways in which developers work on the system. Fortunately, many development tasks do have a structure. This structure emerges from a developers actions when changing the system. In this paper, we describe how the structure of many tasks crosscuts system artifacts, and how by capturing that structure, we can make it as easy for developers to work on changes scattered across the systems structure as it is to work on changes that line up with the systems structure.

Learning from project history: a case study for software development

The lack of lightweight communication channels and other technical and sociological difficulties make it hard for new members of a non-collocated software development team to learn effectively from their more experienced colleagues while they are coming up-to-speed on a project. To address this situation, we have developed a tool, named Hipikat, that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This project memory is built automatically with little or no change to existing work practices. We report an exploratory case study evaluating whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. To assess the appropriateness of the recommendations, we investigated when and how developers queried the project memory, how the evaluated the recommended artifacts, and the process by which they utilized the artifacts. We found that newcomers did use the recommendations and their final solutions exploited the recommended artifacts, although most of the Hipikat queries came in the early stages of a change task. We describe the case study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

Coordinating open-source software development

Open-source software (OSS) projects are arguably the quintessential example of distributed software development, with their openness to a large pool of world-wide contributors and their loose organizational structure. To cope with the demands which this openness and fluidity place on the development process, open-source projects have evolved their own methods and organization. This paper looks at the ways some of the major and most successful OSS projects deal with the issue of coordination among their many contributors. Although each of the projects examined in this paper developed some unique practices, there are also significant commonalities. The paper then goes on to indicate some of the problems caused by the existing practices and puts forward some possible approaches to OSS coordination that could make OSS development more efficient.

V-Lynx: bringing the World Wide Web to sight impaired users

The World Wide Web (WWW) project merges the techniques of networked information and hypertext to make an easy but powerful global information system. A client program called a browser is used to access documents in the WWW system and present them all as parts of a seamless hypertext information space. However, todays browsers are primarily graphically or text oriented, which makes the whole system inaccessible to sight- impaired users. In this project we wanted to extend an existing browser with voice output. This extension would allow the sight- impaired to use, at least, textual data, which, at present, forms the bulk ofinformation available over the Web. Our browser should be able to read the document a line or paragraph at a time, read only the first sentence in a paragraph for quick scanning of the document, convey the document structure (headings, emphasized text,lists, hyperlinks), and allow for easy navigation while inside and between documents.

Collaboration support for novice team programming

Learning computer programming in a modern university course is rarely an individual activity; however, IDEs used in introductory programming classes do not support collaboration at a level appropriate for novices. The goal of our research is to make it easier for first-year students to experience working in a team in their programming assignments. Based on our previous work developing and evaluating IDEs for novice programmers, we have identified two main areas of required functionality: 1) features for code sharing and coordination; and 2) features to support communication. We have extended an existing teaching-oriented integrated development environment (called Gild) with features to support code sharing and coordination. We report on a preliminary study in which pairs of students used a prototype of our collaborative IDE to work on a programming assignment. The goals of this study were to evaluate the effectiveness and usability of the new features and to determine requirements for future communication support.

A framework for describing and understanding mining tools in software development

We propose a framework for describing, comparing and understanding tools for the mining of software repositories. The fundamental premise of this framework is that mining should be done by considering the specific needs of the users and the tasks to be supported by the mined information. First, different types of users have distinct needs, and these needs should be taken into account by tool designers. Second, the data sources available, and mined, will determine if those needs can be satisfied. Our framework is based upon three main principles: the type of user, the objective of the user, and the mined information. This framework has the following purposes: to help tool designers in the understanding and comparison of different tools, to assist users in the assessment of a potential tool; and to identify new research areas. We use this framework to describe several mining tools and to suggest future research directions.