ProGuide

Gerade in sicherheitskritischen Bereichen ist die Sicherstellung einer hohen Softwarequalität relevant. Stellen Sie sich die Folgen bei einer Rettungsaktion vor, wenn die Kommunikation zwischen Leitstelle und Rettungseinheiten aufgrund eines Softwarefehlers ausfällt. Unter den verschiedenen Maßnahmen zur Erzielung einer hohen Qualität sind Regelungen, wie die einzelnen Software-Engineering-Artefakte (wie Anforderungen, Designdokumente, Testfälle etc.) verknüpft werden müssen. Durch eine solche Verknüpfung (auch Tracing genannt) kann beispielsweise überprüft werden, ob alle Anforderungen umgesetzt und auch getestet werden. Richtigkeit und Vollständigkeit dieser Traces gehören zur Erfüllung der Qualitätssicherungskriterien (QS). Was die Entwicklung sicherheitskritischer Systeme erschwert, ist die Tatsache, dass das Erstellen oder Aktualisieren dieser Artefakte und deren Verknüpfung selten die Aufgabe eines einzelnen Ingenieurs ist. Vielmehr erfordert dies die Koordination mehrerer Ingenieure: einige sind für die Definition von High- Level-Anforderungen verantwortlich, andere für deren Verfeinerung auf Low-Level-Anforderungen, andere verantwortlich für die Entwicklung von Testfällen usw. Diese Ingenieure müssen sich daher koordinieren, um Fehler wie etwas das Fehlen eines Testfalls oder eine nicht nachgezogene Anforderungsaktualisierung zu vermeiden. Dazu beschreibt ein Software-Engineering-Prozess, wie sich diese Ingenieure koordinieren sollen. Den Prozess zu befolgen und sicherzustellen, dass die Qualitätskriterien erfüllt werden, ist nicht trivial. Oftmals müssen Ingenieure wissentlich aufgrund von Zeitdruck oder unvorhergesehene Situationen vorübergehend von den Prozess- und QS-Kriterien abweichen. Ziel des Projekts ist es, Ingenieure dabei zu unterstützen, eine Abweichung von den Prozess- und QS- Kriterien zu beheben, auch wenn einige Arbeiten bereits als erledigt gelten und andere auf diesen Ergebnissen aufbauen. Beispielsweise muss eine High-Level-Anforderung überarbeitet werden, obwohl diese bereits zu einer Low-Level-Anforderung verfeinert wurde. Eine strikte Befolgung des Prozesses erlaubt es eventuell nicht, dies zu tun. Der in diesem Forschungsprojekt untersuchte Ansatz unterstützt die Ingenieure dabei, bewusst zu werden, welche Artefakte von einer Änderung (und damit Prozessabweichung) betroffen sind, welche QS-Kriterien möglicherweise nicht mehr erfüllt sind und wer in die Entscheidung zur Behebung eingebunden werden soll. Letztendlich besteht das Ziel darin, detaillierte, umsetzbare Anleitungen zu den Behebungsmöglichkeiten zu geben, jedoch weiterhin Unterstützung zu bieten, welche Prozessschritte durchgeführt werden müssen und ob andere QS- Einschränkungen erfüllt sind, auch wenn die bestehende Abweichung noch nicht behoben ist. Das Projekt wird die Auswirkung einer solchen Engineering-Unterstützung durch die Anwendung in einer realen Software-Engineering-Umgebungen zeigen. Es wird erwartet, dass Software-Ingenieure weniger Zeit aufwenden müssen, um herauszufinden, gegen welche QS-Beschränkungen sie verstoßen oder wer davon betroffen ist, sowie dass sie weniger QS-Kriterien verletzen welche zu kostspieligen Fehlern und/oder deren zeitaufwändiger Behebung führen.

Softwareprozesse zusammen mit der Software-Qualitätssicherung (QA) zielen darauf ab, sicherzustellen und nachzuweisen, dass die Engineering-Prozesse zu der entsprechenden Softwarequalität führen. Dennoch besteht eine Spannung zwischen der Notwendigkeit, Vorschriften und Prozessen zu folgen, und dem Bedürfnis, bei Bedarf davon abweichen zu können. Das Problem besteht also darin, wie man Ingenieur:innen in Anwesenheit verletzter Prozess- und Qualitäts-Constraints automatisierte Prozessunterstützung bieten kann. Dies ist nicht trivial, da eine Prozessabweichung typischerweise nicht nur eine einzelne Person betrifft, sondern Auswirkungen auf andere Ingenieur:innen hat. Ohne Bewusstsein für die Prozessabweichung und deren Auswirkungen auf andere könnte eine Abweichung (wie z. B. ein nicht erfülltes QA-Constraint) unbemerkt bleiben oder nicht vollständig korrigiert werden. Die Constraint-Verletzung könnte sich dann auf nachfolgende Prozessschritte und deren Engineering-Artefakte ausbreiten, was letztlich zu kostspieligem Mehraufwand zu einem späteren Zeitpunkt oder zu einer geringeren Softwarequalität führt. Wir argumentieren, dass die Unterstützung in zwei Formen erfolgen muss. Erstens durch Unterstützung der Ingenieur:innen bei der Bestimmung, welche Aktivitäten erforderlich sind, um in einen konsistenten Prozesszustand zurückzukehren, und zweitens durch die Identifikation der betroffenen Prozessschritte und deren verantwortlichen Ingenieur:innen. In diesem Projekt haben wir untersucht, wie man Software-Engineering-Prozesse und deren QA-Constraints passiv im Hintergrund verwalten kann, sodass Ingenieur:innen flexibel vom Prozess abweichen können. Wir haben Algorithmen entwickelt, um die Ursachen zu identifizieren und zu analysieren, wer sich abstimmen muss, um eine Abweichung im Prozess und/oder bei den QA-Anforderungen zu beheben. Ebenso haben wir Algorithmen zur Bestimmung des Wirkungskreises einer Abweichung etabliert, um die nachfolgenden Effekte auf andere zu identifizieren. Letztlich ermöglichen unsere Mechanismen die Erstellung eines detaillierten Reparaturplans, der die Ingenieur:innen durch die verschiedenen Alternativen zurück zu einem konformen Prozess führt. Die zentrale Innovation besteht darin, auch denjenigen Ingenieur:innen eine Unterstützung zu bieten, die von einer Abweichung betroffen sind. Evaluierungen mit Ingenieur:innen aus den Bereichen Luftverkehrskontrolle und Automobilindustrie haben gezeigt, dass unsere neu entwickelten Modelle, Techniken und Algorithmen in einem Proof-of-Concept-Prototyp eine effektive Unterstützung unter realistischen Bedingungen bieten. Die Ingenieur:innen begrüßen die automatisierten Prüfungen und das unmittelbare Feedback.