Context Possessing up-to-date knowledge, skills and transversal competencies (KSTs) is essential for both the successful delivery of software projects and a career in software engineering (SE). However, the technological landscape is changing rapidly, posing continuous challenges: for professionals entering the market or pivoting careers, for organizations hiring and monitoring workforce expertise and for educational institutes designing or updating their curricula. Objectives We study job requirements within and across SE occupations (Applications Programmers, Software Developers, Systems Analysts, Web and Multimedia Developers) to assist software organizations to better face skill mismatch and skills’ gap problems, software engineers in upskilling and reskilling endeavors and software education institutes in providing more industrially relevant curricula. Method In this study, we leverage a large corpus of online job advertisements, which are jointly collected by CEDEFOP and Eurostat. The dataset is analyzed through the lens of concepts and techniques from the study of biodiversity of species to assess the variation of expertise and identify skills that are transferable or unique in these occupations. Specifically, we adopt established diversity indices, such as alpha diversity, beta diversity, ordination methods, and indicator species analysis, aiming to quantify both the variety of skills within occupations and the differences across them. This approach highlights both the breadth and distinctiveness of expertise across occupations, rendering the biodiversity perspective a central and practical part of our methodology. Results The results reveal that the complete list of KSTs that is used to characterize the profiles of OJAs for SE-related occupations is very broad and that skillset required for each occupation is quite distinct, since there are statistically significant differences in the composition of the skillsets. Transversal Skills and Competences (T) appear to be the most transferable qualification; or “adapt to change” and “work in teams” are the KSTs that appears more uniformly to all studied software occupations, and “computer programming” is the top hard-skill that appears more uniformly to all occupations. However, each occupation shows some specific qualifications. Conclusion The results are contrasted against the literature, are interpreted, various implications to researchers and practitioners are provided, and a retrospective analysis of the tailoring of the biodiversity approach to SE labor landscape is provided. Overall, the proposed biodiversity analysis adds value by providing a novel, theory-driven methodology to assess skill variation, identifying both common and occupation-specific KSTs, and supporting evidence-based workforce and curriculum design.

The use of Generative AI, and more specifically Large-Language Models (LLMs), is becoming an essential aid in the software development process. An increasing number of software engineers are using general-purpose or code-trained LLMs for writing code, formulating requirements or deriving test cases. However, since this practice has come so abruptly into the daily routines of developers, the research community is still lacking an in-depth evaluation of its effectiveness. A major aspect of software engineering using LLMs that is rather unexplored is the quality of the code that is generated. In this paper, we explore the ability of GenAI to assist developers in performing refactoring activities, employing well-established Object-Oriented Programming “ good-practices ” like GoF Design Patterns and SOLID principles. To achieve this goal, we have performed a controlled experiment on junior developers, relying on a cross-over experimental design, and asked them to complete development tasks with and without the use of an LLM. The results suggested that GenAI-Assisted solutions outperformed Humans-Only ones in terms of the correctness of implementing the selected practice (pattern or principle), whereas Humans-Only solutions were superior in cognitive steps of the refactoring process such as the identification of the problem and the compromised quality attributes.

The rapid integration of Artificial Intelligence (AI) – including Machine Learning (ML) and Generative AI – into software systems is reshaping the software development lifecycle. As AI-driven systems become more dynamic and complex, traditional approaches to Technical Debt (TD) management face increasing limitations. Simultaneously, AI-assisted development introduces new forms of TD, particularly in relation to maintainability, explainability, and data governance. This study aims to explore how Technical Debt Management (TDM) must adapt in the context of AI-enhanced software development. It investigates (1) the evolution of TD in AI-driven systems, and (2) the implications of using AI technologies within the software engineering process. We conducted a multivocal literature review, combining insights from both peer-reviewed research and industry sources. Following established guidelines, we systematically analyzed 61 primary sources, categorized TD types and management activities, and identified key challenges and practices emerging in the AI era. Our findings reveal that data-related, infrastructure, and pipeline-related TD are particularly prevalent in ML systems. Machine Learning Operations (MLOps) practices are increasingly recognized as essential for managing such debt, especially in relation to dynamic data dependencies and model retraining. In parallel, AI-generated artifacts and automated pipelines introduce new governance and maintainability challenges. Technical Debt in AI systems demands continuous, automated, and cross-functional management strategies. As software evolves in response to data and usage, new operational paradigms – grounded in practices like MLOps and Small Language Model Operations (SLMOps) – will be vital to ensure long-term software sustainability. This study provides a foundational map for researchers and practitioners navigating the intersection of AI and TD management. • Data-centric AI systems introduce new forms of TD in data, infrastructure, and governance. • MLOps is often assumed in research, while its practices and security concerns are overlooked. • Gray literature captures real-world data debt practices absent in academic sources. • Prompt and explainability debt are rising issues in GenAI with little formal support. • SLMOps may offer future-ready frameworks for managing lightweight AI pipelines.

Software artifacts and source code are often viewed as pure technical constructs aiming primarily at delivering specific functionality to the end users. However, almost each line of a computer program is the result of software engineer’s craftsmanship and thus reflects their skills and capabilities, but also their aesthetic view of how code should be written. Additionally, by nature, the code is not an artifact that is managed by a single person: the code is peer-reviewed, in some cases programmed in pairs, or maintained by different people. In this respect, the first impression for the quality of a code is usually a matter of “ reading ” the “ beauty ” of the code and then diving into the details of the actual implementation. This “ first-look ” impression can psychologically bias the software engineers, either positively or negatively and affect their evaluation. In this article we propose a novel code beauty model (accompanied with metrics) and empirically explore: (a) if different software engineers perceive code beauty in the same way; (b) if the proposed code beauty metrics are correlated to the perceived code beauty by individual software engineers; and (c) if code beauty metrics are correlated to software maintainability. The results of the study suggest: (a) that code beauty is highly subjective and different software engineers perceive a code chunk as beautiful or not in an inconsistent way; (b) that some code beauty metrics can be considered as correlated to maintainability; and therefore, the “ first-look ” impression might to some extent be representative of the quality of the reviewed code chunk.

ABSTRACT Although JavaScript dominates modern software development, research on its quality attributes remains scarce, despite the fundamental differences that distinguish it from other languages. This motivates dedicated research related to JavaScript quality attributes and metrics. This paper aims to identify (a) the quality attributes of the JavaScript language that are mainly studied and (b) the quality metrics that are used to quantify them. Additionally, the paper provides information on the tools that can be used to measure quality metrics. To achieve these goals, we have conducted a mapping study on seven journals and eight conferences of high quality. A total of 142 primary studies, published between 2002 and February 2025, have been selected and analyzed, to identify and classify software metrics to high‐level quality attributes, as described in ISO/IEC 25010:2011. Maintainability, Security, Reliability, and Usability quality attributes are the most studied ones. Furthermore, 78 generic and 48 JavaScript‐specific metrics were identified. A wide dispersion of metrics has been identified for assessing each quality attribute, based on different development tasks. Moreover, a variety of tools and benchmarks were identified. A clear research trend in JavaScript quality assessment related to issues that involve software reuse, code testing, and dynamic code analysis has been identified. Yet differences among primary studies in quality assessment and quantification, along with tool adoption indicate the need for further exploration of these recurring topics.

In recent years, the game industry has experienced significant growth from both a financial and a social viewpoint. Developing compelling games that rely on novel content is a challenge for 3-D firms, especially in terms of meeting the diverse expectations of end users. Game development is performed by multidisciplinary teams of professionals, in which game/level designers play a crucial role. Inevitably, they often depend on programmers for technical implementations creating bottlenecks, even for prototyping purposes. This issue has raised the need for introducing efficient low-code environments that empower individuals without programming expertise to develop 3-D games. This work introduces Codeless3D, a prototype for low-code 3-D game creation by nonprogrammers. The proposed approach and the tool aim to reduce design and development time, bridging the gap between conceptualization and production. To evaluate the usefulness of Codeless3D, in terms of usability and its vision, an evaluation study was conducted. The findings suggested that Codeless3D effectively reduces design and development time for stakeholders in the game development field. Overall, this article contributes to the emerging trend of low-code tools in the entertainment domain and offers insights for further improvements in game design and development processes.

The rise of Large Language Models (LLMs) has provided new directions for addressing downstream text classification tasks, such as vulnerability prediction, where segments of the source code are classified as vulnerable or not. Several recent studies have employed transfer learning in order to enhance vulnerability prediction taking advantage of the prior knowledge of the pre-trained LLMs. In the current study, different Transformer-based pre-trained LLMs are examined and evaluated with respect to their capacity to predict vulnerable software components. In particular, we fine-tune BERT, GPT-2, and T5 models, as well as their code-oriented variants namely CodeBERT, CodeGPT, and CodeT5 respectively. Subsequently, we assess their performance and we conduct an empirical comparison between them to identify the models that are the most accurate ones in vulnerability prediction.

Software artifacts and source code are often viewed as pure technical constructs aiming primarily at delivering specific functionality to the end users. However, almost each line of a computer program is the result of developers' craftsmanship and thus reflects their skills and capabilities, but also their aesthetic view of how code should be written. Additionally, by nature, the code is not an artifact that is managed by a single person: the code is peer-reviewed, in some cases programmed in pairs, or maintained by different people. In this respect, the first impression for the quality of a code is usually a matter of "reading" the aesthetics of the code and then, diving into the details of the actual implementation. This "first-look" impression can psychologically bias the software engineer, either positively or negatively and affect his/her evaluation. In this article we investigate whether code beauty (or code aesthetics) must be valued in software programs, as a proxy to the quality of the code. Specifically, we attempt to relate the notion of code beauty with code quality metrics. For this purpose, we catalogued existing beauty measures (assessing the aesthetics of images, objects, and alphanumeric displays), tailored them to match code beauty, and correlated them to structural properties that are related to Technical Debt Interest (such as coupling, cohesion, etc.). The results of the study suggest that some code beauty metrics can be considered as correlated to TD Interest; and therefore, the "first-look" impression might to some extent be representative of the quality of the reviewed code chunk.

Service-Oriented Architectures (SOA) have become a standard for developing software applications, including but not limited to cloud-based ones and enterprise systems. When using SOA, software engineers organize the desired functionality into self-contained and independent services that are invoked through end-points (with API calls). The use of this emerging technology has changed drastically the way that software reuse is performed, in the sense that a “ service ” is a “ code chunk ” that is reusable (preferably in a black-box manner), but in many (especially “ in-house ”) cases, white-box reuse is also meaningful. To confront the reuse challenges opened-up by the rise of SOA, in the SmartCLIDE project 1 we have developed a framework (a methodology and a platform) to aid software engineers in systematic and more efficient (in terms of time, quality, defects, and process) reuse of services, when developing SOA-based cloud applications. In this work, we: (a) present the SmartCLIDE methodology and the Eclipse Open SmartCLIDE platform; and (b) evaluate the usefulness of the framework, in terms of relevance, usability, and obtained benefits. The results of the study have confirmed the relevance and rigor of the framework, unveiled some limitations, and pointed to interesting future work directions, but also provided some actionable implications for researchers and practitioners.

Abstract Monitoring technical debt (TD) is considered highly important for software companies, as it provides valuable information on the effort required to repay TD and in turn maintain the system. When it comes to TD repayment, however, developers are often overwhelmed with a large volume of TD liabilities that they need to fix, rendering the procedure effort demanding. Hence, prioritizing TD liabilities is of utmost importance for effective TD repayment. Existing approaches rely on the current TD state of the system; however, prioritization would be more efficient by also considering its future evolution. To this end, the present work proposes a practical approach for prioritization of TD liabilities by incorporating information retrieved from TD forecasting techniques, emphasizing on the class‐level granularity to provide highly actionable results. Specifically, the proposed approach considers the change proneness and forecasted TD evolution of software artifacts and combines it with proper visualization techniques, to enable the early identification of classes that are more likely to become unmaintainable. To demonstrate and evaluate the approach, an empirical study is conducted on six real‐world applications. The proposed approach is expected to facilitate developers better plan refactoring activities, in order to manage TD promptly and avoid unforeseen situations long term.

In recent years, we have witnessed an important increase in research focusing on how machine learning (ML) techniques can be used for software quality assessment and improvement. However, the derived methodologies and tools lack transparency, due to the black-box nature of the employed machine learning models, leading to decreased trust in their results. To address this shortcoming, in this paper we extend the state-of-the-art and -practice by building explainable AI models on top of machine learning ones, to interpret the factors (i.e. software metrics) that constitute a module as in risk of having high technical debt (HIGH TD), to obtain thresholds for metric scores that are alerting for poor maintainability, and finally, we dig further to achieve local interpretation that explains the specific problems of each module, pinpointing to specific opportunities for improvement during TD management. To achieve this goal, we have developed project-specific classifiers (characterizing modules as HIGH and NOT-HIGH TD) for 21 open-source projects, and we explain their rationale using the SHapley Additive exPlanation (SHAP) analysis. Based on our analysis, complexity, comments ratio, cohesion, nesting of control flow statements, coupling, refactoring activity, and code churn are the most important reasons for characterizing classes as in HIGH TD risk. The analysis is complemented with global and local means of interpretation, such as metric thresholds and case-by-case reasoning for characterizing a class as in-risk of having HIGH TD. The results of the study are compared against the state-of-the-art and are interpreted from the point of view of both researchers and practitioners.

One of the most well-known laws of software evolution suggests that code quality deteriorates over time. Following this law, recent empirical studies have brought evidence that Technical Debt (TD) Principal tends to increase (in absolute value) as the system grows, since more technical debt issues are added than resolved over time. To shed light into how technical debt accumulation occurs in practice, in this paper we explore specific maintenance activities (i.e., feature addition, bug fixing, and refactoring) and explore the balance between the technical debt that they introduce or resolve. To achieve this goal, we rely on studying Pull Requests (PR), which are the most established way to contribute code to an open-source project. A Pull Request is usually comprised by more than one commits, corresponding to a specific development / maintenance activity. In our study, we categorized Pull Requests, based on their labels, to find the effect that the different maintenance activities have on the accumulation of technical debt across evolution. In particular, we have analysed more than 13.5K pull requests (mined from 10 OSS projects), by calculating the TD Principal (calculated through SonarQube) before and after the Pull Requests. The results of the study suggested that several labels are used for tagging Pull Requests, out of which the most prevalent ones are new features, bug fixing, and refactoring. The effect of these activities on TD Principal accumulation is statistically different, and: (a) the addition of features tends to increase TD Principal; (b) refactoring is having an almost consistent positive effect (reducing TD Principal); and (c) bug fixing activity has undecisive impact on TD Principal. These results are compared to existing studies, interpreted, and various useful implications for researchers and practitioners have been drawn.

Decision making pervades software and systems engineering. Intertemporal decisions involve trade-offs among outcomes at different points in time. They play a central role in systems design, as recognised since the inception of the software engineering (SE) field. They are also crucial for the sustainability of design decisions. However, temporal decision making is not adequately understood in SE. The field of Judgement and Decision Making (JDM) offers important empirical findings and research methods that could be utilised. This article establishes a baseline for studying how software professionals handle intertemporal choices. It examines how temporal distance affects choices in an example scenario, explores in what areas of software development such decisions can be found, and examines how systems design decisions can be characterised and studied as intertemporal. We developed a method to study intertemporal choice in SE, based on an initial set of psychological theory grounded in JDM. We instantiated the method in a study to elicit responses to an intertemporal choice task followed by a Cognitive Task Analysis (CTA) interview. We found that study participants overall tended to discount future outcomes, but individual participants varied wildly in how they valued present vs. future outcomes. They indicated several locations in which intertemporal choices occur in everyday software development. Based on these findings, and by reconciling our initial theory with existing JDM theory and results, we further developed and refined our theory and study method into a framework for studying intertemporal decision making in SE. To obtain a basis for more sustainable software systems design decisions, SE research should adopt a more comprehensive, detailed, and empirically consistent way of understanding and studying intertemporal choices. We provide suggestions for how future research could achieve practical methods that address essential characteristics of real-life systems design decisions.

Abstract Design patterns are well‐known solutions to recurring design problems that are widely adopted in the software industry, either as formal means of communication or as a way to improve structural quality, enabling proper software extension. However, the adoption and correct instantiation of patterns is not a trivial task and requires substantial design experience. Some patterns are conceptually close or present similar design alternatives, leading novice developers to improper pattern selection, thereby reducing maintainability. Additionally, the mis‐instantiation of a GoF (Gang‐of‐Four) design pattern, leads to phenomena such as pattern grime or architecture decay. To alleviate this problem, in this work we propose an approach that can help software engineers to more easily and safely select the proper design pattern, for a given design problem. The approach relies on decision trees, which are constructed using domain knowledge, while options are conveyed to software engineers through an Eclipse Theia plugin. To assess the usefulness and the perceived benefits of the approach, as well as the usability of the tool support, we have conducted an industrial validation study, using various data collection methods, such as questionnaires, focus groups, and task analysis. The results of the study suggest that the proposed approach is promising, since it increases the probability of the proper pattern being selected, and various useful future work suggestions have been obtained by the practitioners.

Quality improvement can be performed at the: (a) micro-management level: interventions applied at a fine-grained level (e.g., at a class or method level, by applying a refactoring); or (b) macro-management level: interventions applied at a large-scale (e.g., at project level, by using a new framework or imposing a quality gate). By considering that the outcome of any activity can be characterized as the product ofimpactandscale, in this paper we aim at exploring the impact of Technical Debt (TD) Macro-Management, whose scale is by definition larger than TD Micro-Management. By considering that TD artifacts reside at the micro-level, the problem calls for a nested model solution; i.e., modeling the structure of the problem: artifacts have some inherent characteristics (e.g., size and complexity), but obey the same project management rules (e.g., quality gates, CI/CD features, etc.). In this paper, we use the Under-Bagging based Generalized Linear Mixed Models approach, to unveil project management activities that are associated with the existence of HIGH_TD artifacts, through an empirical study on 100 open-source projects. The results of the study confirm that micro-management parameters are associated with the probability of a class to be classified as HIGH_TD, but the results can be further improved by controlling some project-level parameters. Based on the findings of our nested analysis, we can advise practitioners on macro-technical debt management approaches (such as “control the number of commits per day”, “adopt quality control practices”, and “separate testing and development teams”) that can significantly reduce the probability of all software artifacts to concentrate HIGH_TD. Although some of these findings are intuitive, this is the first work that delivers empirical quantitative evidence on the relation between TD values and project- or process-level metrics.

JavaScript (JS) is one of the most popular programming languages for developing client-side applications mainly due to allowing the adoption of different programming styles, not having strict syntax rules, and supporting a plethora of frameworks. The flexibility that the language provides may accelerate the development of application, but also pose threats to the quality of the final software product, e.g., introducing Technical Debt (TD). TD reflects the additional cost of software maintenance activities to implement new features, occurring due to poorly developed solutions. Being able to forecast the levels of TD in the future can be extremely valuable in managing TD, since it can contribute to informed decision making when designating future repayments and refactoring budget among a company's projects. Despite the popularity of JS and the undoubtful benefits of accurate TD forecasting, in the literature, there is available only a limited number of tools and methodologies that are able to: (a) forecast TD during software evolution, (b) provide a ground-truth TD quantifications to train forecasting, since TD tools that are available are based on different rulesets and none is recognized as a state-of-the-art solution, (c) take into consideration the language-specific characteristics of JS. As a main contribution for this study, we propose a methodology (along with a supporting tool) that supports the aforementioned goals based on the Backward Stepwise Regression and Auto-Regressive Integrated Moving Average (ARIMA). We evaluate the proposed approach through a case study on 19,636 releases of 105 open-source applications. The results point out that: (a) the proposed model can lead to an accurate prediction of TD, and (b) the Number of appearances of the “new” and “eval” keyword along with the number of “anonymous” and “arrow” functions are among the features of JavaScript language that are related to high levels of TD.

Developing modern secure and low-energy applications in a short time imposes new challenges and creates the need of designing new software tools to assist developers in all phases of application development. The design of such tools cannot be considered a trivial task, as they should be able to provide optimization of multiple quality requirements. In this paper, we introduce the SDK4ED platform, which incorporates advanced methods and tools for measuring and optimizing maintainability, dependability and energy. The presented solution offers a com-plete tool-flow for providing indicators and optimization meth-ods with emphasis on embedded software. Effective forecasting models and decision-making solutions are also implemented to improve the quality of the software, respecting the constraints imposed on maintenance standards, energy consumption limits and security vulnerabilities. The use of the SDK4ED platform is demonstrated in a healthcare embedded application.

Developing software based on services is one of the most emerging programming paradigms in software development. Service-based software development relies on the composition of services (i.e., pieces of code already built and deployed in the cloud) through orchestrated API calls. Black-box reuse can play a prominent role when using this programming paradigm, in the sense that identifying and reusing already existing/deployed services can save substantial development effort. According to the literature, identifying reusable assets (i.e., components, classes, or services) is more successful and efficient when the discovery process is domain-specific. To facilitate domain-specific service discovery, we propose a service classification approach that can categorize services to an application domain, given only the service description. To validate the accuracy of our classification approach, we have trained a machine-learning model on thousands of open-source services and tested it on 67 services developed within two companies employing service-based software development. The study results suggest that the classification algorithm can perform adequately in a test set that does not overlap with the training set; thus, being (with some confidence) transferable to other industrial cases. Additionally, we expand the body of knowledge on software categorization by highlighting sets of domains that consist ‘grey-zones’ in service classification.

Despite the attention that Technical Debt has attracted over the last years, the quantification of TD Interest still remains rather vague (and abstract). TD Interest quantification is hindered by various factors that introduce a lot of uncertainty, such as: identifying the parts of the system that will be maintained, quantifying the load of maintenance, as well as the size of the maintenance penalty, due to the existence of TD. In this study, we aim to shed light on the current approaches for quantifying TD Interest by exploring existing literature within the TD and Maintenance communities. To achieve this goal, we performed a systematic mapping study on Scopus and explored: (a) the existing approaches for quantifying TD Interest; (b) the existing approaches for estimating Maintenance Cost; and (c) the factors that must be taken into account for their quantification. The broad search process has returned more than 1,000 articles, out of which only 25 provide well-defined mathematical formulas/ equations for the quantification of TD Interest or Maintenance Cost (only 6 of them are explicitly for TD Interest). The results suggest that despite their similarities, the quantification of TD Interest presents additional challenges compared to Maintenance Cost Estimation, constituting (at least for the time being) the accurate quantification of TD Interest an open and distant to solve research problem. Regarding the factors that need to be considered for such an endeavor, based on the literature: size, complexity, and business parameters are those that are more actively associated to TD Interest quantification.

Technical Debt estimation relies heavily on the use of static analysis tools looking for violations of pre-defined rules. Largely, Technical Debt principal is attributed to the presence of low-level code smells, unavoidably tying the effort for fixing the problems with mere coding inefficiencies. At the same time, despite their simple definition, the detection of most code smells is non-trivial and subjective, rendering the assessment of Technical Debt principal dubious. To this end, we have revisited the literature on code smell detection approaches backed by tools and developed an Eclipse plugin that incorporates six code smell detection approaches. The combined application of various smell detectors can increase the certainty of identifying actual code smells that matter to the development team. We also conduct a case study to investigate the agreement among the employed code smell detectors. To our surprise the level of agreement is quite low even for relatively simple code smells, threating the validity of existing TD analysis tools and calling for increased attention to the precise specification of code and design level issues.

To date, the identification and quantification of Technical Debt (TD) rely heavily on a few sophisticated tools that check for violations of certain predefined rules, usually through static analysis. Different tools result in divergent TD estimates calling into question the reliability of findings derived by a single tool. To alleviate this issue, we present a tool that employs machine learning on a dataset built upon the convergence of three widely-adopted TD Assessment tools to automatically assess the class-level TD for any arbitrary Java project. The proposed tool is able to classify software classes as high-TD or not, by synthesizing source code and repository activity information retrieved by employing four popular open source analyzers. The classification results are combined with proper visualization techniques, to enable the identification of classes that are more likely to be problematic. To demonstrate the proposed tool and evaluate its usefulness, a case study is conducted based on a real-world open-source software project. The proposed tool is expected to facilitate TD management activities and enable further experimentation through its use in an academic or industrial setting.

Abstract Technical debt management is of paramount importance for the software industry, since maintenance is the costlier activity in the software development lifecycle. In this article, we present the SDK4ED platform that enables efficient technical debt management (i.e., measurement, evolution analysis, prevention, etc.) at the code level, and evaluate its capabilities in an industrial setting. The SDK4ED platform is the outcome of a 3‐year project, including several software industries. Since, the research rigor of the approaches that reside in SDK4ED have already been validated, in this work we focus: (a) on the presentation of the platform per se; (b) the evaluation of its industrial relevance; (c) the usability of the platform; as well as (d) the financial implications of its usage.

While technical debt grows in absolute numbers as software systems evolve over time, the density of technical debt (technical debt divided by lines of code) is reduced in some cases. This can be explained by either the application of refactorings or the development of new artifacts with limited Technical Debt. In this paper we explore the second explanation, by investigating the relation between the amount of Technical Debt in new code and the evolution of Technical Debt in the system. To this end, we compare the Technical Debt Density of new code with existing code, and we investigate which of the three major types of code changes (additions, deletions and modifications) is primarily responsible for changes in the evolution of Technical Debt density. Furthermore, we study whether there is a relation between code quality practices and the ‘cleanness’ of new code. To obtain the required data, we have performed a large-scale case study on twenty-seven open-source software projects by the Apache Software Foundation, analyzing 66,661 classes and 56,890 commits. The results suggest that writing “clean” (or at least “cleaner”) new code can be an efficient strategy for reducing Technical Debt Density, and thus preventing software decay over time. The findings also suggest that projects adopting an explicit policy for quality improvement, e.g., through discussions on code quality in board meetings, are associated with a higher frequency of cleaner new code commits. Therefore, we champion the establishment of processes that monitor the density of Technical Debt of new code to control the accumulation of Technical Debt in a software system.

Technical Debt (TD) is a successful metaphor in conveying the consequences of software inefficiencies and their elimination to both technical and non-technical stakeholders, primarily due to its monetary nature. The identification and quantification of TD rely heavily on the use of a small handful of sophisticated tools that check for violations of certain predefined rules, usually through static analysis. Different tools result in divergent TD estimates calling into question the reliability of findings derived by a single tool. To alleviate this issue we use 18 metrics pertaining to source code, repository activity, issue tracking, refactorings, duplication and commenting rates of each class as features for statistical and Machine Learning models, so as to classify them as High-TD or not. As a benchmark we exploit 18.857 classes obtained from 25 Java projects, whose high levels of TD has been confirmed by three leading tools. The findings indicate that it is feasible to identify TD issues with sufficient accuracy and reasonable effort: a subset of superior classifiers achieved an F2-measure score of approximately 0.79 with an associated Module Inspection ratio of approximately 0.10. Based on the results a tool prototype for automatically assessing the TD of Java projects has been implemented.

Context: Making architectural decisions is a crucial task but also very difficult, considering the scope of the decisions and their impact on quality attributes.To make matters worse, architectural decisions need to combine both technical and business factors, which are very dissimilar by nature.Objectives: We provide a cost-benefit approach and supporting tooling that treats architectural decisions as financial investments by: (a) combining both technical and business factors; and (b) transforming the involved factors into currency, allowing their uniform aggregation.Apart from illustrating the method, we validate both the proposed approach and the tool, in terms of fitness for purpose, usability, and potential limitations.Method: To validate the approach, we have performed a case study in a software development company, in the domain of low-energy embedded systems.We employed triangulation in the data collection phase of the case study, by performing interviews, focus groups, an observational session, and questionnaires.Results: The results of the study suggested that the proposed approach: (a) provides a structured process for systematizing decision-making; (b) enables the involvement of multiple stakeholders, distributing the decision-making responsibility to more knowledgeable people; (c) uses monetized representations that are important for assessing decisions in a unified manner; and (d) enables decision reuse and documentation. Conclusions:The results of the study suggest that architectural decision-making can benefit from treating this activity as a financial investment.The various benefits that have been identified from mixing financial and technological aspects are well-accepted from industrial stakeholders.

Background: The development of scientific software applications is far from trivial, due to the constant increase in the necessary complexity of these applications, their increasing size, and their need for intensive maintenance and reuse. Aim: To this end, developers of scientific software (who usually lack a formal computer science background) need to use appropriate software engineering (SE) practices. This paper describes the results of a systematic mapping study on the use of SE for scientific application development and their impact on software quality. Method: To achieve this goal we have performed a systematic mapping study on 359 papers. We first describe a catalogue of SE practices used in scientific software development. Then, we discuss the quality attributes of interest that drive the application of these practices, as well as tentative side-effects of applying the practices on qualities. Results: The main findings indicate that scientific software developers are focusing on practices that improve implementation productivity, such as code reuse, use of third-party libraries, and the application of "good" programming techniques. In addition, apart from the finding that performance is a key-driver for many of these applications, scientific software developers also find maintainability and productivity to be important. Conclusions: The results of the study are compared to existing literature, are interpreted under a software engineering prism, and various implications for researchers and practitioners are provided. One of the key findings of the study, which is considered as important for driving future research endeavors is the lack of evidence on the trade-offs that need to be made when applying a software practice, i.e., negative (indirect) effects on other quality attributes.

Abstract During the last decades, software traceability has been studied in a large number of studies, from different perspectives (e.g., how to create traces and what are its benefits). This large body of knowledge needs to be better explored and exploited by both practitioners and researchers: We need an overview of different aspects of traceability and a structured way to assess and compare existing work in order to extend it with new research or apply it in practice, Thus, we have conducted a secondary study on this large corpus of primary studies, focusing on empirical studies on software traceability, without setting any further restrictions in terms of investigating a specific domain or concrete artifacts. The study explores the goals of existing approaches and the empirical methods used for their evaluation. Its main contributions are the investigation of (a) the type of artifacts linked through traceability approaches; (b) the benefits of using artifact traceability approaches; (c) the ways of measuring their benefit; and (d) the research methods used. The results of the study suggest that (i) requirements artifacts are dominant in traceability; (ii) the research corpus focuses on the proposal of novel techniques for establishing traceability; and (iii) the main benefits are the improvement of software correctness and maintainability. Finally, although many studies include some empirical validation, there is still room for improvements and research methods that can be used more extensively. The obtained results are discussed under the prism of both researchers and practitioners and are compared against the state‐of‐the‐art.

Abstract Game mechanics are high‐level descriptions of common game requirements; however, they do not provide any guidance on their code implementation. Nevertheless, their implementation involves high volumes of essential complexity, which in turn leads to the introduction of accidental complexity (long methods, code repetition, etc.). A possible solution to this problem is to map game mechanics to design patterns, in order to provide template instantiations that handle structural complexity. The aim of this study is twofold: (a) introduce template instantiations of game mechanics with Gang of Four (GoF) patterns and (b) evaluate such mappings in terms of extendibility and reusability. To achieve these objectives, we developed an online repository of mappings between GoF patterns and game mechanics and conducted an experiment to explore the benefits of the mapping. The results of the study suggest that the implementation of game mechanics with GoF patterns is beneficial, because the time to extent the current implementation or reuse code chunks is not prolonged, whereas the implementations are less faulty. Finally, the suggested mapping will equip game mechanics with sample implementations (that adhere to good design principles—ensuring extendibility) that can be reused, acting as a starting point for source code development.

Due to the rapid advancements in the hardware architectures of High-Performance Computing infrastructures, new challenges have arisen in the development of scientific software applications. In particular, software that runs on Exascale machines, needs to be highly portable, highly parallelizable and at the same time maintainable, since software for HPC evolves constantly over time. By taking into account that an overall optimization of all the aforementioned qualities is not realistic, in this study, we explore the possible trade-offs, when optimizing the run-time qualities of the software (i.e., performance and portability) through state-of-practice techniques in Exascale software development, in expense of code maintainability, as expressed by technical debt. To achieve this goal, we have performed a case study, in which the effect of run-time optimizations on technical debt has been measured. The results suggest that run-time optimizations tend to reduce TD principal, whereas the effect on interest is not consistent. The results are discussed in detail in this paper from the point of view of both researchers and practitioners.

A GitHub profile is becoming an essential part of a developer's resume enabling HR departments to extract someone's expertise, through automated analysis of his/her contribution to open-source projects. At the same time, having clear insights on the technologies used in a project can be very beneficial for resource allocation and project maintainability planning. In the literature, one can identify various approaches for identifying expertise on programming languages, based on the projects that developer contributed to. In this paper, we move one step further and introduce an approach (accompanied by a tool) to identify low-level expertise on particular software frameworks and technologies apart, relying solely on GitHub data, using the GitHub API and Natural Language Processing (NLP)---using the Microsoft Language Understanding Intelligent Service (LUIS). In particular, we developed an NLP model in LUIS for named-entity recognition for three (3) .NET technologies and two (2) front-end frameworks. Our analysis is based upon specific commit contents, in terms of the exact code chunks, which the committer added or changed. We evaluate the precision, recall and f-measure for the derived technologies/frameworks, by conducting a batch test in LUIS and report the results. The proposed approach is demonstrated through a fully functional web application named RepoSkillMiner. Tool Links : Video, Code Repo, Application, Validation Dataset

The cornerstones of technical debt (TD) are two concepts borrowed from economics: principal and interest. Although in economics the two terms are related, in TD there is no study on this direction so as to validate the strength of the metaphor. We study the relation between Principal and Interest, and subsequently dig further into the ‘ingredients’ of each concept (since they are multi-faceted). In particular, we investigate if artifacts with similar levels of TD Principal exhibit a similar amount of TD Interest, and vice-versa. To achieve this goal, we performed an empirical study, analyzing the dataset using the Mantel test. Through the Mantel test, we examined the relation between TD Principal and Interest, and identified aspects that are able to denote proximity of artifacts, with respect to TD. Next, through Linear Mixed Effects (LME) modelling we studied the generalizability of the results. The results of the study suggest that TD Principal and Interest are related, in the sense that classes with similar levels of TD Principal tend to have similar levels of Interest. Additionally, we have reached the conclusion that aggregated measures of TD Principal or Interest are more capable of identifying proximate artifacts, compared to isolated metrics. Finally, we have provided empirical evidence on the fact that improving certain quality properties (e.g., size and coupling) should be prioritized while ranking refactoring opportunities in the sense that high values of these properties are in most of the cases related to artifacts with higher levels of TD Principal. The findings shed light on the relations between the two concepts, and can be useful for both researchers and practitioners: the former can get a deeper understanding of the concepts, whereas the latter can use our findings to guide their TD management processes such as prioritization and repayment.

Refactoring is a prevalent technique that can be applied for improving software structural quality. Refactorings can be applied at different levels of granularity to resolve 'bad smells' that can be identified in various artifacts (e.g., methods, classes, packages). A fundamental software engineering principle that can be applied at various levels of granularity is the Single Responsibility Principle (SRP), whose violation leads to the creation of lengthy, complex and non-cohesive artifacts; incurring smells like Long Method, God Class, and Large Package. Such artifacts, apart from being large in size tend to implement more than one functionalities, leading to decreased cohesion, and increased coupling. In this paper, we study the effect of applying refactorings that lead to conformance to the SRP, at all three levels of granularity to identify possible differences between them. To study these differences, we performed an industrial case study on two large-scale software systems (more than 1,500 classes). Since SRP is by definition related to modularity, as a success measure for the refactoring we use coupling and cohesion metrics. The results of the study can prove beneficial for both researchers and practitioners, since various implications can be drawn.

Context: Technical Debt (TD) quantification has been studied in the literature and is supported by various tools; however, there is no common ground on what information shall be presented to stakeholders. Similarly to other quality monitoring processes, it is desirable to provide several views of quality through a dashboard, in which metrics concerning the phenomenon of interest are displayed. Objective: The aim of this study is to investigate the indicators that shall be presented in such a dashboard, so as to: (a) be meaningful for industrial stakeholders, (b) present all necessary information, and (c) be simple enough so that stakeholders can use them. Method: We explore TD Management (TDM) activities (i.e., measurement, prioritization, repayment) and choose the main concepts that need to be visualized, based on existing literature and toolsupport. Next, we perform a survey with 60 software engineers (i.e., architects, developers, etc.) working for 11 software development companies located in 9 countries, to understand their needs for TDM. Results / Conclusions: The results of the study suggest that different stakeholders need a different view of the quality dashboard, but also some commonalities can be identified. For example, on the one hand, managers are mostly interested in financial concepts, whereas on the other hand developers are more interested in the nature of the problems that exist in the code. The outcomes of this study can be useful to both researchers and practitioners, in the sense that the former can focus their efforts on aspects that are meaningful to industry, whereas the latter to develop meaningful dashboards, with multiple views.

Software reuse is a well-established software engineering process that aims at improving development productivity. Although reuse can be performed in a systematic way (e.g., through product lines), in practice, reuse is performed in many cases opportunistically, i.e., copying small code chunks either from the web or in-house developed projects. Knowledge sharing communities and especially StackOverflow constitute the primary source of code-related information for amateur and professional software developers. Despite the obvious benefit of increased productivity, reuse can have a mixed effect on the quality of the resulting code depending on the properties of the reused solutions. An efficient concept for capturing a wide-range of internal software qualities is the metaphor of Technical Debt which expresses the impact of shortcuts in software development on its maintenance costs. In this paper, we present the results of an empirical study on the relation between the existence of reusing code retrieved from StackOverflow on the technical debt of the target system. In particular, we study several open-source projects and identify non-trivial pieces of code that exhibit a perfect or near-perfect match with code provided in the context of answers in StackOverflow. Then, we compare the technical debt density of the reused fragments, obtained as the ratio of inefficiencies identified by SonarQube over the lines of reused code, to the technical debt density of the target codebase. The results provide insights to the potential impact of small-scale code reuse on technical debt and highlight the benefits of assessing code quality before committing changes to a repository.

Successful software project survival and progress over time is highly dependent on effectively managing the maintenance process. Estimating accurately maintenance process factors like the maintenance effort and the level of changes required for a new release is considered a crucial task for allocating resources. In this work we examine the maintenance process factors of JavaScript applications, which at the moment are understudied despite the need of language specific maintenance models. Furthermore we propose two maintenance indices for estimating the changes and the effort required for maintaining JavaScript applications by considering a variety of maintenance drivers. We evaluated the proposed indices through a case study on 5,788 releases coming from 60 popular JavaScript applications. The results show that project activity factors (i.e., number of open bugs and number of corrective maintenance activities) are important maintenance drivers. The proposed indices are evaluated in terms of predictive and discriminative power and both achieve high accuracy.

Secondary studies are vulnerable to threats to validity. Although, mitigating these threats is crucial for the credibility of these studies, we currently lack a systematic approach to identify, categorize and mitigate threats to validity for secondary studies. In this paper, we review the corpus of secondary studies, with the aim to identify: (a) the trend of reporting threats to validity, (b) the most common threats to validity and corresponding mitigation actions, and (c) possible categories in which threats to validity can be classified. To achieve this goal we employ the tertiary study research method that is used for synthesizing knowledge from existing secondary studies. In particular, we collected data from more than 100 studies, published until December 2016 in top quality software engineering venues (both journals and conference). Our results suggest that in recent years, secondary studies are more likely to report their threats to validity. However, the presentation of such threats is rather ad hoc, e.g., the same threat may be presented with a different name, or under a different category. To alleviate this problem, we propose a classification schema for reporting threats to validity and possible mitigation actions. Both the classification of threats and the associated mitigation actions have been validated by an empirical study, i.e., Delphi rounds with experts. Based on the proposed schema, we provide a checklist, which authors of secondary studies can use for identifying and categorizing threats to validity and corresponding mitigation actions, while readers of secondary studies can use the checklist for assessing the validity of the reported results.

The assessment of software quality is one of the most multifaceted (eg, structural, product, and process quality) and subjective aspects of software engineering, as in most cases, it is substantially based on expert judgement. Such assessments can be performed at almost all phases of software development (from project inception to maintenance) and at different levels of granularity (from source code to architecture). However, human judgement is (1) inherently biased by implicit, subjective criteria applied in the evaluation process, and (2) its economical effectiveness is limited compared to automated or semi­automated approaches. For these reasons, the research community is still looking for new, more effective methods of assessing various qualitative characteristics of software systems and the related processes. In recent years, we observed a rising interest in adopting various approaches to exploiting machine learning (ML) and automated decision­making processes in several areas of software engineering. These models and algorithms help to reduce effort and risk related to human judgment in favor of automated systems, which are able to make informed decisions based on available data and evaluated with objective criteria. Thus, the adoption of machine learning techniques seems to be one of the most promising ways to improve software quality evaluation. This special issue aims at providing researchers with the possibility to spread novel ideas and methods to make machine learning actionable for the assessment of software quality artifacts and processes. The call for papers was originally published in SE­WORLD, the journal webpage, and other forums relevant to the software engineering community. We particularly encouraged the authors of papers accepted at the 2nd International Workshop on Machine Learning for Software Quality Evaluation (MaLTeSQuE 20181) to submit a revised, extended version of the workshop papers. All submitted papers went through a rigorous review process, which involved up to three internationally recognized experts of the field. This ensured rigor, novelty, and the scientific contribution expected by the Journal of Software: Evolution and Process. As a result, out of the six submitted papers, four of them were recommended for publication. It is our hope that the papers presented in this special issue will further foster the research community toward the intersection between machine learning and software quality assessment. We would like to thank the Editor­in­Chief of the Journal of Software: Evolution and Process, Professor Gerardo Canfora, for allowing us to present this special issue. We are very grateful to all our reviewers for their efforts in evaluating the submitted papers as well as for their timely and constructive reviews that have helped the authors to substantially improve the quality of their works. Finally, we would like to thank the authors who have submitted and revised their papers according to the reviewers' feedback and who have made this special issue possible.

Abstract To capitalize upon the benefits of software reuse, an efficient selection among candidate reusable assets should be performed in terms of functional fitness and adaptability. The reusability of assets is usually measured through reusability indices. However, these do not capture all facets of reusability, such as structural characteristics, external quality attributes, and documentation. In this paper, we propose a reusability index (REI) as a synthesis of various software metrics and evaluate its ability to quantify reuse, based on IEEE Standard on Software Metrics Validity. The proposed index is compared with existing ones through a case study on 80 reusable open‐source assets. To illustrate the applicability of the proposed index, we performed a pilot study, where real‐world reuse decisions have been compared with decisions imposed by the use of metrics (including REI). The results of the study suggest that the proposed index presents the highest predictive and discriminative power; it is the most consistent in ranking reusable assets and the most strongly correlated to their levels of reuse. The findings of the paper are discussed to understand the most important aspects in reusability assessment (interpretation of results), and interesting implications for research and practice are provided.

Empirical evidence has pointed out that Extract Method refactorings are among the most commonly applied refactorings by software developers. The identification of Long Method code smells and the ranking of the associated refactoring opportunities is largely based on the use of metrics, primarily with measures of cohesion, size and coupling. Despite the relevance of these proper-ties to the presence of large, complex and non-cohesive pieces of code, the empirical validation of these metrics has exhibited relatively low accuracy (max precision: 66%) regarding their predictive power for long methods or extract method opportunities. In this work we perform an empirical validation of the ability of cohesion, coupling and size metrics to predict the existence and the intensity of long method occurrences. According to the statistical analysis, the existence and the intensity of the Long Method smell can be effectively predicted by two size (LoC and NoLV), two coupling (MPC and RFC), and four cohesion (LCOM1, LCOM2, Coh, and CC) metrics. Furthermore, the integration of these metrics into a multiple logistic regression model can predict whether a method should be refactored with a precision of 89% and a recall of 91%. The model yields suggestions whose ranking is strongly correlated to the ranking based on the effect of the corresponding refactorings on source code (correl. coef. 0.520). The results are discussed by providing interpretations and implications for research and practice.

Documentation issues in software projects have been recently classified as a type of technical debt (TD), a concept that express-es how shortcuts during software development result in additional maintenance and evolution effort. The specific type of TD is termed documentation debt, and is among the most prevalent ones in practice and research. In this study we propose a tool-based approach for preventing documentation TD during requirements engineering, by: (a) integrating requirements specifications into the IDE, and (b) enabling the real-time creation of traces between requirements and code. To this end, we collaborated with a small/medium software company and conducted a qualitative case study to: (a) analyze the current process and identify existing TD types, (b) collect the requirements and implement a tool that aims at preventing the accumulation of documentation TD, and (c) investigate whether the tool successfully meets its goal. The results of the study suggest that the developers are motivated to use the developed tool, since they feel that they can develop, maintain and utilize requirements specifications and traces as part of their daily routine.

Modularity is one of the key principles of software design. In order for a software system to be modular, it should be organized into modules that are highly coherent internally, whereas at the same time as independent from other modules as possible. In this paper we explore coupling and cohesion metrics at the software package level-i.e., one of most basic levels of software functional decomposition in object-oriented (OO) systems, with the aim of investigating their relation to the technical debt of each package. Current state-of-the-art tools in TD measurement are working on the source code level, and the extent to which they can unveil limitations at the architecture level (e.g., violations of the modularity principle), has not been explored so far. To achieve this goal, we conducted a case study on 1,200 packages retrieved from 20 well-known open source software projects. The results of the study suggested that current measures of technical debt are able to identify / predict modules that lack modularity, and therefore suffer from Architectural Technical Debt (ATD). The results of the study are discussed both from the practitioners' and re-searchers' point of view.

The set of concepts collectively known as Technical Debt (TD) assume that software liabilities set up a context that can make a future change more costly or impossible; and therefore repaying the debt should be pursued. However, software developers often disagree with an automatically generated list of improvement suggestions, which they consider not fitting or important for their own code. To shed light into the reasons that drive developers to adopt or reject refactoring opportunities (i.e. TD repayment), we have performed an empirical study on the potential factors that affect the developers' decision to agree with the removal of a specific TD liability. The study has been addressed to the developers of four well-known open-source applications. To increase the response rate, a personalized assessment has first been sent to each developer, summarizing his/her own contribution to the TD of the corresponding project. Responds have been collected through a custom built web application that presented code fragments suffering from violations as identified by SonarQube along with information that could possibly affect their level of agreement to the importance of resolving an issue. These factors include data such as the frequency of past changes in the module under study, the number of bugs, the type and intensity of the violation, the level of involvement of the developer and whether he/she is a contributor in the corresponding project. Multivariate statistical analysis methods have been used to understand the importance and the underlying relationships among these factors and the results are expected to be useful for researchers and practitioners in TD Management.

Technical debt management entails the quantification of principal and interest. In our previous work we had introduced a framework for calculating the Technical Debt Breaking Point (TD-BP), which is a point in time where the accumulated interest becomes larger than the principal; thus the debt of the company is no longer sustainable after this point in time. In this paper, we instantiate this framework and validate its ability to assess the breaking point of source code modules in an industrial setting. The results of the validation suggest that the calculated TD-BP is strongly correlated to experts' opinion on the sustainability of modules, and that it can accurately rank components, based on their maintenance difficulty.

Source code refactorings and transformations are extensively used by embedded system developers to improve the quality of applications, often supported by various open source and proprietary tools. They either aim at improving the design time quality such as the maintainability and reusability of software artifacts, or the runtime quality such as performance and energy efficiency. However, an inherent trade-off between design- and run-time qualities is often present posing challenges to embedded software development. This work is a first step towards the investigation of the impact of transformations for improving the performance and the energy efficiency on software quality metrics and the impact of refactorings for increasing the design time quality on the execution time, the memory and the energy consumption. Based on a set of embedded applications from widely used benchmark suites and typical transformations and refactorings, we identify interrelations and trade-offs between the aforementioned metrics.

Monitoring software quality is a non-trivial task, since it requires the selection of: (a) quality attributes, based on application domain and development phase, and (b) appropriate metrics to quantify them. We aim to aid this process by reviewing the state-of-research on design-time qualities and metrics.

During software evolution technical debt (TD) follows a constant ebb and flow, being incurred and paid back, sometimes in the same day and sometimes ten years later. There have been several studies in the literature investigating how technical debt in source code accumulates during time and the consequences of this accumulation for software maintenance. However, to the best of our knowledge there are no large scale studies that focus on the types of issues that are fixed and the amount of TD that is paid back during software evolution. In this paper we present the results of a case study, in which we analyzed the evolution of fifty-seven Java open-source software projects by the Apache Software Foundation at the temporal granularity level of weekly snapshots. In particular, we focus on the amount of technical debt that is paid back and the types of issues that are fixed. The findings reveal that a small subset of all issue types is responsible for the largest percentage of TD repayment and thus, targeting particular violations the development team can achieve higher benefits.

Change proneness is a quality characteristic of software artifacts that represents their probability to change in the future due to: (a) evolving requirements, (b) bug fixing, or (c) ripple effects. In the literature, change proneness has been associated with many negative consequences along software evolution. For example, artifacts that are change-prone tend to produce more defects, and accumulate more technical debt. Therefore, identifying and monitoring modules of the system that are change-prone is of paramount importance. Assessing change proneness requires information from two sources: (a) the history of changes in the artifact as a proxy of how frequently the artifact itself is changing, and (b) the source code structure that affects the probability of a change being propagated among artifacts. In this paper, we propose a method for assessing the change proneness of classes based on the two aforementioned information sources. To validate the proposed approach, we performed a case study on five open-source projects. Specifically, we compared the accuracy of the proposed approach to the use of other software metrics and change history to assess change proneness, based on the 1061-1998 IEEE Standard on Software Measurement. The results of the case study suggest that the proposed method is the most accurate and reliable assessor of change proneness. The high accuracy of the method suggests that the method and accompanying tool can effectively aid practitioners during software maintenance and evolution.

One of the first steps towards the effective Technical Debt (TD) management is the quantification and continuous monitoring of the TD principal. In the current state-ofresearch and practice the most common ways to assess TD principal are the use of: (a) structural proxies—i.e., most commonly through quality metrics; and (b) monetized proxies—i.e., most commonly through the use of the SQALE (Software Quality Assessment based on Lifecycle Expectations) method. Although both approaches have merit, they seem to rely on different viewpoints of TD and their levels of agreement have not been evaluated so far. Therefore, in this paper, we empirically explore this relation by analyzing data obtained from 20 open source software projects and build a regression model that establishes a relationship between them. The results of the study suggest that a model of seven structural metrics, quantifying different aspects of quality (i.e., coupling, cohesion, complexity, size, and inheritance) can accurately estimate TD principal as appraised by SonarQube. The results of this case study are useful to both academia and industry. In particular, academia can gain knowledge on: (a) the reliability and agreement of TD principal assessment methods and (b) the structural characteristics of software that contribute to the accumulation of TD, whereas practitioners are provided with an alternative evaluation model with reduced number of parameters that can accurately assess TD, through traditional software quality metrics and tools.

Technical Debt Management (TDM) refers to activities that are performed to prevent the accumulation of Technical Debt (TD) in software. The state-of-research on TDM lacks empirical evidence on the relationship between the amount of TD in a software module and the interest that it accumulates. Considering the fact that in the last years, a large portion of software applications are deployed in the web, we focus this study on PHP applications. Although the relation between debt amount and interest is well-defined in traditional economics (i.e., interest is proportional to the amount of debt), this relation has not yet been explored in the context of TD. To this end, the aim of this study is to investigate the relation between the amount of TD and the interest that has to be paid during corrective maintenance. To explore this relation, we performed a case study on 10 open source PHP projects. The obtained data have been analyzed to assess the relation between the amount of TD and two aspects of interest: (a) corrective maintenance (i.e., bug fixing) frequency, which translates to interest probability and (b) corrective maintenance effort which is related to interest amount. Both interest probability and interest amount are positively related with the amount of TD accumulated in a specific module. Moreover, the amount of TD is able to discriminate modules that are in need of heavy corrective maintenance. The results of the study confirm the cornerstone of TD research, which suggests that modules with a higher level of incurred TD, are costlier in maintenance activities. In particular, such modules prove to be more defect-prone and consequently require more (corrective) maintenance effort.

Abstract Gang of Four (GoF) patterns are well‐known best practices for the design of object‐oriented systems. In this paper, we aim at empirically assessing their relationship to energy consumption, ie, a performance indicator that has recently attracted the attention of both researchers and practitioners. To achieve this goal, we investigate pattern‐participating methods (ie, those that play a role within the pattern) and compare their energy consumption to the consumption of functionally equivalent alternative (nonpattern) solutions. We obtained the alternative solution by refactoring the pattern instances using well‐known transformations (eg, replace polymorphism with conditional statements). The comparison is performed on 169 methods of 2 GoF patterns (namely, State/Strategy and Template Method), retrieved from 2 well‐known open source projects. The results suggest that for the majority of cases the alternative design excels in terms of energy consumption. However, in some cases (eg, when the method is large in size or invokes many methods) the pattern solution presents similar or lower energy consumption. The outcome of our study can be useful to both researchers and practitioners, because we: (1) provide evidence on a possible negative effect of GoF patterns, and (2) can provide guidance on which cases the use of the pattern is not hurting energy consumption.

`Extract Method' is considered one of the most frequently applied and beneficial refactorings, since the corresponding Long Method smell is among the most common and persistent ones. Although Long Method is conceptually related to the implementation of diverse functionalities within a method, until now, this relationship has not been utilized while identifying refactoring opportunities. In this paper we introduce an approach (accompanied by a tool) that aims at identifying source code chunks that collaborate to provide a specific functionality, and propose their extraction as separate methods. The accuracy of the proposed approach has been empirically validated both in an industrial and an open-source setting. In the former case, the approach was capable of identifying functionally related statements within two industrial long methods (approx. 500 LoC each), with a recall rate of 93 percent. In the latter case, based on a comparative study on open-source data, our approach ranks better compared to two well-known techniques of the literature. To assist software engineers in the prioritization of the suggested refactoring opportunities the approach ranks them based on an estimate of their fitness for extraction. The provided ranking has been validated in both settings and proved to be strongly correlated with experts' opinion.

Software quality attributes are assessed by employing appropriate metrics. However, the choice of such metrics is not always obvious and is further complicated by the multitude of available metrics. To assist metrics selection, several properties have been proposed. However, although metrics are often used to assess successive software versions, there is no property that assesses their ability to capture structural changes along evolution. We introduce a property, Software Metric Fluctuation (SMF), which quantifies the degree to which a metric score varies, due to changes occurring between successive system's versions. Regarding SMF, metrics can be characterized as sensitive (changes induce high variation on the metric score) or stable (changes induce low variation on the metric score). SMF property has been evaluated by: (a) a case study on 20 OSS projects to assess the ability of SMF to differently characterize different metrics, and (b) a case study on 10 software engineers to assess SMF's usefulness in the metric selection process. The results of the first case study suggest that different metrics that quantify the same quality attributes present differences in their fluctuation. We also provide evidence that an additional factor that is related to metrics’ fluctuation is the function that is used for aggregating metric from the micro to the macro level. In addition, the outcome of the second case study suggested that SMF is capable of helping practitioners in metric selection, since: (a) different practitioners have different perception of metric fluctuation, and (b) this perception is less accurate than the systematic approach that SMF offers. SMF is a useful metric property that can improve the accuracy of metrics selection. Based on SMF, we can differentiate metrics, based on their degree of fluctuation. Such results can provide input to researchers and practitioners in their metric selection processes.

Population aging has brought important challenges at social, economical, and healthcare issues, mainly due to the increasing number of people that need intensive care. Ambient Assisted Living (AAL) systems that aim at assisting people in their health-related activities have emerged. In another perspective, Reference Architectures (RAs) are a special type of software architecture that promotes reuse of design expertise and facilitates the development, standardization, and evolution of software systems. During the last years, important RAs for AAL systems have been created. However, there is a lack of studies that compare RAs for healthcare systems in AAL domain, making the selection among RAs a rather difficult task. In this paper, we present a comparative analysis and evaluate the completeness of that healthcare RAs. Specifically, we intend to offer: (i) a guide to select the most complete and adequate RA for software projects, and (ii) to describe research directions to improve existing and future RAs for that systems.

Ambient Assisted Living (AAL) has become focus of attention for governmental organisations, and healthcare and ICT researchers. AAL includes methods, products, services, and software systems to support the everyday lives of elders. To develop AAL software systems, reference architectures (i.e., a special software architecture that guides the development, standardization, and evolution of systems architectures) have been proposed. Despite of the existing reference architectures, their use is a difficult task, due their high level of abstraction. Moreover, these architectures do not support the development of systems for telemonitoring and self-management of chronic diseases at home. The main objective of this project is to propose a reference architecture for Healthcare Supportive Home (HSH) systems. With this project we will contribute in promoting and reusing the knowledge of expertise and in supporting the development, standardization, evolution, and quality of HSH software systems.

Context: Change impact analysis investigates the negative consequence of system changes, i.e., the propagation of changes to other parts of the system (also known as the ripple effect). Identifying modules of the system that will be affected by the ripple effect is an important activity, before and after the application of any change. Goal: However, in the literature, there is only a limited set of studies that investigate the probability of a random change occurring in one class, to propagate to another. In this paper we discuss and evaluate the Ripple Effect Measure (in short REM), a metric that can be used to assess the aforementioned probability. Method: To evaluate the capacity of REM as an assessor of the prob-ability of a class to change due to the ripple effect, we: (a) mathematically validate it against established metric properties (e.g., non-negativity, monotonicity, etc.), proposed by Briand et al., and (b) empirically investigate its validity as an assessor of class proneness to the ripple effect, based on the 1061-1998 IEEE Standard on Software Measurement (e.g., correlation, predictive power, etc.). To apply the empirical validation process, we conducted a holistic multiple-case study on java open-source classes. Results: The results of REM validation (both mathematical and empirical) suggest that REM is a theoretically sound measure that is the most valid assessor of the probability of a class to change due to the ripple effect, compared to other existing metrics.

Stability refers to a software system's resistance to the “ripple effect”, i.e., propagation of changes. In this paper, we investigate the stability of classes that participate in instances/occurrences of GoF design patterns. We examine whether the stability of such classes is affected by (a) the pattern type, (b) the role that the class plays in the pattern, (c) the number of pattern occurrences in which the class participates, and (d) the application domain. To this end, we conducted a case study on about 65.000 Java open-source classes, where we performed change impact analysis on classes that participate in zero, one (single pattern), or more than one (coupled) pattern occurrences. The results suggest that, the application of design patterns can provide the expected “shielding” of certain pattern-participating classes against changes, depending on their role in the pattern. Moreover, classes that participate in coupled pattern occurrences appear to be the least stable. The results can be used for assessing the benefits and liabilities of the use of patterns and for testing and refactoring prioritization, because less stable classes are expected to require more effort while testing, and urge for refactoring activities that would make them more resistant to change propagation.

Context: Investing on Open Source Software (OSS) as a "code reuser", involves certain risks, such as the difficulty in understanding the level of OSS design quality Aim: We investigate the levels of design quality of OSS projects, across different application domains. Method: We conducted a case study, which is the most fitting research method for observing a phenomenon in its real context, which is active for a long period of time, and for which variables cannot be controlled. Results: We present the values for seven design quality metrics of 546 OSS projects, as well as the statistically significant differences across application domains. Conclusions: The results of the study suggest that OSS application domains correlate with several design quality characteristics, in the sense that projects within one application domain appear to have similar levels of design quality. In addition to that, the results reveal application domains with high and low levels of design quality.