Software Analyse

Software-Qualitätsanalyse bei der Übernahme einer unbekannten Codebasis bezeichnet das strukturierte Vorgehen, um in kurzer Zeit den Zustand einer fremden Software zu bewerten. Statische Analyse-Werkzeuge wie SonarQube liefern dabei erste Einblicke zu Wartbarkeit, Robustheit und Sicherheit. Fehlende Dokumentation und unvollständig übergebene Komponenten zählen zu den häufigsten Risiken solcher Übernahmen.

Das Wichtigste in Kürze

• Wer Testing als erstes aus dem Budget streicht, macht Projekte teurer und komplizierter, nicht günstiger, weil fehlende Qualitätssicherung Probleme nur verzögert, nicht verhindert.
• Eine vollzeitige Testmanagerin im Entwicklungsteam ist unüblich, bringt aber strukturelle Klarheit, die alle anderen Disziplinen direkt entlastet.
• Offenheit über Projektrisiken muss früh kommen: Wer schlechte Nachrichten zurückhält, bekommt sie zu einem ungünstigeren Zeitpunkt zurück.
• Agiles Mindset bedeutet hier konkret, das Team-Setup mitten im Projekt umzubauen, als sich die Anforderungen verschoben haben, zum Beispiel einen zweiten Architekten statt Entwickler einzusetzen.
• Eine Migration ohne Downtime gelingt zuverlässiger, wenn sie drei Wochen vorher mit echten Live-Daten vollständig geprobt wird.

Eine fremde Software übernehmen heißt, mit Überraschungen rechnen

Wer eine bestehende Software kauft, übernimmt selten ein sauber dokumentiertes Paket. Häufiger ist es ein Überraschungsei: Man weiß nicht genau, was drinsteckt, wie es um die Qualität steht und ob das System überhaupt wartbar ist.

Genau diese Ausgangslage hatte ein Anbieter für öffentliche Mobilität bei der Übernahme eines bestehenden Ticketshops. Es ging nicht nur um Nutzungsrechte, sondern um das ganze Produkt. Vor dem Kauf war unklar, welche Komponenten mitkommen, wie gut der Code ist und ob sich die Übernahme lohnt.

Sonja Trimmel und Helmut Nitsch begleiteten dieses Projekt. Ihre Erfahrung zeigt, worauf es ankommt, wenn man eine unbekannte Codebasis übernimmt und in einen tragfähigen Zustand bringt.

Wie bewertet man eine fremde Codebasis in kurzer Zeit?

Eine erste Einschätzung gelingt auch unter Zeitdruck, wenn man statische Analyse einsetzt. Für die initiale Bewertung standen nur eineinhalb Tage zur Verfügung, bei mehreren tausend Zeilen Code zu wenig für eine manuelle Vollprüfung.

Werkzeuge zur statischen Analyse, etwa SonarQube, liefern in dieser Situation einen brauchbaren Eindruck. Sie machen Aussagen über Wartbarkeit, Robustheit und Sicherheitsaspekte, ohne dass ein lauffähiges System nötig ist.

Gerade bei einem Ticketshop zählt der Sicherheitsblick. Ein solches System hat einen hohen Touchpoint nach außen und wird mit viel Frequenz genutzt. Diese Eigenschaften lassen sich automatisiert gut betrachten.

In diesem Fall lag kein lauffähiges System vor. Der Ticketshop war online sichtbar, geprüft wurde nur ein Stück des bereitgestellten Codes, mit statischer Analyse und manueller Durchsicht. Für eine erste Abschätzung reicht das, um daraus konkrete Vorschläge abzuleiten.

Der Code war nicht das Problem, die fehlenden Teile waren es

Bei der Übernahme einer Software ist oft nicht der Code die größte Hürde, sondern das, was nicht mitgeliefert wird. Der geprüfte Code selbst war ordentlich, keine gravierenden Mängel.

Schwieriger waren die Lücken rundherum. Durch wechselnde Verantwortlichkeiten kamen manche Komponenten erst spät. Die Dokumentation entsprach nicht dem Umfang, den ein professionelles Team als Standard ansetzt.

Während der Einarbeitung zeigte sich der eigentliche Knackpunkt: Ein Teil der Software lag nur als Blackbox vor, als Kompilat ohne Quellcode. Rund zwei Drittel der Software waren im Code verfügbar, ein Drittel nicht.

Dieser Moment markiert den Punkt, an dem aus einer planbaren Übernahme ein Überraschungsei wird. Plötzlich steht die Frage im Raum, wie man mit fehlendem Quellcode weiterarbeitet.

Warum ein agiles Mindset bei Software-Übernahmen den Unterschied macht

Wer eine unbekannte Software übernimmt, braucht die Fähigkeit, den Plan unterwegs zu ändern. Die ursprüngliche Idee war: Code analysieren, ein Refactoring machen, einige Funktionen ergänzen, Bugs beheben und Dokumentation nachziehen.

Tatsächlich verschob sich der Fokus. Sehr viel Zeit floss in die Analyse, weil man das System komplett verstehen, alle Teile finden und für die Weiterverwendung aufbereiten musste. Aus der reinen Refactoring-Idee wurde die Frage, was der Kunde im ersten Schritt wirklich braucht.

Das Team-Setup wurde entsprechend umgebaut. Statt mit der anfänglichen Besetzung weiterzumachen, nahm man einige Entwickler heraus und holte einen zweiten Architekten ins Projekt. Insgesamt standen fünf Monate, zwei Architekten und zwei Entwickler zur Verfügung.

Helmut Nitsch betont, dass es dabei nicht um Agilität als Etikett geht.

Da rede ich nicht von dem, was man gepredigt bekommt, sondern davon, ein agiles Mindset zu haben, um auf gewisse Dinge flexibel reagieren zu können. Das ist essentiell gewesen. — Helmut Nitsch

Diese Flexibilität, gepaart mit dem Vertrauensvorschuss des Auftraggebers, war ein Erfolgsfaktor auf beiden Seiten.

Wie plant man eine Migration ohne Downtime?

Eine Migration ohne erlaubte Downtime gelingt durch wiederholtes Proben mit echten Daten. Bei einem Ticketshop darf das System nicht ausfallen, der Wechsel muss praktisch von jetzt auf gleich funktionieren.

Drei Wochen vor dem Termin wurde die Migration mit allen Live-Daten geprobt und vollständig vorbereitet. Dieser Trockenlauf deckt Fehlerquellen auf, bevor sie im Ernstfall zuschlagen.

Erschwerend kam der Zeitpunkt hinzu. Durch Verschiebungen fiel die Migration in die Urlaubszeit, und der Chefarchitekt war in den entscheidenden drei Wochen abwesend. Eine Migration in der Hitze und in der Urlaubszeit erhöht das Risiko menschlicher Fehler.

Die Lösung lag in der Vorbereitung. Der zweite Architekt und der Chefentwickler probten die Migration und bereiteten alles vor. Nach Rückkehr des Architekten ging das Team alles erneut gemeinsam durch.

Auch der Termin war nicht zufällig. Gewählt wurde ein Dienstagmittag, statistisch der Zeitpunkt mit den wenigsten Nutzern im Ticketshop. Das Ergebnis: Die eigentliche Migration dauerte fünf Minuten, danach lief alles.

Die unterschätzten Faktoren am Migrationstag

Neben Technik und Planung zählen die weichen Faktoren. Am Migrationstag saßen alle Entwickler in einem klimatisierten Raum, früh am Start, mit bereitgestelltem Essen und Trinken.

Versorgung und Stimmung sind keine Nebensache. Wer am kritischen Tag für ein gutes Arbeitsumfeld sorgt, senkt Stress und damit die Fehlerwahrscheinlichkeit. Die Faustregel dahinter ist einfach: zweimal planen, einmal machen.

Ehrlichkeit und Kommunikation tragen das Projekt

Sobald Überraschungen auftauchen, entscheidet die Kommunikation über den Ausgang. Am Projekt waren vier Unternehmen beteiligt, entsprechend eng war die Abstimmung nötig.

Das Vorgehen war konsequent: Jede neue Erkenntnis wurde sofort an alle Beteiligten gemeldet. Man rief das Team zusammen, schrieb Szenarien auf, in einem Fall vier oder fünf, und jeder steuerte seine Einschätzung bei.

Entscheidungen wurden aktiv erzwungen. In Meetings galt die Regel, den Raum nicht zu verlassen, bevor eine Entscheidung steht, weil Verzögerung nur Geld kostet. Hartes Priorisieren gehört dazu.

Die kritischste Phase kam fast am Anfang. Fehlende Dokumentation, noch nicht gelieferter Code und die Erkenntnis, dass sich Zeit und Budget so nicht ausgehen, brachten echten Druck, zumal weitere Projekte daran hingen.

In dieser Lage half nur Offenheit. Statt Probleme zu verschweigen, legte man die Szenarien offen auf den Tisch: Mit diesem Vorgehen kommt man bis hierher, mit jenem bis dorthin, und nur mit diesem bis zum Ende. Information-Hiding bringt nichts, denn das verschwiegene Problem taucht später auf, meist im ungünstigsten Moment.

Commitment des Kunden ist mehr als Budget

Ein starkes Commitment des Auftraggebers zeigt sich darin, dass er das ganze Team auf eine gemeinsame Sprache vorbereitet. Vor Projektstart schickte der Kunde das gesamte Team in einen Scrum-Kurs.

Das Ziel war nicht reine Wissensvermittlung, sondern reibungsloser Austausch. Wenn alle Beteiligten dieselben Begriffe verstehen, entsteht beim Abstimmen kein Reibungsverlust.

Der Effekt war spürbar. Wenn das Team etwas sagte, wusste die Gegenseite genau, was gemeint war. Solches Engagement unterscheidet sich deutlich vom verbreiteten Muster, bei dem der Kunde “macht mal” sagt und nur mit ein paar Halbtagskräften unterstützt.

Beim Sparen wird zuerst das Testen gestrichen, und das rächt sich

Eine Konstante zieht sich durch über zwanzig Jahre Testing: Beim Sparen trifft es zuerst das Testen. Das macht ein Projekt nicht günstiger, sondern komplizierter und teurer.

Entwicklung bedeutet nicht nur Coding. Ein Entwicklungsteam braucht weitere Disziplinen, von Requirements Engineering bis Testing. Diese Disziplinen bringen mehr, als sie kosten, und helfen, ein Projekt erfolgreich abzuschließen.

In diesem Projekt war eine Vollzeit-Testmanagerin dabei, was bei Entwicklungsprojekten eher unüblich ist. Üblicher ist die halbe Stelle, die nebenbei testet. Die Vollzeit-Besetzung gab dem Vorgehen strukturell viel vor.

Welche Lehren bleiben für die nächste Software-Übernahme?

Die wichtigste Lehre lautet: Stelle das Team-Setup von Anfang an divers auf, auch wenn du glaubst zu wissen, wie das Projekt verläuft. Im Projekt musste das Team mehrfach umgebaut werden, sobald sich die Richtung änderte.

Ein interdisziplinäres Team kann eine Kompetenz durch eine andere ersetzen, wenn das Projekt sich dreht. Genau dieses Umstufen war ein Erfolgsfaktor. Vorhanden waren unter anderem App-Entwicklung, verschiedene Cloud-Technologien und Know-how aus Testing, Projektmanagement und Automatisierung, gebündelt auf vergleichbarem Niveau.

Für die Praxis lassen sich die tragenden Faktoren so zusammenfassen:

Eine fremde Software zu übernehmen bleibt ein Risiko. Wer aber Analyse, Flexibilität, ehrliche Kommunikation und ein breit aufgestelltes Team zusammenbringt, kann selbst aus einem Überraschungsei ein tragfähiges Produkt machen.