Softwarearchäologie ist die Untersuchung einer schlecht oder un-dokumentierten älteren Software-Implementierung als Teil der Software Wartung. Sie wird vor allem dann nötig, wenn es kein oder nur eingeschränktes Wissen zu einem System gibt. [...]
Software-Archäologie wird vor allem dann nötig, wenn historisch stark gewachsene oder undokumentierte Systeme vor einer Ablösung stehen. Im Interview verrät Philipp Ambros, worauf es dabei ankommt.
Was sind die Gründe, warum es kein Wissen zum System gibt?
Viele IT-Abteilungen haben Systeme im Einsatz die ihre geplante Lebensdauer schon lange überschritten haben und von einzelnen Programmierern weiterentwickelt und gewartet werden. Das ganze Wissen über die IT-Systeme, das jahrelang aufgebaut wurde, steckt in dieser einen Person. In der Realität sieht es dann so aus, dass dieses Wissen aufgrund von Personalwechsel, Pensionierung oder wie es auch schon bei einem unserer Kunden geschehen ist, durch einen Todesfall nicht mehr abrufbar ist. Somit fehlt auf einmal das gesamte Know-How zu dem System.
Das klingt sehr dramatisch in diesem speziellen Fall – nicht nur für die betroffene Person, auch für das Unternehmen. Welche Möglichkeiten bieten sich dann zur Lösung an, sodass nicht das ganze Unternehmen stillsteht?
Ja, das ist eine herausfordernde Situation für das betroffene Unternehmen. Man könnte jetzt zum Beispiel ein Entwickler-Team beauftragen, das dann über einen längeren Zeitraum intensiv daran arbeitet, das System zu verstehen und zu dokumentieren. Das ist jedoch entsprechend kostspielig und zeitaufwändig, deswegen empfehle ich in solchen Fällen eine „Softwarearchäologie“ durchzuführen, um dasselbe Ergebnis günstiger und schneller zu erzielen.
Gibt es noch andere Fälle, bei denen SWA zum Einsatz kommt?
Ja, zum Beispiel Unternehmen, in denen der oder die EntwicklerIn sehr gut ausgelastet ist und keine Zeit für die entsprechende Dokumentation hat. Eine andere Person damit zu beauftragen geht aufgrund des fehlenden Know-Hows nicht. In so einem Fall kommt die SWA zum Einsatz. Das SWA-Programm wird direkt in die Deploymentkette eingebunden. Bei jedem Update läuft das Programm mit und schreibt eine automatische Dokumentation. Es fallen mittelfristig nur die Lizenzkosten für das Tool an, die wesentlich billiger sind als der Arbeitseinsatz.
Wie geht ihr als Experten bei der Dokumentation vor?
Eine Nachdokumentation hat verschiedene Phasen. Zur Orientierung generieren wir zuerst eine Grafik, um die Zusammenhänge des Systems nachzuvollziehen. Bestimmte Teile aus dem System werden herausgegriffen und gemeinsam mit dem Team erarbeiten wir ein Regelwerk, wie etwas in der Dokumentation dargestellt werden soll, sodass diese gut lesbar für die Mitarbeiter ist. Das daraus resultierende Regelwerk wird anschließend auf den gesamten Code angewandt.
Alternativ kann man auch noch weitere Regelwerke aufbauen, die den Fokus auf andere Teile oder andere Abstraktionsstufen im Code legen bzw. diesen für andere Positionen im Unternehmen z.B. für AbteilungsleiterInnen aufbereiten.
Wie aufwändig ist eine SWA und wie lange dauert es, bis die Dokumentation abgeschlossen ist?
Sind aktuelle Programmiersprachen im Einsatz, sind die Applikationen rasch dokumentiert. Es gibt jedoch auch in die Jahre gekommene Systeme. Manche dieser Systeme stammen noch aus den 70er Jahren – da dauert die Dokumentation etwas länger. Da es noch nur wenige Programmierer gibt, die diese Codes beherrschen, müssen wir uns erst das Wissen dazu aneignen. Vor allem im öffentlichen Bereich und im Bankwesen sind noch viele ältere Systeme im Einsatz.
* Philipp Ambros ist Manager bei ReqPOOL.
Be the first to comment