Im Laufe der Zeit werden IT-Systeme häufig von zahlreichen Problemen geplagt: Die Implementierung neuer Features kostet zunehmend mehr Zeit, der Quellcode ist schlecht nachvollziehbar, Entwicklungs- und Wartungskosten schnellen in die Höhe. Doch bevor grundlegende Entscheidungen getroffen oder Investitionen getätigt werden, empfiehlt sich eine gründliche Problemanalyse: Ein Software Review, in dessen Rahmen das System von internen oder externen Reviewern umfassend und systematisch untersucht und bewertet wird. Im Rahmen dieses Artikels möchten wir vorstellen, wie ein solches Review ablaufen kann.
Wir teilen Reviews in den meisten Fällen in fünf Phasen auf:
- Klärung der Review-Ziele
- Vorstellung des Vorhabens in einem Kick-off-Workshop
- Durchführung von Stakeholder-Interviews
- Durchführung verschiedener Analysen
- Kommunikation der Ergebnisse
Der Gesamtumfang kann dabei wenige Tage bis zu mehreren Wochen betragen – je nach Größe und Komplexität des zu betrachtenden Systems und der gewünschten Tiefe der Review-Ergebnisse.
Da die Probleme eines Systems viele, auch miteinander verknüpfte, Ursachen haben können, sollten in allen Phasen eine große Bandbreite an Aspekten, technischer, konzeptioneller und organisatorischer Natur, berücksichtigt werden, wir bezeichnen das als Breitensuche.
Klärung von Zielen, Umfang, Gegenstand
Vor Beginn eines Software Reviews sollten zunächst die Review-Ziele, der zeitliche Umfang, der Gegenstand und die Vorgehensweise mit dem Auftraggeber oder Entwicklungsverantwortlichen abgesprochen werden. Sofern es sich um ein unbekanntes System handelt ist es daneben sinnvoll, sich erste Informationen und Dokumentation des Systems zu beschaffen um den weiteren Verlauf besser planen zu können.
Kick-off-Workshop
Als Nächstes wird im Rahmen eines Kick-off-Workshops das Review-Vorhaben, dessen Ziele und Ablauf allen Interessierten vorgestellt, sowie dem Review-Team das zu analysierende System, seine Rahmenbedingungen und Prozesse skizziert. Es ist wichtig, dass alle relevanten Stakeholder teilnehmen, damit die Review-Ziele abgestimmt sind und die wichtigsten Architekturtreiber identifiziert werden können.
Stakeholder-Interviews
Die anschließenden Stakeholder-Interviews bilden zusammen mit den Analysen das Kernstück eines Reviews und bieten tiefe Einblicke in einzelne Aspekte des Systems. Die Interview-Partner sollten, im Sinne der Breitensuche, aus möglichst unterschiedlichen Bereichen kommen. Infrage kommen beispielsweise:
- Nutzer
- Test/Qualitätssicherung, falls nicht Teil des Entwicklungsteams
- Personen aus Infrastruktur und/oder Betrieb
- Mitglieder des Entwicklungsteams
Interviews sollten gut vorbereitet werden. Idealerweise werden den Interviewpartnern die Fragen vorab übermittelt, so dass diese sich entsprechend vorbereiten können und vielleicht auch passende Unterlagen zum Gespräch mitbringen können.
Schon Jerry Weinberg sagte: “Clients always know how to solve their problems, and always tell the solution in the first five minutes”. Viele Stakeholder sind sich der existierenden Probleme eines Systems sehr bewusst und haben sich auch bereits Gedanken zu Lösungsmöglichkeiten gemacht. Oftmals fehlt aber eine Plattform um die bereits bekannten Probleme und Lösungsvorschläge systematisch zu sammeln, zu konsolidieren, aufzubereiten und zu priorisieren – ein Review kann eine solche Plattform bieten.
Analysen
Parallel zu den Interviews erfolgen Analysen, in denen verschiedene Aspekte des Systems anhand jeweils geeigneter Methodiken oder Fragestellungen nach Schwachpunkten untersucht werden. Manchmal ergibt sich aus den Ergebnissen dieser Analysen der Wunsch nach weiteren Interviews – und umgekehrt.
Wir betrachten im Rahmen von Analysen üblicherweise die folgenden Aspekte: Kontext des Systems, Qualitätseigenschaften, Anwendungsdaten, Architektur, Quellcode, Prozesse und Infrastruktur.
Kontextanalyse
Die Kontextanalyse dient zur Untersuchung von Risiken und Problemen der Schnittstellen zu Nachbarsystemen. Das Augenmerk sollte dabei auf den Ablauf von Schnittstellenänderungen, die Kosten der Schnittstelle und die Qualität der Datenlieferung gerichtet werden.
Qualitative Analyse
Die Qualität eines Systems gibt an, inwieweit es bestehenden Anforderungen genügt, beispielsweise Performance, Stabilität, Änderbarkeit, Time-to-Market oder Sicherheit. Zunächst einmal sollte geklärt werden, was diese Anforderungen im konkreten Fall sind. Eine Sachbearbeitungsanwendung im Versicherungsumfeld wird sehr wahrscheinlich sehr hohe Anforderungen an eine zuverlässige, dauerhafte Speicherung von Daten haben, aber vermutlich nicht allzu hohe Anforderungen im Bereich horizontale Skalierbarkeit haben. Dagegen wird eine Anwendung zur Überwachung von Kühlräumen für Lebensmittel sehr wahrscheinlich sehr hohe Anforderungen im Bereich Ausfallsicherheit haben, vermutlich ist es aber nicht ganz so dramatisch, wenn zwischendurch mal ein Messwert verloren geht.
Eine Übersicht über alle Qualitätsanforderungen kann unter zu Hilfe nahme der ISO 25010, welche eine umfassende Auflistung von Qualitätsattributen beinhaltet, erarbeitet werden. Dazu können beispielsweise Qualitätsszenarien genutzt werden. So wird bei einem Nutzungsszenario eine Funktion des Systems Schritt für Schritt durchgegangen und dabei qualitative Anforderungen abgeleitet.
Eine Alternative dazu ist das Quality Storming. Dabei handelt es sich um ein Workshopformat, zur kollaborativen Erarbeitung von Qualitätsanforderungen. Eine genaue Beschreibung finden Sie in Quality-Storming.
Architekturanalyse
Im Bereich der Systemarchitektur empfehlen sich Analysen auf unterschiedlichen Abstraktionsniveaus. Wir unterscheiden hier zwischen Domänen-, Makro und Mikroarchitektur. Die Domänenarchitektur befasst sich mit der fachlichen Modularisierung der Anwendungslandschaft und den Informationsflüssen zwischen den Anwendungen. Eine suboptimale Modellierung an dieser Stelle kann zu einer engen Kopplung und unnötig komplexen und fehleranfälligen Systemen führen. Eine gute Möglichkeit Probleme in diesem Bereich zu analysieren bieten Methoden aus dem Bereich Domain Driven Design. Details dazu finden Sie beispielsweise in DDD. Bei der Makroarchitektur geht es um übergreifende Themen, die innerhalb einer Systemlandschaft einheitlich geregelt werden sollten um Einheitlichkeit und Nachvollziehbarkeit zu gewährleisten. Dazu gehören beispielsweise die zur Kommunikation zwischen Anwendungen verwendeten Protokolle, die UI-Integration der verschiedenen Teilsysteme, Monitoring und Logging, Betriebsschnittstellen, etc. Hier gilt es zunächst zu prüfen ob und welche Vorgaben es für diese Themen gibt und ob diese in sich selbst Lücken oder Widersprüche aufweisen. Der nächste Schritt ist dann, zu überprüfen ob diese Vorgaben in den Systemen auch umgesetzt werden. Bei der Mikroarchitektur geht es um die Interna eines Systems. Sie umfasst beispielsweise die interne Modularisierung, Architekturmuster, Frameworks, Bibliotheken und Programmiersprachen. Zentrale Punkte sind hier eine Einschätzund der Zukunftsfähigkeit des Technologiestacks und eine Analyse der internen Modularisierung und Abhängigkeiten des Systems.
Codeanalyse
Die Analyse des Quellcodes liefert Hinweise darauf, in wieweit die Vorgaben aus Mikro- und Makroarchitektur korrekt umgesetzt werden. Daneben ermöglicht er eine Beurteilung der handwerklichen Qualität, beispielsweise ob schwer verständliche Teile, verursacht durch übermäßige Größe, Komplexität oder Abhängigkeiten vorhanden sind, sowie des aktuellen Wartungslevels im Hinblick auf die Aktualität der verwendeten Frameworks und Bibliotheken. Ein weiterer wichtiger Aspekt ist, in welchem Umfang automatisierte Tests vorhanden sind und was diese abdecken. Interessant ist unter Umständen auch eine Untersuchung der Historie der Versionsverwaltung um Hotspots, also Stellen die besonders oft geändert werden, zu entdecken. Zentrale Stellen des Sourcecodes sollten in jedem Fall manuell durchgesehen werden. Da es im Rahmen eines Reviews üblicherweise jedoch nicht möglich ist, die gesamte Codebasis manuell zu analysieren empfiehlt es sich auch auf die Unterstützung von Tools wie SonarQube, TeamScale, ReSharper oder Checkstyle zur automatisierten Analyse zurückzugreifen.
Analyse von Anwendungsdaten
Bei den meisten Systemen ist die zuverlässige und performante Speicherung und Bereitstellung von Daten eine Kernaufgabe. Da die Daten eines Systems oftmals länger leben als der Quellcode, verdienen sie eine besondere Aufmerksamkeit. Dies betrifft insbesondere die Aspekte Konsistenz, Datenmodell, Datenqualität und effiziente Nutzung. Zunächst gilt es hier, sich einen Überblick über die datenspeichernden Systeme zu verschaffen und zu ermitteln, ob die eingesetzte Datenspeicher die funktionalen Anforderungen des Systems erfüllen. Solche Anforderungen können beispielsweise die effiziente Speicherung von Binärdaten, Konsistenzbedingungen oder die Bereitstellung von Funktionen für Volltextsuche sein. Als Nächstes sollte ein Blick auf die Datenmodellierung geworfen werfen: Passt das vom Datenspeicher vorgegebene Datenmodell zur Struktur der Daten? Wird die vorgegebene Datenmodellierung effizient und korrekt umgesetzt? Probleme mit der Datenqualität können sich durch die Notwendigkeit manueller Nacharbeiten oder die Implementierung von Workarounds bemerkbar machen. Prüfen Sie außerdem Antwortzeiten und Durchsatz von Anfragen und machen Sie besonders lang laufende Anfragen ausfindig. Falls das System Daten für andere bereitstellt, sollte geprüft werden wie zugänglich die Daten für andere Systeme sind. Dies umfasst Aspekte wie die Schnittstellendokumentation, Zugriffslimits, Performance-Engpässe oder das verwendete Austauschprotokoll.
Analyse von Prozessen
Die Art und Weise wie Anforderungen geklärt und priorisiert werden, wie ein System entwickelt, getestet und in Produktion gebracht wird, hat erheblichen Einfluss auf die Time-to-Market und die Qualität des Systems. Auch hier gilt, dass das Vorgehen in erster Linie zum Projekt passen muss und es keine universal richtige Vorgehensweise gibt. Wenn Änderungen nur in großen Abständen notwendig sind, weil das Programm nur einmal im Jahr für einen Steuerabschluss benötigt wird ist evtl. ein Vorgehen mit langen Iterationszyklen in Ordnung, in der schnelllebigen Welt des E-Commerce hingegen nicht. Schwierig wird es insbesondere, wenn mehrere beteilige Personen unterschiedliche Ziele verfolgen. Ein weiteres negatives Merkmal ist es, wenn Prozesse durch exzessives Gatekeeping geprägt sind, beispielsweise explizite Freigaben bei jedem Schritt eines Prozesses erforderlich sind.
Analyse von Infrastruktur
Die Betriebsinfrastruktur und die zugehörigen Betriebsabläufe befinden sich häufig in einem Spannungsfeld sich widersprechender Ziele: Hohe Ausfallsicherheit mit geringen Kosten bei gleichzeitig hoher Änderungsgeschwindigkeit. Eine zentrale Aufgabe der Analyse ist es, herauszufinden, ob hier ein für das Projekt guter Kompromiss gefunden wurde oder beispielsweise mehr in die Automatisierung sich wiederholender Tasks investiert werden oder auf eine einfachere Betriebsinfrastruktur gewechselt werden sollte. Als zweiter wichtiger Punkt, wird geprüft, welche Risiken in puncto Systemausfall vorhanden sind und ob und wie diese adressiert werden. Im Idealfall wird nach jedem größeren Systemausfall ein Post Mortem erstellt, also eine detaillierte Beschreibung, welche Einzelfehler zu dem Ausfall geführt haben. Aus diesen Post Mortems können dann Playbooks, also detaillierte Handlungsanweisungen für spezifische Fehlerfälle abgeleitet werden.
Kommunikation der Ergebnisse
Am Abschluss eines Software Reviews steht üblicherweise ein Abschlussbericht oder eine Abschlusspräsentation. Unser Vorschlag ist, diese in fünf Teile zu gliedern.
- Eine kurze, prägnante Zusammenfassung der wesentlichen Erkenntnisse, ein sogenanntes Management Summary.
- Beschreibung der organisatorischen Rahmenbedingungen des Reviews, wie etwa Ziele, Scope und Beschränkungen.
- Eine Auflistung der Aspekte die beibehalten werden sollten, da sie einen fundamentalen Mehrwert für das System liefern.
- Eine Liste der gefundenen Probleme. Diese sollten nach wirtschaftlichen und technischen Kriterien gruppiert werden. Wir verwenden dazu, sofern es keine anderen Vorgaben gibt, das folgende Schema:
- Je nach Aufgabenstellung wird der Bericht noch um eine Empfehlung von Maßnahmen ergänzt.
Häufigkeit von Software Reviews
Je nach Entwicklungsgeschwindigkeit und Änderungsrate kann es sinnvoll sein, Reviews in regelmäßigen Abständen zu wiederholen. Dabei kann auf vorhergehende Ergebnisse zurückgegriffen werden, um die Verbesserungen seit dem letzten Review zu prüfen. In der Zwischenzeit kann sich auch der Fokus eines Softwaresystems und damit die Qualitätsziele verschieben, sodass eine neue Zielarchitektur erarbeitet werden muss. Solche Themen kommen am besten in Gesprächen zutage in denen man sich nicht mit den konkreten Tagesgeschäftsthemen beschäftigt. So können versteckte technische Schulden wesentlich früher erkannt und adressiert werden, was zu einer langfristigen Nutzung eines Softwaresystems beitragen kann.
Hinweis
Falls wir Ihr Interesse am Thema “Software Reviews” geweckt haben und Sie sich intensiver mit dem Thema beschäftigen möchten, werfen Sie doch einen Blick in unser gleichnamiges Buch.