Reverse Engineering
Verlorenes Wissen wieder verfügbar machen!
Haben Sie in Ihrem Unternehmen Anwendungen auf Basis von Excel oder Access, dBASE oder Clipper, Pascal oder Delphi oder auch Cobol im Einsatz, die sie nicht mehr warten und weiterentwickeln können? Haben Mitarbeiter, die für ihr Unternehmen programmiert haben, ihr Unternehmen verlassen und ist somit das Wissen um wichtige Anwendungen in Teilen verschollen? Wenn Sie eine der beiden Fragen mit „Ja“ beantworten können, ist Reverse Engineering möglicherweise ein Ansatz, der Ihnen hilft, das verlorene Wissen wieder verfügbar zu machen.
Was ist eigentlich Reverse Engineering?
Unter Reverse Engineering wird die Neukonstruktion eines Objektes aus einem vorhandenen Objekt verstanden. Es ist sozusagen der Prozess der Nachkonstruktion, mit dem Ziel der Wiedergewinnung einer Bauanleitung, mittels derer wieder neue Objekte erstellt werden können.
Um einen Chip, eine Hardware, ein System, eine Anlage, ein Möbel, ein Produkt oder ein Gebäude bauen zu können, wird in aller Regel ein detaillierter Bauplan benötigt. Dieser besteht zumeist aus einer Stückliste und einer Bauanleitung, die detailliert beschreibt, welche Einzelteile in welcher Anzahl, in welcher Reihenfolge mit welchen Werkzeugen zusammengebaut werden, damit am Ende das fertige Produkt entsteht. Jeder kennt das, der schon mal ein Möbel aus einem Mitnahmemarkt oder eine Lego-Modell aufgebaut hat.
Fehlt der Bauplan, wird es problematisch. Dann gilt es, durch detaillierte Analyse eines vorhandenen Objekts herauszufinden, wie es aufgebaut ist, wie die Bauteile angeordnet sind und wie die Teile miteinander zusammenspielen. Der Bauplan muss sozusagen aus dem vorhandenen Objekt wieder hergeleitet werden. In der Analyse zerlegt man es dazu nach und nach in seine Baugruppen und Einzelteile und gewinnt durch diesen Prozess sukzessive ein Verständnis der funktionalen Zusammenhänge und Abhängigkeiten zwischen den Baugruppen, Bauteilen und ihren Einzelelementen.
Während dieses Analyse-Prozesses werden die durchgeführten Arbeitsschritte und Erkenntnisse dokumentiert, so dass als Ergebnis ein neuer Bauplan entsteht, anhand dessen das Objekt wieder exakt nachgebildet werden kann.
Reverse Engineering von Software
Das Verfahren des Reverse Engineering funktioniert ebenso für Systeme und Software. Hier wird es zu einer echten Herausforderung wenn nur noch der ausführbare Maschinencode des Programms existiert - also beispielsweise die com- oder exe-Dateien nebst einigen dll’s. In solchen Fällen muss der Quellcode entweder aus den kompilierten Programmen mittels geeigneter Methoden und Tools zurückgewonnen werden oder es ist aus der „Überwachung“ der Programmaktivitäten zurückzuschließen, was das Programm exakt macht, nach welchen Regeln es arbeitet und wie es aufgebaut sein könnte. In diesen beiden Fällen ist nicht sichergestellt, dass das Reverse Engineering vollumfänglich gelingt.
Liegt der Source Code des Programms vor, ist das Reverse Engineering primär eine Fleißarbeit, bei der es darum geht, insbesondere das fachliche Wissen aus dem bestehenden Programmcode zu extrahieren und zu dokumentieren. Der Programmierer muss den Quellcode analysieren und verstehen, um herauszuarbeiten, was das Programm genau macht. Dazu ist jedes Modul und jede Funktion des Programms auf die fachlichen Verarbeitungsregeln zu untersuchen, die in dem Programm abgebildet sind.
Hierzu ist selbstverständlich Erfahrung in der Softwareentwicklung und in den entsprechenden Programmiersprachen erforderlich, fachliche Kenntnisse hingegen sind förderlich, aber nicht zwingend notwendig.
Visual Basic for Applications ist ein beliebter Kandidat
Reverse Engineering von Software wird bei uns häufig für solche Anwendungen nachgefragt, die mit VBA auf der Basis von Excel oder Access programmiert wurden. Diese Technologien kommen in den Facheinheiten von Unternehmen häufig zum Einsatz, da die Mitarbeiter damit schnell Ergebnisse erzielen können, ohne tiefergehende Kenntnisse in der Software-Entwicklung haben zu müssen. Da bei diesen Programmen der Sourcecode vorhanden ist, können diese immer erfolgreich reverse engineered werden.
Meistens sind diese Anwendungen in den Fachbereichen der Unternehmen entstanden, in aller Regel ohne Mitwirkung der zentralen IT-Abteilung. Mitarbeiter der Facheinheiten haben diese Anwendungen in Eigenleistung entwickelt, um sich Ihr täglichen Arbeitsalltag zu erleichtern. Im Laufe der Zeit wuchs der Funktionsumfang an und irgendwann wurde die Anwendung geschäftskritisch, ohne dass dies jemals beabsichtigt gewesen wäre. Bemerkt wird dies meistens erst, wenn der Mitarbeiter, der die Anwendung entwickelt hat, abwesend ist, etwas mit der Anwendung nicht funktioniert und niemand verfügbar ist, der die Probleme kurzfristig beheben kann.
Das ist dann der Zeitpunkt wo das Telefon klingelt und wir gebeten werden, uns das doch „bitte einmal anzusehen“.
Kommt man dieser Bitte nach, ist das Bild oftmals identisch: viele wissen, was in die Anwendung einfließt (Input) und was dabei herauskommt (Output), was in der Anwendung selbst geschieht, weiß nur der Mitarbeiter, der das Programm entwickelt hat. Dieser ist leider gerade abwesend ist oder hat das Unternehmen inzwischen verlassen.
Eine Dokumentation ist meistens ebenso wenig vorhanden, wie qualifizierte Kommentare im Quellcode. Der Quellcode gleicht eher einem Fischernetz das gerade auf die Pier geworfen wurde als einem strukturierten Programm.
Reverse Engineering macht Geschäftsprozesse und -regeln transparent
Unsere Aufgabe ist es dann, die im Sourcecode vergrabenen Geschäftsprozesse und deren Verarbeitungsregeln zu extrahieren und zu verstehen. Dadurch werden die detaillierten Verarbeitungsschritte transparent, die in dem Programm stattfinden. Hierzu muss sich ein qualifizierter Programmierer Zeile für Zeile durch das Programm arbeiten und detailliert extrahieren, was an welcher Stelle geschieht – oder auch geschehen sollte, denn oft sind diese Programme leider auch fehlerbehaftet.
In der Praxis wird dies dadurch erschwert, dass die fachliche Logik und die Steuerung des Programmablaufs meistens in maximaler Entropie miteinander verwoben über den gesamten Programmode verteilt sind. Grundlegende Anforderungen und Regeln einer strukturierten Programmierung sind allzu oft nicht beachtet, da sie dem Mitarbeiter, der das Programm geschrieben hat, nicht bekannt sind oder waren. Übrigens: Gerade bei den VBA Anwendungen ist es meistens wirklich ein einzelner Mitarbeiter, der eine solche Anwendung über Jahre entwickelt und weiterentwickelt hat. Gerade diese sogenannten IDV Anwendungen, wobei IDV für „Individuelle Datenverarbeitung“ steht, lassen sich auf jeden Fall reverse engineeren.
Durch Reverse Engineering gewachsenen Strukturen reorganisieren
Daneben gibt es noch die altgedienten Anwendungen die von der zentralen IT-Abteilung erstellt wurden und die aus einer Zeit stammen, als Change-Management, Requirements-Engineering und Release-Management ebensolche Fremdworte waren wie Versionskontrolle.
Derartige Anwendungen wurde im Laufe der Jahre stetig erweitert, um neue Anforderungen abzudecken. Viele verschiedene Entwickler haben an diesen Projekten mitgearbeitet. Neue Prozesse und Funktionen wurden zwar zumeist systematisch in die Anwendung implementiert allerdings wurde die begleitende Dokumentation vernachlässigt wodurch der Zusammenhang zwischen den Programmmodulen und den fachlichen Anforderungen nicht mehr durchgängig ersichtlich ist.
Irgendwann kommt dann der Punkt, an dem selbst die Programmierer, die langjährig an der Anwendung programmiert haben sukzessive den Überblick verlieren, obwohl sie sehr viel über das gesamte System wissen und mit den grundlegenden Aspekten der Softwareentwicklung bestens vertraut sind. I.d.R. macht sich dies dadurch bemerkbar, dass die Wartungsaufwendungen stetig ansteigen und die Umsetzung neuer Anforderungen immer mehr Zeit verschlingt, gar ein Anforderungsstau entsteht. Darüber hinaus häufen sich die Fehler im System und die Zyklen für Weiterentwicklung und Tests werden länger.
Sodann gilt es zu entscheiden, ob die Weiterentwicklung und Wartung einer solchen Anwendung noch technisch möglich ist ohne ihre Stabilität zu gefährden und ob dies aus wirtschaftlichen Aspekten sinnvoll ist. Sofern man sich hier gegen die Weiterentwicklung entscheidet, ist der Zeitpunkt für ein Reverse Engineering oder auch für eine komplette Neukonzeption und -entwicklung der Anwendung gekommen. Bei dieser Gelegenheit ist auf jeden Fall ein zeitgemäßes, stabiles und zukunftsfähiges Fundament für die Anwendung auszuwählen.
Mit Reverse Engineering fit für die Zukunft werden
Reverse Engineering im Bereich der Anwendungssoftware bedeutet eben nicht nur Verfahren und Geschäftslogik (Business Logic) aus der Analyse von vorhandenen Programmen zu extrahieren. Reverse Engineering von Anwendungssoftware bedeutet viel mehr, Ihre Anwendungen für die Zukunft fit zu machen.
Am Ende ist es eine Frage des Aufwandes, des Budgets, der Wichtigkeit und der Dringlichkeit, ob man eine Anwendung einem Reverse Engineering unterzieht oder ob man einen alternativen Weg wählt. Sollten Sie Anwendungen im Einsatz haben, die sie nicht mehr vollumfänglich verstehen, lohnt es auf jeden Fall, unverbindlich bei uns zu anzufragen.