Serverless computing is an umbrella paradigm that encompasses multiple service categories, including Function-as-a-Service (FaaS) and Backend-as-a-Service (BaaS). It has reshaped cloud application development by abstracting infrastructure management tasks such as provisioning, scaling, and operational maintenance from developers, thereby enabling greater focus on application logic. To realize these benefits, organizations need to select among various FaaS platforms such as AWS Lambda, Google Cloud Functions, Azure Functions, and Apache OpenWhisk to develop their serverless applications. Nevertheless, the increasing number of available FaaS platforms and their heterogeneous characteristics (e.g., timeout constraints, cold-start behavior, memory and package size limits, and event-source integration) make platform selection complex and knowledge-intensive for the decision makers. The main objective of this study is to support decision-makers in selecting appropriate FaaS platforms by designing an effective and systematic decision model. The model aims to simplify the selection process, reduce time and effort, and provide deeper insights into platform suitability based on specific organizational requirements. We employed a mixed-method research design to develop a decision model for the FaaS platforms selection problem. The model contains a mapping of 219 features across 16 FaaS platforms. The model was evaluated through five real-world case studies conducted at different software development companies. It suggests and prioritizes more than one FaaS platform based on the participants’ requirements. The case study participants reported that the model offered valuable insights and significantly simplified the selection process by reducing the time and costs associated with the decision-making process. We observe in the empirical evidence that decision-makers can make more rational, efficient, and effective decisions with the decision model. Additionally, the model provides reusable insights that can support future research, such as developing new frameworks and solutions for emerging challenges in serverless computing.

Abstract Managing software quality is crucial for maintainable software systems, yet understanding how quality attributes are discussed within the informal, noisy context of issue trackers remains a significant challenge. Current automatic approaches for categorizing quality concerns often falter, as they are typically validated on small domain-specific datasets and are ill-equipped to parse the conversational language of developer discourse. This hinders effective prioritization and technical debt management. This paper introduces QualiTagger, an automated approach for classifying seven distinct software quality attributes from issue tracker text, and QualiDataSet, a novel, curated dataset of over 700,000 labeled GitHub issues that underpins this work. We demonstrate that an ensemble of specialized binary classifiers, built upon the DistilRoBERTa architecture, significantly outperforms a single multiclass model and shows superior or comparable efficacy to a general-purpose Large Language Model (GPT-4o) for this task. The model’s real-world applicability is further validated through an industrial case study at Visma focusing on security issues) and a user study with software engineering students. Our evaluation confirms that QualiTagger achieves high classification accuracy and, crucially, generalizes effectively to previously unseen (Out-of-Distribution) projects, a key indicator of its practical utility. By providing both a robust classification tool and a large-scale public dataset, this research enables a more nuanced, data-driven understanding of how software quality is managed in practice, offering valuable insights for project management and future empirical software engineering research

The world faces escalating crises: record-breaking temperatures, widespread fires, severe flooding, increased oceanic microplastics, and unequal resource distribution. Academia introduces courses around sustainability to meet the new demand, but software engineering education lags behind. While software systems contribute to environmental issues through high energy consumption, they also hold the potential for solutions, such as more efficient and equitable resource management. Yet, sustainability remains a low priority for many businesses, including those in the digital sector. Business as usual is no longer viable. A transformational change in software engineering education is urgently needed. We must move beyond traditional curriculum models and fully integrate sustainability into every aspect of software development. By embedding sustainability as a core competency, we can equip future engineers not only to minimise harm but also to innovate solutions that drive positive, sustainable change. Only with such a shift can software engineering education meet the demands of a world in crisis and prepare students to lead the next generation of sustainable technology. This article discusses a set of challenges and proposes a customisable education roadmap for integrating sustainability into the software engineering curricula. These challenges reflect our perspective on key considerations, stemming from regular, intensive discussions in regular workshops among the authors and the community, as well as our extensive research and teaching experience in the field.

Abstract Although architecture instability has been studied and measured using a variety of metrics, a deeper analysis of which project parts are less stable and how such instability varies over time is still needed. While having more information on architecture instability is, in general, useful for any software development project, it is especially important in Open Source Software (OSS) projects where the supervision of the development process is more difficult to achieve. In particular, we are interested when OSS projects grow from a small controlled environment (i.e., the cathedral phase) to a community-driven project (i.e., the bazaar phase). In such a transition, the project often explodes in terms of software size and number of contributing developers. Hence, the complexity of the newly added features, and the frequency of the commits and files modified may cause significant variations of the instability of the structure of the classes and packages. Consequently, in this article we analyze the instability in OSS projects, especially during that sensitive phase where they become community-driven. Our results show that instability metrics can be easily obtained in such type of transitions. We also observed from our case studies that instability metrics can help finding out the balance between adding new functionality and performing refactoring. As a conclusions we state that instability metrics offer relevant information in the transition phase from the cathedral to the bazaar.

Achieving the UN Sustainable Development Goals (SDGs) demands a shift by industry, governments, society, and individuals to reach adequate levels of awareness and actions to address sustainability challenges. Software systems will play an important role in moving towards these targets. Sustainability skills are necessary to support the development of software systems and to provide sustainable IT-supported services for citizens. While there is a growing number of academic bodies including sustainability education in engineering and computer science curricula, there is not yet comprehensive research on the competencies and skills required by IT professionals to develop such systems. This study aims to identify the industrial sustainability needs for education and training from software engineers’ perspective. For this, we answer the following questions: (1) what are the interests of organisations with an IT division with respect to sustainability? (2) what do organisations want to achieve with respect to sustainability, and how? and (3) what are the sustainability-related competencies and skills that organisations need to achieve their sustainability goals? We conducted a qualitative study with interviews and focus groups with experts from twenty-eight organisations with an IT division from nine countries to understand their interests, goals, and achievements related to sustainability, and the skills and competencies needed to achieve their goals. Our findings show that organisations are interested in sustainability, both idealistically and increasingly for core business reasons. They seek to improve the sustainability of software processes and products but encounter difficulties, like the trade-off between short-term financial profitability and long-term sustainability goals or an unclear understanding of sustainability concepts from a software engineering perspective. To fill these gaps, they have promoted in-house training courses, collaborated with universities, and sent employees to external training. The acquired competencies should support translating environmental and social benefits into economic ones and make sustainability an integral part of software development.

Context-aware systems are gaining increasing importance in industry as managing and using context information opens new opportunities for reconfiguration, digital twin concepts, performance monitoring, and so forth. Today, there is an immense variety of context-aware systems, from mobile applications to complex systems which require run time reconfiguration. The diversity of methods for acquiring the relevant data, as well as the specific use case requirements, complicate the management and usage of context information. Thus, the usage of context information for the reconfiguration management of systems demands adequate processes to identify and model system-relevant context. Consequently, in this research, we present a new method for identifying and modeling the context information that is relevant to trigger a system reconfiguration as well as automated context model creation in the form of ontologies and feature models. We suggest the ontology usage to disambiguate the data from different sources. The implementation of context-aware behavior is beyond the scope of this article and will be included in future research. We validate our ideas using cases study in the wind energy domain and unmanned automated vehicle domain.Note to Practitioners—Dynamically changing environments, require systems that continuously monitor their environment and adapt when necessary to ensure safe and optimal operation. For the system to adapt, it is necessary to define which of the environmental variables are relevant and when a change should lead to a reconfiguration of the system. The method presented in this article helps practitioners to identify these environmental variables. A rapidly changing environment also means having to interact with different systems from different vendors. The relevant environmental variables could be provided by different systems or collected by different sensors that rely on different data models. To cope with this heterogeneous environment, it is useful to create a formalized and reusable context model, describing the relevant environmental variables. A formalized context model serves as a semantic layer to link heterogeneous data and enables operation in a changing environment. In this way, the result of the presented method is transformed automatically into an ontology.

A micro-service architecture emphasizes the use of subsystems that are small enough for changing them on the fly. Such architecture supports the continuous evolution of the system because individual services can be updated at different times, making system maintenance flexible. Consequently, the architecturally important properties of micro-services are constituted by service APIs that must be well maintained, with experimental, static, and deprecated versions clearly indicated. Like any software, micro-services can induce technical debt (TD) problems in service API, architecture and source code, if their quality and maintainability have not been asserted beforehand. This paper explores the relationship between TD and micro-services. Specifically, we investigate the role of architectural smells (AS) in open-source micro-service projects, where the architectural debt is principally recognized through the detection of architectural smells in the projects. As tools for this investigation, we used Arcan and Designite. The empirical data for the work is constituted by 20 open-source projects where we analyze the relationship between architecture smells and micro-services.

Technical debt analysis is used to detect problems in a codebase. Most technical debt indicators rely on measuring the quality of the code, as developers tend to induce recurring technical debt that emerges along with evolution cycles. This debt can emerge when project pressure leads to process deviations, for instance. In agile methods like Scrum, such deviations are commonly known as ScrumButs (like Scrum but …), which can be considered as a form of process debt. In this paper, we investigate two recurring signs of process debt (i.e. code smells and anti-patterns) caused by Scrumbuts. Our contribution investigates typical ScrumBut practices found in agile projects in one company and we report the relationships found between problems in code and ScrumBut issues. Our findings identify three types of ScrumButs, their root causes, and how these relate to concrete code smells and anti-patterns.

The increasing importance of automation and smart capabilities for factories and other industrial systems has led to the concept of Industry 4.0 (I4.0). This concept aims at creating systems that improve the vertical and horizontal integration of production through (i) comprehensive and intelligent automation of industrial processes, (ii) informed and decentralized real-time decision making, and (iii) stringent quality requirements that can be monitored at any time. The I4.0 infrastructure, supported in many cases by robots, sensors, and algorithms, demands highly skilled workers able to continuously monitor the quality of both the items to be produced and the underlying production processes. While the first attempts to develop smart factories and enhance the digital transformation of companies are under way, we need adequate methods to support the identification and specification of quality attributes that are relevant to I4.0 systems. Our main contribution is to provide a refined version of the ISO 25010 quality model specifically tailored to those qualities demanded by I4.0 needs. This model aims to provide actionable support for I4.0 software engineers that are concerned with quality issues. We developed our model based on an exhaustive analysis of similar proposals using the design science method as well as expertise from seasoned engineers in the domain. We further evaluate our model by applying it to two important I4.0 reference architectures further clarifying its application.

Abstract Traditionally, the quality of a software or system architecture has been evaluated in the early stages of the development process using architecture quality evaluation methods. Emergent approaches like Industry 4.0 require continuous monitoring of both run‐time and development‐time quality properties, in contrast to traditional systems where quality is evaluated at specific milestones using techniques such as project reviews. Considering the dynamics and minimum down‐time imposed by the industrial production domain, it must also be ensured that Industry 4.0 system evaluations are continuously performed with high confidence and with as much automation as possible, using simulations, for instance. In this regard, there is a need to develop new methods for continuously monitoring and evaluating the quality properties of software‐based systems for Industry 4.0, which must be supported by automated quality evaluation techniques. In this research we analyze traditional architecture evaluation methods and Industry 4.0 scenarios, and propose an approach based on Digital Twins and simulations to continuously evaluate runtime quality aspects of the architecture and systems of industrial production plants. The evaluation is based on the instantiation of our approach for a concrete demand of an automation plant in the automotive domain.

Technical debt (TD) has been recognized as an important quality problem for both software architecture and code. The evolution of TD techniques over the past years has led to a number of research and commercial tools. In addition, the increasing trend of opportunistic reuse (as opposed to systematic reuse), where developers reuse code assets in popular repositories, is changing the way components are selected and integrated into existing systems. However, reusing software opportunistically can lead to a loss of quality and induce TD, especially when the architecture is changed in the process. However, to the best of our knowledge, no studies have investigated the impact of opportunistic reuse in TD. In this paper, we carry out an exploratory study to investigate to what extent reusing components opportunistically negatively affects the quality of systems. We use one commercial and one research tool to analyze the TD ratios of three case systems, before and after opportunistically extending them with open-source software.

Abstract Usability is a highly desired but often ignored software quality. Effective user interfaces tend to increase learnability, effectiveness and user satisfaction. But usability is often neglected in the early stages of software development and is thus frequently not address in a system's architectural design. Furthermore, because usability is often neglected or deferred, it is difficult to estimate the effort specifically spent on adding or improving usability mechanisms in the software architecture and in code. In this work, we present a case study where we analyze the impact of introducing a variety of usability mechanisms to a mobile application and we report on the architectural changes that must be made in the software architecture to accommodate them. We also report on the additional code required to implement these usability mechanisms and we investigate the users' satisfaction of combining and using several usability mechanisms in a mobile application. Finally, we evaluated user responses—both positive and negatives—to these usability mechanisms via a questionnaire involving 25 users from different roles and different organizations and including contextual interviews to analyze the qualitative responses of the subjects. Our results show that apart from the relatively modest modeling and coding effort, the combination of several usability mechanisms seems beneficial for users of mobile systems and increases the satisfaction during the interaction with the system.

The new era of

Abstract Much has been investigated about software reuse since the software crisis. The development of software reuse methods, implementation techniques, and cost models has resulted in a significant amount of research over years. Nevertheless, the increasing adoption of reuse techniques, many of them subsumed under higher level software engineering processes, and advanced programming techniques that ease the way to reuse software assets, have hidden somehow in the recent years new research trends on the practice of reuse and caused the disappearance of several reuse conferences. Also, new forms of reuse like open data and feature models have brought new opportunities for reuse beyond the traditional software components. From past to present, we summarize in this research the recent history of software reuse, and we report new research areas and forms of reuse according to current needs in industry and application domains, as well as promising research trends for the upcoming years.

Owing to the critical role of software-intensive systems in society, software engineers have the accountability to consider sustainability as a goal while structuring a software system. However, there are no practical guidelines providing a tangible decomposition of the sustainability aspect. Moreover, there are limited quantifiable methods to support sustainable design and analysis.The purpose of this study is to help software practitioners to take sustainability into account by providing systematic guidelines for the software engineering process. We propose a framework that presents a meta model to decompose sustainability requirements and an assessment approach to evaluate sustainability achievements.This work presents an integrated framework that combines a goal-based approach, scenario-based approach, and feature modeling to gather sustainability related requirements and corresponding features. For sustainability assessment, software analysis and machine learning techniques are utilized to analyze software products based on sustainability metrics and criteria.The empirical study conducted with participants from academia and industry revealed that the proposed framework improves participant's ability to consider sustainability aspect in their software engineering tasks through focusing on requirements, design, and evaluation. With the provided sustainability meta-model, the participants could extract more stakeholders, requirements, and features in shorter time. Moreover, the empirical study result also demonstrated that this study is capable to indicate specific scenarios that should be redesigned to improve the sustainability achievements level.

Architecture erosion constitutes the most visible effect of the degradation of design. It is a major reason to address the design debt, often caused by architectural mismatch problems. Today, the identification of design erosion is a major concern for designers and software maintainers. Adequate tools are necessary to identify and repair the debt. This paper describes our experience on identifying architectural erosion problems on existing open source software applications through the support of two well known tools. Moreover, we outline if the tools provide useful hints in repairing some of the detected problems.

Ensuring the longevity of a software system is an important concern for developers and maintainers. However, when a system's architecture decays during evolution and its quality degrades as a result, the system's long-term sustainability is highly affected. In this light, providing mediums to estimate and track the sustainability of a software system is necessary to help engineers stay aware of system health. Most existing techniques and tools estimate the level of sustainability in code, paying significantly less attention to the analysis and understanding of architectural decay. This position paper provides a taxonomy of architectural smells, metrics, and their impacted quality properties. We relate these smells to maintenance and evolution areas as a first step toward our ultimate goal of estimating the sustainability of systems. We finally report some initial results drawn from a set of subject systems as promising future work using our taxonomy.

The importance of architectural knowledge (AK) management for software development has been highlighted over the past ten years, where a significant amount of research has been done. Since the first systems using design rationale in the seventies and eighties to the more modern approaches using AK for designing software architectures, a variety of models, approaches, and research tools have leveraged the interests of researchers and practitioners in AK management (AKM). Capturing, sharing, and using AK has many benefits for software designers and maintainers, but the cost to capture this relevant knowledge hampers a widespread use by software companies. However, as the improvements made over the last decade didn't boost a wider adoption of AKM approaches, there is a need to identify the successes and shortcomings of current AK approaches and know what industry needs from AK. Therefore, as researchers and promoters of many of the AK research tools in the early stages where AK became relevant for the software architecture community, and based on our experience and observations, we provide in this research an informal retrospective analysis of what has been done and the challenges and trends for a future research agenda to promote AK use in modern software development practices.

We theorize a two-mind model of design thinking. Mind 1 is about logical design reasoning, and Mind 2 is about the reflection on our reasoning and judgments. The problem solving ability of Mind 1 has often been emphasized in software engineering. The reflective Mind 2, however, has not received much attention. In this study, we want to find out if Mind 2, or reflection, can improve design discourse, a prerequisite of design quality. We conducted multiple case studies with 12 student groups, divided into test groups and control groups. We provided external reflections to the test groups. No reflections were given to the control groups. We analyzed the quality of the design discourse in both groups. We found that reflection (Mind 2) improves the quality of design discourse (Mind 1) under certain preconditions. The results highlight the significance of reflection as a mean to improve the quality of design discourse. We conclude that software designers need both Mind 1 and Mind 2 to obtain a higher quality design discourse, as a foundation for a good design. Copyright © 2016 John Wiley & Sons, Ltd.

Software product line (SPL) engineering has proven to improve software quality and shorten development cycles, cost and time. In product line engineering, product derivation is concerned with the realization of the variability at the implementation level. However, the majority of research works focuses on instantiating the variants selected in the final product, while the derivation at the architecture level has been poorly explored. As product line engineers often customize the product architecture by hand during the application engineering phase, the derivation and customization processes of the product line architecture (PLA) might be in some cases error-prone. Consequently, in this research we present an Ontology-based product Architecture Derivation (OntoAD) framework which automates the derivation of product-specific architectures from an SPL architecture. Our solution uses a language-independent model to specify the product line architecture and a model-driven engineering approach for architecture derivation activities. We use an ontology formalism to reason about the automatic generation of model-to-model transformation rules based on the selection of features and we illustrate our approach using a voice over IP motivating example. Finally, we report results about scalability and performance regarding the size of the variability model.

SUMMARY As a summary of past, current, and future trends in software maintenance and reengineering research, we give in this editorial a retrospective look from the past 14 years to now. We provide insight on how software maintenance has evolved and on the most important research topics presented in the series of the European Conference on Software Maintenance and Reengineering. Copyright © 2011 John Wiley & Sons, Ltd.

A complete and detailed (full) Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, this is typically too onerous for systematic industrial use as it is not cost effective to write, maintain, or read. The key idea investigated in this article is that DRD should be developed only to the extent required to support activities particularly difficult to execute or in need of significant improvement in a particular context. The aim of this article is to empirically investigate the customization of the DRD by documenting only the information items that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a specific DRD information item depends on its category (e.g., assumptions, related requirements, etc.) and on the activity it is meant to support. We investigate this hypothesis through two controlled experiments involving a total of 75 master students as experimental subjects. Results show that the value of a DRD information item significantly depends on its category and, within a given category, on the activity it supports. Furthermore, on average among activities, documenting only the information items that have been required at least half of the time (i.e., the information that will probably be required in the future) leads to a customized DRD containing about half the information items of a full documentation. We expect that such a significant reduction in DRD information should mitigate the effects of some inhibitors that currently prevent practitioners from documenting design decision rationale.

Runtime variability is a key technique for the success of Dynamic Software Product Lines (DSPLs), as certain application demand reconfiguration of system features and execution plans at runtime. In this emerging research work we address the problem of dynamic changes in feature models in sensor networks product families, where nodes of the network demand dynamic reconfiguration at post-deployment time.

Abstract Current software architecture practices have been focused on modeling and documenting the architecture of a software system by means of several architectural views. In practice, the standard architecture documentation lacks explicit description of the decisions made and their underlying rationale, which often leads to knowledge loss. This fact strongly affects the maintenance activities as we need to spend additional effort to replay the decisions made as well as to understand the changes performed in the design. Hence, codifying this architectural knowledge is a challenging task that requires adequate tool support. In this research, we test the capabilities of Architecture Design Decision Support System (ADDSS), a web‐based tool for supporting the creation, maintenance, use, and documentation of architectural design decisions (ADD) with their architectures. We used ADDSS to codify architectural knowledge and to maintain those trace links between the design decisions and other software artefacts that would help in the maintenance operations. We illustrate the usage of the tool through four different experiences and discuss the potential benefits of using this architectural knowledge and its impact on the maintenance and evolution activities. Copyright © 2009 John Wiley & Sons, Ltd.

Software product lines have already proven to be a successful methodology for building and maintaining a collection of similar software products, based on a common architecture. However, when the base system is heterogeneous and extremely large in size, an extra level of complexity is introduced that should be addressed with appropriate methods and techniques. A good example of this kind of systems is the product family composed by the software distributions composed by libre (free, opensource) software, and based on Linux or BSD kernels. All of them can be considered as a part of a product line, based on a large collection of thousands of packages. One of the main problems faced by these distributions is the increasingly growing number of dependencies among packages, which is already caused problems, with a high risk of rendering the management of such large distributions impossible. In this paper we address some of challenges and main problems of Linux distributions when adopting a product line approach, with special focus to the maintenance and evolution of such systems.

Capturing and using design rationale is becoming a hot topic for software architects, as architectural design decisions are now considered first class entities that should be recorded and documented explicitly. Capturing such architecture knowledge has been underestimated for several years as architects have been only focused on documenting their architectures and neglecting the rationale that led to them. The importance of recording design rationale becomes enormous for maintenance and evolution activities, as design decisions can be replayed in order to avoid highly cost architecture recovery processes. Hence, in this work we describe how architecture design decisions can be captured and documented with specific tool support. We also provide effort estimation in capturing such knowledge and we compare this with architecture modeling efforts in order to analyze the viability of knowledge capturing strategies.

This paper describes the ADDSS tool which enables capturing and documenting architectural design decisions in order to avoid knowledge vaporization.

Software architecting is a highly knowledge-intensive process demanding and producing a large and rich amount of information. To remain competitive, companies and organizations working in the IT sector must be able to manage this knowledge portfolio and effectively exploit and reuse it. In the era of Web 2.0, knowledge grids, social networking, global development and semantic Web, this working session addresses the problem of building a knowledge community in the field of software architecture. To this end, we aim at exploring the wishes of academics and industrial organizations, on the one hand, and their boundaries on he other. Our goal is to compare and contrast the inputs from academia and industry, and gain a shared understanding about what can be done now, and in the near future.

Today, software intensive systems are developed more and more using product line approaches. These approaches require the definition of a set of product line artifacts including the product line architecture that implicitly or explicitly specifies some degree of variability. This variability is used to instantiate concrete software product instances. A product line approach not only implies reuse of architecture-level design knowledge, it also facilitates reuse of implementation-level artefacts, such as source code and executable components. The use of software product lines can reduce the cost of developing new products significantly.

In this work we describe the problems found during the integration process of web products built under a lightweight product line. They are particularly important in development and maintenance processes because time to market of web products is often short and frequently driven by the market pressure. Due to changes in the team, we compare the results obtained by junior and senior teams in order to evaluate the delay in the project.