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.

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.

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.