Ein kleines Entwicklungsteam startet ein neues Vorhaben. Die fachliche Domäne ist grundsätzlich bekannt, das Produkt aber etwas Neues. Das Team ist mit den angedachten Technologien größtenteils vertraut, erste Ideen enthalten jedoch auch unbekanntes Terrain. Die Mitglieder stellen sich die Frage: "Sind wir auf dem richtigen Weg?" Anzeige Stefan Toth Stefan Toth ist Gründer der embarc GmbH und Autor zahlreicher Artikel, sowie der Bücher "Vorgehensmuster für Softwarearchitektur" und "Software-Systeme reviewen". Als Berater begleitet er Start-ups, Mittelständler und Großkonzerne bei der organisatorischen, methodischen und technischen Neuausrichtung. Stefan Zörner Stefan Zörner ist Softwarearchitekt bei embarc. Er unterstützt in Entwurfs- und Umsetzungsfragen und teilt seine Erfahrungen regelmäßig in Vorträgen, Artikeln und Workshops. Szenenwechsel. Eine große Anwendung ist in die Jahre gekommen. Die aktuelle Betriebsumgebung steht perspektivisch nicht länger zur Verfügung, die Software ist schwer zu warten. Es steht ein massiver Umbau an, gegebenenfalls sogar eine Neuentwicklung oder der Umstieg auf eine Standardsoftware. Auch hier stellen sich den Softwarearchitektinnen und -architekten viele Fragen, und die Antworten sind mitunter weitreichend. Dies sind zwei Situationen von vielen, in denen das Innehalten und Betrachten der bestehenden oder angedachten Softwarearchitektur Sicherheit bringen kann. Die Softwarearchitektur einer Anwendung bezeichnet die grundlegenden Ideen, die im weiteren Verlauf nur schwer zurückzunehmen sind. Inhaltlich kann das etwa die Wahl des Architekturstils (zum Beispiel Microservices) betreffen oder die Zerlegung in kleinere Teile und deren Zusammenspiel. Weitere typische Themenkomplexe sind die Technologieauswahl, die Frage nach Deployment-Aspekten oder auch der Entwicklungsmethodik (beispielsweise Test- oder Release-Strategien). Diese Entscheidungen sind langlebig, und die Beteiligten treffen sie in der Regel, ohne alle Einflussfaktoren zu kennen. Es ist daher ratsam, die Maßnahmen zu einem geeigneten Zeitpunkt zu reflektieren, um mögliche Risiken aufzudecken und die Entscheidungen so abzusichern. Bauchgefühl ist dabei nicht immer angebracht. Wer die grundlegenden Ideen von Softwaresystemen geordnet beleuchten oder bewerten möchte, kann auf eine Vielzahl von Methoden zurückgreifen. Sie stammen oft aus dem akademischen Umfeld und bringen zwar belastbare Ergebnisse, aber auch spürbaren Aufwand mit. Architecture Tradeoff Analysis Method ist ein verbreitetes Beispiel [1]. ATAM arbeitet sehr fundiert und personalintensiv, es gibt jedoch auch praktikable Ansätze, die in weniger kritischen Situationen zu schnellen Ergebnissen führen. Was macht Architekturbewertung? Anzeige Bei Architektur-Reviews geht es um die Frage, ob Entscheidungen zur Zielsetzung und Aufgabenstellung passen, also zu organisatorischen Vorgaben rund um Termine und Budgets, zum technischen Kontext wie der Zielumgebung oder zu zentralen Qualitätsanforderungen wie Zuverlässigkeit oder Wartbarkeit. Die Bewertung kann durch einen oder mehrere Außenstehende erfolgen, durch das Team selbst oder auch gemeinsam. Die Bewertungsmethoden beschreiben die erforderlichen Vorarbeiten, die im Review benötigten Beteiligten und ihre Rollen, den genauen Ablauf sowie die Form des Ergebnisses. Viele der Bewertungsmethoden neigen zu Vierbuchstaben-Abkürzungen, wobei A, M und R besonders häufig vorkommen und wahlweise zum Beispiel für Architecture, Analysis, Approach, Method und Review stehen. Die Urmutter dieser Methoden ist die Software Architecture Analysis Method (SAAM), die im Wesentlichen der Carnegie Mellon University entstammt. Abbildung 1 zeigt eine Auswahl von Review-Verfahren jeweils inklusive Slogan, grobem Ablauf und Zusammenhängen. Im Lauf der Zeit haben sich verschiedene Bewertungsmethoden für Softwarearchitektur etabliert, von ATAM bis heute. Das Bild zeigt eine kleine Auswahl (Abb. 1). (Bild: Embarc) Szenarienbasierte Bewertungsmethoden Wer sich mit Bewertungsmethoden beschäftigt, stellt schnell fest, dass die Architecture Tradeoff Analysis Method eine Sonderrolle einnimmt. Praktisch jede Methodenbeschreibung vergleicht den eigenen Ansatz als Erstes mit ATAM, stellt die Unterschiede und natürlich vor allem die Vorzüge heraus. ATAM sollte man also auf jeden Fall kennen. Die Methode ist gekennzeichnet durch eine breite Stakeholder-Beteiligung und sehr fundierte Analyseschritte rund um Qualitätsanforderungen. Abbildung 2 zeigt auf der linken Seite den groben Ablauf in Bewertungsphasen. Die zentrale erste Phase ist in detaillierte Schritte aufgefächert. Der Utility Tree bildet ein zentrales Merkmal im Ablauf einer ATAM-Bewertung, hier am Beispiel des Messenger-Dienstes Threema (Abb. 2). (Bild: Embarc) Nach einer Vorbereitungsphase, die organisatorische Dinge wie die Zusammensetzung des Bewertungsteams und die zeitliche Planung klärt, geht der Verlauf in einen Workshop-Modus über. Am Anfang dieser Phase 1 stehen Überblickspräsentationen zur Methode selbst, zur Zielsetzung und zur Architektur des zu betrachtenden Systems. Bei der eigentlichen Bewertung dreht sich in ATAM alles um sogenannte Qualitätsszenarien. Das sind beispielhafte Interaktionen mit dem System oder dessen Erstellung, bei denen qualitative Eigenschaften wie Sicherheit oder Zuverlässigkeit im Fokus stehen. Abbildung 2 enthält auf der rechten Seite zur Illustration den Ausschnitt eines Utility Tree, der Qualitätsszenarien zu Qualitätsmerkmalen sortiert. Als Blätter des Utility Tree sind einige Beispielszenarien für den mobilen Instant Messenger Threema angegeben, die im Austausch mit dem Entwicklungsteam über dessen Architektur entstanden sind. Der Utility Tree ist sehr hilfreich für ein erstes Verständnis der qualitativen Anforderungen an das betrachtete System und bildet den zentralen Bewertungsmaßstab von ATAM. Qualitätsszenarien und der Utility Tree entstehen in Schritt 5 von Phase 1 (siehe Abbildung 2), beispielsweise durch ein Brainstorming im Rahmen des Workshops. Die Teilnehmerinnen und Teilnehmer priorisieren die Szenarien nach fachlichem Nutzen und technischem Risiko. In Schritt 6 folgt die Analyse, die in ATAM den größten Raum einnimmt: Dabei diskutieren die Beteiligten die Dinge, die ein potenzielles Risiko für den Erfolg des Systems darstellen – zeitlich begrenzt, szenariobasiert und nach der erarbeiteten Priorität. Die Szenarien dienen dabei als Diskussionsgrundlage. Nach einer kurzen Vorstellung der Ideen, Konzepte und Entscheidungen für das gerade besprochene Szenario leiten die Teilnehmer Stärken, Risiken und auch Kompromisse für die Software ab. Bei einer Diskussion des untersten Szenarios in Abbildung 2 beispielsweise käme der Einsatz von Betriebssystem-Funktionalität (iOS, Android) durch die jeweiligen nativen Threema-Apps zur Sprache. Änderungen im Betriebssystem durch die Hersteller können bei Updates zu Problemen führen. Die Abhängigkeiten vom jeweiligen Betriebssystem sind Kompromisse (Details siehe [2]). ATAM sieht nach der Analyse eines ersten Rutschs an Szenarien eine Ruhepause und dann eine zweite Analyse-Phase vor. In dieser kommen weitere Stakeholder hinzu, die ihre eigenen Szenarien mitbringen und den Utility Tree ergänzen. Die anschließende Analyse entspricht dem Vorgehen in Phase 1. In der Nachbereitung sichert das Bewertungsteam die Ergebnisse, beispielsweise durch Abfotografieren der Flipcharts, verfasst einen Abschlussbericht und plant gegebenenfalls Folgeaktivitäten. Insgesamt liegt der zeitliche Aufwand einer ATAM-Bewertung mit seinen moderierten Workshops zwischen zwei Tagen und mehreren Wochen. Wesentliche Aufwandstreiber sind dabei die Anzahl der eingebundenen Stakeholder und die der durchgesprochenen Szenarien. Entscheidungen als Aufhänger Bei ATAM machen die Review-Beteiligten zunächst die Anforderungen explizit und sprechen diese dann in Form konkreter Qualitätsszenarien der Reihe nach durch. Dabei kommen nicht unbedingt alle Architekturentscheidungen zur Sprache. Für fachliche Stakeholder ist diese Herangehensweise gut nachvollziehbar, zumal sie selbst Szenarien schreiben und priorisieren. Entwicklungsteams werden dabei hingegen mitunter ungeduldig: Die Betonung der Anforderungsseite sorgt dafür, dass vermeintlich spannende, technologische Fragestellungen spät, unvollständig oder gar nicht zur Diskussion kommen, da kein hoch priorisiertes Szenario sie berührt. Die Methode Decision-Centric Architecture Review (DCAR) [4] geht genau andersherum vor und rückt Architekturentscheidungen ins Zentrum. Anstatt sich von einzelnen Anforderungsaspekten in unterschiedliche Systembereiche und Konzepte leiten zu lassen, beleuchtet die Methode einzelne Architekturansätze von allen Anforderungsperspektiven. Die Reviewer arbeiten neben den Risiken in der Architektur auch die zentralen Einflussfaktoren für Entscheidungen heraus. Die Durchführung von DCAR ist wie bei ATAM workshopbasiert. Nach einer Offline-Vorbereitung treffen sich Entwicklungs- und Bewertungsteam. Am Anfang der eigentlichen Review-Session (als Dauer ist ein Tag üblich) stehen kurze Vorstellungen der Methode, der wesentlichen Ziele der zu betrachtenden Software und deren Architektur. Danach entsteht ein netzartiges Abhängigkeitsdiagramm, die Decision Relationship View, die zentrale Entwurfsentscheidungen, deren Abhängigkeiten untereinander und deren Zusammenhang mit wichtigen Einflüssen ("Forces") zeigt. Die Wahl einer passenden Persistenztechnologie kann beispielsweise von einer vorhergehenden Plattformentscheidung und gleichzeitig von Performanz- und Konsistenzüberlegungen beeinflusst sein. Es sind also mehrere Einflusskräfte am Werk. Im Rahmen eines DCAR-Workshops können die Teilnehmer nie alle identifizierten Entscheidungen besprechen. Daher wählen sie die wichtigsten direkt im Workshop aus und das Entwicklungsteam dokumentiert sie nach einem Schema ("Entscheidung"), das Architecture Decision Records ähnelt. Abbildung 3 zeigt, wie so etwas in der Praxis aussieht. Die Vorlage ist an eine Abbildung aus dem Paper "Decision-Centric Architecture Reviews" [4] angelehnt, inhaltlich geht es wieder um eine konkrete Entscheidung bezüglich des Messengers Threema. Die in einem DCAR-Workshop dokumentierten Entscheidungen ähneln Architecture Decision Records (Abb. 3). (Bild: Embarc) Falls die am Workshop Teilnehmenden die Entscheidungen wie empfohlen parallel dokumentiert haben, präsentieren sie ihren Blick auf die Problemstellung, den gewählten Ansatz und dessen Kontext. Danach diskutieren alle Beteiligten und geben als Bewertung ein Stimmungsbild in Form von Ampelfarben ab (siehe Abbildung 3 unten). Dabei bedeutet Grün, dass die Entscheidung genau passt; Gelb stellt eine noch akzeptable Einschätzung dar, Rot starke Ablehnung. Am Ende des Workshops stehen als wesentliches Roh-Ergebnis die dokumentierten Entscheidungen mit den Ampeleinschätzungen im Raum. Hieraus lassen sich sehr gut Stärken, Schwächen und Risiken der Architektur ableiten. Dieses Verdichten in Form eines Ergebnisberichtes findet im Anschluss an den Workshop statt. DCAR schlägt hierzu eine konkrete Gliederung vor. Dieses Nachdokumentieren der Architekturentscheidungen in kompakter Form stellt einen interessanten Seiteneffekt der Methode dar. Neben der eigentlichen Bewertung entsteht ein besseres Verständnis der Architektur und ihrer Zusammenhänge. Wie ATAM kommt auch DCAR primär aus dem akademischen Umfeld, wobei die Autoren das Senken des Aufwands als ihre Hauptmotivation angeben. Dies erreicht DCAR neben dem Fokussieren auf die wichtigsten Entscheidungen vor allem dadurch, dass die Teilnehmer die Anforderungen nicht so detailliert analysieren und sich etwas weniger Stakeholder beteiligen. Gleichwohl ist DCAR noch vergleichsweise aufwendig, da es noch immer recht viele Beteiligte einbezieht. Andere, im Folgenden gezeigte Methoden setzen dort an und kommen schlanker daher. Expertenbasierte Bewertungen Der Pattern-Based Architecture Review (PBAR) [5] verwendet Muster, um Analysearbeit zu sparen. Damit sind weniger die objektorientierten Entwurfsmuster gemeint als vielmehr die Architekturmuster, die das System als Ganzes oder zumindest große Teile davon strukturieren und beeinflussen. Diese Bewertungsmethode macht sich zunutze, dass bekannte Stile (wie Microservices, Schichten, hexagonale Architektur …) oder auch Muster (wie Service-Registry, Backends for Frontends, relationale Datenhaltung …) bekannte Auswirkungen auf Qualitätsmerkmale wie Wartbarkeit oder Performance haben. In einem betont schlanken, workshopbasierten Ansatz identifizieren die Beteiligten die in der Software absichtlich oder implizit verwendeten Stile sowie Muster und prüfen, ob sie zu den Zielen der betrachteten Software passen. Neben den genannten groben Architekturstilen passen hier auch moderne, spezifischere Pattern-Kataloge und Best Practices wie die Sammlung zu Microservices von Chris Richardson oder die Architekturframeworks der großen Public-Cloud-Anbieter wie das Well Architected Framework von AWS. PBAR kommt ebenfalls aus dem akademischen Umfeld, bezieht sich aber vor allem auf kleine, stark an der Time-to-Market ausgerichtete Vorhaben, die sich für einen Architektur-Review normalerweise keine Zeit nehmen. Der Ansatz über Muster stellt gegenüber DCAR eine Fokussierung dar, weil nicht beliebige Entscheidungen beleuchtet werden, sondern nur Muster auf Systemebene. Die Autoren behaupten nicht, darüber alle Risiken aufdecken zu können, aber in sehr kurzer Zeit immerhin einige. Den Reviewern fällt in PBAR eine besondere Verantwortung zu, denn sie müssen passende Muster, deren Einsatzzweck und deren Auswirkungen auf Qualitätsmerkmale gut kennen. PBAR zählt damit eher zu den Experten-Reviews. Eine weitere leichtgewichtige Methode setzt auch voll auf Experten-Power: Der Tiny Architectural Review Approach (TARA) [6] nutzt viele der genannten Techniken von ATAM und DCAR bei Bedarf, verzichtet jedoch auf das Einbeziehen aller Stakeholder des Systems. Er verlässt sich noch stärker auf das Wissen und die Erfahrung der Reviewer. Pre-Mortem und LASR Ein leichtgewichtiger, aber nicht expertenbasierter Bewertungsansatz nennt sich Pre-Mortem [7, 8]. Anders als andere leichtgewichtige Methoden spart Pre-Mortem nicht an den Beteiligten und münzt das kollektive Wissen sehr rasch in Ergebnisse um. Fast ohne Umschweife stellt Pre-Mortem die Frage, was bei dem zu analysierenden Softwaresystem zum Misserfolg führen wird. Diese Frage wird aus der Sicht einer hypothetischen Zukunft gestellt, in der das System bereits gescheitert ist. Die Gruppe hält sich also nicht mit Möglichkeiten und Wahrscheinlichkeiten auf, sondern geht direkt in die Risiko- und Problemidentifikation. Von allen genannten Methoden ist Pre-Mortem die effektivste, wenn es um Zeiteinsatz pro Output geht. Der Output ist aber auch sehr vom Systemverständnis, Kontextwissen und der Kreativität der Gruppe abhängig. Auf die Pre-Mortem-Idee setzt auch die neueste Review-Methode auf: Lightweight Approach for Software Reviews (LASR) [9]. Sie verheiratet die Zielorientierung von ATAM mit der effektiven Risikosuche von Pre-Mortem. Für beide Seiten (Ziele und Risiken) sind Materialien, zum Beispiel in Form von Spielkarten, als Ideengeber enthalten, die auch kleineren Gruppen eine geeignete Betrachtungsbreite ermöglichen. Abbildung 4 zeigt den Kern-Review von LASR mit dessen zwei Aktivitäten und insgesamt vier Schritten. Erste Aufgabe in LASR ist es, eine Zielsetzung für die betrachtete Software zu erarbeiten. Ein schlankes Mission Statement (Schritt 1) soll zunächst die Köpfe der Beteiligten öffnen. Für Threema könnten in diesem Zuge folgende Claims als Teil des Mission Statement entstehen: Mobile-App verfügbar für Android- und iOS-Geräte Schutz der Privatsphäre stets gewährleistet Zuverlässiger Versand von Nachrichten und Medieninhalten Datenschutzkonform (DSGVO etc.) Identität eines Kommunikationspartners zweifelsfrei feststellbar Sicher mit einzelnen Kontakten und in Gruppen kommunizieren Der Ablauf von LASR besteht aus zwei Aktivitäten mit insgesamt vier Schritten (Abb. 4). (Bild: Embarc) Anschließend verdichtet der Bewertungsmaßstab (Schritt 2) die wichtigsten Zielsetzungen auf ein übersichtliches Format: Die Teilnehmerinnen und Teilnehmer halten die Top 3 bis maximal Top 5 Qualitätsmerkmale mit einem Zielwert (0 bis 100) in einem Netzdiagramm fest, das später auch das Ergebnis des Reviews visualisiert. Für Threema sind Sicherheit, Zuverlässigkeit, Wartbarkeit, Kompatibilität und Benutzbarkeit die Top-Ziele, wobei insbesondere Zuverlässigkeit und Sicherheit hohe Zielwerte aufweisen. In den anderen Zielbereichen sind es durchschnittliche Anforderungen. In Schritt 3 ("Basis-Review") folgt dann ein dem Pre-Mortem ähnlicher Bewertungsansatz, wobei ideengebende Risiko-Karten zum Einsatz kommen. Über dreißig Karten zeigen typische Risikothemen und organisieren sich in acht Risikokategorien, beispielsweise Altsysteme, Plattformen, Fremdsysteme, Build- und Deployment-Aspekte oder auch methodische und organisatorische Probleme rund um Kompetenzen oder Prozesse. Mit dieser Inspiration ausgestattet, definieren die Reviewer konkrete Risiken für die Software und ordnen sie den Top-Qualitätszielen zu. Es entsteht eine blaue Ergebnislinie im LASR-Ergebnisdiagramm, das neben der grünen Ziellinie auch in Rot die gefundenen Abweichungen zeigt (siehe Abbildung 5). LASR-Ergebnisdiagramm, wobei die Achsen Ziele des Beispiels Threema nennen (Abb. 5). (Bild: Embarc) Schritt 4 erinnert dann an ATAM und mündet in einer zielorientierten Diskussion, allerdings nur in den Bereichen mit hoher Unsicherheit und nicht in voller Breite. Damit schafft LASR einen Ansatz, der günstig genug ist, um ihn wiederholt anzuwenden, aber doch fundierter und abwechslungsreicher arbeitet als Pre-Mortem. Für wen eignet sich welche Methode? So unterschiedlich wie die Anlässe sind auch die Review-Methoden selbst. ATAM gilt als die berühmteste und gleichzeitig als schwergewichtigste. Es gibt jedoch Anlässe, zu denen diese zeit- und personalaufwendige Methode passt. Bei der Auswahl einer Methode ist der Kontext entscheidend: Die organisatorische Komplexität Die Anzahl der Stakeholder Der Grad der Unsicherheit/Uneinigkeit Die Einschätzung, wie kritisch die Situation ist Die benötigte Konfidenz Der Zustand der Dokumentation / das Wissen in der Organisation Die Systemgröße Sind viele der genannten Faktoren niedrig ausgeprägt, könnte eine leichtgewichtige Methode interessant sein. Als leichtgewichtig bezeichnen sich fast alle Bewertungsmethoden, die nach ATAM veröffentlicht wurden. Bei ihnen kommen unterschiedliche Ideen zum Einsatz, um den Aufwand zu sparen: weniger beteiligte Personen, weniger aufwendig gestaltete Analyseschritte, schnellere Ergebnisse und eine Kombination aus mehreren dieser Strategien. Wo liegt der jeweilige Sweet Spot? DCAR kann ähnlich aufwendig wie ATAM werden, wenn man alle bedeutsamen Entscheidungen bewertet. Die Stärke liegt darin, einzelne Entscheidungen isoliert bewerten zu können, was gut zu iterativen Entwicklungsprozessen passt. PBAR und TARA funktionieren bei erfahrungsschwachen Teams und einem deutlichen Wissensunterschied zu den Reviewern am besten. Pre-Mortem ist wiederum eine Gruppenmethode und braucht kein Kompetenzgefälle. Weil Pre-Mortem innerhalb von zwei Stunden erste Problem-Cluster herausarbeitet und deren Bearbeitung thematisiert, ist es vor allem innerhalb des Entwicklungsteams geeignet. In agilen Projekten findet sich vielleicht in jedem vierten oder sechsten Sprint Raum für solch ein systematisches und kollektives Meeting zu "Was geht potenziell gerade schief?". LASR professionalisiert die Idee des Pre-Mortem, steuert Gruppen zu den Zielen des gebauten Softwareprodukts und sorgt mit Standardrisiken für inhaltliche Breite. Auch bei LASR ist schnell ein erstes Ergebnis vorhanden, das die Gruppe danach iterativ verfeinert. Im Fokus steht wie bei ATAM das System als Ganzes. Im Sweet Spot liegen damit Anlässe, die eine rasche Gesamtaussage erfordern oder bei denen unklar ist, wie viel das Team in einen Review investieren möchte. Für Einsteiger eignen sich eher schlankere Methoden. Interessenten wenden diese zunächst in eher unkritischem Kontext und mit wohlwollend eingestellten Entwicklungsteams an. Bei größeren Reviews sollten sie auf externe Erfahrung zurückgreifen, falls die Zeit für das eigene Vorantasten fehlt. iX Sonderheft Softwarearchitektur (Bild: iX) Dieser Artikel ist auch im iX/Developer-Sonderheft zu finden, das sich an Softwarearchitektinnen und Softwarearchitekten richtet. Neben den klassischen Architekturinhalten zu Methoden und Pattern gibt es Artikel zu Soziotechnischen Systemen, Qualitätssicherung oder zu Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies und Sicherheit. Als Autoren konnten wir bekannte Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln – wie dem hier vorliegenden – sowohl für Architektureinsteiger als auch Spezialisten weitergeben. Quellen [1] R. Kazman, M. Klein, P. Clements; ATAM: Method for Architecture Evaluation, Technical Report CMU/SEI-2000-TR-004; Carnegie Mellon University 2000 [2] Threema GmbH; Cryptography Whitepaper; Version vom April 2024 [3] Kazman, M. Klein, P. Clements; Making Architecture Design Decisions: An Economic Approach, Technical Report CMU/SEI-2002-TR-035; Carnegie Mellon University 2002 [4] Avgeriou, V. Eloranta, N. Harrison, U. van Heesch, K. Koskimies; Decision-Centric Architecture Reviews; IEEE Software Volume 31, Number 1 2014 [5] Harrison, Paris Avgeriou; Pattern-Based Architecture Reviews; IEEE Software Volume 28, Number 6, 2011 [6] Woods; Industrial Architectural Assessment Using TARA; Ninth Working IEEE/IFIP Conference on Software Architecture, 2011 [7] Klein; Performing a Project Premortem; Harvard Business Review, September 2007 [8] D. Gray, S. Brown, J. Macanufo; Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers; O'Reilly, 1. Auflage 2010 [9] S. Toth, S. Zörner; Software-Systeme reviewen mit dem Lightweight Approach for Software Reviews; Leanpub 2023 (who)