Supporting and accelerating reproducible empirical research in software evolution and maintenance using TraceLab Component Library

Dit, Bogdan; Moritz, Evan; Linares‐Vásquez, Mario; Poshyvanyk, Denys; Cleland‐Huang, Jane

doi:10.1007/s10664-014-9339-3

Cited by 17 publications

(15 citation statements)

References 54 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…in a system, and those roles can be used for maintenance tasks such as design recovery [38,39], feature location [59,58,131,57], program comprehension, and pattern/anti-pattern detection [63,61,31,98].…”

Section: Unit Test Case Stereotypesmentioning

confidence: 99%

Automatically Documenting Software Artifacts

2016

2016 IEEE International Conference on Software Maintenance and Evolution (ICSME)

View full text Add to dashboard Cite

Software artifacts, such as database schema and unit test cases, constantly change during evolution and maintenance of software systems. Co-evolution of code and DB schemas in Database-Centric Applications (DCAs) often leads to two types of challenging scenarios for developers, where (i) changes to the DB schema need to be incorporated in the source code, and (ii) maintenance of a DCAs code requires understanding of how the features are implemented by relying on DB operations and corresponding schema constraints. On the other hand, the number of unit test cases often grows as new functionality is introduced into the system, and maintaining these unit tests is important to reduce the introduction of regression bugs due to outdated unit tests. Therefore, one critical artifact that developers need to be able to maintain during evolution and maintenance of software systems is up-to-date and complete documentation.

show abstract

Section: Unit Test Case Stereotypesmentioning

confidence: 99%

Automatically Documenting Software Artifacts

2016

2016 IEEE International Conference on Software Maintenance and Evolution (ICSME)

View full text Add to dashboard Cite

show abstract

“…These techniques operate using a variety of approaches: textual or structural analysis of the source code [32], [35], [36], historic analysis of software change information [31], [34] and dynamic analysis of pass/fail testcase information [15]. As bug reports are usually formulated in natural language and the source code also includes large amounts of comments and identifiers, Information-Retrieval (IR) based bug localization techniques are frequently proposed for bug localization [3], [6], [8], [9], [13], [17], [26], [27], [29], [32]- [35], [37].…”

Section: Introductionmentioning

confidence: 99%

BoostNSift: A Query Boosting and Code Sifting Technique for Method Level Bug Localization

Razzaq¹,

Buckley²,

Patten³

et al. 2021

Preprint

View full text Add to dashboard Cite

Locating bugs is an important, but effort-intensive and time-consuming task, when dealing with large-scale systems. To address this, Information Retrieval (IR) techniques are increasingly being used to suggest potential buggy source code locations, for given bug reports. While IR techniques are very scalable, in practice their effectiveness in accurately localizing bugs in a software system remains low. Results of empirical studies suggest that the effectiveness of bug localization techniques can be augmented by the configuration of queries used to locate buggy code. However, in most IR-based bug localization techniques, presented by researchers, the impact of the queries' configurations is not fully considered. In a similar vein, techniques consider all code elements as equally suspicious of being buggy while localizing bugs, but this is not always the case either.In this paper, we present a new method-level, informationretrieval-based bug localization technique called "BoostNSift". BoostNSift exploits the important information in queries by 'boost'ing that information, and then 'sift's the identified code elements, based on a novel technique that emphasizes the code elements' specific relatedness to a bug report over its generic relatedness to all bug reports. To evaluate the performance of BoostNSift, we employed a state-of-the-art empirical design that has been commonly used for evaluating file level IR-based bug localization techniques: 6851 bugs are selected from commonly used Eclipse, AspectJ, SWT, and ZXing benchmarks and made openly available for method-level analyses. The performance of BoostNSift is compared with the openly-available state-ofthe-art IR-based BugLocator, BLUiR, and BLIA techniques. Experiments show that BoostNSift improves on BLUiR by up to 324%, on BugLocator by up to 297%, and on BLIA up to 120%, in terms of Mean Reciprocal Rank (MRR). Similar improvements are observed in terms of Mean Average Precision (MAP) and Top-N evaluation measures.

show abstract

“…A systematic review published in 2016 regarding an international repository including data of thousands of software projects, concluded that several studies lack clarity on how the data were prepared and used, which makes difficult to compare results among studies as well as replicate them [35]. Another study published in 2015 stands out that research studies in SM are notoriously hard to reproduce due to lack of datasets, and implementation details such as parameter values or environmental settings [36]. Finally, a study of 2018 found that many studies hinder replications and decreased the comparability among them because of unavailable data [37].…”

Section: Introductionmentioning

confidence: 99%

“…We perform the comparison among prediction accuracies of the SGB, SLR, MLP, RBFNN, GRNN, ɛ‐SVR, ʋ‐SVR, DT and ARu models taking into account the following issues suggested when machine learning models and non‐machine learning models (such as a SLR) are compared [13] Use of the absolute residuals (ARs) as a criterion for comparing the prediction accuracy between the models. Application of the leave‐one‐out cross‐validation (LOOCV) as a validation method. Description of the manner of how the SGB was optimised. Use of mutually exclusive data sets for training and testing the models. Selection of a suitable statistical test to compare the prediction accuracy among models from data dependence and normality analysis. Statistical significance difference as the means for comparing the prediction accuracy. A systematic review published in 2016 regarding an international repository including data of thousands of software projects, concluded that several studies lack clarity on how the data were prepared and used, which makes difficult to compare results among studies as well as replicate them [35]. Another study published in 2015 stands out that research studies in SM are notoriously hard to reproduce due to lack of datasets, and implementation details such as parameter values or environmental settings [36]. Finally, a study of 2018 found that many studies hinder replications and decreased the comparability among them because of unavailable data [37].…”

Section: Introductionmentioning

confidence: 99%

Stochastic gradient boosting for predicting the maintenance effort of software‐intensive systems

2020

View full text Add to dashboard Cite

The maintenance of software-intensive systems (SISs) must be undertaken to correct faults, improve the design, implement enhancements, adapt programmes such that different hardware, software, system features, and telecommunications facilities can be used, as well as to migrate legacy software. A lack of planning has been identified as one explanation for late and over budget software projects. An activity of planning is effort prediction. The goal of this study is to propose the application of a stochastic gradient boosting (SGB) model for predicting the SIS maintenance effort. We compare the SGB prediction accuracy with those obtained with statistical regression, neural network, support vector regression, decision trees, and association rules. We trained and tested the models with five SIS data sets selected from the International Software Benchmarking Standards Group Release 11. The SGB prediction accuracy was statistically better than the mentioned five models in the two larger data sets. We can conclude that a SGB can be applied to predict the maintenance effort of SISs coded in languages of the third generation and developed on either mainframes or multi-platform. The predicted effort corresponds to the aggregate of efforts obtained from the project team, project management, and project administration.

show abstract

Supporting and accelerating reproducible empirical research in software evolution and maintenance using TraceLab Component Library

Cited by 17 publications

References 54 publications

Automatically Documenting Software Artifacts

Automatically Documenting Software Artifacts

BoostNSift: A Query Boosting and Code Sifting Technique for Method Level Bug Localization

Stochastic gradient boosting for predicting the maintenance effort of software‐intensive systems

Contact Info

Product

Resources

About