Untitled

Briand, Lionel C.; Wüst, Jürgen; Lounis, Hakim

doi:10.1023/a:1009815306478

Cited by 134 publications

(7 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It can also involve a sort of meta-study, where a study with one group of subjects is later followed by another study using another group, and the results are compared (e.g. [41,54,55]).…”

Section: Direct Comparisons Of Students and Professionalsmentioning

confidence: 99%

“…This gap was then confirmed in an industrial followup with 33 developers, where only 29% of test cases were negative but they were responsible for finding 71% of the defects [54]. Briand et al used a similar methodology, where results from student projects were subsequently largely confirmed by an industrial followup [41]. The context was using defect data to evaluate object-oriented quality metrics.…”

Section: Studies Showing Similarity Of Students and Professionalsmentioning

confidence: 99%

See 1 more Smart Citation

Using Students as Experimental Subjects in Software Engineering Research -- A Review and Discussion of the Evidence

Feitelson

2015

Preprint

View full text Add to dashboard Cite

Should students be used as experimental subjects in software engineering? Given that students are in many cases readily available and cheap it is no surprise that the vast majority of controlled experiments in software engineering use them. But they can be argued to constitute a convenience sample that may not represent the target population (typically "real" developers), especially in terms of experience and proficiency. This causes many researchers (and reviewers) to have reservations about the external validity of student-based experiments, and claim that students should not be used. Based on an extensive review of published works that have compared students to professionals, we find that picking on "students" is counterproductive for two main reasons. First, classifying experimental subjects by their status is merely a proxy for more important and meaningful classifications, such as classifying them according to their abilities, and effort should be invested in defining and using these more meaningful classifications. Second, in many cases using students is perfectly reasonable, and student subjects can be used to obtain reliable results and further the research goals. In particular, this appears to be the case when the study involves basic programming and comprehension skills, when tools or methodologies that do not require an extensive learning curve are being compared, and in the initial formative stages of large industrial research initiatives -in other words, in many of the cases that are suitable for controlled experiments of limited scope.

show abstract

“…It can also involve a sort of meta-study, where a study with one group of subjects is later followed by another study using another group, and the results are compared (e.g. [41,54,55]).…”

Section: Direct Comparisons Of Students and Professionalsmentioning

confidence: 99%

Section: Studies Showing Similarity Of Students and Professionalsmentioning

confidence: 99%

Using Students as Experimental Subjects in Software Engineering Research -- A Review and Discussion of the Evidence

Feitelson

2015

Preprint

View full text Add to dashboard Cite

show abstract

“…Olague et al [85] claimed that the QMOOD metrics [11] were suitable for fault prediction, while the MOOD suite of metrics [28,29] was not. Cohesion metrics (LCC and TCC) [14] had modest effectiveness for predicting future faults [18,74], and coupling metrics, proposed by Briand et al [17] were good predictors of future faults [16][17][18]31]. Our work, rather than demonstrating a coarse, weak correlation between code entity size and defects detected, uses code size to drive test generation, improving code coverage and fault detection.…”

Section: Related Workmentioning

confidence: 91%

“…There are also a large number of metrics designed specifically for object oriented programs. Some (referred to as CBO, WMC and RFC, in the relevant papers) have been proposed as useful predictors of pre-release faults [12,18,53,85,88], while other measures, such as LCOM, DIT, and NOC, did not perform well [53,85,85,88,118]. Olague et al [85] claimed that the QMOOD metrics [11] were suitable for fault prediction, while the MOOD suite of metrics [28,29] was not.…”

Section: Related Workmentioning

confidence: 99%

Using Relative Lines of Code to Guide Automated Test Generation for Python

Holmes

Ahmed

Brindescu

et al. 2020

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

Raw lines of code (LOC) is a metric that does not, at first glance, seem extremely useful for automated test generation. It is both highly language-dependent and not extremely meaningful, semantically, within a language: one coder can produce the same effect with many fewer lines than another. However, relative LOC , between components of the same project, turns out to be a highly useful metric for automated testing. In this article, we make use of a heuristic based on LOC counts for tested functions to dramatically improve the effectiveness of automated test generation. This approach is particularly valuable in languages where collecting code coverage data to guide testing has a very high overhead. We apply the heuristic to property-based Python testing using the TSTL (Template Scripting Testing Language) tool. In our experiments, the simple LOC heuristic can improve branch and statement coverage by large margins (often more than 20%, up to 40% or more) and improve fault detection by an even larger margin (usually more than 75% and up to 400% or more). The LOC heuristic is also easy to combine with other approaches and is comparable to, and possibly more effective than, two well-established approaches for guiding random testing.

show abstract

“…Conclusions shows apart from {noc} all metrics are useful to predict faults tendency (Briand et al, 2000). Wust and Briand determined that {dit} metrics are inversely correlated to fault proneness and {noc} metrics is an insignificant predictor of fault tendency (Briand, Wüst & Lounis, 2001). Yu et al selected eight metrics to explored the relationship amongst these metrics and the tendency to identify faults.…”

Section: Inheritance In Sfpmentioning

confidence: 97%

Exclusive use and evaluation of inheritance metrics viability in software fault prediction—an experimental study

Aziz

Khan

Nadeem

2021

PeerJ Computer Science

View full text Add to dashboard Cite

Software Fault Prediction (SFP) assists in the identification of faulty classes, and software metrics provide us with a mechanism for this purpose. Besides others, metrics addressing inheritance in Object-Oriented (OO) are important as these measure depth, hierarchy, width, and overriding complexity of the software. In this paper, we evaluated the exclusive use, and viability of inheritance metrics in SFP through experiments. We perform a survey of inheritance metrics whose data sets are publicly available, and collected about 40 data sets having inheritance metrics. We cleaned, and filtered them, and captured nine inheritance metrics. After preprocessing, we divided selected data sets into all possible combinations of inheritance metrics, and then we merged similar metrics. We then formed 67 data sets containing only inheritance metrics that have nominal binary class labels. We performed a model building, and validation for Support Vector Machine(SVM). Results of Cross-Entropy, Accuracy, F-Measure, and AUC advocate viability of inheritance metrics in software fault prediction. Furthermore, ic, noc, and dit metrics are helpful in reduction of error entropy rate over the rest of the 67 feature sets.

show abstract

Untitled

Abstract: This paper aims at empirically exploring the relationships between most of the existing design coupling, cohesion

Cited by 134 publications

References 35 publications

Using Students as Experimental Subjects in Software Engineering Research -- A Review and Discussion of the Evidence

Using Students as Experimental Subjects in Software Engineering Research -- A Review and Discussion of the Evidence

Using Relative Lines of Code to Guide Automated Test Generation for Python

Exclusive use and evaluation of inheritance metrics viability in software fault prediction—an experimental study

Contact Info

Product

Resources

About