A Continuous Software Quality Monitoring Approach for Small and Medium Enterprises

Proceedings of the Fifteenth International Conference on Predictive Models and Data Analytics in Software Engineering

Taibi

2019

Self Cite

Technical Debt analysis is increasing in popularity as nowadays researchers and industry are adopting various tools for static code analysis to evaluate the quality of their code. Despite this, empirical studies on software projects are expensive because of the time needed to analyze the projects. In addition, the results are difficult to compare as studies commonly consider different projects. In this work, we propose the Technical Debt Dataset, a curated set of project measurement data from 33 Java projects from the Apache Software Foundation. In the Technical Debt Dataset, we analyzed all commits from separately defined time frames with SonarQube to collect Technical Debt information and with Ptidej to detect code smells. Moreover, we extracted all available commit information from the git logs, the refactoring applied with Refactoring Miner, and fault information reported in the issue trackers (Jira). Using this information, we executed the SZZ algorithm to identify the fault-inducing and -fixing commits. We analyzed 78K commits from the selected 33 projects, detecting 1.8M SonarQube issues, 38K code smells, 28K faults and 57K refactorings. The project analysis took more than 200 days. In this paper, we describe the data retrieval pipeline together with the tools used for the analysis. The dataset is made available through CSV files and an SQLite database to facilitate queries on the data. The Technical Debt Dataset aims to open up diverse opportunities for Technical Debt research, enabling researchers to compare results on common projects.

Section: Licensementioning

confidence: 99%

“…Regarding the data collection process and the traditional trade-off between being up-to-date and curation [6], we preferred emphasizing the curation of the dataset rather than providing a limited 16 GitHub Terms of Service. goo.gl/yeZh1E Accessed: May 2019 up-to-date amount of data.…”

Section: Threats To Validitymentioning

confidence: 99%

The Technical Debt Dataset

Lenarduzzi

Proceedings of the Fifteenth International Conference on Predictive Models and Data Analytics in Software Engineering

Taibi

2019

Self Cite

“…Understanding these laws also requires interdisciplinary studies that combine computing, quality management, and psychology. A continuous quality management approach [24] [23], could help to prevent TD. Moreover, management studies help to develop better processes, while psychology and organizational studies can explain why estimation errors occur.…”

Section: Discussionmentioning

confidence: 99%

“…Companies need to find the golden mean in quality improvement, where the cost-benefit ratio is the lowest [22]. Moreover, companies should consider continuous quality monitoring approaches, instead of one-shot refactoring [23] [24].…”

Section: Continuous Improvementmentioning

confidence: 99%

An Empirical Study on Technical Debt in a Finnish SME

Lenarduzzi

Orava

2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

et al. 2019

Self Cite

Background. The need to release our products under tough time constraints has required us to take shortcuts during the implementation of our products and to postpone the correct implementation, thereby accumulating Technical Debt. Objective. In this work, we report the experience of a Finnish SME in managing Technical Debt (TD), investigating the most common types of TD they faced in the past, their causes, and their effects. Method. We set up a focus group in the case-company, involving different roles. Results. The results showed that the most significant TD in the company stems from disagreements with the supplier and lack of test automation. Specification and test TD are the most significant types of TD. Budget and time constraints were identified as the most important root causes of TD. Conclusion. TD occurs when time or budget is limited or the amount of work are not understood properly. However, not all postponed activities generated "debt". Sometimes the accumulation of TD helped meet deadlines without a major impact, while in other cases the cost for repaying the TD was much higher than the benefits. From this study, we learned that learning, careful estimations, and continuous improvement could be good strategies to mitigate TD These strategies include iterative validation with customers, efficient communication with stakeholders, meta-cognition in estimations, and value orientation in budgeting and scheduling.

“…Fortunately, several studies [25], [26], [27], [28], [29] have used our Technical Debt Dataset. Thus, there is a good possibility we will be able to replicate at least some of them.…”

Section: Threats To Validitymentioning

confidence: 99%

Methodological Issues in Observational Studies

SIGSOFT Softw. Eng. Notes

2019

Background. Starting from the 1960s, practitioners and researchers have looked for ways to empirically investigate new technologies such as inspecting the effectiveness of new methods, tools, or practices. With this purpose, the empirical software engineering domain started to identify different empirical methods, borrowing them from various domains such as medicine, biology, and psychology. Nowadays, a variety of empirical methods are commonly applied in software engineering, ranging from controlled and quasi-controlled experiments to case studies, from systematic literature reviews to the newly introduced multivocal literature reviews. However, to date, the only available method for proving any cause-effect relationship are controlled experiments.Objectives. The goal of the thesis is introducing new methodologies for studying causality in empirical software engineering. Methods. Other fields use observational studies for proving causality. They allow observing the effect of a risk factor and testing this without trying to change who is or is not exposed to it. As an example, with an observational study it is possible to observe the effect of pollution on the growth of a forest or the effect of different factors on development productivity without the need of waiting years for the forest to grow or exposing developers to a specific treatment. Conclusion. In this thesis, we aim at defining a methodology for applying observational studies in empirical software engineering, providing guidelines on how to conduct such studies, how to analyze the data, and how to report the studies themselves.