Ein System für die kontinuierliche Spezifikation, Verifikation und Verfeinerung von Resilienz-Szenarien
Resilienz beschreibt die Fähigkeit von Softwaresystemen unter widrigen Umständen ihre Funktionsfähigkeit (teilweise) aufrechtzuerhalten und sich zu erholen. Auf der einen Seite sind Microservice-basierte Softwaresysteme regelmäßig erwarteten und unerwarteten Änderungen ausgesetzt, z.B. Lastspitzen, (Neu-)Deployments, Hardware- und Softwarefehler. Auf der anderen Seite statten Softwarearchitekten ihre Systeme mit Resilienzmechanismen aus, z.B. Autoscaler, Timeouts oder Circuit Breakern, um die Resilienz ihrer Systeme gegen Änderungen zu erhöhen. Diese Resilienzmechanismen können jedoch nicht unmittelbar reagieren und das Erreichen eines vollständigen Schutzes gegen Änderungen ist oft praktisch unmöglich. Folglich führen die Änderungen zu sogenanntem transientem Verhalten, z.B. vorübergehenden Verschlechterungen der Antwortzeiten oder Erfolgsraten.
Obwohl transientes Verhalten die Nutzererfahrung stark beeinträchtigen kann, z.B. durch die verschlechterten Antwortzeiten, werden Resilienzanforderungen bezüglich transientem Verhalten in der Praxis oft nicht oder nur unzureichend berücksichtigt [1]. Aufgrund der Komplexität von Resilienzvorfällen und transientem Verhalten, enthalten Resilienzanforderungen meist viel Unsicherheit. Vorfälle treten oft unerwartet auf, was es schwer macht alle Details der Vorfälle und das erwartete Systemverhalten vorab vollständig zu spezifizieren. Es ist insbesondere schwer für Softwarearchitekten ihre Anforderungen und Erwartungen angemessen zu parametrisieren, z.B. ob ein Service innerhalb von ein, zwei, oder drei Minuten wiederhergestellt werden soll. Wir streben daher einen Prozess zur kontinuierlichen Spezifikation, Verifikation und Verfeinerung von Resilienzanforderungen an.
In früheren Arbeiten sind mehrere (hauptsächlich Java- und Python-basierte) Werkzeuge entstanden, die diesen Prozess punktuell unterstützen sollen, z.B. ein Resilienzsimulator [2], ein Werkzeug zur Verifikation von Resilienzanforderungen [3], ein Chatbot zur Vorschlagsgenerierung [4], ein Werkzeug zur Parameteroptimierung von Resilienzanforderungen und einige weitere. Ziel dieses Projekts ist die Integration dieser Werkzeuge in einen konsistenten Gesamtansatz zur kontinuierlichen Spezifikation, Verifikation und Verfeinerung von Resilienzanforderungen [5]. Darüber hinaus sollen mit weiteren zu entwickelnden Werkzeugen vereinzelt konzeptionelle Lücken geschlossen und die existierenden Werkzeuge frontend- und backendseitig weiterentwickelt werden.
Ihr arbeitet also in einem sog. Brownfield-Projekt, bei dem schon System(teil)e vorliegen und angepasst werden. Dies wird auch in der Praxis zu einem Großteil Eure Aufgabe sein. Studien haben nämlich gezeigt, dass Entwickler nur zu einem sehr gerigen Anteil (< 20%) tatsächlich Systeme neu entwickeln (sog. Greenfield-Projekte). Da dieses Masterprojekt inhaltlich in das laufende Forschungsprojekts „Data-driven Specification and Verification of Resilience Scenarios (DiSpel)“ eingebettet ist, erhaltet ihr gleichzeitig Einblicke in aktuelle Forschung.
Wir freuen uns auf Eure Mitarbeit!
Lernziele
Das Masterprojekt beinhaltet die praktische Anwendung von Methoden, Techniken und Werkzeugen des Software Engineering, z.B. die Arbeit mit Versionsverwaltungssystemen und Build-Pipelines sowie die Container-basierte Anwendungsentwicklung.
Die Projektarbeit wird in Kleingruppen durchgeführt, deshalb gehören der Erwerb von Kenntnissen und Erfahrungen des Projektmanagements ebenfalls zu den angestrebten Ergebnissen. Konkret werden wir hierbei Methoden des agilen Projektmanagements kennenlernen.
Fachlich vermittelt dieses Masterprojekt Konzepte aus den Feldern Softwarequalität und -architektur, insbesondere bezüglich Resilienz von Microservice-basierten Softwaresystemen. Hierbei werden außerdem formale Techniken zur Spezifikation und Verifikation von Anforderungen vermittelt.
Vorgehen
Im begleitenden Seminar soll die Einarbeitung in die existierenden Werkzeuge und deren Konzepte erfolgen. Im eigentlichen Projekt entwickeln wir das Gesamtsystem kontinuierlich entsprechend agiler Softwareentwicklung (Scrum oder Scrum-ähnlich) weiter, wobei die Betreuer als Kunden auftreten.
