»Der Einsatz von Teamscale und regelmäßige Qualitätsretrospektiven durch CQSE-Qualitätsingenieur:innen helfen uns, eine hohe Softwarequalität sicherzustellen, Wissen im Team zu verteilen und einen systematischen Umgang bezüglich Softwaresicherheit gegenüber Aufsichtsbehörden nachzuweisen.«
Rainer Midderhoff, Leiter Stab Cyber Incidents und Regulierung
Langlebigkeit ist zugleich ein zentraler Mehrwert und eine fundamentale Herausforderung für geschäftskritische Software. Der Zahn der Zeit macht schließlich auch vor Software nicht halt. Hoher Releasedruck, personelle Wechsel oder sich wandelnde Anforderungen können einen schleichenden Verfall der Softwarequalität erzeugen, insbesondere über lange Zeiträume. Und damit die Langlebigkeit von Software bedrohen. Falls dies nicht rechtzeitig erkannt und gegengesteuert wird, droht Entwicklungsteams ein böses Erwachen.
Rainer Midderhoff und die Entwicklungsteams der Lebensversicherung von 1871 a. G. (LV 1871) haben diese Herausforderung schon lange erkannt. Und so begann die andauernde Partnerschaft mit der CQSE bereits im Jahr 2012, etwa zeitgleich mit unserem ersten Mitarbeiter. Dieses Jubiläum nehmen wir zum Anlass, auf die gemeinsame Erfolgsgeschichte zurückzublicken und darauf, wie die LV 1871 die Zukunftsfähigkeit ihrer Software langfristig im Griff behält.
Werfen wir zu diesem Zweck beispielhaft den Blick auf das Softwaresystem, das wir bereits am längsten begleiten: Conformer 2 (C2). C2 ist das Vertragsverwaltungssystem für fondsgebundene Versicherungen der LV 1871. Es ist in Java und Typescript geschrieben und umfasst über 468k Codezeilen (mit Leerzeilen und Kommentaren). Die Software verwaltet etwa die Hälfte aller von der LV 1871 geschlossenen Verträge.
Die Zukunftsfähigkeit einer derart geschäftskritischen Anwendung findet selbstverständlich eine hohe Beachtung. Um diesbezüglich eine objektive Einschätzung zu bekommen, beauftragte Rainer Midderhoff im Jahr 2011 die CQSE mit der Durchführung eines Softwareaudits als Standortbestimmung. Ergebnis war, dass C2 eine überdurchschnittlich hohe Softwarequalität aufweist, insbesondere bezüglich Codestruktur, Bug-Patterns und Ausnahmebehandlung. Dieses erfreuliche Auditergebnis bestätigte die Einschätzung von Rainer Midderhoff und dem C2-Team, dass C2 eine hohe Softwarequalität aufwies.
Zugleich war klar, dass am Erhalt dieses Qualitätsniveaus fortlaufend gearbeitet werden muss. Und so führte die LV 1871 gemeinsam mit der CQSE einen expliziten Quality-Control-Prozess ein, bestehend aus Teamscale als Werkzeug zur Qualitätsanalyse und regelmäßigen Qualitätsretrospektiven als zentralem Steuerungsinstrument.
Im Laufe der Jahre haben acht Qualitätsingenieur:innen der CQSE inzwischen insgesamt 80 Qualitätsretrospektiven mit Rainer Midderhoff und dem C2-Team durchgeführt. Bei jeder Retrospektive traf sich das Team mit den Qualitätsingenieur:innen zu einem Workshop. Dabei wurde die Qualität der C2-Anwendung gemeinsam analysiert, diskutiert und ggf. Verbesserungsmaßnahmen eingeleitet.
In den ersten Jahren fanden die Retrospektiven immer vor Ort statt. Während der Corona-Pandemie wurde notgedrungen auf ein Remote-Format ausgewichen, wodurch die Arbeit erfolgreich fortgesetzt werden konnte. Inzwischen finden die Retrospektiven mal vor Ort und mal remote statt. Motivation dabei ist, Reisezeiten zu begrenzen und gleichzeitig einen Raum für fruchtbare Diskussionen zu schaffen, welche erfahrungsgemäß eher vor Ort zustande kommen.
Inhaltlich basieren die Diskussionen weitestgehend auf Ergebnissen der statischen Codeanalyse sowie der Test-Gap-Analyse von Teamscale, die sowohl das Java-Backend als auch das TypeScript-Frontend einschließen. Damit wird eine Vielzahl von Qualitätsaspekten abgedeckt, wie Korrektheit, Wartbarkeit und nicht zuletzt auch Sicherheit (Security).
Um die Wartbarkeit von C2 langfristig zu gewährleisten, wurden die Analyseergebnisse aus Teamscale in den Qualitätsretrospektiven diskutiert. Anschließend wurden dabei identifizierte Aufräumarbeiten in Form von Jira-Tickets festgehalten und als Teil der regulären Entwicklungsarbeit umgesetzt. Insgesamt kamen über die Jahre 844 solcher Tickets zusammen, von denen 781 bis heute umgesetzt und 63 bewusst ignoriert wurden. Eine erfreuliche Quote von 93 %, was die Relevanz der identifizierten Maßnahmen unterstreicht. Das C2-Team resümiert: »Dadurch, dass eine Stunde im Monat mit externer Beteiligung fest geblockt war, haben wir uns die Zeit auch genommen, um über Qualität zu diskutieren, anstatt das zugunsten anderer Tätigkeiten runterpriorisiert. Das war für uns enorm wertvoll!«
Neben der Identifikation von konkreten Aufräumarbeiten war die Etablierung eines gemeinsames Qualitätsverständnisses ein wichtiges Ergebnis der Qualitätsretrospektiven. Durch Diskussionen über Programmierung und Qualität konnte das C2-Team unterschiedliche Meinungen wahrnehmen, eine gemeinsame Sicht entwickeln und sich Best Practices erarbeiten. Laut Teammitgliedern »lag ein Mehrwert der Qualitätsretrospektiven in der gemeinsamen, regen Diskussion der Findings, um einen gemeinsamen Blick für Qualitätsthemen zu entwickeln«. Beispielsweise dazu, ob beim Exception-Handling Runtime-Exceptions geworfen werden dürfen oder nicht. Und »selbst nach 80 Qualitätsretrospektiven gingen die Diskussionsthemen nicht aus«.
Die folgende Abbildung 1 zeigt, dass die Codequalität über die Zeit effektiv zugenommen hat und das Team damit ihr gesetztes Ziel sogar übertroffen hat. Aufgrund einer Umstellung des Versionskontrollsystems sind die Daten nicht für den gesamten Zeitraum, sondern erst ab 2017 verfügbar. Über die Zeit ist der Umfang des Softwaresystems kontinuierlich von 275k auf 323k Codezeilen (ohne Kommentare und Leerzeilen) gewachsen (blau). Zeitgleich sank die Anzahl der Findings aus der statischen Codeanalyse (rot) von 4k auf 2,5k Findings. Es wurde also fortlaufend aufgeräumt und insgesamt 1,8k Findings behoben. Tatsächlich konnte das Team in diesem Prozess nicht nur die Wartbarkeit erhöhen, sondern auch Fehler im Code frühzeitig beheben.
Abb. 1: Dargestellt ist die Anzahl der Codezeilen (blau) und der Findings aus der statischen Codeanalyse (orange) der C2-Software seit 2017. Das Wachstum der Codebasis und die Abnahme der Findings und somit die Verbesserung der Qualität sind deutlich erkennbar.
Das C2-Team nutzte die Test-Gap-Analyse in Teamscale, um Lücken in der Testautomatisierung zu identifizieren und zu schließen. Und um eine hohe Testabdeckung von 79 % als Sicherheitsnetz vor Regressionen beizubehalten.
Zusammenfassend halfen die Qualitätsretrospektiven, eine hohe Code- und Testqualität zu erhalten, Feldfehler zu vermeiden und die Wartbarkeit von C2 langfristig zu verbessern.
In jedem Entwicklungsteam kommt es früher oder später zu personellen Wechseln. »Alte Hasen« wenden sich neuen Herausforderungen zu und nehmen Erfahrung und Wissen mit sich. Neue Gesichter kommen als Verstärkung ins Team und müssen sich zunächst einarbeiten, um möglichst schnell produktiv zu werden.
Die folgende Abbildung 2 zeigt, welche enorme Dynamik derartige Entwicklungen in einem langlebigen Projekt wie C2 bedeuten. Wir sehen die Commits im C2-Versionskontrollsystem über die Zeit. Jede Zeile bzw. Farbe steht für eine Person. Das Ende einer Zeile bedeutet, dass die entsprechende Person aus dem Projekt ausgeschieden ist. Der Anfang einer neuen Zeile, dass eine Person hinzukam.
Abb. 2: Dargestellt ist die Commit-Aktivität in C2 seit 2017. Jede Zeile entspricht einer:m Entwickler:in. Deutlich wird der Wechsel der beteiligten Personen und die unterschiedlich lange Zeit, die im Projekt mitgearbeitet wurde.
Während einige Entwickler:innen über einen längeren Zeitraum von mehreren Jahren aktiv waren, waren andere Entwickler:innen nur für einige Monate oder Jahre Teil des Teams. Insgesamt arbeiteten über die Zeit 45 Personen an C2. Aktuell sind es sieben.
Insbesondere bei größeren Teamveränderungen wurden die Qualitätsretrospektiven gezielt zum Wissenstransfer eingesetzt. Zudem werden Themen in gewissen Abständen erneut aufgegriffen, um Wissen aufzufrischen, neue Ideen einzubringen und neue Teammitglieder einzuarbeiten. »Wenn neue Leute ins Team kommen, bekommen sie durch die Diskussionen in den Qualitätsretrospektiven mehr oder weniger automatisch Wissen über Qualitäts- und Programmier-Best Practices mit,« resümiert Rainer Midderhoff.
Dabei brachten die CQSE-Qualitätsingenieur:innen neue Ideen aus anderen Kundenkontexten und aus der akademischen Forschung ein, um die LV-interne Sicht zu komplementieren. Inzwischen begleitet Florian Deißenböck, einer der CQSE-Qualitätsingenieure, das C2-System sogar länger als alle aktuell aktiven Entwickler:innen und trägt so nochmals zum Wissenserhalt bei.
Die Regelmäßigkeit und Verbindlichkeit der Qualitätsretrospektiven war auch hier von zentraler Bedeutung, damit der Wissensaustausch im Alltag nicht hinten runtergefallen ist und insbesondere neue Teammitglieder Zugang zu diesem Wissen erhalten haben.
Da das C2-Team eine Versicherungssoftware entwickelt, gelten weitreichende und immer weiter wachsende regulatorische Vorgaben wie beispielsweise der »Digital Operational Resiliance Act« (DORA). Der Quality-Control-Prozess mit statischer Codeanalyse und Qualitätsretrospektiven erwies sich als wichtiger Baustein zu deren Umsetzung.
Durch »Static Application Security Testing (SAST)«-Analysen in Teamscale wurden potentielle Sicherheitslücken im Code identifiziert, in den Retrospektiven diskutiert und anschließend ggf. entfernt. Die Qualitätsretrospektiven boten auch eine ideale Möglichkeit, die Relevanz von Sicherheitsfindings und -kategorien an konkreten Beispielen aus der eigenen Codebasis zu diskutieren. So konnte die SAST-Konfiguration fortlaufend validiert und für die Anforderungen des C2-Teams optimiert werden. So gelang eine gute Balance im Zielkonflikt einerseits möglichst viele Sicherheitslücken frühzeitig zu finden und andererseits die Entwicklerproduktivität nicht durch zu viele False Positives stark einzuschränken.
Durch die Trendanalysen im Rahmen der Qualitätsretrospektiven wurden Verletzungen regulatorischer Vorgaben regelmäßig analysiert und ggf. Gegenmaßnahmen eingeleitet. Das Festhalten derselben in Form von Jira-Tickets erlaubte einen leichtgewichtige Dokumentation. Weiterhin stellte jede Qualitätsretrospektive durch Qualitätsingenieur:innen der CQSE ein externes Review der Qualität und Sicherheit dar.
Insgesamt wurde damit die Einhaltung der regulatorischen Vorgaben erreicht und es konnten entsprechende Nachweise gegenüber Prüfern geführt werden. »Der Einsatz von Teamscale sowie regelmäßige Codereviews durch CQSE-Expert:innen helfen uns, einen systematischen Umgang bezüglich Softwaresicherheit gegenüber Aufsichtsbehörden nachzuweisen«, sagt Rainer Midderhoff.
Für Rainer Midderhoff und das C2-Team hat sich gezeigt, dass Qualitätsretrospektiven sehr gut geeignet sind, um einen schleichenden Qualitätsverfall über lange Zeit zu verhindern. Auch nach all den Jahren ist C2 weiterhin bezüglich Softwarequalität und -sicherheit gut aufgestellt. »Der Einsatz von Teamscale und regelmäßige Qualitätsretrospektiven durch CQSE-Qualitätsingenieur:innen helfen uns, eine hohe Softwarequalität sicherzustellen, Wissen im Team zu verteilen und einen systematischen Umgang bezüglich Softwaresicherheit gegenüber Aufsichtsbehörden nachzuweisen«, fasst Rainer Midderhoff zusammen.
Deshalb werden Qualitätsretrospektiven mit der CQSE auch in Zukunft fester Bestandteil der C2-Weiterentwicklung bleiben. Und Qualitätsretrospektiven wurden in der Zwischenzeit auch von vielen anderen Teams der LV 1871 für deren Softwaresysteme erfolgreich übernommen.