Praktikable Ansätze zur Verbesserung der Entwicklung eines Altsystems
Zusammenfassung
Die vorliegende Arbeit befasst sich mit der Durchführung einer Altsystemanalyse, um deren Strukturen zu verstehen und die Grundlagen für die Weiterentwicklung bzw. Neuimplementierung von Systemteilen zu legen.
Altsysteme sind mit hohen Kosten und Risiken verbunden, daher stellen diese für die Industrie ein großes Problem dar.
Als Forschungsobjekt wird das Portal DIE WELT untersucht, da die Pflege und Wartung des WELT-CMS ein großes Fehlerpotential aufweist. Es besteht ein großer Bedarf an einer Übersicht von kritischen Codeteilen und potentielle Schwachstellen des Systems, um weitere Strategien zur Qualitätsicherung zu entwickeln. Dabei stellt sich die Frage: mit welchen Strategien sich eine bereits existierende alte Codebasis verbessern lässt?
Diese Arbeit hat das Ziel, eine Analyse bei
WeltN24 durchzuführen und eine Bewertung des Altsystems hinsichtlich gefundener Probleme vorzunehmen, um daraus einige Strategien für die Softwareentwicklung vom laufenden
Forschungsobjekt abzuleiten. Dafür werden zuerst einige existierende Methoden diskutiert und daraufhin folgende Ansätze angewandt: Analyse von Defekten anhand von Fehlerberichten und Defektkorrekturen; Identifizierung kritischer Module im System; Analyse von Wartungsaufwand und Wirkung des unerreichbaren Codes; Analyse des Einsatzes der Unit Tests und deren Aufwand. Zum Schluss werden die kritischen Punkte bewertet und mögliche Verbesserungsvorschläge vorgelegt.
Fallstudie
Die vorliegende Arbeit wird in Kooperation mit
WeltN24 durchgeführt. Als Forschungsobjekt dient das Premium-Nachrichten-Portal der WELT-Gruppe. Es ist ein komplexes Altsystem, welches aufgrund der monolithischen Architektur sehr mühsam zu pflegen ist und bietet somit ein angemessenes "Grundgerüst", mit dessen Hilfe die Forschungsfragen dieser Arbeit bearbeitet werden.
Zielsetzung
Das Hauptziel dieser Arbeit liegt in der Durchführung einer angemessenen Analyse, um die Strategien für
WeltN24 ableiten zu können, wie man mit dem vorliegenden Systemen umgehen kann.
Eine Möglichkeit zu einer wertvollen Altsystemanalyse bieten die Verfahren, die sich nicht nur auf den Jetzt-Zustand des Codes beziehen, sondern ebenfalls auf statistische Daten aus dem Projekt und Änderungen in der Versionsgeschichte beruhen.
Der Schwerpunkt der ausgesuchten Strategien erstreckt sich auf die Verfahren aus dem Bereich
Mining Software Repositories. Diese enthalten unter anderem das Betrachten der Versionsgeschichte eines Projektes, welche statistisch oder qualitativ ausgewertet werden kann, um evtl. Informationen über Defekte und ihren Ursprung zu gewinnen.
Aus den Praxisproblemen werden folgende Forschungsfragen abgeleitet und in dieser Ausarbeitung beantwortet:
- (I) Inwiefern können durch eine Code-Review von Fehlerkorrekturen bestimmte Fehlermuster im System erkannt werden?
- (II) Welche Module haben ein großes Fehlerpotenzial und werden durch welche Variablen beeinflusst?
- (III) Wie teuer ist der Wartungsaufwand für unerreichbare Codeblöcke?
- (IV) Wie können die Unit Tests für den vorhandenen schwer testbaren Code geschrieben werden?
Um die aufgelisteten Fragen zu beantworten, werden zuerst existierende Strategien erarbeitet, passende ausgesucht und im Unternehmen angewandt. Die Auswahl der Forschungsstrategien und Forschungsmethoden werden im Zuge dieser Ausarbeitung begründet. Im nächsten Schritt werden die Ergebnisse bewertet und mögliche Verbesserungsvorschläge unterbreitet.
Entwurf und Konzept
Für das Konzept wurden die folgenden Ansätze ausgewählt, die auf oben beschriebene Forschungsfragen geantwortet werden:
(I) Ermittlung von defektanfälligen Komponenten anhand Defekt-Korrekturen
Das Ziel: Identifizierung von kritischen Modulen im System.
Das Konzept:
- Identifizierung von Bugfix Links:
- Überführung des SVN-Repositories in MySQL Datenbank mit Hilfe von CVSAnalY
- Einlesen von JIRA Datenbank
- Erkennen von Bugfix Links durch die Ermittlung der Fehlerbericht-ID aus der entsprechenden Commit-Nachricht
- Verifizierung von Bugfix Links:
- Alle Kandidaten mit JIRA-ID, welche in vielen Commits vorkommen, sollen abgelehnt werden.
- Alle Kandidaten mit einer kleinen JIRA-ID können abgelehnt werden.
- Alle Kandidaten mit einem negativen Zeitabstand sollen abgelehnt werden.
- Ein Commit verweist auf einen Fehlerbericht, welcher nach dem Zeitpunkt des Commits aufgetreten ist.
- Identifizierung der Module mit den meisten Korrekturen
Unter einem
Bugfix Link wird das Paar von einem Fehlerbericht und der entsprechenden Fehlerkorrektur verstanden.
Zur Auswertung werden folgende Fragen beantwortet:
- Gibt es Module, die besonders defektanfällig sind? Welche?
- Welche Änderungen oder Eigenschfaten von Änderungen führen zu weiteren Problemen?
- Wie groß ist der Aufwand für Korrekturen?
- Welche weitere Maßnahmen nach der Auswertung von Defektdaten können zu einer weiteren Entwicklungsverbesserung führen?
(II) Erkennung von Defektmustern im Code anhand Fehlerberichte
Das Ziel: Analyse von Defekten anhand von Fehlerberichten und Defektkorrekturen, um häufige Fehlermuster zu identifizieren und deren Ursprung besser zu verstehen.
Das Konzept:
- Die Auswahl der Fehlerberichten aus der Fehlerdatenbank;
- Defekterkennung in Code (Manuelle Code-Review der ausgewählten Defekten im Code)
- Fehlerklassifizierung
Unter einem
Fehlermuster werden hier die Teilmengen von Fehlern verstanden, die hinsichtlich ausgewählter/definierter Kriterien die gleichen Ausprägungen haben.
Zur Auswertung werden folgenden Fragen beantwortet:
- Gibt es ähnliche Defekte im System?
- Welche Arten von Defekten kommen meistens vor?
- Was sind die Ursachen bzw. Probleme von Fehlermustern?
- Wie kann diese Klassifikation zu einer Entwicklungsverbesserung in der vorhandenen Fallstudie führen?
(III) Wartungsaufwand von unerreichbaren Codeblöcken
Das Ziel: Analyse von Wartungsaufwand und Wirkung des unerreichbaren Codes.
Das Konzept:
- Ermittlung von unerreichbaren Codeblöcken durch SonarQube Metriken
- Analyse des ermittelten Codes
Zur Auswertung werden folgenden Fragen beantwortet:
- Wieviele unerreichbare Codeblöcke können aus dem System entfernt werden?
- Wie kann eine Codebereinigung ohne großes Risiko durchgeführt werden?
(IV) Testabdeckung
Das Ziel: Analyse des Einsatzes bzw. der Weiterentwicklung der Unit Tests und deren Aufwand für eine kritische Komponente im System.
Das Konzept:
- Auswahl eines kritischen Modul
- Weiterentwicklung von Unit Tests für ausgewählten Modul
Zur Auswertung werden folgenden Fragen beantwortet:
- Wie viele Unit Tests wird tatsächlich gebraucht, um für eine bestimmte Funktionalität eine gute Testabdeckung zu erreichen?
- Wie hoch sollte die Testabdeckung bei WeltN24 angestrebt werden?
- Wie kann die geforderte Testabdeckung in der bestehenden Fallstudie nachgezogen werden?