scholarly journals A study on the evolution of software quality and technical debt in open source applications

2020 ◽  
Author(s):  
Θεόδωρος Αμανατίδης

Σχεδόν όλα τα συστήματα λογισμικού εξελίσσονται συνεχώς για να ικανοποιήσουν νέες ανάγκες και να προσαρμοστούν στις μεταβαλλόμενες απαιτήσεις της εποχής. Η ανάλυση εξέλιξης λογισμικού μπορεί να αποκαλύψει σημαντικές πληροφορίες σχετικά με τις πρακτικές συντήρησης που ακολουθούνται από τις ομάδες προγραμματιστών. Ο στόχος της διδακτορικής διατριβής είναι να μελετήσει την εξέλιξη των εφαρμογών ανοικτού κώδικα διερευνώντας την εξέλιξη της ποιότητας του λογισμικού καθώς και του κόστους συντήρησης, όπως αποτυπώνεται από τη έννοια του Τεχνικού Χρέους (ΤΧ). Το Τεχνικό Χρέος είναι μια έννοια στον προγραμματισμό που αντικατοπτρίζει την επιπλέον προσπάθεια συντήρησης που προκύπτει όταν αναπτύσσεται «μη-βέλτιστος» κώδικας, που είναι εύκολο να παραδοθεί γρήγορα, αντί να εφαρμόζονται οι βέλτιστες πρακτικές. Η διατριβή διερευνά την διαχρονική εξέλιξη ενός μεγάλου αριθμού εφαρμογών ανοιχτού κώδικα. Οι εφαρμογές αναλύθηκαν στο πλαίσιο των οκτώ (8) νόμων του Lehman περί εξέλιξης λογισμικού και ειδικότερα, εξετάστηκε εάν οι νόμοι επιβεβαιώνονται στην πράξη για διαδικτυακές εφαρμογές ανοιχτού κώδικα. Οι οκτώ νόμοι του Lehman αναφορικά είναι: Συνεχής Αλλαγή (Νόμος I), Αυξανόμενη Πολυπλοκότητα (Νόμος II), Αυτορρύθμιση (Νόμος III), Διατήρηση της Οργανωτικής Σταθερότητας (Νόμος IV), Διατήρηση της Eξοικείωσης (Νόμος V), Συνεχής Ανάπτυξη (Νόμος VI) Φθίνουσα Ποιότητα (VII) και Σύστημα Ανατροφοδότησης (VIII). Τα αποτελέσματα παρέχουν ευρήματα ότι η εξέλιξη των διαδικτυακών εφαρμογών συμμορφώνεται με τους περισσότερους νόμους. Τα τελευταία χρόνια, η έννοια του ΤΧ έχει γνωρίσει αυξανόμενη προσοχή από την ερευνητική κοινότητα. Συγκεκριμένα, μεγάλο μέρος των ερευνητικών μελετών επικεντρώθηκε στην έννοια του επιτοκίου Τεχνικού Χρέους, το οποίο αντικατοπτρίζει την πρόσθετη προσπάθεια συντήρησης που προκύπτει λόγω της ύπαρξης μη-βέλτιστου λογισμικού (δηλαδή, λόγω της ύπαρξης τεχνικού χρέους). Ακολουθώντας τις τάσεις της σύγχρονης έρευνας στη διαχείριση του TD, η διατριβή είχε ως στόχο τη διερεύνηση του αντίκτυπου του ΤΧ στη διορθωτική συντήρηση και συγκεκριμένα, σε ποιο βαθμό η παρουσία του ΤΧ καθυστερεί τον ρυθμό ανάπτυξης του λογισμικού αυξάνοντας τον χρόνο και την προσπάθεια που απαιτείται για τη διόρθωση σφαλμάτων. Παρόλο που το ΤΧ εκτιμάται και ποσοτικοποιείται συνήθως είτε σε ολόκληρο το σύστημα είτε σε μεμονωμένες μονάδες λογισμικού (αρχεία ή κλάσεις), η πραγματική αιτία για την συσσώρευση του ΤΧ είναι οι ίδιοι οι προγραμματιστές μέσω των πρακτικών που ακολουθούν κατά την ανάπτυξη κώδικα. Έτσι, η διατριβή επιχειρεί να διερευνήσει τη σχέση μεταξύ των χαρακτηριστικών των προγραμματιστών και της τάσης που έχουν να εισαγάγουν ΤΧ στο λογισμικό. Παρά το γεγονός ότι το ΤΧ έχει καθιερωθεί στην κοινότητα της Τεχνολογίας Λογισμικού, παραμένει μια μεταφορά και όπως όλες οι μεταφορές, αποτελεί μια αφηρημένη έννοια. Αυτό σημαίνει ότι ο τρόπος που ορίζεται και ερμηνεύεται από τους μηχανικούς λογισμικού είναι υποκειμενικός. Κάθε προγραμματιστής έχει τη δική του αντίληψη σχετικά με την σοβαρότητα του ΤΧ που εντοπίζεται στο λογισμικό του. Υπάρχουν πολλές φωνές που αμφισβητούν την εγκυρότητα του τρόπου ανίχνευσης και υπολογισμού του ΤΧ με τη χρήση αυτοματοποιημένων εργαλείων στατικής ανάλυσης (static analysis of source code). Με αφορμή τα παραπάνω, στο πλαίσιο αυτής της διατριβής εστάλη μια έρευνα σε ένα μεγάλο αριθμό προγραμματιστών που εμπλέκονται στην ανάπτυξη διαδικτυακών εφαρμογών ανοιχτού κώδικα. Η έρευνα, που είχε την μορφή online ερωτηματολογίου, στόχο είχε να αντλήσει πληροφορίες σχετικά με τους παράγοντες που οδηγούν τους προγραμματιστές να αποδεχτούν ή να απορρίψουν διορθώσεις που προτείνονται από αυτοματοποιημένα εργαλεία μέτρησης ΤΧ. Τα υπάρχοντα εργαλεία αξιολόγησης ΤΧ ακολουθούν διαφορετική προσέγγιση και κανόνες για την ποσοτικοποίηση του ΤΧ το καθένα. Κατά συνέπεια, το κάθε εργαλείο παράγει διαφορετικά αποτελέσματα από τα άλλα με αποτέλεσμα να μην υπάρχει μία αντικειμενική βάση για τα ποιο εργαλείο παράγει τα πιο ρεαλιστικά αποτελέσματα. Η προτεινόμενη διατριβή, προσπαθώντας να προσφέρει μία λύση στην έλλειψη της αντικειμενικότητας γύρω από την μέτρηση του ΤΧ, επιχειρεί να εντοπίσει σύνολα αρχείων/κλάσεων στα οποία εντοπίστηκε υψηλό ΤΧ ταυτόχρονα από τρία (3) ευρέως χρησιμοποιούμενα εργαλεία ΤΧ (CAST AIP, Squore και SonarQube). Αυτά τα αρχεία/κλάσεις υψηλού ΤΧ μπορούν να αποτελέσουν σημείο αναφοράς επικυρωμένων μονάδων υψηλού ΤΧ και με αυτόν τον τρόπο μπορεί να δημιουργηθεί μια βάση που θα συνδράμει στην κατάρτιση πιο εξελιγμένων τεχνικών αναγνώρισης ΤΧ. Παράλληλα, η διατριβή προτείνει μια στατιστική μεθοδολογία για την έγκυρη εξαγωγή του προαναφερόμενου συνόλου αρχείων/κλάσεων με υψηλό ΤΧ.

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.


Author(s):  
Himanshi Vashisht ◽  
Sanjay Bharadwaj ◽  
Sushma Sharma

Code refactoring is a “Process of restructuring an existing source code.”. It also helps in improving the internal structure of the code without really affecting its external behaviour”. It changes a source code in such a way that it does not alter the external behaviour yet still it improves its internal structure. It is a way to clean up code that minimizes the chances of introducing bugs. Refactoring is a change made to the internal structure of a software component to make it easier to understand and cheaper to modify, without changing the observable behaviour of that software component. Bad smells indicate that there is something wrong in the code that have to refactor. There are different tools that are available to identify and emove these bad smells. A software has two types of quality attributes- Internal and external. In this paper we will study the effect of clone refactoring on software quality attributes.


2022 ◽  
Vol 31 (2) ◽  
pp. 1-23
Author(s):  
Jevgenija Pantiuchina ◽  
Bin Lin ◽  
Fiorella Zampetti ◽  
Massimiliano Di Penta ◽  
Michele Lanza ◽  
...  

Refactoring operations are behavior-preserving changes aimed at improving source code quality. While refactoring is largely considered a good practice, refactoring proposals in pull requests are often rejected after the code review. Understanding the reasons behind the rejection of refactoring contributions can shed light on how such contributions can be improved, essentially benefiting software quality. This article reports a study in which we manually coded rejection reasons inferred from 330 refactoring-related pull requests from 207 open-source Java projects. We surveyed 267 developers to assess their perceived prevalence of these identified rejection reasons, further complementing the reasons. Our study resulted in a comprehensive taxonomy consisting of 26 refactoring-related rejection reasons and 21 process-related rejection reasons. The taxonomy, accompanied with representative examples and highlighted implications, provides developers with valuable insights on how to ponder and polish their refactoring contributions, and indicates a number of directions researchers can pursue toward better refactoring recommenders.


2021 ◽  
Author(s):  
Jenifer Tabita Ciuciu-Kiss ◽  
Melinda Tóth ◽  
István Bozó

Static source code analyser tools are operating on an intermediate representation of the source code that is usually a tree or a graph. Those representations need to be updated according to the different versions of the source code. However, the developers might be interested in the changes or might need information about previous versions, therefore, keeping different versions of the source code analysed by the tools are required. RefactorErl is an open-source static analysis and transformation tool for Erlang that uses a graph representation to store and manipulate the source code. The aim of our research was to create an extension of the Semantic Program Graph of RefactorErl that is able to store different versions of the source code in a single graph. The new method resulted in 30% memory footprint decrease compared to the available workaround solutions.


2021 ◽  

Abstract Many security vulnerabilities can be detected by static analysis. This paper is a case study and a performance comparison of four open-source static analysis tools and plugins (PMD, SpotBugs, Find Security Bugs, and SonarQube) on Java source code. Experiments have been conducted on the widely used Juliet Test Suite with respect to six selected weaknesses from the official Top 25 list of Common Weakness Enumeration. In this study, analysis metrics have been calculated for helping Java developers decide which tools can be used when checking their programs for security vulnerabilities. It turned out that particular weaknesses are best detected with particular tools.


Sign in / Sign up

Export Citation Format

Share Document