Abstract

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
Objectives: The purpose of this study was to field-test a recently developed AR-based serious game designed to promote SSE self-efficacy, called Spot. Methods: Thirty participants played the game and answered 3 questionnaires: a baseline questionnaire, a second questionnaire immediately after playing the game, and a third questionnaire 1 week later (follow-up). Results: The majority of participants considered that the objective quality of the game was high, and considered that the game could have a real impact in SSE promotion. Participants showed statistically significant increases in SSE self-efficacy and intention at follow-up. Of the 24 participants that had never performed a SSE or had done one more than 3 months ago, 12 (50.0%) reported doing a SSE at follow-up. Conclusions: This study provides supporting evidence to the use of serious games in combination with AR to educate and motivate users to perform SSE. Spot seems to be an inconspicuous but effective strategy to promote SSE, a cancer prevention behavior, among healthy individuals. Practice implications: Patient education is essential to tackle skin cancer, particularly melanoma. Serious games, such as Spot, have the ability to effectively educate and motivate patients to perform a cancer prevention behavior.