The SQALE Quality and Analysis Models for Assessing the Quality of Ada Source Code

Coq, Thierry; Rosen, Jean-Pierre

doi:10.1007/978-3-642-21338-0_5

Cited by 3 publications

(2 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…development , security requirements, and project status) are used to characterize and quantify code debt. Regarding code quality, Letouzey [4] proposed SQALE method to estimate the quality and the existing percentage of TD of an application source code. The SQALE method measures TD as a composite of different categories, coupled with their related metrics.…”

Section: Testing and Development Technical Debtmentioning

confidence: 99%

Understanding the impact of technical debt in coding and testing

Abad

Karimpour

et al. 2016

Proceedings of the 3rd International Workshop on Software Engineering Research and Industrial Practice

View full text Add to dashboard Cite

Technical Debt (TD) refers to the long-term consequences of shortcuts taken during different phases of software development life cycle. Lack of attention to monitoring and managing testing and development debt can contribute to unexpectedly large cost overruns and severe quality issues in software development projects. This paper describes a case study conducted with an industry partner to explore the impact of TD in coding and testing. By conducting (i) a semistructured interview, and (ii) a quantitative survey, we found that (1) the status of TD is largely project-independent, (2) we could not reject that there is no significant difference between the percentage of existing TD and the required time for reducing this TD in testing and development teams, (3) there is a statistically significant difference between the perceived influence of reducing TD on productivity increase in testing and development teams, (4) team member's experience has impact on the existing percentage of TD and influences productivity increase that is caused by reducing TD, (5) allocating more resources such as time, budget, and infrastructure is considered a potential solution for reducing TD.

show abstract

Section: Testing and Development Technical Debtmentioning

confidence: 99%

Understanding the impact of technical debt in coding and testing

Abad

Karimpour

et al. 2016

Proceedings of the 3rd International Workshop on Software Engineering Research and Industrial Practice

View full text Add to dashboard Cite

show abstract

“…Calculation models involve the use of mathematical models to measure technical debt. Coq and Rosen (2011) proposed an Ada language-compliant quality model using the SQALE assessment method, which measures technical debt by assessing the testability, changeability, and reusability of Ada software. Nugroho et al (2011) utilized empirical data to quantify the cost of technical debt principal and interest, taking into account factors such as repair effort, rework fraction, rebuild value, maintenance fraction, and quality factor.…”

Section: Measurement Of Satdmentioning

confidence: 99%

Management of Self-Admitted Technical Debt using Machine Learning

View full text Add to dashboard Cite

Technical debt is a prevalent phenomenon in software development, where developers make sub-optimal decisions to achieve short-term goals, often at the expense of long-term evolvability and maintainability. These decisions, analogous to financial debt, incur principal and interest over time, which can negatively affect various aspects of software development, and especially making changes either for implementing new features or for fixing bugs. Therefore, effective management of technical debt is crucial to ensure software health in the long run.One way to manage technical debt is by identifying and documenting it explicitly within various software artifacts. This category of technical debt is known as Self-Admitted Technical Debt (SATD), where developers use textual artifacts, such as source code comments, commit messages, issue tracking systems, and pull requests, to indicate the presence of technical debt and its possible consequences. For example, a developer may write a code comment like "TODO: this method needs refactoring" to admit that the current code is not optimal and requires improvement in the future. By identifying and analyzing SATD, developers can gain insights into the technical debt landscape of a software system and take appropriate actions to address it.Despite the prevalence and importance of technical debt in software development, current research and practice on managing technical debt, especially SATD, are inadequate. Existing approaches mainly focus on identifying SATD from source code comments, neglecting other textual artifacts that contain valuable information about SATD, such as issues, commit messages, and pull requests. This oversight leads to undetected SATD accumulation, which can potentially spiral out of control and threaten software quality and sustainability. Moreover, code comments often lack essential contextual and repayment information that can help developers understand the rationale, implications, and solutions for SATD. This lack of visibility hinders informed decisions to repay SATD and hides the true status of resolved SATD. Therefore, there is a need for novel and comprehensive approaches to identify, analyze, and repay SATD from various textual artifacts in software projects.To fulfill this objective, as a first step we explore SATD in issue tracking systems before considering multiple sources. By examining SATD in these systems, we can Abstract better comprehend the nature, causes, and repayment of SATD in software projects. To this end, we conducted a qualitative analysis on a sample of 500 issues, identifying and analyzing sentences in issues that refer to SATD. Our research revealed eight types of SATD found in issue trackers: architecture, build, code, defect, design, documentation, requirement, and test debt. We also identified three distinct cases of technical debt identification in issue trackers, with only a small fraction (13.1%) of technical debt being recognized by its creators. Interestingly, the majority of SATD was repaid primarily by those who identi...

show abstract

How does Technical Debt Evolve within Pull Requests? An Empirical Study with Apache Projects

Calixto,

Araújo,

Alves

2024

Anais Do XXXVIII Simpósio Brasileiro De Engenharia De Software (SBES 2024)

View full text Add to dashboard Cite

Technical Debt (TD) refers to the cost to rectify the quality issues affecting a software system. A pull request (PR) represents a discrete unit of work that must adhere to particular quality standards to be integrated into the main codebase. They can serve as a means to gauge how developers address TD and how codebase quality may decay over time. In this work, we present an empirical study on 12 Apache Java repositories, analyzing 2,035 PRs to examine how TD evolves within them. Using the SonarQube tool, we evaluated (i) how TD changes within PRs and (ii) which types of TD issue are most frequently overlooked and resolved. Our results suggest that TD issues are prevalent in PRs, with a tendency to follow a ratio of 1:2:1 (reduced: unchanged: increased). Furthermore, across all issues, we found that the most frequently overlooked are related to code duplication and cognitive complexity, while the most resolved ones include code duplication and obsolete code. These insights can help practitioners become more aware and might inspire the creation of new tools that make managing TD during PRs easier.

show abstract

The SQALE Quality and Analysis Models for Assessing the Quality of Ada Source Code

Cited by 3 publications

References 2 publications

Understanding the impact of technical debt in coding and testing

Understanding the impact of technical debt in coding and testing

Management of Self-Admitted Technical Debt using Machine Learning

How does Technical Debt Evolve within Pull Requests? An Empirical Study with Apache Projects

Contact Info

Product

Resources

About