Refactoring Cost Estimation for Architectural Technical Debt

Abstract

Paying-off the Architectural Technical Debt by refactoring the flawed code is important to control the debt and to keep it as low as possible. Project Managers tend to delay paying off this debt because they face difficulties in comparing the cost of the refactoring against the benefits gained. These managers need to estimate the cost and the efforts required to conduct these refactoring activities as well as to decide which flaws have higher priority to be refactored. Our research is based on a dataset used by other researchers that study the technical debt. It includes more than 18,000 refactoring operations performed on 33 apache java projects. We applied the COCOMO II:2000 model to calculate the refactoring cost in person-months units per release. Furthermore, we investigated the correlation between the refactoring efforts and two static code metrics of the refactored code. The research revealed a weak correlation between the refactoring efforts and the size of the project, and a moderate correlation with the code complexity. Finally, we applied the DesigniteJava tool to verify our research results. From the analysis we found a significant correlation between the ranking of the architecture smells and the ranking of refactoring efforts for each package. Using machine learning practices, we took the architecture smells level and the code metrics of each release as an input to predict the levels of the refactoring effort of the next release. We calculated the results using our model and found that we can predict the ‘High’ and ‘Very High’ levels, the most significant levels from managers’ perspective, with [Formula: see text] accuracy.