Project Data Incorporating Qualitative Factors for Improved Software Defect Prediction

Fenton, Norman; Neil, Martin; Marsh, William; Hearty, Peter; Radliński, Łukasz; Krause, Paul

doi:10.1109/promise.2007.11

Cited by 34 publications

(41 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Taken together, these results indicate that a prediction of changing requirements will not be achieved based solely upon the requirement attributes examined in this study. Further consideration of more complex causal factors, such as the process factors and analysis techniques that have been found to correlate with requirements volatility [8,9], and also levels of effort and ability thought to influence the likelihood of defects [30].…”

Section: Discussion Of Resultsmentioning

confidence: 99%

“…In contrast to the predictive approach by correlation, a number of researchers are seeking to develop and evaluate more complex causal relationships [27][28][29]. In particular, Fenton [29,30], whose causal models were engineered to predict defect rates, argues that many models using small numbers of prediction variables ignore 'causal' factors such as programmer ability, or design quality. Further, models that reflect true causal mechanisms facilitate understanding and explanation as well as prediction.…”

Section: Requirements Change Predictionmentioning

confidence: 99%

“…Further, models that reflect true causal mechanisms facilitate understanding and explanation as well as prediction. Most illuminating about Fenton's work is the observation that results of studies to examine the relationship between requirement complexity and defect rate disagree entirely and argues that without including some measure of 'testing effort', the relationship between complexity and defect rate is arbitrary [30].…”

Section: Requirements Change Predictionmentioning

confidence: 99%

See 2 more Smart Citations

Towards an understanding of the causes and effects of software requirements change: two case studies

McGee

Greer

2012

Requirements Eng

View full text Add to dashboard Cite

Changes to software requirements not only pose a risk to the successful delivery of software applications but also provide opportunity for improved usability and value. Increased understanding of the causes and consequences of change can support requirements management and also make progress towards the goal of change anticipation. This paper presents the results of two case studies that address objectives arising from that ultimate goal. The first case study evaluated the potential of a change source taxonomy containing the elements 'market', 'organisation', 'vision', 'specification', and 'solution' to provide a meaningful basis for change classification and measurement. The second case study investigated whether the requirements attributes of novelty, complexity, and dependency correlated with requirements volatility. While insufficiency of data in the first case study precluded an investigation of changes arising due to the change source of 'market', for the remainder of the change sources, results indicate a significant difference in cost, value to the customer and management considerations. Findings show that higher cost and value changes arose more often from 'organisation' and 'vision' sources; these changes also generally involved the co-operation of more stakeholder groups and were considered to be less controllable than changes arising from the 'specification' or 'solution' sources. Results from the second case study indicate that only 'requirements dependency' is consistently correlated with volatility and that changes coming from each change source affect different groups of requirements. We conclude that the taxonomy can provide a meaningful means of change classification, but that a single requirement attribute is insufficient for change prediction. A theoretical causal account of requirements change is drawn from the implications of the combined results of the two case studies.

show abstract

Section: Discussion Of Resultsmentioning

confidence: 99%

Section: Requirements Change Predictionmentioning

confidence: 99%

Section: Requirements Change Predictionmentioning

confidence: 99%

See 1 more Smart Citation

Towards an understanding of the causes and effects of software requirements change: two case studies

McGee

Greer

2012

Requirements Eng

View full text Add to dashboard Cite

show abstract

“…Unfortunately, such approaches are not effective in estimating the overall number of defects. Probably the most appropriate approach to defect prediction with regard to risk analysis is Bayesian belief nets Fenton & Neil (1999a), Fenton et al (2007). This approach can be employed to predict the number of defects Fenton et al (2008) and can provide the cause-effect relations.…”

Section: Predicting the Number Of Defectsmentioning

confidence: 99%

Automatic Control of the Software Development Process with Regard to Risk Analysis

Jureczko¹

2012

Automation

View full text Add to dashboard Cite

“…Should we extrapolate from old data to build a parametric model; e.g. using a Bayes net [9], or the linear equations of COCOMO [5,7]? Or is it best to reason directly from data, without an intervening parametric model, using case-based reasoning (CBR) [26]?…”

Section: Introductionmentioning

confidence: 99%

Case-based reasoning vs parametric models for software quality optimization

Brady

2010

Proceedings of the 6th International Conference on Predictive Models in Software Engineering

View full text Add to dashboard Cite

Background: There are many data mining methods but few comparisons between them. For example, there are at least two ways to build quality optimizers, programs that find project options that change quality measures like defects, development effort (total staff hours), and time (elapsed calendar months). In the first way, we construct a parametric model to represent prior software projects. In the second way, we just apply case-based reasoning to reason directly from historical cases.Aim: To assess case-based reasoning vs parametric modeling for quality optimization.Method: We compared the W case-based reasoner against the SEEWAW parametric modeling tool.Results: W is easy to explain and fast to build. It makes no parametric assumptions and hence can be rapidly applied to project data in many formats. SEESAW is an elaborate tool that can only process project data expressed in a particular ontology (i.e. just the COCOMO attributes). It is also slower to execute than W . In 24 different tests comparing W and SEESAW, W always performs at least as well as SEESAW. In 6 of those tests W performed statistically better (all tests used Mann-Whitney, 95% confidence). Lastly, like any CBR method, it comes with a built-in maintenance strategy (just add more cases).Conclusion: The W case-based reasoning tool is recommended over the SEESAW parametric modeling tool for purposes of quality optimization (except in the case where there is no local data).

show abstract

Project Data Incorporating Qualitative Factors for Improved Software Defect Prediction

Abstract: Abstract

Cited by 34 publications

References 8 publications

Towards an understanding of the causes and effects of software requirements change: two case studies

Towards an understanding of the causes and effects of software requirements change: two case studies

Automatic Control of the Software Development Process with Regard to Risk Analysis

Case-based reasoning vs parametric models for software quality optimization

Contact Info

Product

Resources

About