Results 1 - 10
of
98
Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools
- In Proceedings of the Conference on Computer Supported Cooperative Work (CSCW’06
, 2006
"... Task dependencies drive the need to coordinate work activities. We describe a technique for using automatically generated archival data to compute coordination requirements, i.e., who must coordinate with whom to get the work done. Analysis of data from a large software development project revealed ..."
Abstract
-
Cited by 116 (16 self)
- Add to MetaCart
(Show Context)
Task dependencies drive the need to coordinate work activities. We describe a technique for using automatically generated archival data to compute coordination requirements, i.e., who must coordinate with whom to get the work done. Analysis of data from a large software development project revealed that coordination requirements were highly volatile, and frequently extended beyond team boundaries. Congruence between coordination requirements and coordination activities shortened development time. Developers, particularly the most productive ones, changed their use of electronic communication media over time, achieving higher congruence. We discuss practical implications of our technique for the design of collaborative and awareness tools. Categories and Subject Descriptors H.5.3 [Information Interfaces and Presentation]: Groups and Organization Interfaces – collaborative computing, computersupported
Feature location using probabilistic ranking of methods based on execution scenarios and information retrieval
- IEEE Trans. Software Eng
, 2007
"... Abstract—This paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The solution to the problem is formulated as a combination of the opinions of different experts. The experts in this work are two existing techniques for feature lo ..."
Abstract
-
Cited by 115 (48 self)
- Add to MetaCart
(Show Context)
Abstract—This paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The solution to the problem is formulated as a combination of the opinions of different experts. The experts in this work are two existing techniques for feature location: a scenario-based probabilistic ranking of events and an information retrieval-based technique that uses latent semantic indexing. The combination of these two experts is empirically evaluated through several case studies, which use the source code of the Mozilla Web browser and the Eclipse integrated development environment. The results show that the combination of experts significantly improves the effectiveness of feature location when compared to each of the experts used independently. Index Terms—program understanding, feature identification, concept location, dynamic and static analyses, information retrieval, Latent Semantic Indexing, scenario-based probabilistic ranking, open source software.
An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks
- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2006
"... Much of software developers’ time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debug ..."
Abstract
-
Cited by 107 (14 self)
- Add to MetaCart
(Show Context)
Much of software developers’ time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse’s navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse’s package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner.
Automatic generation of suggestions for program investigation
- In Proc. Joint Europ. Softw. Eng. Conf. and ACM SIGSOFT Int’l Symp. Foundations Softw. Eng
, 2005
"... Before performing a modification task, a developer usually has to investigate the source code of a system to understand how to carry out the task. Discovering the code relevant to a change task is costly because it is an inherently human activity whose success de-pends on a large number of unpredict ..."
Abstract
-
Cited by 86 (2 self)
- Add to MetaCart
(Show Context)
Before performing a modification task, a developer usually has to investigate the source code of a system to understand how to carry out the task. Discovering the code relevant to a change task is costly because it is an inherently human activity whose success de-pends on a large number of unpredictable factors, such as intuition and luck. Although studies have shown that effective developers tend to explore a program by following structural dependencies, no methodology is available to guide their navigation through the typically hundreds of dependency paths found in a non-trivial pro-gram. In this paper, we propose a technique to automatically pro-pose and rank program elements that are potentially interesting to a developer investigating source code. Our technique is based on an analysis of the topology of structural dependencies in a program. It takes as input a set of program elements of interest to a developer and produces a fuzzy set describing other elements of potential in-terest. Empirical evaluation of our technique indicates that it can help developers quickly select program elements worthy of inves-tigation while avoiding less interesting ones.
Feature Location in Source Code: A Taxonomy and Survey
- Journal of Software Maintenance and Evolution: Research and Practice
, 2011
"... Feature location is the activity of identifying an initial location in the source code that implements functionality in a software system. Many feature location techniques have been introduced that automate some or all of this process, and a comprehensive overview of this large body of work would be ..."
Abstract
-
Cited by 80 (14 self)
- Add to MetaCart
Feature location is the activity of identifying an initial location in the source code that implements functionality in a software system. Many feature location techniques have been introduced that automate some or all of this process, and a comprehensive overview of this large body of work would be beneficial to researchers and practitioners. This paper presents a systematic literature survey of feature location techniques. Eighty-nine articles from 25 venues have been reviewed and classified within the taxonomy in order to organize and structure existing work in the field of feature location. The paper also discusses open issues and defines future directions in the field of feature location.
Representing Concerns in Source Code
, 2003
"... Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is ..."
Abstract
-
Cited by 76 (7 self)
- Add to MetaCart
Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the
Asking and answering questions during a programming change task.
- IEEE Transactions on Software Engineering,
, 2008
"... ..."
(Show Context)
Exploring the neighborhood with Dora to expedite software maintenance
- In 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE/ACM
, 2007
"... Completing software maintenance and evolution tasks for today’s large, complex software systems can be difficult, often requiring considerable time to understand the system well enough to make correct changes. Despite evidence that successful programmers use program structure as well as identifier n ..."
Abstract
-
Cited by 56 (7 self)
- Add to MetaCart
(Show Context)
Completing software maintenance and evolution tasks for today’s large, complex software systems can be difficult, often requiring considerable time to understand the system well enough to make correct changes. Despite evidence that successful programmers use program structure as well as identifier names to explore software, most existing program exploration techniques use either structural or lexical identifier information. By using only one type of information, automated tools ignore valuable clues about a developer’s intentions—clues critical to the human program comprehension process. In this paper, we present and evaluate a technique that exploits both program structure and lexical information to help programmers more effectively explore programs. Our approach uses structural information to focus automated program exploration and lexical information to prune irrelevant structure edges from consideration. For the important program exploration step of expanding from a seed, our experimental results demonstrate that an integrated lexical- and structural-based approach is significantly more effective than a state-of-the-art structural program exploration technique.
Navtracks: Supporting navigation in software maintenance
- In ICSM 2005: Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM’05
, 2005
"... In this paper, we present NavTracks, a tool that supports browsing through software. NavTracks keeps track of the navigation history of software developers, forming associations between related files. These associations are then used as the basis for recommending potentially related files as a devel ..."
Abstract
-
Cited by 45 (1 self)
- Add to MetaCart
(Show Context)
In this paper, we present NavTracks, a tool that supports browsing through software. NavTracks keeps track of the navigation history of software developers, forming associations between related files. These associations are then used as the basis for recommending potentially related files as a developer navigates the software system. We present the reasoning behind NavTracks, its basic algorithm, a case study, and propose some future work. 1.
Program comprehension as fact finding
- In Proceedings of Foundations of Software Engineering
, 2007
"... Little is known about how developers think about design during code modification tasks or how experienced developers ’ design knowledge helps them work more effectively. We performed a lab study in which thirteen developers worked for 3 hours understanding the design of a 54 KLOC open source applica ..."
Abstract
-
Cited by 41 (18 self)
- Add to MetaCart
(Show Context)
Little is known about how developers think about design during code modification tasks or how experienced developers ’ design knowledge helps them work more effectively. We performed a lab study in which thirteen developers worked for 3 hours understanding the design of a 54 KLOC open source application. Participants had from 0 to 10.5 years of industry experience and were grouped into three “experts ” and ten “novices. ” We observed that participants spent their time seeking, learning, critiquing, explaining, proposing, and implementing facts about the code such as “getFold-Level has effects”. These facts served numerous roles, such as suggesting changes, constraining changes, and predicting the amount of additional investigation necessary to make a change. Differences between experts and novices included that the experts explained the root cause of the design problem and made changes to address it, while novice changes addressed only the symptoms. Experts did not read more methods but also did not visit some methods novices wasted time understanding. Experts talked about code in terms of abstractions such as “caching ” while novices more often described code statement by statement. Experts were able to implement a change faster than novices. Experts perceived problems novices did not and were able to explain facts novices could not. These findings have interesting implications for future tools.
