| |
In MSR '06: Proceedings of the 2006 international workshop on Mining software repositories (2006), pp. 144-150.
|
| |
Software Maintenance, 2003. ICSM 2003. Proceedings. International Conference on (2003), pp. 23-32.
Abstract
Version control and bug tracking systems contain large amounts of historical information that can give deep insight into the evolution of a software project. Unfortunately, these systems provide only insufficient support for a detailed analysis of software evolution aspects. We address this problem and introduce an approach for populating a release history database that combines version data with bug tracking data and adds missing data not covered by version control systems such as merge points. Then simple queries can be applied ...
|
| |
Software Maintenance, 2000. Proceedings. International Conference on (2000), pp. 120-130.
Abstract
Large scale software products must constantly change in order to adapt to a changing environment. Studies of historic data from legacy software systems have identified three specific causes of this change: adding new features; correcting faults; and restructuring code to accommodate future changes. Our hypothesis is that a textual description field of a change is essential to understanding why that change was performed. Also, we expect that difficulty, size, and interval would vary strongly across different types of changes. To test ...
|
| |
In ICSE '06: Proceedings of the 28th international conference on Software engineering (2006), pp. 282-291.
Abstract
Dynamic inference techniques have been demonstrated to provide useful support for various software engineering tasks including bug finding, test suite evaluation and improvement, and specification generation. To date, however, dynamic inference has only been used effectively on small programs under controlled conditions. In this paper, we identify reasons why scaling dynamic inference techniques has proven difficult, and introduce solutions that enable a dynamic inference technique to scale to large programs and work effectively with the imperfect traces typically available in industrial ...
|
| |
In PLDI '05: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, Vol. 40, No. 6. (June 2005), pp. 15-26.
|
| |
In SOSP '01: Proceedings of the eighteenth ACM symposium on Operating systems principles, Vol. 35, No. 5. (December 2001), pp. 57-72.
|
| |
In MSR '06: Proceedings of the 2006 international workshop on Mining software repositories (2006), pp. 3-9.
|
| |
IEEE Transactions on Software Engineering In Software Engineering, IEEE Transactions on, Vol. 31, No. 6. (11 July 2005), pp. 429-445.
Abstract
We apply data mining to version histories in order to guide programmers along related changes: "Programmers who changed these functions also changed...." Given a set of existing changes, the mined association rules 1) suggest and predict likely further changes, 2) show up item coupling that is undetectable by program analysis, and 3) can prevent errors due to incomplete changes. After an initial change, our ROSE prototype can correctly predict further locations to be changed; the best predictive power is obtained for ...
|
| |
Software Engineering, IEEE Transactions on, Vol. 31, No. 6. (2005), pp. 446-465.
Abstract
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 ...
|
| |
Software Engineering, 2001. ICSE 2001. Proceedings of the 23rd International Conference on (2001), pp. 657-664a.
|
| |
In ICSE '06: Proceedings of the 28th international conference on Software engineering (2006), pp. 361-370.
Abstract
Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach ...
|
| |
IEEE Trans. Softw. Eng., Vol. 29, No. 2. (February 2003), pp. 151-166.
|
| |
In SOSP '01: Proceedings of the eighteenth ACM symposium on Operating systems principles (2001), pp. 73-88.
|
| |
Software Maintenance, 2000. Proceedings. International Conference on (2000), pp. 131-142.
Abstract
Most studies of software evolution have been performed on systems developed within a single company using traditional management techniques. With the widespread availability of several large software systems that have been developed using an “open source” development approach, we now have a chance to examine these systems in detail, and see if their evolutionary narratives are significantly different from commercially developed systems. The paper summarizes our preliminary investigations into the evolution of the best known open source system: the Linux operating ...
|
| |
Software Engineering, IEEE Transactions on, Vol. 31, No. 6. (2005), pp. 481-494.
Abstract
Case studies can help to validate claims that open source software development produces higher quality software at lower cost than traditional commercial development. One problem inherent in case studies are external validity - we do not know whether or not results from one case study apply to another development project. We gain or lose confidence in case study results when similar case studies are conducted on other projects. This case study of the FreeBSD project, a long-lived open source project, provides ...
|
| |
IEEE Transactions on Software Engineering, Vol. 27, No. 1. (Jan 2001), pp. 1-12.
Abstract
A central feature of the evolution of large software systems is that change-which is necessary to add new functionality, accommodate new hardware, and repair faults-becomes increasingly difficult over time. We approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines ...
|
| |
In IWPSE '02: Proceedings of the International Workshop on Principles of Software Evolution (2002), pp. 76-85.
|
Search
Search
