Von vielen Anwendern wurden wir in der letzten Zeit daraufhin angesprochen, wie es denn mit der Dokumentation von Programmen bei den Kollegen aussieht. Auch bei unserer Umfrage konnten wir feststellen, daß derzeit realisierte Software-Dokumentationen noch lange nicht den Wunschvorstellungen der Anwender entsprechen. "Wenn wir eine Schreibkraft hätten, könnten wir unsere Programme dokumentieren" war eine Aussage, "wir haben zu wenige Programmierer" die andere, oder "uns fehlt einfach die Zeit, es wird immer wieder hinausgeschoben und schließlich gar nicht gemacht".
Lediglich ein multinationales Unternehmen, das lebhaften Software-Austausch mit Schwesterfirmen im Ausland betreibt, hat eine wirtschaftliche Lösung gefunden.
Dietrich Lesser, Leiter der EDV-Abteilung der Eternit AG, Berlin
Auch bei uns im Hause gibt es erhebliche Schwierigkeiten mit der Programmdokumentation. Wir arbeiten derzeit mit einem relativ kleinen Programmierer-Stab von 15 Mitarbeitern und haben ein großes EDV-System, eine IBM 370/155 Modell 2 mit zur Zeit zwei MB. Das derzeit etwas ungünstige Verhältnis Großsystem/Programmierer-Stab ist die Ursache, daß andere Verwaltungsaufgaben dann immer etwas liegenbleiben. Es wird gerade nur das Notwendigste gemacht.
Natürlich sind wir uns darüber im klaren, daß - bedingt schon durch eine entsprechende Gesetzgebung, die gerade im Finanzbereich auf uns zukommt - hier etwas getan werden muß Problematisch ist allerdings der große Update-Aufwand.
Natürlich gibt es bei uns bei jedem neuen Programm Unterlagen, nur ob und wie diese dann weitergeführt werden, das ist bedingt durch die fehlende Zeit unser derzeitiges Problem. Der jetzige Zustand kann keineswegs als befriedigend bezeichnet werden Unterschiede gibt es auch bei den Programmierern. Teilweise haben wir in den Programmen eine Großschreibung. Außerdem gibt es drei Seiten, die ausgefüllt werden, bevor Programme in die Produktion gehen.
Die mangelnde Dokumentation hat allerdings keinen Einfluß auf den gesamten Arbeitsablauf. Wir haben eine sehr geringe Fluktuation innerhalb der EDV und jeder kennt des anderen Arbeitsgebiet, so daß notfalls auch ein anderer weiterarbeiten kann. Außerdem gibt es bei uns etliche Mitarbeiter, die ein Art Supervisor-Funktion ausüben und Einblick in alle anstehenden Probleme haben.
Hans Kremeier, Leiter der Datenverarbeitung Jenaer Glaswerke, Mainz
Wir haben Richtlinien, Anweisungen und ein EDV-Handbuch, - danach richten wir uns. Außerdem gibt es 20 bis 30 Formulare, die ebenfalls weitestgehend verwendet werden. Das EDV-Handbuch wird sukzessive durch EDV-Richtlinien die sporadisch erstellt werden, ergänzt.
Bleibt die Frage inwieweit sich immer an diese Richtlinien gehalten wird hier gibt es gewisse Schwierigkeiten, das muß man ganz offen sagen. Wir sind gerade dabei, uns zu überlegen, eventuell ein geschlossenes Konzept von der Organisationsseite her einzuführen, in Verbindung zum Beispiel mit der normierten Programmierung und - jetzt das neueste - der strukturierten Programmierung. Hierzu werden beispielsweise von der ADV/Orga Systeme angeboten Eventuell wollen wir auf dieser Basis ein geschlossenes Konzept entwickeln.
Bei unserer jetzigen Lösung - es handelt sich hierbei um die bereits erwähnten Formulare und Bücher, die wir selbst entwickelt haben - gibt es immer Schwierigkeiten. Das ist letztlich davon abhängig, wie intensiv sich die Leute an diese Regelung halten. Man kann ja nicht immer wieder jedes Programm überprüfen Unsere Richtlinien werden zwar fortlaufend ergänzt und erweitert, aber speziell hier im EDV-Bereich. Wenn man sich nun das Vorfeld, die Organisation, betrachtet, so gibt es hier gewisse Lücken. Dieses Vorfeld möchten wird gerne durch ein neues System ablösen, durch das dann zusammen mit unseren Unterlagen ein Optimum an Dokumentation erarbeitet werden kann Dadurch soll sowohl das Vorfeld - darin sind auch die Fachabteilungen eingeschlossen - als auch unser EDV-Bereich abgedeckt werden.
Unser derzeitiges Dokumentationsverfahren haben wir seit 1970 eingesetzt. Leider ist es nicht revisionsfähig, wenn ein Mitarbeiter der Revisionsabteilung nicht grundlegende Programmier-Kenntnisse hat.
Wir haben in letzter Zeit eine umfangreiche Checkliste erstellt die auf mehreren Seiten festhält, was wir alles realisieren wollen, was alles neu eingeführt werden soll, ob noch mehr Software notwendig wird, ob Dokumentation, ob Standardpakete, eventuell andere Abrechnungssysteme usw. Als Ziel haben wir uns gesetzt im Laufe dieses Jahres mit einem System zu beginnen.
Generelles Problem bei der Dokumentation von Programmen ist, daß die Termine in der Programmierung zu eng gesetzt sind. Immer wieder nimmt sich ein Programmierer vor, die Dokumentation gleich nach der Programmierung durchzuführen. Meist ist seine Kapazität dann aber schon anderweitig verplant und die Arbeit bleibt liegen.
Jürg Kestenholz, Leiter der EDV-Abt. der Du Pont de Nemours GmbH, Düsseldorf
Dokumentation ist zwar sehr oft etwas was auf die Seite des leicht Vernachlässigenden gerät, aber mit etwas strenger Supervision ist da schon Ordnung zu halten.
In unserem Hause haben wir damit keinerlei Probleme. Unsere Programme werden prinzipiell in Cobol geschrieben, und zwar schreiben wir bewußt seit etwa sechs bis sieben Jahren modulares Cobol. Was heute das "In-Wort" zu sein scheint, ist bei uns schon historisch. Grundsatz bei uns ist: Ein Mann, der ein Cobol-Programm liest, muß unbedingt wissen, worum es geht. Das Programm muß fest dokumentiert sein mit vielen Erklärungen, die den Paragraphen vorangehen und genau aussagen, was gemacht wird. Es gibt also kein "moove A to B". Das ganze muß unbedingt lesbar sein - auch für einen nicht getrimmten Programmierer.
Zusätzlich gibt es bei uns noch sehr detaillierte Operating-Instructions. Ganz klar ist, daß Record-Layouts und Informationen, die für einen File wichtig sind, auch in einem File pro Programm angelegt sind. Darin enthalten ist immer die letzte Compilation. Wir halten nichts von Flow-Charts die werden nicht auf dem laufenden gehalten, das braucht man auch bei unseren Cobol-Programmen nicht. Die ganze Dokumentation wird von einem Supervisor überwacht, der sich regelmäßig mit dem Operating-Supervisor abstimmt. So erfahren wir umgehend, wenn die Dokumentation nicht mit dem Job übereinstimmt.
Anfangs war unser System sehr zeitaufwendig, die Leute mußten daran gewöhnt werden, damit zu arbeiten. Aber das ist schon Jahre her. Heute können wir sagen unsere Art der Dokumentation zahlt sich unbedingt aus. Wir kennen das Problem nicht, daß zum Beispiel nur der Herr Meyer einen Job bearbeiten kann und nicht der Herr Huber weil er nichts davon versteht.
Wir sind ein multinationales Unternehmen und arbeiten viel mit unseren Schwesterfirmen zusammen. Wir betreiben intensiven Programmaustausch, so daß nicht jeder in jedem Land dasselbe schreibt, sondern da wird ausgetauscht. Dabei ist es absolut notwendig, Programme für Leute zu schreiben, die sie noch nie gesehen haben und trotzdem verstehen müssen.
Unser Revisor hat vor kurzer Zeit mit einigen unserer Programme gearbeitet und ich war erstaunt, ein so positives Echo zu hören. Die Leute waren anscheinend überrascht, daß mit relativ wenigen Mitteln ein recht passables, vernünftiges und ökonomisches Kontrollsystem zur Verfügung steht.
Konstantin Wey, Leiter Org./Prog. des LOB-Rechenzentrums in München
Bei uns gibt es eine Dokumentation - allerdings stellt sich die Frage, was ist Dokumentation und wie weit will man es damit treiben. Perfektionisten sind wir auf diesem Gebiet nicht. Ich unterscheide drei Teile der Dokumentation: einmal die Dokumentation in Zusammenhang mit dem Kunden. In einer Kundenmappe wird die gesamte Korrespondenz und alles gesammelt, was sich zwischen Kunden und Rechenzentrum ereignet hat. Die zweite Form der Dokumentation liegt in der Abteilung Organisation/Programmierung. Pro Programm haben wir eine Programmappe in der alles enthalten sein sollte angefangen beim Ablaufplan über eine Problembeschreibung, Listenbilder, Kartenbilder, Satzaufbau sowie die neueste Umwandlungsliste. Der dritte Teil der Dokumentation liegt in der Produktion, also im Rechenzentrum. Pro Kunde und pro Job je Kunde existiert ein Ablaufplan, wie das Operating erfolgen soll.
Ein Problem an dem wahrscheinlich auch viele andere zu knabbern haben, ist daß irgendwann ein System zur Dokumentation eingeführt wird. Ab diesem Zeitpunkt werden dann die Programme entsprechend behandelt, für neue Projekte hält man sich auch an die Anweisungen, was aber geschieht mit älteren Programmen? Teilweise fehlen da Unterlagen oder sie sind überall im Hause verstreut so daß eine Dokumentation rückwirkend gar nicht mehr möglich ist. In den seltensten Fällen ist auch die Zeit dafür da einen Mann an diese alten Programme zu setzen, um sie wieder auf Vordermann zu bringen.
Auch möchte niemand in den alten Programmen herumwühlen. Irgend jemand im Hause weiß, wie das läuft und dabei bleibt es dann meistens. Die Abläufe kennt keiner mehr, denn die Leute die die Programme geschrieben haben, sind meist nicht mehr im Haus.
Im Normalfall wird die Dokumentation bei uns kontinuierlich fortgeführt es gibt aber immer wieder Fälle da eilt es besonders und wenn die ersten Testläufe durchgeführt werden, gibt es noch eine Menge Änderungen, die dann nicht mehr so genau dokumentiert sind.
Solange aber die Mappe vorhanden ist und somit ein Gerüst des Programms nachvollzogen werden kann kommen wir gut hin.