We present a engineering case study on the design and evolution of a cloud-native MLOps pipeline in an industrial setting using Databricks. Motivated by the operational and lifecycle challenges of deploying machine-learning models at scale, the project adopted a platform-centric approach to automation, reproducibility, and scalable operation. The pipeline integrates versioned data management, experiment tracking and registry-based promotion, CI/CD for ML, and environment isolation to bridge experimentation and production. Security and data-privacy constraints are operationalized through workspace isolation, role-based access control, and secrets management integrated into deployment automation. Our methodological approach entailed an engineering case-study design, incorporating triangulation across development artifacts, CI/CD records, and collaborative design episodes. The paper delivers three contributions: (i) a platform-grounded reference architecture documenting the design decisions, trade-offs, and deliberate deviations from vendor guidance that shaped the final implementation; (ii) collaboration practices that align roles across DataOps, ModelOps, and DevOps showing how shared artifacts and platform constraints structure cross-role coordination; and (iii) recurring implementation patterns and practitioners lessons that are capability-oriented and transferable beyond the specific platform. The results provide practitioners with empirical evidence on how MLOps automation is realized and constrained in practice, filling a gap that vendor documentation and conceptual frameworks alone do not address.

Federated Learning (FL) is a collaborative learning paradigm in which multiple clients train a shared global model without exchanging data. Clients communicate only model updates with a central aggregator. In parallel, Machine Learning Operations (MLOps) streamline the development, deployment, and monitoring of ML systems, while their extension, Federated Learning Operations (FLOps), aims to bring the operational discipline to decentralized and privacy-sensitive settings. This study presents a systematic mapping study (SMS) on FL and FLOps, and clarifies foundational concepts and uncovers new perspectives within this evolving field. We focus on FLOps and FL features: architecture, communication and aggregation models. First research question (RQ) focuses on prevalent FL computing architectures. Second RQ covers data transfer between FL components. Third RQ determines breadth of FLOps application in the scientific literature. Fourth RQ identifies distinct approaches to global model aggregation. Our analysis reveals that Edge-based local training with Cloud-based aggregation is the most adopted architecture, combining Edge privacy and responsiveness with Cloud computational capacity. Communication is enabled through lightweight protocols such as Message Queuing Telemetry Transport (MQTT), but protocol choice depends on constraints. Notably, FLOps remains a rarely addressed topic, indicating a substantial gap in end-to-end support for FL pipelines. Federated Averaging (FedAvg) is the most employed aggregation approach, valued for its simplicity and effectiveness with heterogeneous data. These findings expose critical research gaps in architectural diversity, protocol selection, lifecycle integration and adaptive aggregation, highlighting the need for more cohesive and scalable FL system design in future work.

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.

In the era of 6G, developing and managing software requires cutting-edge software engineering (SE) theories and practices tailored for such complexity across a vast number of connected edge devices. Our project aims to lead the development of sustainable methods and energy-efficient orchestration models specifically for edge environments, enhancing architectural support driven by AI for contemporary edge-to-cloud continuum computing. This initiative seeks to position Finland at the forefront of the 6G landscape, focusing on sophisticated edge orchestration and robust software architectures to optimize the performance and scalability of edge networks. Collaborating with leading Finnish universities and companies, the project emphasizes deep industry-academia collaboration and international expertise to address critical challenges in edge orchestration and software architecture, aiming to drive significant advancements in software productivity and market impact.

The implementation of smart manufacturing, which utilises advanced digital technologies to enhance the agility and productivity of the traditional manufacturing sector, has the potential to reduce resource consumption, optimise processes and enhance safety. One challenge in process automation (PA) is its strict real-time requirements. One solution to this challenge is the use of Edge and Fog computing platforms with finite computational power, which brings processing and data storing closer to the data sources. This proximity of computing devices reduces the latency and bandwidth requirements, relaxes the need for a reliable Internet connection, and provides more security in design over the Cloud solutions. This paper compares the performance of Edge and Fog computing for soft real-time machine learning-based visual process monitoring that supports the human operator. The objective is to get a better understanding how this ML task can be relocated within Edge and Fog layers. Moreover, the article provides con-siderations of emerging difficulties of practical implementation of Continuous Training pipeline and soft real-time steam detection.

The evolution of cloud computing, driven by ad-vances in mobile, edge technologies, and AI, has led to the development of the Cognitive Cloud Continuum (COCLCON). However, this paradigm introduces new challenges in managing and optimizing computing resources across a heterogeneous environment. This paper explores best practices for declaring resources within COCLCON, with a focus on efficient resource allocation and transparently declaring available resources by de-vices. In this study, we undertook a non-holistic literature review to identify current technologies used to specify requirements and to determine current gaps in best practices. The main outcome of our work is a proposed schema for Resource Provisioning Declaration, which will allow for increased knowledge related to the available devices and resources within the COCLCON.

Balancing the management of technical debt within recommender systems requires effectively juggling the introduction of new features with the ongoing maintenance and enhancement of the current system. Within the realm of recommender systems, technical debt encompasses the trade-offs and expedient choices made during the development and upkeep of the recommendation system, which could potentially have adverse effects on its long-term performance, scalability, and maintainability. In this vision paper, our objective is to kickstart a research direction regarding Technical Debt in AI-based Recommender Systems. We identified 15 potential factors, along with detailed explanations outlining why it is advisable to consider them.

Edge-to-cloud computing is an emerging paradigm for distributing computational tasks between edge devices and cloud resources. Different approaches for orchestration, offloading, and many more purposes have been introduced in research. However, it is still not clear what has been implemented in the industry. This work aims to merge this gap by mapping the existing knowledge on edge-to-cloud tools by providing an overview of the current state of research in this area and identifying research gaps and challenges. For this purpose, we conducted a Multivocal Literature Review (MLR) by analyzing 40 tools from 1073 primary studies (220 PS from the white literature and 853 PS from the grey literature). We categorized the tools based on their characteristics and targeted environments. Overall, this systematic mapping study provides a comprehensive overview of edge-to-cloud tools and highlights several opportunities for researchers and practitioners for future research in this area. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

As software systems become increasingly complex and interconnected, the risk of security debt has risen significantly, increasing cyber-attacks and data breaches. Vulnerability prioritization is a critical activity in software engineering as it helps identify and address security vulnerabilities in software systems promptly and effectively. With the increasing complexity of software systems and the growing number of potential threats, it is essential to have a systematic approach to vulnerability prioritization to ensure that the most critical vulnerabilities are addressed first. The present study aims to investigate the agreement between the default and the National Vulnerability Database (NVD) severity levels. We analyzed 1626 vulnerabilities encompassing 12 unique types of vulnerabilities associated with 125 Common Platform Enumeration identifiers belonging to 105 Apache projects. Our results show a scarce correlation between the default and NVD severity levels. Thus, the default severity of vulnerabilities is not trustworthy. Moreover, we discovered that, surprisingly, the same type of vulnerability has several NVD severity; therefore, no default prioritization can be accurate based only on the type of vulnerability. Future studies are needed to accurately estimate the priority of vulnerabilities by considering several aspects of vulnerabilities rather than only the type.

Software vulnerabilities play a major role, as there are multiple risks associated, including loss and manipulation of private data. The software engineering research community has been contributing to the body of knowledge by proposing several empirical studies on vulnerabilities and automated techniques to detect and remove them from source code. The reliability and generalizability of the findings heavily depend on the quality of the information mineable from publicly available datasets of vulnerabilities as well as on the availability and suitability of those databases. In this paper, we seek to understand the anatomy of the currently available vulnerability databases through a systematic mapping study where we analyze (1) what are the popular vulnerability databases adopted; (2) what are the goals for adoption; (3) what are the other sources of information adopted; (4) what are the methods and techniques; (5) which tools are proposed. An improved understanding of these aspects might not only allow researchers to take informed decisions on the databases to consider when doing research but also practitioners to establish reliable sources of information to inform their security policies and standards.

Companies develop cloud-native systems deployed on public and private clouds. Since private clouds have limited resources, the systems should run efficiently by keeping performance related anomalies under control. The goal of this work is to understand whether a set of five performance-related KPIs depends on the metrics collected at runtime by Kafka, Zookeeper, and other tools (168 different metrics). We considered four weeks worth of runtime data collected from a system running in production. We trained eight Machine Learning algorithms on three weeks worth of data and tested them on one week’s worth of data to compare their prediction accuracy and their training and testing time. It is possible to detect performance-related anomalies with a very high level of accuracy (higher than 95% AUC) and with very limited training time (between 8 and 17 minutes). Machine Learning algorithms can help to identify runtime anomalies and to detect them efficiently. Future work will include the identification of a proactive approach to recognize the root cause of the anomalies and to prevent them as early as possible.

DevOps has become increasingly widespread, with companies employing its methods in different fields. In this context, MLOps automates Machine Learning pipelines by applying DevOps practices. Considering the high number of tools available and the high interest of the practitioners to be supported by tools to automate the steps of Machine Learning pipelines, little is known concerning MLOps tools and their functionalities. To this aim, we conducted a Multivocal Literature Review (MLR) to (i) extract tools that allow for and support the creation of MLOps pipelines and (ii) analyze their main characteristics and features to provide a comprehensive overview of their value. Overall, we investigate the functionalities of 13 MLOps Tools. Our results show that most MLOps Tools support the same features but apply different approaches that can bring different advantages, depending on user requirements.

Developing an AI-based system is uniquely challenging as it requires knowledge across multiple domains. Though the project team is required to be versatile, it is possible that their repertoire cannot cover all of the requirements of the system, which results in damage to the software quality. Therefore, it is critical to have an effective team knowledge management (KM) strategy to detect the valuable “unknown”, optimize the “known” task assignment, and enlarge the team knowledge base. Moreover, it is more effective to support the process with data-driven approaches.

DevOps practices are the de facto sandard when developing software. The increased adoption of machine learning (ML) to solve problems urges us to adapt all the current approaches to developing a new standard that can take full benefit from the new solution. In this work we propose a graphical representation for DevOps for ML-based applications, namely MLOps, and also outline open research challenges. The pipeline aims to get the best of both worlds by maintaining the simple and iconic pipeline of DevOps, yet improving it by adding new circular steps for ML incorporation. This aims to create an ML-based development subsystem that can be self-maintained, and is capable of evolving side-by-side with the software development.

Background. Several recent software engineering studies use data mined from the version control systems adopted by the different software projects. However, inspecting the data and statistical methods used in those studies reveals several problems with the current approach, mainly related to the dependent nature of the data. Objective. We analyzed time-dependent data in software engineering at commit level, and propose an alternative approach based on time series analysis. Method. We identified statistical tests designed for time series analysis and propose a technique to model time dependent data, similarly to what is done in finance and weather forecasting. We applied our approach to a small set of projects of different sizes, investigating the behaviour of the SQALE Index, in order to highlight the time and interdependency of the different commits. Results. Using these techniques, we analysed and model the data, showing that it is possible to investigate this type of commit data using methods from time series analysis. Conclusion. Based on the promising results, we plan to validate the robustness of the approach by replicating previous works.

Abstract Background Developers spend more time fixing bugs refactoring the code to increase the maintainability than developing new features. Researchers investigated the code quality impact on fault-proneness, focusing on code smells and code metrics. Objective We aim at advancing fault-inducing commit prediction using different variables, such as SonarQube rules, product, process metrics, and adopting different techniques. Method We designed and conducted an empirical study among 29 Java projects analyzed with SonarQube and SZZ algorithm to identify fault-inducing and fault-fixing commits, computing different product and process metrics. Moreover, we investigated fault-proneness using different Machine and Deep Learning models. Results We analyzed 58,125 commits containing 33,865 faults and infected by more than 174 SonarQube rules violated 1.8M times, on which 48 software product and process metrics were calculated. Results clearly identified a set of features that provided a highly accurate fault prediction (more than 95% AUC). Regarding the performance of the classifiers, Deep Learning provided a higher accuracy compared with Machine Learning models. Conclusion Future works might investigate whether other static analysis tools, such as FindBugs or Checkstyle, can provide similar or different results. Moreover, researchers might consider the adoption of time series analysis and anomaly detection techniques.

Open Source Software (OSS) is nowadays used and integrated in most of the commercial products. However, the selection of OSS projects for integration is not a simple process, mainly due to a of lack of clear selection models and lack of information from the OSS portals. We investigate the factors and metrics that practitioners currently consider when selecting OSS. We also investigate the source of information and portals that can be used to assess the factors, as well as the possibility to automatically extract such information with APIs. We elicited the factors and the metrics adopted to assess and compare OSS performing a survey among 23 experienced developers who often integrate OSS in the software they develop. Moreover, we investigated the APIs of the portals adopted to assess OSS extracting information for the most starred 100K projects in GitHub. We identified a set consisting of 8 main factors and 74 sub-factors, together with 170 related metrics that companies can use to select OSS to be integrated in their software projects. Unexpectedly, only a small part of the factors can be evaluated automatically, and out of 170 metrics, only 40 are available, of which only 22 returned information for all the 100K projects. Therefore, we recommend project maintainers and project repositories to pay attention to provide information for the project they are hosting, so as to increase the likelihood of being adopted. OSS selection can be partially automated, by extracting the information needed for the selection from portal APIs. OSS producers can benefit from our results by checking if they are providing all the information commonly required by potential adopters. Developers can benefit from our results, using the list of factors we selected as a checklist during the selection of OSS, or using the APIs we developed to automatically extract the data from OSS projects.