HCI Bibliography Home | HCI Conferences | CHASE Archive | Detailed Records | RefWorks | EndNote | Hide Abstracts
CHASE Tables of Contents: 0809101112131415

Proceedings of the 2011 International Workshop on Cooperative and Human Aspects of Software Engineering

Fullname:Proceedings of the 4th International Workshop on Cooperative and Human Aspects of Software Engineering
Editors:Marcelo Cataldo; Cleidson de Souza; Yvonne Dittrich; Rashina Hoda; Helen Sharp
Location:Honolulu, Hawaii
Dates:2011-May-21 to 2011-May-28
Publisher:ACM
Standard No:ISBN: 1-4503-0680-2, 978-1-4503-0680-5; ACM DL: Table of Contents hcibib: CHASE11
Papers:19
Pages:92
Links:Conference Home Page
  1. Full papers
  2. Position papers
  3. Short papers

Full papers

A case study of post-deployment user feedback triage BIBAFull-Text 1-8
  Andrew J. Ko; Michael J. Lee; Valentina Ferrari; Steven Ip; Charlie Tran
Many software requirements are identified only after a product is deployed, once users have had a chance to try the software and provide feedback. Unfortunately, addressing such feedback is not always straightforward, even when a team is fully invested in user-centered design. To investigate what constrains a teams evolution decisions, we performed a 6-month field study of a team employing iterative user-centered design methods to the design, deployment and evolution of a web application for a university community. Across interviews with the team, analyses of their bug reports, and further interviews with both users and non-adopters of the application, we found most of the constraints on addressing user feedback emerged from conflicts between users heterogeneous use of information and inflexible assumptions in the team's software architecture derived from earlier user research. These findings highlight the need for new approaches to expressing and validating assumptions from user research as software evolves.
Branching and merging: an investigation into current version control practices BIBAFull-Text 9-15
  Shaun Phillips; Jonathan Sillito; Rob Walker
The use of version control has become ubiquitous in software development projects. Version control systems facilitate parallel development and maintenance through branching, the creation of isolated codelines. Merging is a consequence of branching and is the process of integrating codelines. However, there are unanswered questions about the use of version control to support parallel development; in particular, how are branching and merging used in practice? What defines a successful branching and merging strategy? As a first step towards answering these questions, we recruited a diverse sample of 140 version control users to participate in an online survey. In this paper, we present the survey results and 4 key observations about branching and merging practices in software development projects.
A qualitative study of the determinants of self-managing team effectiveness in a scrum team BIBAFull-Text 16-23
  Cleviton V. F. Monteiro; Fabio Q. B. da Silva; Isabella R. M. dos Santos; Felipe Farias; Elisa S. F. Cardozo; André R. G. do A. Leitão; Dacio N. M. Neto; Miguel J. A. Pernambuco Filho
There are many evidences in the literature that the use self-managing teams has positive impacts on several dimensions of team effectiveness. Agile methods, supported by the Agile Manifesto, defend the use of self-managing teams in software development in substitution of hierarchically managed, traditional teams. The goal of this research was to study how a self-managing software team works in practice and how the behaviors of the software organization support or hinder the effectiveness of such teams. We performed a single case holistic case study, looking in depth into the actual behavior of a mature Scrum team in industry.
   Using interviews and participant observation, we collected qualitative data from five team members in several interactions. We extract the behavior of the team and of the software company in terms of the determinants of self-managing team effectiveness defined in a theoretical model from the literature. We found evidence that 17 out of 24 determinants of this model exist in the studied context. We concluded that certain determinants can support or facilitate the adoption of methodologies like Scrum, while the use of Scrum may affect other determinants.
Mining and visualizing developer networks from version control systems BIBAFull-Text 24-31
  Andrejs Jermakovics; Alberto Sillitti; Giancarlo Succi
Social network analysis has many applications in software engineering and is often performed through the use of visualizations. Discovery of these networks, however, presents a challenge since the relationships are initially not known. We present an approach for mining and visualizing networks of software developers from version control systems. It computes similarities among developers based on common file changes, constructs the network of collaborating developers and applies filtering techniques to improve the modularity of the network. We validate the approach on two projects from industry and demonstrate its use in a case study of an open-source project. Results indicate that the approach performs well in revealing the structure of development teams and improving the modularity in visualizations of developer networks.
How do we trace requirements: an initial study of analyst behavior in trace validation tasks BIBAFull-Text 32-39
  Wei-Keat Kong; Jane Huffman Hayes; Alex Dekhtyar; Jeff Holden
Traceability recovery is a tedious, error-prone, person-power intensive task, even if aided by automated traceability tools. Human analysts must vet candidate traceability links retrieved by such tools and must often go looking for links that such tools fail to locate as they build a traceability matrix. This paper examines a research version of the traceability tool REquirements TRacing On target (RETRO) that logs analyst actions. We examine the user logs in order to understand how analysts work on traceability recovery tasks. Such information is a pre-requisite to understanding how to better design traceability tools to best utilize analyst time while developing a high quality final traceability matrix.
Impact of collaborative traces on trustworthiness BIBAFull-Text 40-47
  Erik H. Trainer; Ban Al-Ani; David F. Redmiles
We investigated how trust among software developers would be affected by providing them with visualizations of collaborative traces. We define collaborative traces to be representations of the past and current activity of a group of developers manipulating software development artifacts. In this paper, we report two main findings. First, we report the results of our controlled experiment in which collaborative traces were visualized. Second, we present an overview of tools which aim to represent collaborative software engineering traces. Our experiment provides evidence that collaborative traces can support the development of several factors of trust identified in our field study. However, we also identified some shortcomings of our current visualizations, gaining insights into future improvements. From our review of tools that represent collaborative traces, we observed that such representations can drive the design of tools that aim to support trust. We also present a table of tools; the table can be used to guide discussion and the design of tools that promote trust in software development.

Position papers

Some non-usage data for a distributed editor: the saros outreach BIBAFull-Text 48
  Lutz Prechelt
After contacting more than 40 companies and 11 OSS projects regarding using our distributed editor Saros, we find that almost all of those many who have a use case for it, are reluctant to even try it out. It appears that distance matters even by anticipatory obedience.
Strawberries are nuts BIBAFull-Text 49
  Tim Frey; Marius Gelhausen
Separation of concerns is a central element for program comprehension. This note briefly explains why human categorization can be interesting for program comprehension.
   Separation of concerns is a central element for program comprehension. This note briefly explains why human categorization can be interesting for program comprehension.
Of code and context: collaboration between developers and translators BIBAFull-Text 50-52
  Malte Ressin; José Abdelnour-Nocera; Andy Smith
Software for international markets often requires cultural adaption in order to be successful in different markets. To achieve this, software developers work together with translators to internationalize and localize their product as necessary. In this paper, we reflect on our experiences of collaboration between these two specialist types from different disciplines. We contrast the differences in object of work, education, values and perception of product quality and illustrate what other factors might have an influence in collaboration. Our experiences suggest that the collaboration between developers and localizers might be improved by integrating translators into development teams, and by emphasizing the importance of understanding each other's work better.

Short papers

A theory of branches as goals and virtual teams BIBAFull-Text 53-56
  Christian Bird; Thomas Zimmermann; Alex Teterev
A common method of managing the complexity of both technical and organizational relationships in a large software project is to use branches within the source code management system to partition the work into teams and tasks. We claim that the files modified on a branch are changed together in a cohesive way to accomplish some task such as adding a feature, fixing a related set of bugs, or implementing a subsystem, which we collectively refer to as the goal of the branch. Further, the developers that work on a branch represent a virtual team. In this paper, we develop a theory of the relationship between goals and virtual teams on different branches. Due to expertise, ownership, and awareness concerns, we expect that if two branches have similar goals, they will also have similar virtual teams or be at risk for communication and coordination breakdowns with the accompanying negative effects. In contrast, we do not expect the converse to always be true. In the first step towards an actionable result, we have evaluated this theory empirically on two releases of the Windows operating system and found support in both.
Workplace warriors: identifying team practices of appropriation in software ecosystems BIBAFull-Text 57-60
  Sebastian Draxler; Adrian Jung; Alexander Boden; Gunnar Stevens
Since the 1990s, the forms of production, distribution, configuration and appropriation of software have changed fundamentally. Nowadays, software is often embedded in software ecosystems, i.e. in complex interrelations between different stakeholders who are connected by a shared technological platform. In our paper, we investigate how small software teams deal with the challenges of appropriating and configuring software in the Eclipse ecosystem for their daily work. We empirically identify three different approaches for dealing with appropriation in software ecosystems which are represented by the "ideal types" lone warrior, centralized organization, and collegial collaboration. Based on a discussion of these strategies and the underlying appropriation practices we found in the field, we suggest theoretical and practical implications for supporting appropriation in software ecosystems.
STCML: an extensible XML-based language for socio-technical modeling BIBAFull-Text 61-64
  John C. Georgas; Anita Sarma
Understanding the complex dependencies between the technical artifacts of software engineering and the social processes involved in their development has the potential to improve the processes we use to engineer software as well as the eventual quality of the systems we produce. A foundational capability in grounding this study of socio-technical concerns is the ability to explicitly model technical and social artifacts as well as the dependencies between them. This paper presents the STCML language, intended to support the modeling of core socio-technical aspects in software development in a highly extensible fashion. We present the basic structure of the language, discuss important language design principles, and offer an example of its application.
Collabode: collaborative coding in the browser BIBAFull-Text 65-68
  Max Goldman; Greg Little; Robert C. Miller
Collaborating programmers should use a development environment designed specifically for collaboration, not the same one designed for solo programmers with a few collaborative processes and tools tacked on. This paper describes Collabode, a web-based Java integrated development environment built to support close, synchronous collaboration between programmers. We discuss three collaboration models in which participants take on distinct roles: micro-outsourcing to combine small contributions from many assistants; test-driven pair programming for effective pairwise development; and a mobile instructor connected to the work of many students. In particular, we report very promising preliminary results using Collabode to support micro-outsourcing.
Teambugs: a collaborative bug tracking tool BIBAFull-Text 69-71
  Gerald Bortis; André van der Hoek
Bug trackers are considered to be one of the primary coordination tools in software development. Interactions with the bug tracker occur throughout the development process, in different settings, from the meeting room to the developer's desk. In this paper, we look at previous field studies of bug trackers and identify the key challenges in supporting coordination. We then describe through several scenarios TeamBugs, a new bug tracker tool. We conclude by raising several research questions for future work.
Studying team evolution during software testing BIBAFull-Text 72-75
  Vibhu Saujanya Sharma; Vikrant Kaulgud
Software development teams are one of the most dynamic entities of any software development project. While the individuals are assigned planned roles at the start of any project, during the course of the project, the team constitution, structure, relationships and roles change. Such changes are often spontaneous and constitute the evolution of the team along different phases of the software development lifecycle. As software development is a team effort, these dynamics may have a significant effect on the development lifecycle itself. This work is aimed at studying the evolution of project teams and gathering insights that can be correlated with project health and outcomes. In this study we apply social network analysis techniques to investigate team evolution in a project in its testing phase. While the questions and insights that we investigate in this paper are valid and useful for all phases of the software development lifecycle, we have focused on software testing phase as it one of the most critical phases in the lifecycle. Our work aims to provide insights in the changes in team interactions and individual roles as the testing process continues and can help find if the same is aligned to the planned and desired project behavior.
Which bug should i fix: helping new developers onboard a new project BIBAFull-Text 76-79
  Jianguo Wang; Anita Sarma
A typical entry point for new developers in an open source project is to contribute a bug fix. However, finding an appropriate bug and an appropriate fix for that bug requires a good understanding of the project, which is nontrivial. Here, we extend Tesseract -- an interactive project exploration environment -- to allow new developers to search over bug descriptions in a project to quickly identify and explore bugs of interest and their related resources. More specifically, we extended Tesseract with search capabilities that enable synonyms and similar-bugs search over bug descriptions in a bug repository. The goal is to enable users to identify bugs of interest, resources related to that bug, (e.g., related files, contributing developers, communication records), and visually explore the appropriate socio-technical dependencies for the selected bug in an interactive manner. Here we present our search extension to Tesseract.
An exploratory study of awareness interests about software modifications BIBAFull-Text 80-83
  Miryung Kim
As software engineers collaboratively develop software, they need to often analyze past and present program modifications implemented by other developers. While several techniques focus on tool support for investigating past and present software modifications, do these techniques indeed address developers' awareness interests that are important to them? We conducted an initial focus group study and a web survey to understand in which task contexts and how often particular types of awareness-interests arise. Our preliminary study results indicate that developers have daily information needs about code changes that affect or interfere with their code, yet it is extremely challenging for them to identify relevant events out of a large number of change-events.
Supporting collaboration in the development of complex engineering software BIBAFull-Text 84-87
  Victoria E. Shipp; Peter Johnson
Software development in engineering firms is a prominent and vital activity, with the success of the business often being dependent on the tools being used. Developing this software requires collaboration between a number of stakeholders, including end-users and other software teams who are often remotely located. This research has used an ethnographic approach to studying communications between stakeholders involved in the development of this type of software. Findings show that users play a vital role in the development team due to their knowledge of the domain and work processes. Supporting this relationship remotely can be challenging, especially due to the reliance on ad-hoc communication strategies. This can sometimes lead to misunderstandings, design rationale being lost, and poor and efficient designs and processes. Lightweight tools that enable flexible design artefacts to be shared and discussed could assist this process and will be investigated in future work.
Requirements maturation analysis based on the distance between the source and developers BIBAFull-Text 88-91
  Takako Nakatani; Toshihiko Tsumaki
The success of a project is often affected by imperfect requirements. In order to cope with this risk, a requirements analyst needs to communicate with a client. However, communication between the requirements analyst and the client is not enough to prevent requirements imperfection, since requirements come from various sources, e.g. environment, laws, documents, actual usage, etc. The process of requirements elicitation is affected by the requirements stability, the ability of a requirements analyst, and accessibility of the source of requirements. This paper focuses on the distance between the source of requirements and a requirements analyst, and clarifies how the distance influences the requirements maturation. Requirements maturation represents the degree to which the requirements are elicited completely. We define a measure for observing requirements maturation and analyzing the accessibility of the source of the requirements. Then, we define a hypothesis. A case is analyzed in order to verify the hypothesis. As a result, there is a correlation between the requirements maturation efficiency and the accessibility of the source of the requirements.