FREIBURG (sg) - Unter einer maschinellen Programmdokumentation wird heute in der Regel längst nicht überall das gleiche verstanden. Zumeist werden damit noch solche Verfahren bezeichnet, die sich bei näherer Betrachtung bestenfalls als "Computer-gestützte", keineswegs aber als "maschinelle" Programmdokumentation erweisen. Dazu muß man sich vorstellen, daß so bezeichnete Dokumentationssysteme ausschließlich dazu dienen, die für eine Dokumentation notwendigen Angaben, anstatt diese direkt aus dem codierten Programmablauf heraus automatisch zu bilden, in diesen nachzutragen. Der Input für derartige Verfahren setzt also in jedem Fall eine manuelle Tätigkeit voraus, die wegen der dazu erforderlichen Sachkenntnis allein vom Programmurheber zu bewerkstelligen ist.

Eine maschinelle Programmdokumentation im strengen Sinne genommen ist jedoch ein Verfahren, das ohne jeglichen manuellen Input, das heißt nurmehr basierend auf den bereits vorhandenen Programm-Statements, auskommt. Solcherart von Dokumentationsverfahren, bei denen lediglich die Programme und deren Prozeduren Verwendung finden, und bei denen eine Mitarbeit des Organisators und/oder Programmierers nicht mehr zwingend erforderlich ist, dienen den Anwendern erfahrungsgemäß am ehesten. Zumal diese weder einen sonderlichen Aufwand erfordern, noch die Verfügbarkeit von mit den zu dokumentierenden Programmen speziell gut vertrauten Personen voraussetzen.

Besonders im Bereich mittelgroßer EDV-Systeme, etwa der IBM /34 und in Zukunft wohl auch der /36, wo davon auszugehen ist, daß beim Anwender eine größere EDV-Mannschaft nicht vorhanden ist, stellen maschinell ablaufende Programmdokumentationen einen beachtlichen Sicherheitsfaktor dar. Das gilt um so mehr, wenn die installierten Anwendungen wie so häufig sowohl vom Hersteller als von Softwarehäusern und/oder freiberuflich tätigen Feierabendprogrammierern stammen. In der Regel haben die Programmersteller nämlich kaum ein Interesse daran, zu den von ihnen bereitgestellten Programmen auch noch eine vernünftige Dokumentation abzuliefern, denn eine nicht existente Programmdokumentation bedeutet für sie doch schon fast so etwas wie eine "Rentenversicherung".

Manchmal mag in der Hektik der Programmentwicklung aber auch einfach die Zeit nicht mehr gereicht haben, um eine ordnungsgemäße Programmdokumentation zu erstellen. Dies trifft insbesondere dann zu, wenn bereits während der Entwicklungsphase laufend Programmänderungen durchzuführen sind. Aber auch die heute noch übliche Tatsache, daß für eine Dokumentation, die im allgemeinen recht zeitaufwendig und mühsam vonstatten geht, keinerlei Mittel bereitgestellt worden sind, muß als Hinderungsgrund dafür gewertet werden, daß mit dem Abschluß der Programmierphase über keine entsprechende Dokumentation verfügt werden kann. Letztendlich wird auch noch die Notwendigkeit einer Programmdokumentation längst nicht allerorts eingesehen. Dies gilt zumal dann, wenn nirgendwo beim Anwender eine Bereitschaft dafür besteht, die hierfür erforderlichen Mittel bereitzustellen.

Dies alles hat letztlich dazu geführt, daß vor allem bei mittelgroßen EDV-Anwendern - jedoch nicht etwa nur bei diesen - die Programmdokumentation zuwenig pfleglich behandelt wurde. Wenn dann aber derartig vernachlässigte Installationen erst einmal einige Jahre bestehen - man denke nur einmal an die vielen IBM/34-Anwender, die etwa vor drei bis fünf Jahren den EDV-Einstieg begonnen haben -, so wird die Notwendigkeit einer Dokumentation frühestens dann erkannt, wenn Änderungen an den bestehenden Anwendungen erforderlich werden oder wenn bestehende Anwendungen erweitert werden sollen. Kann oder will man nun dafür nicht m(...)auf den Ersteller der Programme zurückgreifen oder sind die Kosten für eine manuelle Erstellung einer Programmdokumentation zu hoch, so ist oft guter Rat teuer. Es sei denn, es findet sich ein Verfahren, das eine maschinelle, sprich automatische Programmdokumentation auf der Basis der Quellenprogramme ermöglicht.