Agile Processes in Software Engineering and Extreme Programming- P6

Agile Processes in Software Engineering and Extreme Programming- P6:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P6138 A. Marchenko and P. Abrahamssondeveloped code. Currently the main drawback of the static code analysis is the lack ofempirical evidence of the correlation between the tool reports and the actual defectsrate. There is also no explicit evidence in the area of embedded software that the useof automated static source code analysis would yield results that confirm thecorrelation between the actual defect rate and predicted defect rate. This paper presents a case study on predicting defects in the domain of embeddedsoftware development by use of automated static code analysis tools. The suitabilityof two particular tools, i.e. CodeScanner and PC-LINT, is tested on a number ofcomponents shipped as a part of Nokia smartphone software. The feasibility of abroader study is indicated.2 Related LiteratureFenton and Neil (1999) outline four general approaches to predicting the number ofdefects in the system. [2]. This article is based on the approach of finding thecorrelation between the defect density and the code metrics. The metrics used for thedefect rate prediction are produced by the process of static code analysis – theanalysis of software statically, without attempting to execute it [3]. There are some studies on the static code analysis effectiveness reportingsomewhat controversial results. Dromey (1996) suggests that code analysis can findmost of quality defects and report them in a way convenient for the developers tocorrect the code. [4] Nachiappan and Thomas (2005) found that there was a strongcorrelation between the number of defects predicted by static analysis tools and thenumber of defects found by testing [5]. On the other hand Lauesen and Younessi(1998) state that the code analysis can locate only a small percentage of meaningfuldefects [6]. As shown above, currently, there are virtually no studies on applicability of staticcode analysis tools in the area of embedded software development as is the case inthis study, i.e. Symbian operating system environment. This study focuses onevaluating the ability of the static code analysis tools to predict the number of defectsin the software written in C++ for the Symbian operating system.3 Research DesignIn this study a number of components of the mobile phone software have beenanalyzed. All the components are written in C++ for the Nokia S60 software platformbased on the Symbian operating system. The source code has been processed by twostatic code analysis tools: CodeScanner [7] and PC-Lint [8]. CodeScanner is a tool specifically developed for the Symbian C++ code analysis,while PC-LINT is a general C++ code analysis tool that can be fitted to the particularenvironment. In this case two sets of in-house built Symbian specific rules have beenused to fit PC-LINT to the Symbian code idioms (“normal” and “strict” rule sets). For the issues reported by the tools the “issue rate” per non-comment KLOC hasbeen computed. The actual defect rate has been obtained from the company defectdatabase. The defects reported within 3 and 6 months after the release date have beentaken into account.Predicting Software Defect Density: A Case Study on Automated Static Code Analysis 139 The projects have been ranked in the order of the rates. The correlation between theranks has been computed in order to find out if there is a link between the issue ratesand the actual defect rates. Spearman rank correlation has been used for the resultsanalysis, because it can be applied even when the association between elements isnon-linear. If rank correlation between the issue rate and the defect rate is positive,then for the projects analyzed, the bigger the issue rate is, the bigger defect rateshould be expected.4 Empirical Results and DiscussionThe case study included five components of the 3rd edition of the Nokia S60 platformfor smartphones. After the testing and debugging related code exclusion, the size ofthe code analyzed was 137 KLOC. Table 1 shows the correlations between the reported issue rates and acknowledgeddefect rates. The first column presents the CodeScanner results. The next threecolumns contain PC-LINT results with different variants. The first line presentscorrelation with critical defects that were reported within 90 days and the second line- with the critical defects reported within 180 days after the release. Table 1. Correlation results of defects/KLOC Actual defect rate Code PC-LINT PC-LINT PC-LINT Scanner strict errors strict errors normal errors rate rate + warnings + warnings rate rate 90 days rate 0.7 -0.7 -0.9 ...