Ademar Aguiar

Abstract
Domain-specific standards and documents heavily regulate safety-critical systems. One example is the DO-178C standard for aerospace, which guides organizations to achieve system safety and evidence for their certification. Under such regulated contexts, most organizations use traditional development processes, in contrast to the massive adoption of Agile in the software industry. Among other benefits, Agile methods promise faster delivery and better flexibility to address customer needs. Adopting Agile methods and practices are possible in aerospace because the DO-178C standard does not prescribe concrete software development methods. In spite of that, Agile development is not used in DO-178C contexts. To help change that, our research aims to understand whether and how organizations engineering safety-critical software systems for aerospace may benefit from Agile methods and practices. We analyzed the DO-178C standard and confirm that it is compatible with Agile methods. Then, we present a systematic literature mapping of adopting Agile in software development for aerospace, where we identified significant concerns, recurrent issues, and several challenges. Some real industry aerospace projects provided us with important data and the perspective of domain experts about the pros and cons of Agile methods in this context. We conclude by proposing an agenda of research opportunities to improve safety-critical software development towards agility that we consider worthy of further research, application and confirmation in wider contexts.

Abstract
Reading, adapting, and maintaining complex software can be a daunting task. We might need to refactor it to streamline the process and make the code cleaner and self-explanatory. Traditional refactoring tools guide developers to achieve better-quality code. However, the feedback and assistance they provide can take considerable time. To tackle this issue, we explored the concept of Live Refactoring. This approach focuses on delivering real-time, visually-driven refactoring suggestions. That way, we prototyped a Live Refactoring Environment that visually identifies, recommends, and applies several refactorings in real-time. To validate its effectiveness, we conducted a set of experiments. Those showed that our approach significantly improved various code quality metrics and outperformed the results obtained from manually refactoring code. © 2024 IEEE Computer Society. All rights reserved.

Abstract
Background: Approaches to documenting the software patterns of a system can support intentionally and manually documenting them or automatically extracting them from the source code. Some of the approaches that we review do not maintain proximity between code and documentation. Others do not update the documentation after the code is changed. All of them present a low level of liveness. Approach: This work proposes an approach to improve the understandability of a software system by documenting the design patterns it uses. We regard the creation and the documentation of software as part of the same process and attempt to streamline the two activities. We achieve this by increasing the feedback about the pattern instances present in the code, during development-i.e., by increasing liveness. Moreover, our approach maintains proximity between code and documentation and allows us to visualize the pattern instances under the same environment. We developed a prototype-DesignPatternDoc-for IntelliJ IDEA that continuously identifies pattern instances in the code, suggests them to the developer, generates the respective pattern-instance documentation, and enables live editing and visualization of that documentation. Results: To evaluate this approach, we conducted a controlled experiment with 21 novice developers. We asked participants to complete three tasks that involved understanding and evolving small software systems-up to six classes and 100 lines of code-and recorded the duration and the number of context switches. The results show that our approach helps developers spend less time understanding and documenting a software system when compared to using tools with a lower degree of liveness. Additionally, embedding documentation in the IDE and maintaining it close to the source code reduces context switching significantly.

Abstract
During the process of software architectural design, numerous questions arise which must be answered. These questions may be about requirements on the proposed system (the problem space) or about how the system should be designed and developed (the solution space). As questions arise they may be answered immediately, deferred until later, or provisionally answered with an assumption about the answer. The objective of this work was to explore the nature of questions that arise during architecture. We explored the types of questions, how they are organized, how they are tracked, and how and when they are answered. We started by surveying highly experienced architects about their practices with respect to architectural questions. We also performed a controlled experiment with master students about organizing architectural questions that clarified and substantiated the survey data. We learned that architectural questions include slightly more questions about the problem space than the solution space, as well as a minority of questions related to the managing of the project. We found that architects often use ad hoc methods to organize and track them, although they typically organize them along more than one dimension. We learned also that, about a third of the time, architects make assumptions about the answers to architectural questions in order to make progress on the architecture. This suggests that some projects may have risks of incorrect design or later costly rework due to inadequate tracking or incorrectly answered architectural questions.

Abstract
Context: Low-code development is a concept whose presence has grown both in academia and the software industry and is discussed alongside others, such as model-driven engineering and domain-specific languages. Usability is an important concept in low-code contexts since users of these tools often lack a background in programming. Grey literature articles have also stated that low-code tools have high usability.Objective: This paper examines the current literature about low-code and no-code to discover more about them and their relationship with usability, particularly its quality, which factors are the most relevant, and how users view these tools. This focus on usability aims to provide a different point of view from other works on low-code.Method: We performed a systematic literature review based on a formal protocol for this study. The search protocol returned a total of 207 peer-review articles across five databases, which was supplemented with a snowballing process. These were filtered using inclusion and exclusion criteria, resulting in 38 relevant articles that were analysed, synthesised and reported.Conclusion: Despite growing interest and a strong enterprise presence in academia, we did not find a formal definition of low-code, although common characteristics have been specified. We found that users have a heightened awareness of usability regarding low-code tools, with some authors performing feasibility studies on their implementations or listing factors that influence the user experience in a given tool. Researchers are considering usability factors unconsciously, and the low-code field would grow if research on usability increased. This paper also suggests a definition for low-code development.