63 publications

Enhancing the modular structure of existing systems has attracted substantial research interest, primarily through (1) software modularization and (2) identifying design issues (e.g., smells) as refactoring opportunities; however, both approaches often prove impractical to guide effective improvement. Inspired by both aforementioned approaches, our previous study introduced a novel and practical architectural smell - called Pairwise Modular Smell (or PairSmell) - for identifying flawed architectural decisions that necessitate further examination. PairSmell is defined as the deviations between the actual modular relation (MR) and the `apt MR'- an MR agreed on by multiple modularization tools (as raters). Although PairSmell has shown its relevance, the reliance on external modularization tools makes it a relatively obscure concept within the community, which in turn may threaten its validity to be used in inspecting software module structure. The objective of this study is to explain PairSmell from the perspective of pair characteristics. To this end, we first conduct a rapid review to collect and synthesize 19 pair characteristics that have been used in the literature to represent relationships between two entities. The collected characteristics are then used to train machine learning models for predicting two forms of PairSmell - inapt separated pairs InSep. and inapt collocated pairs InCol, based on a curated dataset of over 6,135,000 pairs of entities derived from 11 open-source Java projects. The trained models achieve up to a 58.6% improvement in ROC-AUC over the baselines. The interpretation of the models reveals that the most influential features for InSep. are out-going dependencies, terms shared with others, and declared fields; while those for InCol include semantic similarity based on tf-idf, terms shared between the pair, terms shared with others, and in-going dependencies. We complement the work with a series of practical examples to illustrate how the influential pair characteristics impact the occurrence of PairSmell. Among our findings, a high number of out-going dependencies of a separated pair may raise questions about the separation, while a low level of shared terms may not justify collocating the two entities.

Software companies have streamlined their engineering processes, and continuous development has been key to achieving flexible, market-driven software solutions. Continuous software engineering (CSE) emerged as an approach to iteratively develop and maintain software, integrating business strategy, development, and operations aligned with agile principles. CSE activities also lead to technical debt (TD) buildup, negatively impacting software quality over time, so technical debt management (TDM) in CSE is crucial. However, TD in CSE is still poorly understood, as well as its causes and consequences, and how to better manage it. In addition, to the best of our knowledge, no study has investigated TDM in CSE. This paper then presents the state of the art of TDM in CSE, focusing on TD causes and consequences and how to manage them continuously. For this, we carefully examined the literature and selected 56 relevant studies from an initial set of 1,299. Our main findings indicate that the field is relatively young and has considerable industry involvement. While most studies reported an experience with TD in continuous and agile contexts or the use of systematic approaches for TDM (e.g., frameworks and processes), none investigated TD explicitly in CSE or tried to understand its causes and consequences in those contexts. Some CSE activities addressed TD, particularly those associated with development, such as continuous architecting, coding, verification/testing, and documentation. Other important activities at the business and operation levels were left aside. These findings supported us in defining a research agenda with important research opportunities that could contribute to maturing the field.

Context: Technical debt (TD) is a widely studied metaphor that helps to explain how sub-optimal decisions, which usually have short-term benefits, can harm software maintainability over time. Although incurring TD is not intrinsically bad, tracking and managing TD are crucial to avoid its negative effects. Hence, researchers and practitioners have proposed and developed diverse approaches and tools for managing TD. However, we are still lacking specialized tools for technical debt management (TDM), specifically ones that can be easily integrated into existing development workflows. Objective: We present and evaluate TagDebt, a bot that can be integrated within GitHub repositories and automatically assign labels to issues (i.e., SATD or non-SATD). TagDebt helps in the identification of TD (i.e., by looking for self-admitted technical debt (SATD)), leading to more efficient TDM. Methods: We carried out a Design Science Research study to design and implement TagDebt. For its evaluation, we executed a Technology Acceptance Model (TAM) study through interviews with 16 practitioners, to check the bot's usefulness, ease of use, and contextual factors that might impact the bot's usage (such as team size and practitioners' roles). Results: Overall, practitioners found that TagDebt is useful, especially for organizing issues and reducing manual work. Furthermore, they pointed out that the bot is overall easy to use, and its documentation is clear. The analysis also revealed that contextual factors, such as team and codebase size, impact the decision to adopt TagDebt. Finally, several improvements were suggested, such as including features to check and update the source code. Conclusion: TagDebt is a proof-of-concept for the development and usage of more specialized tools for TDM. It helps to make TD visible without disrupting existing workflows, which could lead to increased adoption of TDM tools and, consequently, help practitioners avoid the risks of unmanaged TD.

Infrastructure as Code (IaC) solutions such as HashiCorp's Terraform and Amazon Web Services’ CloudFormation are invaluable tools in dealing with the increasing complexity of deploying software systems continuously on the cloud, and the need to manage larger and more complex infrastructures. However, not many existing works have examined the cost implications of IaC adoption for cloud-based software systems. In this work, we apply thematic analysis to 2289 file diffs, spanning 828 commits from 618 repositories, to identify recurring solutions and ineffective practices in cost management of Terraform and CloudFormation artifacts. We uncover a catalog of five patterns and seven antipatterns, and analyze their (co-)occurrences. Our results indicate that many teams address cost reactively by making incremental fixes, while others take proactive steps such as configuring budgets, integrating cost reports, and designing preventative templates. To aid practitioners in catching these issues early, we also present a linter as an extension of the Checkov tool that automates detection of selected (anti)patterns in Terraform and CloudFormation files, offering real-time feedback on potential oversights. We evaluated the utility of this tool by applying it to 182 active open-source repositories and soliciting practitioner feedback. Our results reveal that while cost-related misconfigurations are widespread, developer engagement is limited, suggesting that cost optimization is often prioritized lower than security or functionality and addressed reactively. Together, this catalog and detection tool provide actionable insights for optimizing cloud resource management, enhancing cost efficiency, and fostering informed decision-making in cloud deployments.

Background. When developers write a TODO or FIXME comment, they are explicitly admitting that the code is suboptimal: a built-in warning that this logic deserves extra scrutiny. Yet it is an open question whether Self-Admitted Technical Debt (SATD) actually receives that scrutiny in the form of software testing. Aim. We aim to characterize the relationship between SATD and testing across three dimensions: the extent to which SATD-affected code is covered by existing tests, whether developers synchronize test additions with debt resolution, and whether such testing affects the long-term observability of resulting defects. Method. For that, we conducted an empirical study on eight open-source Java projects, analyzing test coverage of 784 SATD instances identified in the latest releases and performing a longitudinal examination of 5,175 SATD removal events. Results. Our results show that while 60.7% of SATD-affected code is covered by existing test suites, developers rarely synchronize test modifications with debt resolution; manual inspection confirms that only 3.4% of SATD removal commits include new tests specifically targeting the resolved debt (vs. 12.5% that co-add tests in the same commit). Longitudinal analysis further suggests that SATD resolutions exhibit nearly identical localized bug induction rates within short-to-medium-term windows regardless of test modifications. However, over a longer, unrestricted observation window, a slight divergence emerges where the test-added group reaches a higher cumulative defect alignment probability (6.32% vs. 4.37%), a counterintuitive trend potentially driven by the selective testing of inherently complex components. Conclusion. Developers treat SATD repayment as an ordinary code change rather than as a high-risk maintenance activity: most debt removals proceed without targeted verification, despite the developer's own prior flag that the code is suboptimal.

Architecture Decision Records (ADRs) play a critical role in preserving the rationale behind system design, yet their creation and maintenance are often neglected due to the associated authoring overhead. This paper investigates whether Large Language Models (LLMs) can mitigate this burden and, more importantly, how different strategies for presenting historical ADRs as context influence generation quality. We curate and validate a large corpus of sequential ADRs drawn from 750 open-source repositories and systematically evaluate five context selection strategies (no context, All-history, First-K, Last-K, and RAFG) across multiple model families. Our results show that context-aware prompting substantially improves ADR generation fidelity, with a small recency window (typically 3–5 prior records) providing the best balance between quality and efficiency. Retrieval-based context selection yields marginal gains primarily in non-sequential or cross-cutting decision scenarios, while offering no statistically significant advantage in typical linear ADR workflows. Overall, our findings demonstrate that context engineering, rather than model scale alone, is the dominant factor in effective ADR automation, and we outline practical defaults for tool builders along with targeted retrieval fallbacks for complex architectural settings.

Managing technical debt (TD) is critical to ensure the sustainability of long-term software projects. However, the time and cost involved in technical debt management (TDM) often discourage practitioners from performing this activity consistently. Continuous Integration and Continuous Delivery (CI/CD) pipelines offer an opportunity to support TDM by embedding automated practices directly into the development workflow. Despite this potential, it remains unclear how TDM tools could be integrated into CI/CD pipelines, and we still lack established best practices for this process. To address this problem, the objective of this study is to understand how TDM tools have been used in CI/CD pipelines and also identify potential configuration anti-patterns. To this end, we conducted a large-scale mining software repository (MSR) study on GitHub. In total, we collected around 600,000 Travis CI configuration files and 50,000 supporting scripts, and identified 3,684 pipelines that contain at least one TDM tool. We applied descriptive statistics to analyze the prevalence of tools and anti-patterns, and our findings show that most tools are executed and integrated using an external script; in addition, Absent Feedback is the most common configuration anti-pattern. We believe that researchers and practitioners can use the evidence of this study to further investigate how to improve both the tools that are integrated in CI/CD and the integration practices.

Continuous software engineering (CSE) has become essential for delivering flexible, market-driven software solutions by integrating development, operations, and business strategy under agile principles. CSE practices also lead to the accumulation of technical debt (TD), highlighting the importance of effective technical debt management (TDM). Traceability can play a key role in TDM by linking TD items to past decisions throughout the software life cycle. However, TD traceability remains underexplored in the literature. This study investigates how software practitioners manage the traceability of TD in CSE environments. We conducted eight semi-structured interviews to understand existing processes, tools used, and challenges. Findings reveal that TD traceability is generally ad hoc, lacks standardized practices, and is primarily supported by tools that focus on visualizing TD in backlogs without preserving decision rationale. These results point out to opportunities for future research to enhance TD traceability in CSE.

Kubernetes is one of the most active and long-lived open source projects, supporting core infrastructure for organisations worldwide. Its decade-long development has involved major architectural changes, multiple governance layers, and sustained efforts to manage technical debt without compromising stability. In this study, we examine the evolution of technical debt in Kubernetes by analysing a longitudinal dataset of 83,368 pull requests and 9,981 mailing list messages in 3,801 threads, spanning from the project's inception in 2014 through July 2025. We investigate when technical debt became a prominent concern in the community, how it was addressed through cleanup activities across different organisational units, and what emotional dynamics accompanied debt-related discussions. Our analysis combines LLM-based classification of mailing list discussions, time series analysis of pull request labels, and emotion detection in developer communications. The findings show that technical debt discussions peaked in 2016-2017, that the project maintained consistent cleanup effort since 2018, and that community attitudes towards debt remediation became increasingly positive over time. These results indicate how large-scale open source projects can embed technical debt management into organisational structure, labelling practices, and cultural norms.

The speed at which code changes are integrated into the software codebase, also referred to as code review velocity, is a prevalent industry metric for improved throughput and developer satisfaction. While prior studies have explored factors influencing review velocity, the role of the review assignment process, particularly the 'group review request', is unclear. In group review requests, available on platforms like Phabricator, GitHub, and Bitbucket, a code change is assigned to a reviewer group, allowing any member to review it, unlike individual review assignments to specific reviewers. Drawing parallels with shared task queues in Management Sciences, this study examines the effects of group versus individual review requests on velocity and quality. We investigate approximately 66,000 revisions in the Mozilla Firefox project, combining statistical modeling with practitioner views from a focus group discussion. Our study associates group reviews with improved review quality, characterized by fewer regressions, while having a negligible association with review velocity. Additional perceived benefits include balanced work distribution and training opportunities for new reviewers.

Rising publication pressure and the routine use of generative AI tools are reshaping how software engineering research is produced, assessed, and taught. While these developments promise efficiency, they also raise concerns about skill degradation, responsibility, and trust in scholarly outputs. This vision paper employs Design Fiction as a methodological lens to examine how such concerns might materialise if current practices persist. Drawing on themes reported in a recent community survey, we construct a speculative artifact situated in a near future research setting. The fiction is used as an analytical device rather than a forecast, enabling reflection on how automated assistance might impede domain knowledge competence, verification, and mentoring practices. By presenting an intentionally unsettling scenario, the paper invites discussion on how the software engineering research community in the future will define proficiency, allocate responsibility, and support learning.

Agent-based coding tools have transformed software development practices. Unlike prompt-based approaches that require developers to manually integrate generated code, these agent-based tools autonomously interact with repositories to create, modify, and execute code, including test generation. While many developers have adopted agent-based coding tools, little is known about how these tools generate tests in real-world development scenarios or how AI-generated tests compare to human-written ones. This study presents an empirical analysis of test generation by agent-based coding tools using the AIDev dataset. We extracted 5,745 commits containing test-related changes and investigated three aspects: the frequency of test additions, the structural characteristics of the generated tests, and their impact on code coverage. Our findings reveal that (i) AI authored 13.9% of all commits adding tests in real-world repositories, (ii) AI-generated test methods exhibit distinct structural patterns, featuring longer code and a higher density of assertions while maintaining lower cyclomatic complexity through linear logic, and (iii) AI-generated tests contribute to code coverage comparable to human-written tests, frequently achieving positive coverage gains across several projects.

We present MKR: Mining Kubernetes Repositories, a dataset capturing more than eleven years of development and community interaction in Kubernetes—an open-source platform for automating the deployment, scaling, and management of containerized applications. As the infrastructure backbone for running thousands of applications across diverse environments, Kubernetes has become one of the most widely adopted and influential projects in modern cloud-native computing. Spanning from June 2014 to July 2025, MKR integrates over two million artefacts from GitHub, including 130,832 commits (through July 2025), 83,368 pull requests, 46,768 issues, and 1,795,423 comments (through March 2025). With contributions from 28,890 unique GitHub commenters and 4,931 commit authors, MKR provides a longitudinal record of how Kubernetes has evolved, scaled, and been maintained over time. The dataset supports research on code evolution, long-term maintenance practices such as API deprecation, contributor retention, governance, and the role of automation in development. MKR allows analyses that connect technical change with decision-making, offering a resource for examining the social and technical dimensions of large-scale open source projects.

Context: In recent years, graph machine learning and particularly graph neural networks have seen successful and widespread applications in many fields, including static source code analysis. Such machine learning techniques enable learning on rich information networks capable of representing different relations and entities. However, there have been no comprehensive studies investigating the use of graph machine learning for static source code analysis. There is no complete systematic picture of what techniques may be considered tried and tested, and where opportunities for future improvements can still be found. Objective: The main goal of this study is to provide a broad overview of the state of the art of static source code analysis using graph machine learning. Methods: A systematic mapping was performed covering 4499 studies, presenting a final selection of 323 primary studies. Results: Among the selected studies, seven major sub-domains were identified. The use and combinations of artefacts, different graph representations, different features, and different machine learning models used were collected and categorised. Conclusions: The use of graph learning, and in particular graph neural networks, has increased significantly since 2018. Although a wide variety of methods is used, across every dimension we investigated (artefacts, graphs, features, models), we found small sets of technologies which are used in the vast majority of studies. Future opportunities lie in exploring under-explored domains more thoroughly, exploring the use of additional artefacts alongside source code, and paying more attention to interpretability and explainability.

Context Maintaining software projects over the long term requires controlling the accumulation of technical debt (TD). However, the time and cost associated with technical debt management (TDM) are often high, hindering practitioners from performing TDM tasks. Using tools for TDM has the potential to reduce the effort involved. Despite this, the adoption of such tools remains low, indicating a need for more efficient tool support. Objective This study aims to understand practitioners’ perspectives on tool support for TDM, specifically regarding the selection and use of these tools. Additionally, we identified potential requirements that could be implemented into existing or new TD tools. Method We surveyed practitioners and received 103 answers, from which 89 valid answers were analyzed using thematic synthesis and descriptive statistics. Results Practitioners’ decision-making processes regarding adopting tools are primarily driven by ten main concerns identified from practitioners’ responses (e.g., the load of information provided by tools). Additionally, we elicited 46 requirements and classified them into two main categories (“Information to be provided” and “Tool Usage”). Conclusion Practitioners aim to maintain control over tool execution and outputs. Our study then highlights the necessity of human-centered approaches for TDM automation, i.e., not only tools are essential, but the interaction between tools and practitioners is critical for a more efficient TDM.

The environmental impact of Artificial Intelligence (AI)-enabled systems is increasing rapidly, and software engineering plays a critical role in developing sustainable solutions. The ''Greening AI with Software Engineering'' workshop,1 funded by the Centre Europ´een de Calcul Atomique et Mol´eculaire (CECAM) and the Lorentz Center, provided an interdisciplinary forum for 29 participants, from practitioners to academics, to share knowledge, ideas, practices, and current results dedicated to advancing green software and AI research. The workshop was held February 3-7, 2025, in Lausanne, Switzerland. Through keynotes, flash talks, and collaborative discussions, participants identified and prioritized key challenges for the field. These included energy assessment and standardization, benchmarking practices, sustainability-aware architectures, runtime adaptation, empirical methodologies, and education. This report presents a research agenda emerging from the workshop, outlining open research directions and practical recommendations to guide the development of environmentally sustainable AI-enabled systems rooted in software engineering principles.

Enhancing the modular structure of existing systems has attracted substantial research interest, focusing on two main methods: (1) software modularization and (2) identifying design issues (e.g., smells) as refactoring opportunities. However, remodularization solutions often require extensive modifications to the original modules, and the design issues identified are generally too coarse to guide refactoring strategies. Combining the above two methods, this paper introduces a novel concept, PairSmell, which exploits modularization to pinpoint design issues necessitating refactoring. We concentrate on a granular but fundamental aspect of modularity principles-modular relation (MR), i.e., whether a pair of entities are separated or collocated. The main assumption is that, if the actual MR of a pair violates its 'apt MR', i.e., an MR agreed on by multiple modularization tools (as raters), it can be deemed likely a flawed architectural decision that necessitates further examination. To quantify and evaluate PairSmell, we conduct an empirical study on 20 C/C++ and Java projects, using 4 established modularization tools to identify two forms of PairSmell: inapt separated pairs $InSep$ and inapt collocated pairs $InCol$. Our study on 260,003 instances reveals that their architectural impacts are substantial: (1) on average, 14.60 % and 20.44 % of software entities are involved in $InSep$ and $InCol$ MRs respectively; (2) $InSep$ pairs are associated with 190 % more co-changes than properly separated pairs, while $InCol$ pairs are associated with 35% fewer co-changes than properly collocated pairs, both indicating a successful identification of modular structures detrimental to software quality; and (3) both forms of PairSmell persist across software evolution. This evidence strongly suggests that PairSmell can provide meaningful insights for inspecting modular structure, with the identified issues being both granular and fundamental, making the enhancement of modular design more efficient.

Managing technical debt (TD) is essential for maintaining long-term software projects. Nonetheless, the time and cost involved in technical debt management (TDM) are often high, which may lead practitioners to omit TDM tasks. The adoption of tools, and particularly the usage of automated solutions, can potentially reduce the time, cost, and effort involved. However, the adoption of tools remains low, indicating the need for further research on TDM automation. To address this problem, this study aims at understanding which TDM activities practitioners are discussing with respect to automation in TDM, what tools they report for automating TDM, and the challenges they face that require automated solutions. To this end, we conducted a mining software repositories (MSR) study on three websites of Stack Exchange (Stack Overflow, Project Management, and Software Engineering) and collected 216 discussions, which were analyzed using both thematic synthesis and descriptive statistics. We found that identification and measurement are the most cited activities. Furthermore, 51 tools were reported as potential alternatives for TDM automation. Finally, a set of nine main challenges were identified and clustered into two main categories: challenges driving TDM automation and challenges related to tool usage. These findings highlight that tools for automating TDM are being discussed and used; however, several significant barriers persist, such as tool errors and poor explainability, hindering the adoption of these tools. Moreover, further research is needed to investigate the automation of other TDM activities such as TD prioritization.

Smart Contracts are pieces of software that are deployed in Blockchain infrastructures to enable the interaction (and production of value) between unknown parties, without intermediaries, but in a trustworthy and transparent manner. A key to Smart Contracts' success is their delivery to excellent standards of quality (e.g., security, documentation, code understandability etc.). To achieve this goal, the development of Smart Contracts needs to be driven by proven software engineering practices. In this paper, we conducted a systematic mapping study to get a comprehensive overview on how "good" software engineering practices are applied to Smart Contract Development. To identify primary studies that lie on the intersection of software engineering and smart contract development, we have selected specific publication venues and queried the literature. After applying the selection criteria, 113 studies were identified, analyzed, and synthesized results have been reported. The results provided some actionable implications for researchers and practitioners.

Context: The popularity of cloud computing as the primary platform for developing, deploying, and delivering software is largely driven by the promise of cost savings. Therefore, it is surprising that no empirical evidence has been collected to determine whether cost awareness permeates the development process and how it manifests in practice. Objective: This study aims to provide empirical evidence of cost awareness by mining open source repositories of cloud-based applications. The focus is on Infrastructure as Code artifacts that automate software (re)deployment on the cloud. Methods: A systematic search through 152,735 repositories resulted in the selection of 2,010 relevant ones. We then analyzed 538 relevant commits and 208 relevant issues using a combination of inductive and deductive coding. Results: The findings indicate that developers are not only concerned with the cost of their application deployments but also take actions to reduce these costs beyond selecting cheaper cloud services. We also identify research areas for future consideration. Conclusion: Although we focus on a particular Infrastructure as Code technology (Terraform), the findings can be applicable to cloud-based application development in general. The provided empirical grounding can serve developers seeking to reduce costs through service selection, resource allocation, deployment optimization, and other techniques.

Technical Debt (TD) refers to non-optimal decisions made in software projects that may lead to short-term benefits, but potentially harm the system's maintenance in the long-term. Technical debt management (TDM) refers to a set of activities that are performed to handle TD, e.g., identification. These activities can entail tasks such as code and architectural analysis, which can be time-consuming if done manually. Thus, substantial research work has focused on automating TDM tasks (e.g., automatic identification of code smells). However, there is a lack of studies that summarize current approaches in TDM automation. This can hinder practitioners in selecting optimal automation strategies to efficiently manage TD. It can also prevent researchers from understanding the research landscape and addressing the research problems that matter the most. Thus, the main objective of this study is to provide an overview of the state of the art in TDM automation, analyzing the available tools, their use, and the challenges in automating TDM. For this, we conducted a systematic mapping study (SMS), and from an initial set of 1086 primary studies, 178 were selected to answer three research questions covering different facets of TDM automation. We found 121 automation artifacts, which were classified in 4 different types (i.e., tools, plugins, scripts, and bots); the inputs/outputs and interfaces were also collected and reported. Finally, a conceptual model is proposed that synthesizes the results and allows to discuss the current state of TDM automation and related challenges. The results show that the research community has investigated to a large extent how to perform various TDM activities automatically, considering the number of studies and automation artifacts we identified. More research is needed towards fully automated TDM, specially concerning the integration of the automation artifacts.

Refactoring is the most prominent way of repaying Technical Debt and improving software maintainability. Despite the acknowledgement of refactorings as a state-of-practice technique (both by industry and academia), refactoring-based quality optimizations are debatable due to three important concerns: (a) the impact of a refactoring on quality is not always positive; (b) the list of available refactoring candidates is usually vast, restricting developers from applying all suggestions; and (c) there is no empirical evidence on which parameters are related to positive refactoring impact on quality. To alleviate these concerns, we reuse a benchmark (constructed in a previous study) of real-world refactorings having either a positive or negative impact on quality; and we explore the parameters (structural characteristics of classes) affecting the impact of the refactoring. Based on the findings, we propose a metrics-based approach for guiding practitioners on how to prioritize refactoring candidates. The results of the study suggest that classes with high coupling and large size should be given priority, since they tend to have a positive impact on technical debt.

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 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.

Large software companies strive to make their engineering processes fast, and agile development has been a key enabler for flexible delivery of solutions following the market needs. In this context, continuous software engineering (CSE) has emerged as a way to iteratively develop software using practices that encompass business strategy, development, and operations that are aligned with the agile methodology. However, these practices can also lead to the accumulation of technical debt (TD), which has shown to be harmful to the software in the long-term. Due to its impact, TD should be managed in the context of CSE. However, to the best of our knowledge, there is a lack of an overview of how TD has been addressed in this context. In this study, we present the state of the art of TD in CSE; for this, we scrutinized the literature and found 41 studies. Our main findings show that this field of study is relatively new, with active participation of the industry, and that most CSE activities are not addressing TD yet; therefore, presenting a number of opportunities for future research.

Cloud adoption is historically driven by cost considerations. As the complexity of the software systems deployed on the cloud continuously increases, and with it also the need to manage larger and more complex infrastructures, Infrastructure as Code (IaC) approaches become invaluable tools. However, not many existing works have looked into the cost implications of IaC use for cloud-based software. In this work we build on an existing dataset that has looked into cost-related commits on IaC artifacts in open-source repositories in order to identify recurring solutions and ineffective practices in cost management. We present a catalog of patterns and antipatterns organizing our findings, and discuss its implication for practitioners and researchers.

Artificial intelligence (AI) has become increasingly popular in software development to automate tasks and improve efficiency. AI has the potential to help while developing or maintaining software, in the sense that it can produce solutions out of a textual requirement specification, and understand code to provide suggestion on how a new requirement could be implemented. In this paper, we focus on the first scenario. Two AI-powered tools that have the potential to revolutionize the way software is developed are OpenAI's ChatGPT and GitHub's Copilot. In this paper, we used LeetCode, a popular platform for technical interview preparation and personal upskilling (self-learning), to evaluate the effectiveness of ChatGPT and Copilot on a set of coding problems, along with ChatGPT's ability to correct itself when provided with feedback. The analysis of the effectiveness can lead to various conclusions, such as on if these solutions are ready to take over coding roles, and to what extent several parameters (difficulty and quality requirements) influence this result. Solutions have been generated for 60 problems using ChatGPT and Copilot, for the Python programming language. We investigated the performance of the models, the recurrent kinds of errors, and the resulting code quality. The evaluation revealed that ChatGPT and Copilot can be effective tools for generating code solutions for easy problems while both models are prone to syntax and semantic errors. Small improvements are observed for ode quality metrics across iterations, although the improvement pattern is not consistently monotonic, questioning ChatGPT's awareness of the quality of its own solutions. Nevertheless, the improvement that was found along iterations, highlights the potential of AI and humans, acting as partners, in providing the optimal combination. The two models demonstrate a limited capacity for understanding context. Although AI-powered coding tools driven by large language models have the potential to assist developers in their coding tasks, they should be used with caution and in conjunction with human coding expertise. Developer intervention is necessary not only to debug errors but also to ensure high-quality and optimized code.

Context: Although Technical Debt (TD) has increasingly gained attention in recent years, most studies exploring TD are based on a single source (e.g., source code, code comments or issue trackers). Objective: Investigating information combined from different sources may yield insight that is more than the sum of its parts. In particular, we argue that exploring how TD items are managed in both issue trackers and software repositories (including source code and commit messages) can shed some light on what happens between the commits that incur TD and those that pay it back. Method: To this end, we randomly selected 3,000 issues from the trackers of five projects, manually analyzed 300 issues that contained TD information, and identified and investigated the lifecycle of 312 TD items. Results: The results indicate that most of the TD items marked as resolved in issue trackers are also paid back in source code, although many are not discussed after being identified in the issue tracker. Test Debt items are the least likely to be paid back in source code. We also learned that although TD items may be resolved a few days after being identified, it often takes a long time to be identified (around one year). In general, time is reduced if the same developer is involved in consecutive moments (i.e., introduction, identification, repayment decision-making and remediation), but whether the developer who paid back the item is involved in discussing the TD item does not seem to affect how quickly it is resolved. Conclusions: Investigating how developers manage TD across both source code repositories and issue trackers can lead to a more comprehensive oversight of this activity and support efforts to shorten the lifecycle of undesirable debt.

In software quality management, the selection strategy for proper metrics varies depending on the application scenarios and measurement objectives. MicroService Architecture (MSA), despite being commonly employed nowadays, still cannot be reliably measured and compared if the microservices in a system are independent. Software managers and architects need to understand whether their microservices are “decoupled enough”, if not, which ones are over-coupled, and by how much. In this paper, we contribute a novel set of metrics – Microservice Coupling Index (MCI) – derived from the relative measurement theory. Instead of measuring coupling evidence with simple counts, we measure how dependent and coupled the microservices are relative to the possible couplings between them. We measured the MCI metrics for 15 open source projects that involve 113 distinct microservices. Empirical investigation confirmed that MCIs differ quite significantly from existing coupling measures and that they are more discriminative than existing ones for separating high and low degrees of microservice couplings and thus more useful in comparing design alternatives. A series of experimental studies were conducted, showing that the larger the MCIs, the less likely the bugs and changes can be localized and separated, and the less likely that the individual microservices in a system can be independently developed and evolved.

The rapid adoption of digital technologies has revolutionized business operations and introduced emerging concepts such as Digital Twin (DT) technology, which has the potential to predict system responses before they occur, making it an attractive option for smart and sustainable tourism. However, implementing DT software systems poses significant challenges, including compliance with regulations and effective communication among stakeholders, and concerns surrounding security, privacy, and trust with the use of big data. To address these challenges, this paper proposes a documentation framework for architectural decisions (DFAD) that applies the concept of big data governance to the digital system. The framework aims to ensure accountability, transparency, and trustworthiness while adhering to rules and regulations. To demonstrate its applicability, a case study and three case scenarios on the potential use of Mobile Positioning Data (MPD) in Indonesia for DT technology in smart and sustainable tourism were examined. The paper highlights the benefits of DFAD in shaping stakeholder communication and human-machine interactions while leveraging the potential of MPD to measure tourism statistics by Statistics Indonesia since 2016. Not only the documentation framework promotes compliance with regulations, but it also facilitates effective communication among stakeholders and enhances trust and transparency in the use of big data in DT technology for smart and sustainable tourism. This paper emphasizes the importance of effective big data governance and its potential to promote sustainable tourism practices. The multidisciplinarity approach on political science, software engineering, tourism, and official statistics provides an opportunity for academic contribution and decision-making processes.

The batch size is an essential parameter to tune during the development of new neural networks. Amongst other quality indicators, it has a large degree of influence on the model’s accuracy, generalisability, training times and parallelisability. This fact is generally known and commonly studied. However, during the application phase of a deep learning model, when the model is utilised by an end-user for inference, we find that there is a disregard for the potential benefits of introducing a batch size. In this study, we examine the effect of input batching on the energy consumption and response times of five fully-trained neural networks for computer vision that were considered state-of-the-art at the time of their publication. The results suggest that batching has a significant effect on both of these metrics. Furthermore, we present a timeline of the energy efficiency and accuracy of neural networks over the past decade. We find that in general, energy consumption rises at a much steeper pace than accuracy and question the necessity of this evolution. Additionally, we highlight one particular network, ShuffleNetV2 (2018), that achieved a competitive performance for its time while maintaining a much lower energy consumption. Nevertheless, we highlight that the results are model dependent.

Modern AI practices all strive towards the same goal: better results. In the context of deep learning, the term "results" often refers to the achieved accuracy on a competitive problem set. In this paper, we adopt an idea from the emerging field of $\color{green}{\text{Green AI}}$ to consider energy consumption as a metric of equal importance to accuracy and to reduce any irrelevant tasks or energy usage. We examine the training stage of the deep learning pipeline from a sustainability perspective, through the study of hyperparameter tuning strategies and the model complexity, two factors vastly impacting the overall pipeline’s energy consumption. First, we investigate the effectiveness of grid search, random search and Bayesian optimisation during hyperparameter tuning, and we find that Bayesian optimisation significantly dominates the other strategies. Furthermore, we analyse the architecture of convolutional neural networks with the energy consumption of three prominent layer types: convolutional, linear and ReLU layers. The results show that convolutional layers are the most computationally expensive by a strong margin. Additionally, we observe diminishing returns in accuracy for more energy-hungry models. The overall energy consumption of training can be halved by reducing the network complexity. In conclusion, we highlight innovative and promising energy-efficient practices for training deep learning models. To expand the application of $\color{green}{\text{Green AI}}$, we advocate for a shift in the design of deep learning models, by considering the trade-off between energy efficiency and accuracy.

Context: Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it can be particularly effective, as developers are experts in their own code and are well-suited to fix the corresponding TD issues. Objective: The goal of our study is to investigate self-fixed technical debt, especially the extent in which TD is self-fixed, which types of TD are more likely to be self-fixed, whether the remediation time of self-fixed TD is shorter than non-self-fixed TD and how development behaviors are related to self-fixed TD. Method: We report on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 44,000 commits obtained from 20 Python and 16 Java projects of the Apache Software Foundation. Results: The results show that about half of the fixed issues are self-fixed and that the likelihood of contained TD issues being self-fixed is negatively correlated with project size, the number of developers and total issues. Moreover, there is no significant difference of the survival time between self-fixed and non-self-fixed issues. Furthermore, developers are more keen to pay back their own TD when it is related to lower code level issues, e.g., Defect Debt and Code Debt. Finally, developers who are more dedicated to or knowledgeable about the project contribute to a higher chance of self-fixing TD. Conclusions: These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities and refining strategies within development teams, and by informing the development of TD management tools.

Sustainable tourism research focuses on mitigating or remediating environmental, social and economic impacts on tourism. In the past years, Big Data approaches have been applied to the field of tourism allowing for remarkable progress. However, there seems to be little evidence to support that such approaches are an inspiration to sustainable tourism and are being implemented. In this context, we aim to obtain a comprehensive overview of the use of Big Data in sustainable tourism to address various issues and understand how Big Data can support decision-making in such scenarios. To that end, this paper reports on the results of a literature review via a combination of a Systematic Literature Review (SLR) in Software Engineering, and the use of the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) method. In summary, we investigated four facets: (a) sources of big data, (b) approaches, (c) purposes, and (d) contexts of application. The results suggest that the use of various approaches have impacted practices in sustainable tourism. The findings provide a thorough understanding of the state of the art of Big Data application in sustainable tourism and provide valuable insights to foster growth both in terms of research and practice.

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.

In recent years, the evolution of software ecosystems and the detection of technical debt received significant attention by researchers from both industry and academia. While a few studies that analyze various aspects of technical debt evolution already exist, to the best of our knowledge, there is no large‐scale study that focuses on the remediation of technical debt over time in Python projects—that is, one of the most popular programming languages at the moment. In this paper, we analyze the evolution of technical debt in 44 Python open‐source software projects belonging to the Apache Software Foundation. We focus on the type and amount of technical debt that is paid back. The study required the mining of over 60K commits, detailed code analysis on 3.7K system versions, and the analysis of almost 43K fixed issues. The findings show that most of the repayment effort goes into testing, documentation, complexity, and duplication removal. Moreover, more than half of the Python technical debt is short term being repaid in less than 2 months. In particular, the observations that a minority of rules account for the majority of issues fixed and spent effort suggest that addressing those kinds of debt in the future is important for research and practice.

Software reuse is a widely adopted practice among both researchers and practitioners. The relation between security and reuse can go both ways: a system can become more secure by relying on mature dependencies, or more insecure by exposing a larger attack surface via exploitable dependencies. To follow up on a previous study and shed more light on this subject, we further examine the association between software reuse and security threats. In particular, we empirically investigate 1244 open-source projects in a multiple-case study to explore and discuss the distribution of security vulnerabilities between the code created by a development team and the code reused through dependencies. For that, we consider both potential vulnerabilities, as assessed through static analysis, and disclosed vulnerabilities, reported in public databases. The results suggest that larger projects in size are associated with an increase on the amount of potential vulnerabilities in both native and reused code. Moreover, we found a strong correlation between a higher number of dependencies and vulnerabilities. Based on our empirical investigation, it appears that source code reuse is neither a silver bullet to combat vulnerabilities nor a frightening werewolf that entail an excessive number of them.

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners' intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies.

Software patterns are well known to both researchers and practitioners. They emerge from the need to tackle problems that become ever more common in development activities. Thus, it is not surprising that patterns have also been explored as a means to address issues...

During the last years the TD community is striving to offer methods and tools for reducing the amount of TD, but also understand the underlying concepts. One popular practice that still has not been investigated in the context of TD, is software reuse. The aim of this paper is to investigate the relation between white-box code reuse and TD principal and interest. In particular, we target at unveiling if the reuse of code can lead to software with better levels of TD. To achieve this goal, we performed a case study on approximately 400 OSS systems, comprised of 897 thousand classes, and compare the levels of TD for reused and natively-written classes. The results of the study suggest that reused code usually has less TD interest; however, the amount of principal in them is higher. A synthesized view of the aforementioned results suggest that software engineers shall opt to reuse code when necessary, since apart from the established reuse benefits (i.e., cost savings, increased productivity, etc.) are also getting benefits in terms of maintenance. Apart from understanding the phenomenon per se, the results of this study provide various implications to research and practice.

The major challenge that a developer confronts when building IoT systems is the management of a plethora of technologies implemented with various constraints, from different manufacturers, that at the end need to cooperate. In this paper we argue that developers can benefit from IoT frameworks by reusing their components so as to build in less time and effort IoT systems that can easily integrate new technologies. In order to explore the reuse opportunities offered by IoT frameworks we have performed a case study and analyzed 503 components reused by 35 IoT projects. We examined (a) the types of functionality that are most facilitated for reuse (b) the reuse strategy that is most adopted (c) the quality of the reused components. The results of the case study suggest that the main functionality reused is the one related to the Device Management layer and that Black-box reuse is the main type. Moreover, the quality of the reused components is improved compared to the rest of the components built from scratch.

Technical Debt (TD) can be paid back either by those that incurred it or by others. We call the former self-fixed TD, and it is particularly effective, as developers are experts in their own code and are best-suited to fix the corresponding TD issues. To what extent is TD self-fixed, which types of TD are more likely to be self-fixed and is the remediation time of self-fixed TD shorter than non-self-fixed TD? This paper attempts to answer these questions. It reports on an empirical study that analyzes the self-fixed issues of five types of TD (i.e., Code, Defect, Design, Documentation and Test), captured via static analysis, in more than 17,000 commits from 20 Python projects of the Apache Software Foundation. The results show that more than two thirds of the issues are self-fixed and that the self-fixing rate is negatively correlated with the number of commits, developers and project size. Furthermore, the survival time of self-fixed issues is generally shorter than non-self-fixed issues. Moreover, the majority of Defect Debt tends to be self-fixed and has a shorter survival time, while Test Debt and Design Debt are likely to be fixed by other developers. These results can benefit both researchers and practitioners by aiding the prioritization of TD remediation activities within development teams, and by informing the development of TD management tools.

Technical debt (TD) reflects issues that may negatively affect software maintenance and evolution. There is currently little evidence on how the different types of TD co-occur; for example, how code smells and design smells affect the same part of the system. This paper investigates how different types of TD co-occur, as well as the time period of the co-occurrence. To that end, we analyzed the co-occurring associations between five types of TD, captured in 42 SonarQube rules, in 3862 files of 20 Python projects from the Apache Software Foundation. We found that this phenomenon is dominant, affecting more than 90% of Python files. We also found that Documentation Debt and Test Debt appear in the majority of the files, although it seems to be mostly by coincidence. Finally, we noticed that co-occurrence of TD seems to happen very quickly: co-occurring issues tend to be introduced within the same week. But once it does happen, it is hard to get rid of. These results can benefit both researchers and practitioners by: aiding the prioritization of TD remediation; leading to novel tools for detecting co-occurring TD and warning potential issues; shedding further light on the explanation of how TD is introduced and can be mitigated.

Systems of Systems (SoS) are playing an important role in many critical sectors of our society as an answer to the ever-growing complexity of software-intensive systems. Resulting from the interoperability among independent constituent systems, SoS can perform more complex and larger missions, not achievable by any of the constituents operating individually. Moreover, the amount of data produced by the constituents can be put together to discover essential knowledge to more adequately achieve the SoS missions. This chapter analyzes the evolution of previous and recent approaches for knowledge discovery in SoS and compares them with existing ones for monolithic systems. We distill some conclusions and new insights and present an agenda for future research in this ever-growing topic.

Context GoF patterns have been extensively studied with respect to the benefit they provide as problem-solving, communication and quality improvement mechanisms. The latter has been mostly investigated through empirical studies, but some aspects of quality (esp. run-time ones) are still under-investigated. Objective In this paper, we study if the presence of patterns enforces the conformance to good coding practices. To achieve this goal, we explore the relationship between the presence of GoF design patterns and violations of good practices related to source code correctness, performance and security, via static analysis. Method Specifically, we exploit static analysis so as to investigate whether the number of violations of good coding practices identified on classes is related to (a) their participation in pattern occurrences, (b) the pattern category, (c) the pattern in which they participate, and (d) their role within the pattern occurrence. To answer these questions, we performed a case study on approximately 13,000 classes retrieved from five open-source projects. Results The obtained results suggest that classes not participating in patterns are more probable to violate good coding practices for correctness, performance and security. In a more fine-grained level of analysis, by focusing on specific patterns, we observed that patterns with more complex structure (e.g., Decorator) and pattern roles that are more change-prone (e.g., Subclasses) are more likely to be associated with a higher number of violations (up to 50 times more violations). Conclusion This finding implies that investing in a well-thought architecture based on best practices, such as patterns, is often accompanied with cleaner code with fewer violations.

Reuse is a common and often-advocated software development practice. Significant efforts have been invested into facilitating it, leading to advancements such as software forges, package managers, and the widespread integration of open source components into proprietary software systems. Reused software can make a system more secure through its maturity and extended vetting, or increase its vulnerabilities through a larger attack surface or insecure coding practices. To shed more light on this issue, we investigate the relationship between software reuse and potential security vulnerabilities, as assessed through static analysis. We empirically investigated 301 open source projects in a holistic multiple-case methods study. In particular, we examined the distribution of potential vulnerabilities between the native code created by a project's development team and external code reused through dependencies, as well as the correlation between the ratio of reuse and the density of vulnerabilities. The results suggest that the amount of potential vulnerabilities in both native and reused code increases with larger project sizes. We also found a weak-to-moderate correlation between a higher reuse ratio and a lower density of vulnerabilities. Based on these findings it appears that code reuse is neither a frightening werewolf introducing an excessive number of vulnerabilities nor a silver bullet for avoiding them.

Smart Homes consist of a plethora of IoT devices most of which developed by different manufacturers. To handle the diversity of IoT devices within the context of Smart Home automation, literature has suggested the use of frameworks. In this paper we argue that developers can benefit from such frameworks as a solution to build flexible and easily extendable systems by reusing their components. For this purpose, we explore the reuse opportunities that can be offered by Eclipse Smart Home (ESH) framework. In particular, we performed a case study and analyzed 107 packages from the ESH framework that offered 240 reusable components to the OpenHab application. We investigated (a) which types of functionality are mostly facilitated for reuse (b) which types of reuse are mostly adopted and what is the integration effort required (c) what is the quality of the reused components and compared them to the components built from scratch. The results of the case study suggest that: the main functionality reused is the one related to Interface Adapters and the main type of reuse is Variable Type. Regarding the effort for integrating the reused components it can range from 38 lines of code to 1421 lines of code. Moreover, the quality of the reused components is slightly improved compared to the rest of the components built from scratch.

The gang of four design patterns are widely adopted in industry as best practices and their effect on software quality has been long investigated in academia, with both positive and negative consequences being observed. One important parameter that relates to the effect of patterns on quality is the deterioration of pattern instances due to the buildup of artifacts unrelated to the pattern structure. This is called pattern grime and can potentially diminish some of the benefits of using patterns in the first place. In this paper we investigate the relation between pattern grime and three qualities, namely performance, security, and correctness. To this end, we conducted a case study with five industrial projects (approx. 260 000 lines of code) implemented by 16 developers. Our findings suggest a correlation between the accumulation of grime and decreased levels of performance, security, and correctness. Moreover, factors such as the project itself, pattern type and the developer can influence this relation. The obtained results can benefit both researchers and practitioners, as we provide evidence on the accumulation of pattern grime and its correlation to performance, security and correctness, and how different factors affect these correlations.

Critical Embedded Systems (CES) are systems in which failures are potentially catastrophic and, therefore, hard constraints are imposed on them. In the last years the amount of software accommodated within CES has considerably changed. For example, in smart cars the amount of software has grown about 100 times compared to previous years. This change means that software design for these systems is also bounded to hard constraints (e.g., high security and performance). Along the evolution of CES, the approaches for designing them are also changing rapidly, so as to fit the specialized needs of CES. Thus, a broad understanding of such approaches is missing. Therefore, this study aims to establish a fair overview on CESs design approaches. For that, we conducted a Systematic Mapping Study (SMS), in which we collected 1,673 papers from five digital libraries, filtered 269 primary studies, and analyzed five facets: design approaches, applications domains, critical quality attributes, tools, and type of evidence. Our findings show that the body of knowledge is vast and overlaps with other types of systems (e.g., real-time or cyber-physical systems). In addition, we have observed that some critical quality attributes are common among various application domains, as well as approaches and tools are oftentimes generic to CES.

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.

Context: GoF design patterns are popular among both researchers and practitioners, in the sense that software can be largely comprised of pattern instances. However, there are concerns regarding the efficacy with which software engineers maintain pattern instances, which tend to decay over the software lifetime if no special emphasis is placed on them. Pattern grime (i.e., degradation of the instance due to buildup of unrelated artifacts) has been pointed out as one recurrent reason for the decay of GoF pattern instances. Goal: Seeking to explore this issue, we investigate the existence of relations between the accumulation of grime in pattern instances and various related factors: (a) projects, (b) pattern types, (c) developers, and (d) the structural characteristics of the pattern participating classes. Method: For that, we empirically assessed these relations through an industrial exploratory case study involving five projects (approx. 260,000 lines of code). Results: Our findings suggest a linear accumulation of pattern grime, which may depend on pattern type and developer. Moreover, we present and discuss a series of correlations between the accumulation of pattern grime and structural characteristics. Conclusions: The outcome of our study can benefit both researchers and practitioners, as it points to interesting future work opportunities and also implications relevant to the refinement of best practices, the raise awareness among developers, and the monitoring of pattern grime accumulation.

Complex software-intensive systems are more and more required as a solution for diverse critical application domains; at the same time, software architecture and also reference architecture have attracted attention as means to more adequately produce and evolve such systems. The main goal of this paper is to summarize our principal contributions in software architecture and reference architecture of software-intensive systems, including Systems-of-Systems. We intend this work can also inspire the opening of other related research lines towards founding the sustainability of such software-intensive systems.

During the development of Critical Embedded Systems (CES), quality attributes that are critical for them (e.g., correctness, security, etc.) must be guaranteed. However, this often leads to complex quality trade-offs, since non-critical qualities (e.g., reusability, understandability, etc.) may be compromised. In this study, we aim at empirically investigating the existence of quality trade-offs, on the implemented architecture, among versions of open source CESs, and compare them with those of systems from other application domains. The results of the study suggest that in CES, non-critical quality attributes are usually compromised in favor of critical quality attributes. On the contrary, we have not observed compromises of critical qualities in favor of non-critical ones in either CES or other application domains. Furthermore, quality trade-offs are more frequent among critical quality attributes, compared to trade-offs among non-critical quality attributes. Our study has implications for both practitioners when making trade-offs in practice, as well as researchers that investigate quality trade-offs.

Critical embedded systems (CES) have become ubiquitous in the modern society, like in cars and energy appliances. However, besides their popularity, engineering of these systems is still particularly challenging. One of the greatest challenges in the development of such systems is their expected high standards of reliability. One of the key solutions to overcome this challenge is to design a sound architecture and validate it against critical quality attributes (CQAs), such as safety, dependability, security and performance. However, currently there are no established architecting processes or methods that are specialized for the domain of CES. Consequently, these systems are sometimes developed without focusing on their architectural design and their level of quality. Thus, the main goal of this PhD project is to develop an architecture design method, specialized in decisions that impacts CQAs. In the context of this project, the proposed method will be evaluated, through an industrial collaborations, with companies of two important application domains: Smart Grid and Ambient Assisted Living.

Reference architectures have emerged as a special type of software architecture that achieves well-recognized understanding of specific domains, promoting reuse of design expertise and facilitating the development, standardization, and evolution of software systems. Because of their advantages, several reference architectures have been proposed and have been also successfully used, including in the industry. However, the most of these architectures are still built using an ad-hoc approach, lacking of a systematization to their construction. If existing, these approaches could motivate and promote the building of new architectures and also support evolution of existing ones. In this scenario, the main contribution of this paper is to present the evolution of ProSA-RA, a process that systematizes the design, representation, and evaluation of reference architectures. ProSA-RA has been already applied in the establishment of reference architectures for different domains and this experience was used to evolve our process. In this paper, we illustrate an application of ProSA-RA in the robotics domain. Results achieved through the use of ProSA-RA have showed us that it is a viable, efficient process and, as a consequence, it could contribute to the reuse of knowledge in several applications domains, by promoting the establishment of new reference architectures.

Embedded systems are computers designed to perform specialized tasks. Examples of embedded systems include printers, consoles and televisions. The software that controls embedded systems usually present critical requirements, since, many times, their failure may result in human harm or environmental damage. Therefore, the design of such software requires a quality driven approach. In software engineering, reference architectures are reusable software engineering artifacts introduced to facilitate the design of software architectures of a given domain. The adoption of reference architectures in embedded systems design offers advantages that could help improve their quality. To assure that the reference architecture presents all required information and address all concerns, it is important to have means of evaluating it, but available evaluation methods for reference architecture require adaptation and may have limitations. In this context, this work introduces a checklist for evaluation of reference architectures of embedded systems. We elaborate on a web based tool that could support the checklist application. To evaluate this checklist, we considered the opinion of experts in software architecture and reference architecture. Also, we successfully applied the checklist in an academic reference architecture project. We expect that this work contributes to the evaluation of reference architectures of embedded systems. Finally, we intend that this work could open interesting, new research perspectives in this direction.

Currently, robotic systems have been more and more required for a diversity of new products, such as in domestic robots and in robots for dangerous environments. As a consequence, an increase in the complexity of these systems is observed, requiring also considerable attention to their quality and productivity. In another perspective, reference architectures have emerged as a special type of software architecture that achieves well-recognized understanding of specific domains, facilitating the development, standardization, and evolution of software systems. In this perspective, reference architectures have also been proposed for the robotic domain and they have been considered an important element to the development of systems for that domain. However, there is a lack of work that present an panorama about these architectures; furthermore, there exists no support to choose a reference architecture when developing or evolving robotic systems. Thus, the main contribution of this paper is to present a panorama about reference architectures of the robotic domain, in particular, for mobile robots. It is worth highlighting that we used the systematic review technique to identify and investigate these architectures. We have found that these architectures have in general become consolidated and have already contributed to the industry during the development of robotic systems. Besides that, results of our investigation could support the decision about which architecture to adopt aiming to develop a new software. Also, our analysis could help to create new reference architectures. However, there are still important perspectives of research that need to be investigated.

The multi-agent patrolling problem has recently received growing attention from the community due to the wide range of potential applications. This work presents an autonomous patrolling system composed by 4 intelligent robots that can freely move through an indoor environment and detect intruders. The robots use a localization/navigation system composed of an artificial neural network (ANN) trained to detect key features of the environment. These features are used to identify context changes, being used as input of a finite state machine (FSM), allowing a topological map localization and navigation of the robot in the environment. When an intruder is detected, a broadcast message with its position is sent, making all other robots execute a multi-agent version of a coordinated A* algorithm in order to determine the best path to reach that position and to surround the target. Then, the robots autonomously navigate through this defined path until reach the goal. Experiments were performed in the player/stage environment in order to evaluate the multi-agent system. The localization/navigation system with intruder detection was evaluated in the real world with a Pioneer P3-AT mobile robot.

Software architectures and reference architectures have been playing a significant role in determining the success of software Systems. In particular, reference architectures have emerged, achieving well-recognized understanding of specific domains, promoting reuse of design expertise and facilitating the development of Systems. In another perspective, agile methodologies have been widely adopted as a promising iterative, incremental and collaborative software development process, including by the software industry. Considering the relevance of reference architectures, initiatives of agile methodologies exploring these architectures are also found. However, there is a lack of a panorama about the uses, impacts and perspectives of such architectures in the agile context. The main objective of this paper is present an detailed view about how reference architectures have been used in the context of agile methodologies. For this, we applied Systematic Review, a technique to systematically explore, organize, summarize, and assess all contributions of a specific research area. As main result, we have observed that reference architecture and agile methodology should be more investigated together. Furthermore, we intend to contribute to open perspectives of new and important research lines.

Context: Systematic mapping provides an overview of a research area to assess the quantity of evidence existing on a topic of interest. In spite of its relevance, the establishment of consistent categories and classification of primary studies in these categories are manually conducted. Objective: We propose an approach, named SM-VTM (Systematic Mapping based on Visual Text Mining), to support categorization and classification stages in the systematic mapping using Visual Text Mining (VTM), aiming at reducing time and effort required in this process. Method: We established SM-VTM, selected a VTM tool and conducted a case study comparing results of two systematic mappings: one performed manually and another using our approach. Results: The results of both systematic mappings were very similar, showing the viability of SM-VTM. Furthermore, since our approach was applied using a tool, reduction of time and effort can be achieved. Conclusions: The application of VTM seems to be very relevant in the context of systematic mapping.

Service-Oriented Architecture (SOA) has received increasing attention by providing low coupling, reuse, productivity, and a better understanding of the business domain. However, there are challenges in creating quality solutions using services. Based on SOA,...

Currently, embedded software have been required more and more by a diversity of new products. As a consequence, an increase in the software complexity can be observed, requiring more attention to the software quality. Initiatives of exploring software engineering knowledge to develop this type of software can be identified, resulting in the Embedded Software Engineering (ESE) research area. However, there is a lack of a complete panorama about researches conducted in the context of ESE. This paper intends to present a view about how software engineering has been currently used in the embedded software development. For this, we have used systematic mapping, a technique based in the Evidence-Based Software Engineering (EBSE). Achieved results point out that in spite of the increase in the interest of applying software engineering to develop embedded software, there are still important lines of research that must receive attention.