Suche
Kolumne

Knigge für Softwarearchitekten: Der Fahnder

Peter Hruschka, Gernot Starke

©Shutterstock.com/Dima Sobko

Willkommen zur zweiten Folge unserer Kolumne über Änderung, Evolution und Sanierung bestehender Software. Diesmal fahnden wir nach Softwareverbrechen, Codesünden oder risikoträchtigen Teilen der Software.

Bei klassischen Delikten haben Fahnder es meistens mit der Einzahl zu tun: ein Täter, ein einziges Verbrechen (Clages, Horst (Hrs): „Grundzüge der Kriminalpraxis“) . Nehmen wir als Beispiel die mutwillig zerschlagene Fensterscheibe: ein Täter, ein Tatwerkzeug, ein beschädigtes Fenster. Bei Software verursachen meistens viele Täter jeweils nur Teile des Gesamtschadens. An einer einzigen Sache werden sozusagen beliebig viele Verbrechen unterschiedlicher Arten begangen. Etwa so, als würde unser Steinewerfer auch noch falsch parken, das Haus mit Graffiti beschmieren und die Haustüre mit Sekundenkleber an ihrem Rahmen fixieren. Statt also klassisch nur nach Motiv und Gelegenheit zu suchen, müssen wir als IT-Fahnder zuerst einmal die begangenen Verbrechen untersuchen:

  • Qualitative Sünden: Wo werden welche Qualitätsanforderungen verletzt?
  • Funktionale Sünden: Wo verhält sich ein System fehlerhaft, stellt nicht die notwendige Funktionalität bereit oder arbeitet falsch?
  • Kostensünden: Wo wird Geld verschwendet – durch überteuerten Betrieb oder aufwändige Wartung/Erweiterung?
  • Codesünden: Wo steckt unverständlicher, schlechter Code?
  • Architektursünden: Welche Entscheidungen, Frameworks, Technologien, Schnittstellen oder Strukturen erscheinen mangelhaft?
  • Prozesssünden: Wo behindern starre oder aufgeblähte Prozesse die effektive Arbeit am System? Welche notwendigen Aufgaben werden vernachlässigt?
  • Managementsünden: Wo fehlt es an notwendiger Unterstützung?

Wir haben schon Systeme erlebt (ähm – erlitten), an denen sämtliche dieser Sünden und Vergehen in wechselnden Mengenverhältnissen begangen wurden. Übrigens haben wir auch (aber nur sehr wenige) Systeme erlebt, an denen keine relevanten Verbrechen verübt wurden.

Finden Sie die begangenen Softwareverbrechen eines Systems (in IT-Speak: Probleme, Risiken und technische Schulden) durch zwei verschiedene Ansätze: Einerseits durch Vernehmung von Opfern und relevanten Zeugen, andererseits über Spurensicherung am echten System.

Opfer und Zeugen vernehmen

Den Tatort, oder besser den „Gegenstand der Verbrechen“, inspizieren Sie am besten aus unterschiedlichen Perspektiven. Zuerst sollten Sie sich live ein Bild von seinem Zustand machen – am besten haben Sie vorher aus Berichten der Beteiligten den ursprünglichen Zweck des Systems verstanden.

Jetzt sind Sie gut gerüstet für die Vernehmung der ersten Opfer und Zeugen: Befragen Sie Anwender, Betreiber und Auftraggeber. Führen Sie Interviews mit Entwicklern und Testern des Systems bzw. direkter Nachbarsysteme. Fragen Sie nach deren Einschätzung der „schlimmsten Sünden“, ob Technologie und Organisation überhaupt zu den Anforderungen passen.

Konzentrieren Sie sich dabei auf die Suche nach Problemen, aber sammeln Sie auch positive Aspekte. Falls Ihre Interviewpartner schon Lösungsansätze vorschlagen, nehmen Sie diese unkommentiert zur Kenntnis – aber verlieren Sie sich jetzt nicht in Lösungsdiskussionen. Es geht um eine Bestandsaufnahme bekannter Schäden, Schwachstellen und Stärken des Systems, nicht um Tatverdächtige. Wir wollen ein möglichst umfassendes Bild von relevanten Stakeholdern, bevor wir später zu Abhilfe oder Therapie kommen.

Spurensicherung

Mit den gezielten Hinweisen der betroffenen Stakeholder können Sie sich an die Spurensuche am System selbst begeben. Wir empfehlen Ihnen dringend, auch hier unterschiedliche Fahndungsansätze zu verfolgen. Zuerst untersuchen Sie die qualitativen Sünden: Die pragmatische Anwendung der erprobten ATAMMethode hilft Ihnen, die geforderten und real vorhandenen Qualitätseigenschaften des Systems sehr feingranular zu untersuchen. Besonders mögen wir an der Methode, dass sie ohne besondere Werkzeuge auf praktisch alle Arten von Systemen anwendbar ist. Sie lernen daraus viel über die Architektur des Systems. Als Nebeneffekt hilft sie, die Qualitätsanforderungen an Systeme sehr präzise zu formulieren. Wesentliche Voraussetzung für ATAM ist allerdings, dass Sie Architekten oder technische Experten des betroffenen Systems beteiligen können.

Zusätzlich zur qualitativen Betrachtung sollten Sie nun einen intensiven Blick auf den Quellcode werfen: Untersuchen Sie Kopplung, Kohäsion und Komplexität, finden Sie Ausreißer nach oben und unten. Korrelieren Sie die Ergebnisse unbedingt mit organisatorischen Metriken, beispielsweise Wartungs- oder Änderungsaufwänden, der Anzahl gefundener Fehler pro Komponente bzw. Subsystem oder der Anzahl vorhandener Know-how-Träger pro Komponente. Durch diese Untersuchung finden Sie kritischen oder riskanten Code.

Follow the Money

Krimiautoren erklären ihren Lesern oftmals, dass die Fahnder und Kommissare „der Spur des Geldes folgen sollen“. Diesen Aspekt der Fahndung sollten Sie auf jeden Fall berücksichtigen. Stellen Sie fest, in welchen Bereichen von Konzeption, Entwicklung, Test und Betrieb für das System welche Kosten entstehen – und wodurch. Vergleichen Sie dies auch mit dem durch das System erzeugten (finanziellen) Nutzen.

Am besten vergleichen Sie diese Ergebnisse mit anderen Systemen oder Projekten („Benchmarking“), sofern Sie diese Möglichkeit besitzen.

Fazit

Falls Sie auch nur im Entferntesten mit Änderungen, Erweiterung, Sanierung oder Evolution bestehender Software zu tun haben, sollte die Fahndung nach „Softwareverbrechen“ (landläufig: „Bewertung“, „Audits“) zu Ihren regulären Tätigkeiten gehören.

Lassen Sie sich nicht von Gangstern einschüchtern – die meisten begehen in der IT-Branche ihre Sünden ja zum Glück unblutig. Aus den Fahndungsergebnissen können Sie effektive Handlungsempfehlungen ableiten und damit konstruktiv für zielgerichtete Verbesserung sorgen.

Aufmacherbild: Magnifying glass on a background von Shutterstock / Urheberrecht: Dima Sobko

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.