Examining the Impact of Self-Admitted Technical Debt on Software Quality

Author(s):  
Sultan Wehaibi ◽  
Emad Shihab ◽  
Latifa Guerrouj
Algorithms ◽  
2020 ◽  
Vol 13 (7) ◽  
pp. 168
Author(s):  
Lerina Aversano ◽  
Martina Iammarino ◽  
Mimmo Carapella ◽  
Andrea Del Vecchio ◽  
Laura Nardi

The technical debt (TD) in a software project refers to the adoption of an inadequate solution from its design to the source code. When developers admit the presence of technical debt in the source code, through comments or commit messages, it is called self-admitted technical debt (SATD). This aspect of TD has been the subject of numerous research studies, which have investigated its distribution, the impact on software quality, and removal. Therefore, this work focuses on the relationship between SATD and TD values. In particular, the study aims to compare the admitted technical debt with respect to its objective measure. In fact, the trends of TD values during SATD removals have been studied. This was done thanks to the use of an SATD dataset and their related removals in four open source projects. Instead, the SonarQube tool was used to measure TD values. Thanks to this work, it turned out that SATD removals in a few cases correspond to an effective reduction of TD values, while in numerous cases, the classes indicated are removed.


2013 ◽  
Vol 24 (4) ◽  
pp. 26-50 ◽  
Author(s):  
Xihui Zhang ◽  
Jasbir S. Dhaliwal ◽  
Mark L. Gillenson ◽  
Thomas F. Stafford

The primary role of testers is to verify and validate the software produced by developers to ensure its quality. Testing is designed to catch problems in the software and report them for correction, so it is a conflict-laden, confrontational, and judgmental process. This “audit” role of testing is inherently adversarial, ensuring the development of components of interpersonal conflict judgments between developers and testers. Prior research indicates that such conflict is likely to be negatively associated with software quality and job satisfaction, producing negative judgments about the artifact production process and about the job itself. This study addresses the question: How do judgments of conflict between developers and testers impact the software development process? The authors develop and empirically test a research model which proposes that the conflict judgment targets of both the tasks and the persons who perform them will have direct impact on both software quality and job satisfaction judgments. Results of testing this model indicate that interpersonal judgments arising from conflict, as well as judgments made by testers and developers about the conflict targets of tasks and persons negatively influence subsequent software quality and job satisfaction judgments. Implications for theory and practice are discussed.


Author(s):  
Atrin Barzegar

The success of a software product depends on several factors. Given that different organizations and institutions use software products, the need to have a quality and desirable software according to the goals and needs of the organization makes measuring the quality of software products an important issue for most organizations and institutions. To be sure of having the right software. It is necessary to use a standard quality model to examine the features and sub-features for a detailed and principled study in the quality discussion. In this study, the quality of Word software was measured. Considering the importance of software quality and to have a good and usable software in terms of quality and measuring the quality of software during the study, experts and skilled in this field were used and the impact of each factor and quality characteristics. It was applied at different levels according to their opinion to make the result of measuring the quality of Word software more accurate and closer to reality. In this research, the quality of the software product is measured based on the fuzzy inference system in ISO standard. According to the results obtained in this study, it is understood that quality is a continuous and hierarchical concept and the quality of each part of the software at any stage of production can lead to high quality products.


Author(s):  
Amanda Damasceno Santana ◽  
Eduardo Figueiredo

When a system evolution is not planned, developers can take decisions that degrade the system quality. To cope with this problem, refactoring can be applied to the source code aiming to increase code quality without modifying the software external behavior. To know when to refactor, the concept of bad smells can be used. Bad smells are snippets of source code that suggest the need of refactoring. However, bad smells does not always appear isolated. The aim of this study is to understand the impact of bad smell agglomerations on the software quality by evaluating a large dataset of open source systems. To achieve our goal, we plan to use data mining techniques complemented with correlation analysis of the dataset.


Sign in / Sign up

Export Citation Format

Share Document