An Industry Perspective to Comparing the SQALE and Quamoco Software Quality Models

Izurieta, Clemente; Griffith, Isaac; Huvaere, Chris

doi:10.1109/esem.2017.42

Cited by 7 publications

(6 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We used the T DR normalization of technical debt according to software size. We used statement lines of code 11 as the proxy for application size; we carried out a Spearman test that uncovered very high correlation (> 0.98) between this metric and the number of application classes and methods for all three target applications.…”

Section: Resultsmentioning

confidence: 99%

“…This is compounded by the lack of a unified perspective regarding technical debt types, causes and impacts. While existing tools integrate the required components to measure technical debt, in many cases there are differences between reported results [9,11]. Also, debt created early during the development cycle compounds interest and is more difficult to deal with, as evidenced by both earlier and recent research [10,31].…”

Section: Majormentioning

confidence: 99%

“…SonarQube, Squore and NDepend use the SQALE [15] model, while Kiuwan uses the Checking Quality Model, which takes into consideration an evaluation of maintainability, reliability, portability, efficiency, and security. Other well-known models include QMOOD, Quamoco and Columbus, which were examined in existing literature [9,11]. Usually, software tools employ static code analysis in order to collect data about several metrics and code coverage that are verified against a set of rules.…”

Section: Preliminaries 21 Technical Debtmentioning

confidence: 99%

“…Researchers also carried out comparative evaluations for wellknown quality models. Authors of [11] noted the existence of inconsistencies between SQALE and Quamoco, as the two models remained in agreement only for software with A-grade quality. When applied on systems having lower maintainability, reliability or security ratings, evaluations diverged.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

Long-Term Evaluation of Technical Debt in Open-Source Software

Molnar

Motogna

2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

Background: A consistent body of research and practice have identified that technical debt provides valuable and actionable insight into the design and implementation deficiencies of complex software systems. Existing software tools enable characterizing and measuring the amount of technical debt at selective granularity levels; by providing a computational model, they enable stakeholders to measure and ultimately control this phenomenon. Aims: In this paper we aim to study the evolution and characteristics of technical debt in open-source software. For this, we carry out a longitudinal study that covers the entire development history of several complex applications. The goal is to improve our understanding of how the amount and composition of technical debt changes in evolving software. We also study how new technical debt is introduced in software, as well as identify how developers handle its accumulation over the long term. Method: We carried out our evaluation using three complex, open-source Java applications. All 110 released versions, covering more than 10 years of development history for each application were analyzed using SonarQube. We studied how the amount, composition and history of technical debt changed during development, compared our results across the studied applications and present our most important findings. Results: For each application, we identified key versions during which large amounts of technical debt were added, removed or both. This had significantly more impact when compared to the lines of code or class count increases that generally occurred during development. However, within each version, we found high correlation between file lines of code and technical debt. We observed that the Pareto principle was satisfied for the studied applications, as 20% of issue types generated around 80% of total technical debt. Interestingly, there was a large degree of overlap between the issues that generated most of the debt across the studied applications. Conclusions: Early application versions showed greater fluctuation in the amount of existing technical debt. We found application size to be an unreliable predictor for the quantity of technical debt. Most debt was introduced in applications as part of milestone releases that expanded their feature set; likewise, we identified releases where extensive refactoring significantly reduced the level of debt. We

show abstract

Section: Resultsmentioning

confidence: 99%

Section: Majormentioning

confidence: 99%

Section: Preliminaries 21 Technical Debtmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Long-Term Evaluation of Technical Debt in Open-Source Software

Molnar

Motogna

2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

show abstract

“…To detect the evolution and remediation of technical debt in the subject systems, we rely on a third-party detection tool: Sonar-Qube, an open-source code-quality measuring and management tool (Campbell and Papapetrou, 2013). The tool was selected for three main reasons: (1) its broad usage for estimating technical debt, both in academic research studies (Digkas et al, 2018(Digkas et al, , 2017Marcilio et al, 2019;Lenarduzzi et al, 2019) and in industry (being used by more than 1,000 companies 6 ); (2) its capacity to perform multi-version analysis and thus, track the evolution and repayment of technical debt over time; and (3) the fact that the tool is based on the SQALE method (Letouzey, 2012;Letouzey and Coq, 2010), which has been published and evaluated academically (Letouzey and Ilkiewicz, 2012;Griffith et al, 2017;Fontana et al, 2016;Dale and Izurieta, 2014). Of course it is not a perfect solution for measuring TD, as a perfect solution does not exist; we expand on the limitations of using SonarQube in the Threats to Validity Section.…”

Section: Technical Debt Identificationmentioning

confidence: 99%

Technical Debt Repayment in Practice

Tan¹

View full text Add to dashboard Cite

Technical Debt (TD) is a metaphor used to describe a trade-off between the shortterm benefits of "cutting corners" in software development and the long-term sustainability of a software system. Researchers have classified technical debt into several different types, such as design or code debt. The amount of technical debt tends to increase during the evolution of software systems. When the increasing technical debt results in extra maintenance and evolution effort, it needs to be (at least partially) managed.Technical debt repayment is the TD management activity which refers to the remediation of technical debt by reworking design and implementation constructs. Paying back all technical debt may be infeasible since there is typically a shortage of resources that can be allocated. Moreover, business stakeholders often prioritize resources (money and time) on developing new features and fixing defects, rather than performing TD refactoring activities. Therefore, developers need to improve resource allocation for TD repayment due to the limited resources and competing business interests. Thus, investigating the factors that influence TD repayment is crucial in finding optimal solutions that maximize value and satisfy resource constraints. The thesis reports on the investigation of how TD is paid back in practice and what factors influence this repayment, by considering both software repositories and the perspective of practitioners.In order to address the stated problem, we first looked into how TD repayment occurs in practice and its evolution over time. Specifically, we focused on the TD fixing rate across projects and across issue types, the repayment effort and the survival time of TD items. The results showed that most of the repayment effort goes into improving testing, adding documentation, reducing complexity, and removing duplication. We also extended a previous study on the same topic that used several Java projects and compared the results of TD remediation in Python and Java perspectief kan niet grondig onderzocht worden door naar een enkele gegevensbron te kijken (bijv. broncode of gesprekken van ontwikkelaars). Daarom hebben we gekeken naar twee gegevensbronnen (issue trackers en broncode) om de tijdlijn te onderzoeken van TD items die ontstaan in broncode, gerapporteerd en besproken worden in issue trackers en vervolgens terugbetaald worden in broncode. Daarvoor hebben we 219 TD-items uit vijf open-sourceprojecten handmatig geëxtraheerd en geïnspecteerd.De resultaten toonden aan dat de meeste TD-items die in issue trackers geïdentificeerd en als opgelost vermeld worden, ook terugbetaald worden in broncode, terwijl ongeveer een vijfde verder besproken wordt nadat ze geïdentificeerd zijn. De opgeloste TD items in issue trackers gerelateerd aan Design Debt hebben een significant hogere kans om terugbetaald te worden in broncode, terwijl Test Debt items minder kans hebben. Bovendien, hoewel het lang duurt om TD items te identificeren (ongeveer een jaar), hebben ze de neiging om binnen een paar dagen daar...

show abstract

Evolution of technical debt remediation in Python: A case study on the Apache Software Ecosystem

Tan

Feitosa

Avgeriou

et al. 2020

J Software Evolu Process

View full text Add to dashboard Cite

In recent years, the evolution of software ecosystems and the detection of technical debt received significant attention by researchers from both industry and academia. While a few studies that analyze various aspects of technical debt evolution already exist, to the best of our knowledge, there is no large‐scale study that focuses on the remediation of technical debt over time in Python projects—that is, one of the most popular programming languages at the moment. In this paper, we analyze the evolution of technical debt in 44 Python open‐source software projects belonging to the Apache Software Foundation. We focus on the type and amount of technical debt that is paid back. The study required the mining of over 60K commits, detailed code analysis on 3.7K system versions, and the analysis of almost 43K fixed issues. The findings show that most of the repayment effort goes into testing, documentation, complexity, and duplication removal. Moreover, more than half of the Python technical debt is short term being repaid in less than 2 months. In particular, the observations that a minority of rules account for the majority of issues fixed and spent effort suggest that addressing those kinds of debt in the future is important for research and practice.

show abstract

An Industry Perspective to Comparing the SQALE and Quamoco Software Quality Models

Cited by 7 publications

References 25 publications

Long-Term Evaluation of Technical Debt in Open-Source Software

Long-Term Evaluation of Technical Debt in Open-Source Software

Technical Debt Repayment in Practice

Evolution of technical debt remediation in Python: A case study on the Apache Software Ecosystem

Contact Info

Product

Resources

About