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.

Software processes together with software Quality Assurance (QA) focus on ensuring and attesting that the engineering processes result in the appropriate software quality. Yet, there exists a tension between the need to follow regulations and the process on the one hand, and the need to be able to deviate on the other hand. The problem is then how to provide automated process guidance to engineers in the presence of violated process and quality constraints. This is non-trivial as a process deviation typically affects not only a single engineer but has impact on other engineers as well. Without awareness of process deviation and its impact on others, a deviation (such as an unfulfilled QA constraint) may go unnoticed or not be completely corrected. The constraint violation then may propagate to subsequent process steps and their engineering artifacts, ultimately leading to costly rework at a later time or lower software quality. We argue that guidance needs to come in two forms. First, supporting engineers in determining which activities are needed to return to a consistent process state, and second, identifying what are the affected process steps and their responsible engineers. In this project, we investigated how to manage software engineering processes and their QA constraints passively in the background so that engineers may flexibly deviate from the process. We developed algorithms for identifying root causes to reason about who needs to coordinate in repairing a process and/or QA deviation. We also established algorithms for determining the deviation impact scope: to identify the subsequent effect on others. Ultimately, our mechanisms allow the generation of detailed repair plan that guide the engineer through the various alternatives back to a compliant process. The key innovation is providing guidance even for those engineers implicated in a deviation. Evaluations with engineers in the air-traffic control and automotive domains has shown that our newly established models, techniques, and algorithms in a proof-of-concept prototype for support effective guidance under realistic conditions. Engineers are welcoming the automated checks and immediate feedback.