Als Software-Dienstleister beginnen wir bei Spaceteams selten bei Null. Obwohl dies gelegentlich vorkommt, ist es weitaus häufiger der Fall, dass eine bestehende Software optimiert, erweitert oder skaliert werden muss.
Um ein solides Verständnis für den Umfang, die Herausforderungen und die Möglichkeiten zu erlangen, beginnt jedes Projekt mit einer „Discovery-Phase“. Wenn ein Tool oder eine Softwarelösung bereits existiert, ist deren Bewertung ein wesentlicher Bestandteil dieser Phase.
In diesem Artikel werden wir:
- Ihnen einen Überblick über unseren allgemeinen Ansatz zur Analyse bestehender Software geben
- Ihnen genauer erklären, worauf wir uns bei der technischen Analyse konzentrieren
- Ihnen die Vorteile einer unabhängigen, externen Evaluierung Ihrer Software durch Experten aufzeigen
Unser allgemeiner Ansatz
Schritt 1: Gespräch mit den Expert:innen
Zunächst vereinbaren wir ein Meeting oder, bei größeren Systemen, eine Reihe von Meetings oder einen Workshop, bei dem unser Kunde uns die Software vorstellt. Dabei werden die angestrebten Geschäftsziele, die Benutzeroberfläche, zentrale Prozesse und alle bekannten Einschränkungen behandelt.
Dies ist niemals eine einseitige Präsentation. Wir stellen währenddessen Fragen und versuchen, ein ganzheitliches Verständnis für folgende Punkte zu entwickeln:
- Welchen Zweck hat die Software?
- Wie interagiert ein:e Nutzer:in mit der Software?
- Wie sieht der aktuelle Entwicklungsworkflow aus?
- Welche Deployment- und Release-Prozesse gibt es?
- Welche Probleme und Einschränkungen sind bekannt?
Bevor wir fortfahren, legen wir gemeinsam den konkreten Umfang der Analyse fest:
Liegt der Schwerpunkt auf Benutzerfreundlichkeit? Skalierbarkeit? Sicherheit? Wartbarkeit? (Oder gleichermaßen auf allen diesen Punkten?)
Diese Abstimmung stellt sicher, dass wir das System aus der richtigen Perspektive bewerten.
Schritt 2: Ein tieferer Einblick
In diesem Schritt tauchen wir in den „Maschinenraum” der Software ein. Je nach Konfiguration kann dies Produktumgebung, Codebase, Dokumentation und Teamprozesse umfassen.
Fachliche Analyse
Im Idealfall erhalten wir Zugriff auf eine laufende Produktions- und/oder Staging-Umgebung. Dies ermöglicht uns:
- das Tool wie ein echter User zu erkunden,
- Prozesse direkt über die Benutzeroberfläche zu verstehen,
- die Benutzerfreundlichkeit und Übersichtlichkeit zu bewerten und
- zu überprüfen, ob die Arbeitsabläufe der beabsichtigten Geschäftslogik entsprechen.
Wir überprüfen auch die verfügbare Dokumentation (falls vorhanden). Interessanterweise ist veraltete oder fehlende Dokumentation ein häufiges Ergebnis dieser Bewertungen.
Technische Analyse
Für die technische Analyse benötigen wir Zugriff auf den Code und die unterstützenden Systeme. Wir untersuchen dabei Fragen wie:
- Wie wartungsfreundlich und modular ist der Code?
- Gibt es strukturelle oder architektonische Engpässe?
- Gibt es Sicherheitslücken?
- Ist der Technologie-Stack modern, angemessen und skalierbar?
Wir schauen dabei auch Tools wie Jira oder vergleichbare Taskboards an, um aus bekannten Bugs, Incidents und bestehenden technische Schulden Ableitungen treffen zu können.
(Wir gehen auf diesen Schritt im Abschnitt „Technische Analyse” weiter unten näher ein.)
Entwicklungsprozessanalyse
Die Softwarequalität hängt eng mit den Teamprozessen zusammen. Daher untersuchen wir:
- Methoden der Zusammenarbeit
- Aufgaben- und Release-Workflows
- Bereitstellungs- und CI/CD-Strukturen
- Kommunikation zwischen Stakeholdern und Entwicklern
Dadurch erhalten wir wertvolle Einblicke in die Art und Weise, wie die Software bisher entwickelt und gewartet wurde.
Schritt 3: Synthese
Evaluierung ist bei Spaceteams niemals eine Ein-Mann-Aufgabe. Wir besprechen die Ergebnisse immer mit mindestens einem Kollegen oder einer Kollegin, hinterfragen Annahmen, validieren Perspektiven und priorisieren gemeinsam die aufgedeckten Probleme.
Die Ergebnisse werden dann für unsere Kund:innen zusammengefasst mit:
- klaren Prioritäten
- konkreten Beispielen (einschließlich Code-Auszügen, falls hilfreich)
- identifizierten Risiken
- Empfehlungen für die nächsten Schritte
Anstatt einen traditionellen PDF-Bericht zu erstellen, dokumentieren wir in der Regel alles auf strukturierte Weise mit Miro – unserem bevorzugten Tool für visuelle Klarheit und Zusammenarbeit.
Schritt 4: Kundenpräsentation und Diskussion
In der Regel treffen wir uns nach ein bis zwei Wochen mit unserem Kunden, um ihnen die Ergebnisse vorzustellen. Wir gehen wichtige Erkenntnisse durch, zeigen relevante Beispiele und diskutieren offen mögliche nächste Schritte.
Manchmal finden diese Diskussionen sofort statt, manchmal ist eine separate Folgesitzung sinnvoller – je nach Komplexität und den Bedürfnissen des Kunden.
Die technische Analyse – was genau machen wir dabei?
Bevor wir Verbesserungen empfehlen oder eine Neuentwicklung planen, nehmen wir uns Zeit, um deine bestehende Software genau zu verstehen. Eine gründliche technische Analyse zeigt uns, was gut funktioniert, wo potenzielle Risiken liegen und wie das System nachhaltig weiterentwickelt werden kann. Diese Phase schafft Klarheit für beide Seiten und sorgt dafür, dass alle Erwartungen für den Rest des Projekts aufeinander abgestimmt sind.
1. Die Software aus erster Hand erkunden
Wir beginnen damit, die Software so zu nutzen, wie es ein:e Endnutzer:in tun würde. Egal, ob es sich um eine Web-App für Kund:innen oder ein internes Business-Tool handelt, dieser Schritt hilft uns, den Zweck, die wichtigsten Nutzerwege und das Verhalten des Systems im täglichen Gebrauch zu verstehen. Hier fallen uns auch erste Anzeichen wie langsam ladende Seiten, unklare Abläufe oder Inkonsistenzen in der Benutzeroberfläche auf. Diese ersten Eindrücke weisen uns auf Bereiche hin, die später möglicherweise einer genaueren Untersuchung bedürfen.
2. Überprüfung der Architektur- und Flow-Diagramme
Wenn Architektur- oder Flow-Diagramme verfügbar sind, untersuchen wir diese als Nächstes. Selbst ein einfaches Diagramm kann viel darüber verraten, wie das System bereitgestellt und strukturiert ist – ob es in der Cloud oder auf eigenen Servern läuft, wie die Komponenten kommunizieren und welche externen Dienste oder Integrationen beteiligt sind. Es hilft uns auch, potenzielle Engpässe oder Einfallstore zu erkennen, an denen Sicherheitslücken bestehen könnten. Mit diesem übergeordneten Kontext lässt sich später das, was wir im Code sehen, viel leichter interpretieren.
3. Erster Blick auf den Code
Nachdem diese Grundlage geschaffen ist, sehen wir uns den Code zunächst einmal grob an. Das Ziel in dieser Phase ist es nicht, jedes Detail zu verstehen, sondern ein Gefühl für den gewählten Tech-Stack, die verwendeten Frameworks und Bibliotheken sowie den allgemeinen Architekturstil zu bekommen. Wir suchen nach Dingen wie veralteten Abhängigkeiten, ungewöhnlichen Code Stellen und Mustern, die auffallen – sowohl guten als auch schlechten. Dieser erste Durchgang gibt uns oft einen Eindruck von der Wartbarkeit des Systems und davon, wie einfach (oder schwierig) zukünftige Änderungen sein könnten.
4. Ausführen der Tests
Wenn das Projekt automatisierte Tests umfasst, sind diese eine wertvolle Informationsquelle. Tests zeigen oft, wie sich das System nach den Vorstellungen der Entwickler verhalten soll, welche Sonderfälle ihnen wichtig waren und wie sicher Änderungen vorgenommen werden können, ohne die bestehende Funktionalität zu beeinträchtigen. Das Vorhandensein, die Struktur und die Abdeckung von Tests sagen viel über die Reife des Projekts aus. Wenn Tests fehlen oder veraltet sind, ist das ebenso aussagekräftig.
5. Tiefgehende Analyse wichtiger Code-Bereiche
Sobald wir uns einen Überblick verschafft haben, tauchen wir tiefer in bestimmte Teile der Codebasis ein – in der Regel in Bereiche, die wichtige Datenflüsse, Geschäftslogik oder Benutzerinteraktionen verarbeiten. Wir analysieren, wie Daten durch das System fließen, wie Benutzer:innen authentifiziert und autorisiert werden und ob sensible Informationen sicher behandelt werden. In dieser Phase decken wir häufig Probleme wie fest codierte Secrets (z.B. Zugangsdaten), unsichere Datenbankzugriffsmuster oder Module auf, die so eng miteinander verbunden sind, dass sie die zukünftige Skalierbarkeit behindern. An dieser Stelle beginnt sich das Gesamtbild der Anwendung abzuzeichnen.
6. Überprüfung auf OWASP-Schwachstellen
Sicherheit hat immer Priorität, daher führen wir eine gezielte Überprüfung auf häufige OWASP-Schwachstellen durch. Dazu gehören beispielsweise das Risiko für Code Injections, schwache Authentifizierungsmechanismen, die Offenlegung sensibler Daten, Cross-Site-Scripting-Probleme oder veraltete Komponenten, die bekannte Sicherheitslücken enthalten. Selbst eine oberflächliche Überprüfung kann wichtige Risiken aufdecken, die frühzeitig im Projekt behoben werden sollten.
7. Transparente Dokumentation der Ergebnisse
Während des gesamten Prozesses dokumentieren wir alles in einem gemeinsamen Miro-Board. Jeder Befund enthält den Kontext des Problems, einen relevanten Codeausschnitt, eine Erklärung, warum es wichtig ist, seinen Schweregrad und einen empfohlenen Ansatz zur Behebung. Dies schafft eine klare, transparente Grundlage für die Diskussion der nächsten Schritte mit dem Kundenteam und stellt sicher, dass wir mit einem gemeinsamen Verständnis über den aktuellen Zustand des Systems vorankommen.
Warum eine externe Analyse wertvoll ist
Aus unserer Sicht sind externe Analysen oft nicht nur wertvoll, sondern schlichtweg notwendig. Dies gilt insbesondere dann, wenn ein Unternehmen maßgeschneiderte Software einsetzt, aber keine internen Spezialist:innen hat, die die Lösung bewerten können. In anderen Fällen ist zwar internes Fachwissen vorhanden, aber die Spezialist:innen verfügen häufig nicht über ausreichende Kapazitäten.
Wenn Ihr Unternehmen keine internen Expert:innen hat, die eine detaillierte Softwarebewertung durchführen können, sind Ihnen möglicherweise Risiken wie die folgenden nicht bewusst:
- Architektonische oder strukturelle Schwächen Ihrer Software
- Sicherheitslücken
- Veralteter oder eng gekoppelter Code mit entsprechenden Abhängigkeiten
- Angestauter technischer Schuldenberg
- Unzureichende Testumgebung
Diese Probleme bleiben oft unsichtbar, bis sie zu kostspieligen Problemen werden. Schwächen in der Architektur und im Code verlangsamen Ihre Entwicklungsleistung, verursachen unerwartete Fehler und machen die Wartung Ihrer Software immer komplizierter. Sicherheitslücken sind ein noch größeres Problem, da sie Ihr Unternehmen anfällig für Angriffe von außen machen.
Und selbst wenn Sie über interne Expert:innen verfügen, ist eine externe Perspektive unglaublich wertvoll: Externe Gutachter:innen haben keine emotionale oder politische Bindung an das Produkt und können daher eine unvoreingenommene, objektive Bewertung abgeben. Darüber hinaus können externe Gutachter:innen sogar neue Erfahrungen aus anderen Projekten einbringen oder Ihr System anhand von Branchenstandards bewerten.
So haben wir beispielsweise kürzlich die Berliner Stadtmission mit einem solchen unvoreingenommenen „Blick von außen“ unterstützt und dabei sowohl die technische Seite (Struktur, Wartungsaufwand, Sicherheit) als auch die organisatorische Seite (Benutzerfreundlichkeit, Prozesse usw.) analysiert. Mit den Ergebnissen erhielt der Kunde einen umfassenden Überblick darüber, wo er steht und in welchen Bereichen Verbesserungspotenzial besteht.
Wie wir bei Spaceteams die „externe Perspektive” sicherstellen
Bei Spaceteams glauben wir an den großen Mehrwert einer externen Perspektive auf unsere Projekte. Da wir in mehreren Teams für verschiedene Kunden arbeiten, haben wir verschiedene teamübergreifende Best Practices eingerichtet, um diese externe Perspektive in unseren Projekten zu gewährleisten:
- Architekturprüfungen für neue Projekte: Unsere erfahrenen Entwickler:innen hinterfragen vorgeschlagene Architekturen und Technologieentscheidungen bereits in einer frühen Phase des Prozesses.
- Regelmäßige technische Show-and-Tell-Sitzungen: Unsere Teams präsentieren sich gegenseitig ihre Lösungen, tauschen Erfahrungen aus und diskutieren Verbesserungsmöglichkeiten.
- Wöchentliche Produktabstimmung: Unsere Teamleiter:innen stimmen sich wöchentlich mit unserem Hey of Engineering ab, um (unter anderem) technische Herausforderungen und gewählte Lösungen zu besprechen.
Möchten Sie wissen, ob Ihre Softwaresysteme in Bezug auf Sicherheit, Wartbarkeit oder Benutzerfreundlichkeit in gutem Zustand sind? Dann ist eine Status-quo-Analyse durch externe Software-Experten eine gute Möglichkeit, dies herauszufinden. Kontaktieren Sie uns einfach oder buchen Sie eine kostenlose Beratung, um mehr zu erfahren!
