Every method for developing software is a prescriptive model. Applying a deconstructionist analysis to methods reveals that there are two texts, or sets of assumptions and ideals: a set that is privileged by the method and a second set that is left out, or marginalized by the method. We apply this analytical lens to software reuse, a technique in software development that seeks to expedite one's own project by using programming artifacts created by others. By analyzing the methods prescribed by Component-Based Software Engineering (CBSE), we arrive at two texts: Methodical CBSE and Amethodical Remixing. Empirical data from four studies on code search on the web draws attention to four key points of tension: status of component boundaries; provenance of source code; planning and process; and evaluation criteria for candidate code. We conclude the paper with a discussion of the implications of this work for the limits of methods, structure of organizations that reuse software, and the design of search engines for source code.

When analyzing data elicited using the “war stories” technique, previously introduced by Lutters and Seaman (Inf Softw Technol 49(6):576–587, 2007 ), we encountered unexpected challenges in applying standard qualitative analysis techniques. After reviewing the literature on stories and storytelling, we realized that a richer analysis would be possible if we accorded more respect to the data’s structure and nature as stories, rather than treating our participants’ utterances simply as textual data. We report on five lessons learned regarding how we can better analyze war stories as stories: 1) war stories tend to be about exceptional situations; 2) war stories tend to be diverse and resistant to being combined into a single grand narrative; 3) the humanities can be a valuable resource for analyzing war stories; 4) war stories are not just text, they are also performances; and 5) war stories are not just data, they are also instructive and evocative.

Software developers search the Web for various kinds of source code for diverse reasons. In a previous study, we found that searches varied along two dimensions: the size of the search target (e.g., block, subsystem, or system) and the motivation for the search (e.g., reference example or as-is reuse). Would each of these kinds of searches require different search technologies? To answer this question, we conducted an experiment with 36 participants to evaluate three diverse approaches (general purpose information retrieval, source code search, and component reuse), as represented by five Web sites (Google, Koders, Krugle, Google Code Search, and SourceForge). The independent variables were search engine, size of search target, and motivation for search. The dependent variable was the participants judgement of the relevance of the first ten hits. We found that it was easier to find reference examples than components for as-is reuse and that participants obtained the best results using a general-purpose information retrieval site. However, we also found an interaction effect: code-specific search engines worked better in searches for subsystems, but Google worked better on searches for blocks. These results can be used to guide the creation of new tools for retrieving source code from the Web.

In this paper, we present a view of design methods as discourse on practice. We consider how the deployment of a particular set of design methods enables and constrains not only practical action but also discursive action within the design practice. A case study of agile software development methods illustrates the ways that methods establish conditions for who can speak in the design process and how. We indentify three main kinds of discourse work performed in the invoking of design methods. These are the establishing of ontologies, the authorizing of voices, and the legitimizing of practices. We then discuss implications of this view on methods for CSCW research on the relationship between methods and practice as well as implications for participation in the design process.

Looking for source code on the Web is a common practice among software developers. Previous research has shown that developers use social cues over technical cues to evaluate source code candidates. However, current source code search engines do not take full advantage of social information. We present a prototype, an extension of Sourcerer, that shows reputation information for each developer involved in the project and the developer's activity level. From this implementation, we have learned that the effectiveness of this approach depends on the amount of reputation information available on the Web, which is currently scarce. We also learned that a ranking algorithm that relies on both relevance and reputation would be beneficial. More research needs to be done to explore ranking algorithms that combine both social and technical information and also reputation information for source code and people.

Research on feature location that applies information retrieval techniques have experimented the kinds of inputs to the corpus and the algorithms that could be used. At first, only source code was used. Later extraction techniques were improved, and data from other software tools and analyses were used to expand or augment the repository. But, does having more diverse data in the repository always produce better results? In this paper, we report on an empirical study to examine the effect of increasing data diversity to improve feature location through search. In particular, we looked at the effect of including: i) change sets from revision control system, ii) tickets from issue trackers, and iii) elements from a Static Dependency Graph (SDG). We searched for three features of Jajuk, an open source Java jukebox, and two features of jEdit, an open source Java text editor. We used four different corpuses built with a combination of the above data. We used Eclipse's code search and an index built with source code as baseline conditions. We found that it is not always better to have more diverse data. Adding SDG data to change sets increased recall, but drove down precision. Adding data from issue trackers had little effect and in one case lowered recall. We also found that large-scale refactoring of the code decreases the effectiveness using change sets for feature location.

In this paper, we present a new construct, called Transitive Changeset, that can be used for feature location. Transitive Changesets are created by extending changesets from revision control systems with additional information. A changeset temporally associate changes and conceptual descriptions provided in a commit transaction. By following transitive relationships from these changesets, we can create a Transitive Changeset that relates concepts in the problem domain to a list of program elements that enclose changes made in the transaction and other relevant program elements. We have implemented a prototype Eclipse plug-in, Kayley, to create

On any project, it is not possible to have complete and accurate concern maps for all possible tasks. We present an approach to create concern maps from available secondary software work artifacts produced by common software tools, such as revisions control. We mine and index concern fragments from repositories of those tools. Developers can search the index for an initial set of relevant fragments. To create a final concern map, the members from the initial set of fragments are validated, merged and expanded using a call graph. Members of the final concern map members are also ranked to guide developers to more relevant sections of the code.

This paper presents an idea of using a structure traversal graph (STG) to characterize whether program comprehension is progressing smoothly. Inspired by electrocardiograms that are used to measure heart rhythms, STGs are an attempt to depict the rhythm of program navigation. STGs are created by abstracting navigation between files to the level of a conceptual architecture graph. We analyzed the navigation patterns of fifteen developers performing a modification task in the laboratory and found that the STG was a good organizing principle for program comprehension behavior.

Requirements engineers with many years of experience have a distinct perspective on the field. To sample this knowledge, we interviewed 34 requirements researchers and practitioners, each with up to 42 years of experience. We used open-ended, structured interviews in which we asked them to reflect on their experiences and professional development as requirements engineers over their careers. Several themes emerged: requirements engineers act as bridges between different worlds, good communication is key, good process can help but isn't everything, shorter requirements documents can be better, and good requirements are driven by customer value not technical elegance. All of these pertain to amethodical requirements engineering. Amethodical concepts are not rejections of method, but rather those concepts that are marginalized and left out of prescriptive methods for carrying out a procedure. We discuss these results and their implications.

The topic of this full-day tutorial was the correct use and interpretation of case studies as an empirical research method. Using an equal blend of lecture and discussion, it gave attendees a foundation for conducting, reviewing, and reading case studies. There were lessons for software engineers as researchers who conduct and report case studies, reviewers who evaluate papers, and practitioners who are attempting to apply results from papers. The main resource for the course was the book Case Study Research: Design and Methods by Robert K. Yin. This text was supplemented with positive and negative examples from the literature.

The success of a task relies on the expertise of its owner to a great degree. But what is the anticipated expertise? In what areas? Our research intends to investigate the skill sets anticipated of requirements engineers. This paper presents a model of the varying levels of RE expertise within the context of the main RE domains. Identifying the layers of RE expertise can provide more realistic expectations of the anticipated expertise. This understanding can in turn be utilised to increase tool usability (by embedding appropriate support for users' expertise), course development (by identifying the anticipated competencies a student demonstrated at the end of a course), task allocation and employment in industry (mapping capability required to a person 's expertise)

The topic of this paper was the correct use and interpretation of case studies as an empirical research method. Using an equal blend of lecture and discussion, it gave a foundation for conducting, reviewing, and reading case studies. There were lessons for software engineers as researchers who conduct and report case studies, reviewers who evaluate papers, and practitioners who are attempting to apply results from papers. The main resource for the course was the book Case Study Research: Design and Methods by Robert K. Yin. This text was supplemented with positive and negative examples from the literature.

Benchmarks have been used in computer science to compare the performance of computer systems, information retrieval algorithms, databases, and many other technologies. The creation and widespread use of a benchmark within a research area is frequently accompanied by rapid technical progress and community building. These observations have led us to formulate a theory of benchmarking within scientific disciplines. Based on this theory, we challenge software engineering research to become more scientific and cohesive by working as a community to define benchmarks. In support of this challenge, we present a case study of the reverse engineering community, where we have successfully used benchmarks to advance the state of research.

No abstract available.

The goal of this workshop is to provide an interactive forum for software engineers and empirical researchers to investigate the feasibility of applying proven methods from other research disciplines to software engineering research. Participants submitted position papers describing problems that might benefit from a multidisciplinary approach. Expert guest speakers from software engineering and other disciplines will address the issues highlighted in the papers with the goal of encouraging more multidisciplinary research.

Software architecture visualization tools tend to support browsing, that is, exploration by following concepts. If architectural diagrams are to be used during daily software maintenance tasks, these tools also need to support specific fact-finding through searching. Searching is essential to program comprehension and hypothesis testing. Furthermore, searching allows users to reverse the abstractions in architectural diagrams and access facts in the underlying program code. We consider the problem of searching and browsing software architectures using perspectives from information retrieval and program comprehension. After analyzing our own user studies and results from the literature, we propose a solution: the Searchable Bookshelf, an architecture visualization tool that supports both navigation styles. We also present a prototype of our tool which is an extension of an existing architecture visualization tool.

No abstract available.

Joining a software development team is like moving to a new country to start employment; the immigrant has a lot to learn about the job, the local customs, and sometimes a new language. In an exploratory case study, we interviewed four software immigrants, in order to characterize their naturalization process. Seven patterns in four major categories were found. In this paper, these patterns are substantiated, and their implications discussed. The lessons learned from this study can be applied equally to improving the naturalization process, and to the formulation of further research questions.