Preliminary Results On Using Static Analysis Tools For Software Inspection

Nagappan, Nachiappan; Williams, Laurie; Hudepohl, J.P.; Snipes, Will; Vouk, Mladen A.

doi:10.1109/issre.2004.30

Cited by 31 publications

(20 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Even if users do not directly get in touch with internal software quality, it is an intuitive observation that internal quality affects external quality to a high degree. This observation is also supported by several studies (e.g., [2][3][4]) though Fenton and Neil found some principal problems with such surveys [5].…”

Section: Introductionsupporting

confidence: 76%

The EMISQ method and its tool support-expert-based evaluation of internal software quality

Plösch

Gruber

Hentschel

et al. 2008

Innovations Syst Softw Eng

View full text Add to dashboard Cite

There is empirical evidence that internal software quality, e.g., the quality of source code, has great impact on the overall quality of software. Besides well-known manual inspection and review techniques for source code, more recent approaches utilize tool-based static code analysis for the evaluation of internal software quality. Despite the high potential of code analyzers the application of tools alone cannot replace well-founded expert opinion. Knowledge, experience and fair judgment are indispensable for a valid, reliable quality assessment, which is accepted by software developers and managers. The EMISQ method (Evaluation Method for Internal Software Quality), guides the assessment process for all stakeholders of an evaluation project. The method is supported by the Software Product Quality Reporter (SPQR), a tool which assists evaluators with their analysis and rating tasks and provides support for generating code quality reports. The application of SPQR has already proved its usefulness in various code assessment projects around the world. This paper introduces the EMISQ method and describes the tool support needed for an efficient and effective evaluation of internal software quality.

show abstract

Section: Introductionsupporting

confidence: 76%

The EMISQ method and its tool support-expert-based evaluation of internal software quality

Plösch

Gruber

Hentschel

et al. 2008

Innovations Syst Softw Eng

View full text Add to dashboard Cite

show abstract

“…This scheme uses the defect type as one of the aspects from which to classify the defect. While the ODC scheme has been used in research [26], [27], several studies conclude that it was too abstract and required adaptations to fit any particular use in practice [14], [28], [29]. In this paper, we propose the General Defect Classification (GDC), a remote ODC-descendant that is a generalization of the scheme refined by Beller et al [28] and Mäntylä and Lassenius [29].…”

Section: B Defect Classificationsmentioning

confidence: 99%

Analyzing the State of Static Analysis: A Large-Scale Evaluation in Open Source Software

Beller

Bholanath

McIntosh

et al. 2016

2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)

150

128

View full text Add to dashboard Cite

Abstract-The use of automatic static analysis has been a software engineering best practice for decades. However, we still do not know a lot about its use in real-world software projects: How prevalent is the use of Automated Static Analysis Tools (ASATs) such as FindBugs and JSHint? How do developers use these tools, and how does their use evolve over time? We research these questions in two studies on nine different ASATs for Java, JavaScript, Ruby, and Python with a population of 122 and 168,214 open-source projects. To compare warnings across the ASATs, we introduce the General Defect Classification (GDC) and provide a grounded-theory-derived mapping of 1,825 ASAT-specific warnings to 16 top-level GDC classes. Our results show that ASAT use is widespread, but not ubiquitous, and that projects typically do not enforce a strict policy on ASAT use. Most ASAT configurations deviate slightly from the default, but hardly any introduce new custom analyses. Only a very small set of default ASAT analyses is widely changed. Finally, most ASAT configurations, once introduced, never change. If they do, the changes are small and have a tendency to occur within one day of the configuration's initial introduction.

show abstract

“…Our basic hypothesis is that the more static analysis defects found, the higher the probability of other defects being present. A similar approach was used in a study carried out at Nortel Networks on an 800 KLOC commercial software system [23]. Automatic inspection defects found by static analysis tools along with code churn was found to be a statistically significant indicator of field failures and is effective in identifying fault-prone modules.…”

Section: Related Workmentioning

confidence: 99%

Static analysis tools as early indicators of pre-release defect density

Nagappan¹,

Ball²

Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005.

Self Cite

106

View full text Add to dashboard Cite

During software development it is helpful to obtain early estimates of the defect density of software components. Such estimates identify fault-prone areas of code requiring further testing. We present an empirical approach for the early prediction of pre-release defect density based on the defects found using static analysis tools. The defects identified by two different static analysis tools are used to fit and predict the actual pre-release defect density for Windows Server 2003. We show that there exists a strong positive correlation between the static analysis defect density and the pre-release defect density determined by testing. Further, the predicted pre-release defect density and the actual pre-release defect density are strongly correlated at a high degree of statistical significance. Discriminant analysis shows that the results of static analysis tools can be used to separate high and low quality components with an overall classification rate of 82.91%.

show abstract

Preliminary Results On Using Static Analysis Tools For Software Inspection

Cited by 31 publications

References 26 publications

The EMISQ method and its tool support-expert-based evaluation of internal software quality

The EMISQ method and its tool support-expert-based evaluation of internal software quality

Analyzing the State of Static Analysis: A Large-Scale Evaluation in Open Source Software

Static analysis tools as early indicators of pre-release defect density

Contact Info

Product

Resources

About