Quantum software engineering aims to establish methodologies, tools, and frameworks to support the development of functional and maintainable quantum applications. A critical aspect within this domain is the maintainability of quantum software, which pertains to the capacity of the system for modification, correction, or evolution over time. Modifiability is particularly significant, as it encompasses mechanisms that enable software to be altered effectively and efficiently without introducing defects or compromising quality. Despite its importance, there has been limited discussion on addressing modifiability in quantum software. Moreover, there is little information on studies that translate maintainability concerns into specific modifiability scenarios. In this paper, we present our investigation on defining a modifiability scenario for quantum software, characterized by sources of stimuli, stimuli, software artifacts related to modifiability, environment, responses to the stimuli, and measures of those responses. We examined the release and version histories of 18 quantum software projects to extract the data from each version. Preliminary findings outline the development of a concrete modifiability scenario for quantum software that facilitates the implementation of defined responses within the modifiability scenario in quantum software.

DevOps is an approach to automated software development and deployment that combines development and operations, with the goal of improving collaboration between teams to optimize the software lifecycle processes, from planning and development to testing, deployment, and monitoring. Despite being an innovative approach, DevOps presents a significant challenge for students in understanding and implementing software development projects. This challenge includes understanding the problem to the solution abstraction that contemplates the design, implementation, and automation of the software development process. This study proposes and evaluates a methodological framework to support students in defining DevOps-oriented technology stacks. The framework combines software architecture and software engineering practices that collectively provide a learning approach based on design decision-making and selection of technologies, frameworks, and tools. We evaluated the framework in two iterations of a capstone course, using a case study that considered the implementation of a DevOps stack on (i) a pre-existing system and (ii) a system from scratch. Results show that students who implemented a DevOps-oriented stack on systems developed from scratch were successful, but those who implemented it on a pre-existing system confronted challenges in configuration management and system flexibility. The proposed framework facilitates the pedagogical experience of implementing DevOps in software development projects, thus rendering it beneficial for students.

Zero Trust Architecture (ZTA) is a novel security approach for building secure systems. ZTA-based systems are built with specific security mechanisms to enforce their basic tenets, for example, explicit verification and least privilege. Although existing security mechanisms have been useful in building ZTA-based systems, the current literature does not provide clear guidance on which security mechanisms should be used by developers of these systems. This article describes the design and results of a systematic mapping study to identify the security mechanisms used in the building of ZTA-based systems. The review yielded 290 articles, of which 30 primary studies were selected. Key findings are: (i) 24 different security mechanisms were reported; (ii) 37 % of them are classified into access control techniques to implement ZTA least priveleges tenet; (iii) ABAC and AIM are the most used mechanisms; (iv) over half of security mechanisms (69 %) focus on resisting attacks (instead of detecting or recovering); and (v) experimentation is a predominant empirical strategy within ZTA security research. The identification of these security mechanisms will enable developers of ZTA-based systems to effectively address the security challenges associated with implementing ZTA tenets.

Microservices is an architectural style that provides several benefits to develop applications as small, independent, and modular services. Building Microservices Architecture (MSA)-based applications is immensely supported by using software testing fundamentals. With the increasing interest in the development of MSA-based applications, it is important to systematically identify, analyze, and classify the publication trends, research themes, approaches, tools, and challenges in the context of testing MSA-based applications. The search yielded 2,481 articles, and 33 articles were finally selected as the primary studies with snowballing. The key findings are that (i) 5 research themes characterize testing approaches in MSA-based applications; (ii) integration and unit testing are the most popular testing approaches; and (iii) addressing the challenges in automated and inter-communication testing is gaining the interest of the community. Additionally, it emerges that there is a lack of dedicated tools to support testing for MSA-based applications, and the reasons and solutions behind the challenges in testing MSA-based applications need to be further explored.

Microservices is an architectural style that conceives systems as a modular, costumer, independent and scalable suite of services; it offers several advantages but its growing popularity has given rise to security challenges. Building secure systems is greatly helped by deploying existing security mechanisms, but current literature does not guide developers about which mechanisms are actually used by developers of microservices-based systems. This article describes the design and results of a systematic mapping study to identify the security mechanisms used in microservices-based systems described in the literature. The study yielded 321 articles, of which 26 are primary studies. Key findings are that (i) the studies mention 18 security mechanisms; (ii) the most mentioned security mechanisms are authentication, authorization and credentials; and (iii) almost 2/3 of security mechanisms focus on stopping or mitigating attacks, but none on recovering from them. Additionally, it emerges that experiments and case studies are the most used empirical strategies in microservices security research. The clear identification of most-used security solutions will facilitate the reuse of existing architectural knowledge to address security problems in microservices-based systems.

Microservice-based systems instantiate an architectural style that conceives of systems as sets of modular, customer-centric, independent, and scalable services. These systems express a similar essential structural organization and seems appropriate to design them using architectural patterns because these combine an understanding of the system domain and good practices. Code repository platforms provide the developer community with ideas and examples about microservice systems, but since they are in early adoption, there is still no clear notion of which actual microservice systems incarnate architectural patterns (if any), reducing the use of frameworks and the achievement of quality attributes. This paper extends a previous study on architectural patterns for microservices in academic and industry sources. We explored which architectural patterns for microservices are used in actual microservice-based open source systems, by subjecting thirty well-known open source projects to a comprehensive multi-criteria code and design review. We found that (1) open source projects use only a few architectural patterns broadly; (2) most projects use the same few frameworks; (3) there are very few microservice architectural patterns as such; and (4) what most projects use (what was previously called) are SOA patterns. This study shows that microservice systems builders do use architectural patterns, but only a few of them. It remains to be determined whether additional patterns would be productively used to build microservice systems, or the few ones currently used are the only ones actually necessary.