ProGuide

Ensuring that software is of high quality is especially relevant in safety-critical domains. Imagine the consequences in a rescue operation when communication between the command center and rescue units fails due to a software bug. Among the various measures to obtain high quality such as testing, there are regulations on how the individual software engineering artifacts (such as requirements, design documents, test cases, etc.) need to be linked. Such linking (also called tracing), for example, enables to check whether all requirements are implemented and also tested. Having these traces correct and complete is part of fulfilling the softwares quality criteria. What makes engineering safety-critical systems harder is the fact that creating or updating these artifacts and establishing the links is rarely the task of a single engineer but involves the coordination of multiple engineers: some responsible for defining high level requirements, others responsible for refining those to low-level requirements, other responsible for devising test cases, and so on. These engineers, therefore, need to coordinate to avoid mistakes such as missing to create a test case or failing to consider a requirement update. To this end, a software engineering process describes how these engineers should coordinate. Following the process and ensuring the quality criteria are fulfilled is not trivial and places a burden on engineers to abide by them. Often engineers have to knowingly deviate from the process and QA criteria temporarily due to time pressure or to handle unforeseen situations that require refining requirements, design documents, implementation, or test cases. The project aims to support engineers in fixing a deviation from the process and quality assurance criteria even when some work is already considered done and others are building on these results. For example, a high-level requirement has to be revised that has already been refined into a low-level requirement. Strictly following the process may not allow to revise it. The approach investigated in this research project supports the engineers to become aware of which artifacts are affected by a change (and thus process deviation), which QA criteria might no longer be fulfilled, and who needs to be involved in the decision on how to fix the deviation. Ultimately, the goal is to provide detailed, actionable guidance on the possible ways to repair a deviation, but still give support on what process steps need to be done and whether other QA constraints are fulfilled even while the existing deviation from the process is not yet fixed. The project will show the effect of such engineering support through the evaluation in real-world software engineering settings. The expected impact is having software engineers spend less time on having to figure out which QA constraints they violate or who are affected, as well as fewer violations of QA constraints that could lead to costly errors in the software and/or time-consuming fixing these errors.