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.

As society is continuously adapting to technological change and progress, fast-moving digital transformations are the driving force for setting the necessary skillsets for the workforce. Furthermore, the advent of Industry 5.0 as a defining concept for the future, which advocates a human-centric coalescence of humans and technology or software, renders the skilled workforce the most important asset in any organization or business. The endgame of the digital transformation is to evoke the reshaping, evolution, or replacement of traditional and possibly obsolete processes at intra- or inter-organizational levels in multiple aspects, introducing innovative ways of re-defining the workforce. In this context SKILLAB will act as a smart tool for handling, honing, and widening the competencies of the personnel of companies, forecasting future skill gaps and providing European citizens with a tool for upskilling and reskilling.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.