Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Aalok Ahluwalia

dblp:243/2596 · DBLP profile ↗
← Back
2ranked-venue papers
1as first author
1since 2021 · last 2022
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2 · 1 first-author · 1 since 2021Databases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Empirical software engineering · 91% Software testing · 9%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering › mining software repositories
defect datasets
0.612022
The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects · ACM Trans. Softw. Eng. Methodol. 2022
Empirical software engineering › mining software repositories
defect prediction
0.612022
The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects · ACM Trans. Softw. Eng. Methodol. 2022
Empirical software engineering
mining software repositories
0.612022
The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects · ACM Trans. Softw. Eng. Methodol. 2022
Software testing › regression testing
test case prioritization
0.212022
The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects · ACM Trans. Softw. Eng. Methodol. 2022

Methods — techniques the papers use, named apart from their topics

machine learning classifier · 0.6
YearPublicationVenuePosition
2022 The Impact of Dormant Defects on Defect Prediction: A Study of 19 Apache Projects
abstract
Defect prediction models can be beneficial to prioritize testing, analysis, or code review activities, and has been the subject of a substantial effort in academia, and some applications in industrial contexts. A necessary precondition when creating a defect prediction model is the availability of defect data from the history of projects. If this data is noisy, the resulting defect prediction model could result to be unreliable. One of the causes of noise for defect datasets is the presence of “dormant defects,” i.e., of defects discovered several releases after their introduction. This can cause a class to be labeled as defect-free while it is not, and is, therefore “snoring.” In this article, we investigate the impact of snoring on classifiers' accuracy and the effectiveness of a possible countermeasure, i.e., dropping too recent data from a training set. We analyze the accuracy of 15 machine learning defect prediction classifiers, on data from more than 4,000 defects and 600 releases of 19 open source projects from the Apache ecosystem. Our results show that on average across projects (i) the presence of dormant defects decreases the recall of defect prediction classifiers, and (ii) removing from the training set the classes that in the last release are labeled as not defective significantly improves the accuracy of the classifiers. In summary, this article provides insights on how to create defects datasets by mitigating the negative effect of dormant defects on defect prediction.
Davide Falessi, Aalok Ahluwalia, Massimiliano Di Penta
ACM Trans. Softw. Eng. Methodol.2
2019 Snoring: a noise in defect prediction datasets
abstract
In order to develop and train defect prediction models, researchers rely on datasets in which a defect is often attributed to a release where the defect itself is discovered. However, in many circumstances, it can happen that a defect is only discovered several releases after its introduction. This might introduce a bias in the dataset, i.e., treating the intermediate releases as defect-free and the latter as defect-prone. We call this phenomenon as "sleeping defects". We call "snoring" the phenomenon where classes are affected by sleeping defects only, that would be treated as defect-free until the defect is discovered. In this paper we analyze, on data from 282 releases of six open source projects from the Apache ecosystem, the magnitude of the sleeping defects and of the snoring classes. Our results indicate that 1) on all projects, most of the defects in a project slept for more than 20% of the existing releases, and 2) in the majority of the projects the missing rate is more than 25% even if we remove 50% of releases.
Aalok Ahluwalia, Davide Falessi, Massimiliano Di Penta
MSR1