Als "drückendes Problem wohl aller DV - Abteilungen" bezeichnet Siegfried Stemper von der Dortmunder Uhde GmbH die Notwendigkeit, den Programmwartungsaufwand zu reduzieren. Klaus Brauer, Leiter des Rechenzentrums der Universität Osnabrück philosophiert: "Auf allen Bemühungen, Programmwartungsaufwand zu reduzieren, lasten die ehernen Gesetze der Datenverarbeitung, daß Software nie fehlerfrei ist und mit der Beseitigung eines Fehlers mindestens ein neuer Fehler eingeschleppt wird." Bei Eigensoftware empfiehlt der Osnabrücker, bereits in der Planungsphase größtes Gewicht auf eine gute "Maintenierbarkeit" zu legen. Sechs DV - Praktiker schildern ihre Erfahrungen. ha

Klaus Brauer, Leiter des Rechenzentrums der Universität Osnabrück in Osnabrück

Auf allen Bemühungen, Programmwartungsaufwand zu reduzieren, lasten die ehernen Gesetze der Datenverarbeitung, daß erstens Software nie fehlerfrei ist und daß zweitens mit der Beseitigung eines Fehlers mindestens ein neuer Fehler in das Produkt eingeschleppt wird.

Ich möchte mich im folgenden auf die Angabe einiger wünschenswerter Vorgehensweisen beschränken, da eine umfassende Darstellung in diesem Rahmen nicht möglich ist. Gegenstand der Überlegungen kann nur Software sein, die vom Rechenzentrum zum dauernden Gebrauch angeboten wird. Hierbei sind zwei Bereiche zu unterscheiden, nämlich:

- Fremdsoftware (Herstellersoftware, gekaufte Systeme, Programmaustausch)

- Eigensoftware (vollständige Eigenentwicklung, adaptierte Systeme)

Programmwartungsaufwand sollte im Bereich der Fremdsoftware mit Ausnahme von Fehlererkennung und -weitermeldung eigentlich nicht entstehen, da ein Maintenancedienst bei der liefernden Institution vorhanden sein muß, der umgehend für Fehlerbehebung und gegebenenfalls Leistungsverbesserung zu sorgen hat.

Bekanntlich ist dieser Idealfall nur selten anzutreffen. Das Rechenzentrum sieht sich oft genötigt, Programmwartung auch für solche Produkte durchzuführen. Eine Reduktion der Wartung kann im wesentlichen nur durch organisatorische Maßnahmen geschehen. Anstatt einer Fülle von exotischen schlecht dokumentierten Spezialanfertigungen, die aus weitgehend unbekannten Quellen bezogen werden, sollten lieber weniger Produkte eingesetzt werden, bei deren Auswahl starkes Gewicht darauf gelegt werden muß, daß die Software einen gewissen Verbreitungsgrad hat und der Hersteller über einen gut eingespielten Maintenancedienst verfügt.

Bei Programmen des Hardwarelieferanten. insbesondere im Bereich der Systemsoftware, ist eine Reduktion des Wartungsaufwandes kaum noch möglich, wenn bei der Auswahl des Herstellers und bei der Abfassung des, Kauf- oder Mietvertrages Fehler gemacht werden. Wenn man also die Möglichkeit hat, sich den Hersteller frei aussuchen zu können, so muß beim Kauf oder Anmietung des Systems den Softwareprodukten der Anbieter mindestens die gleiche Aufmerksamkeit geschenkt werden wie der Hardware.

Im Bereich der Eigensoftware ist eine Reduktion des Programmwartungsaufwandes immer dann möglich, wenn bereits in der Planungsphase der Gesichtspunkt einer guten Maintenierbarkeit mit größtem Gewicht versehen wird. Wie kann das geschehen? Nach grundsätzlichen Überlegungen darüber, was das Produkt zu leisten hat, wird mit Hilfe des Top-down-Verfahrens das Problem analysiert und in Teilprobleme zerlegt. Dabei erhält man automatisch einen modularen und übersichtlichen Programmaufbau. Das Testkonzept wird in dieser Phase mitentwickelt. Die Dokumentation hat parallel zur Erstellung zu erfolgen und darf nicht als ungeliebte Fronarbeit am Ende der Implementation stehen. Erst wenn die Konzeption des zu erstellenden Produktes festliegt und dokumentiert ist, kann die Codierung beginnen.

Verwendet werden sollten grundsätzlich nur höhere Programmiersprachen, denn eine bessere Lesbarkeit der Quelle ist höher zu bewerten als Einsparung an Betriebsmitteln wie etwa Rechenzeit oder Zentralspeicherplatz. Die sinken, den Preise für Hardware einerseits und die rapide steigenden Kosten für Personal andererseits unterstreichen dies. Bei der Codierung sollten selbst unter Verzicht auf Eleganz nur international genormte Sprachelemente verwendet werden Maschinenabhängige Konstanten und sonstige Größen, die im Lade der Zeit Änderungen unterworfen sind, dürfen nicht an diversen Stellen Im Pro-gramm versteckt werden sondern sind an einer klar definierten und dokumentierten Stelle zusammenzufassen. Ähnlich ist vorzugehen, wenn zum Beispiel in Form von Unterprogrammaufrufen rechnerspezifische Systemleistungen genutzt werden müssen. Programmquellen sollten reichlichen und aussagekräftigen Kommentar enthalten.

Bereits in der Konzeptionsphase müssen Gesichtspunkte der Erweiterbarkeit der Leistungen berücksichtigt werden, gegebenenfalls werden dummy-Unterprogramme erstellt, die zunächst nur die Meldung produzieren, daß die gewünschte Leistung noch nicht implementiert sei. Nach erfolgreichem Abschluß der Testphase muß vor der Freigabe des Produktes ein Benutzermanual angefertigt und die Fehlerbearbeitung, organisiert werden.

Hierzu gehört unbedingt die Festlegung personeller Zuständigkeiten. Gerechterweise muß ich zugeben, daß die erwähnten Vorgehensweisen in meinem Hause zur Zeit noch nicht in vollem Umfange realisiert sind. Besonderes Gewicht ist in einem Hochschulrechenzentrum auf die Bemerkungen zu legen, den Benutzern, die ihre Programme selbst erstellen, diese Gedanken nahezubringen.

Klaus Ewald, EDV-Leiter bei Travenol, München

Man ändert, stellt um, erweitert etc. Solche Worte sind für fast alle EDV-Leute nicht unbekannt. Vielmehr gehören sie zum Standardvokabular der Programmierer, wenn man sie fragt, an welchem Projekt sie gerade arbeiten.

Der Wartungsaufwand bestehender Systeme nimmt einen immer größeren Prozentsatz der verfügbaren Mann Tage in Anspruch. Er liegt bei uns zwischen 30 und 50 Prozent.

Programmierer steigen oft unter schwierigen Bedingungen in ein Programm ein, weil sie es entweder selbst nicht geschrieben haben und Dokumentationsunterlagen fehlen oder weil es ein uralter Schinken ist, den sie zwar selbst mal geschrieben haben, aber am liebsten nicht mehr anrühren. Man ändert es oft gar nicht, sondern schreibt es, lieber neu und - viel besser. All dies kostet sehr viel Zeit. Es gibt mit Sicherheit kein Patentrezept, wie man diesen Aufwand reduzieren kann, jedoch einige gezielte Maßnahmen, die den Wartungsaufwand reduzieren beziehungsweise den Zeitaufwand hierfür minimieren.

- Intensive Zusammenarbeit mit den Fachbereichen, um eine neue Aufgabenstellung bis ins kleinste Detail und sehr zukunftsbezogen durchzudiskutieren.

- Klare, saubere Programmierung, in der ein Programm in logisch zusammengehörende Segmente aufgeteilt wird und nicht wie ein, Roman heruntercodiert wird.

- Standards für das Codieren von Programmen wie einheitliche Feldnamen, Kommentare in die Umwandlungslisten. Erstellen von Unterprogrammen, die bestimmte Rechenroutinen oder logische Verzweigungen beinhalten.

- Verwendung von Tabellendateien für alle variablen Codes für Währungstabellen, Prozentsätze, Lagerarten, etc.

- Ein Programm wirklich erst dann freizugeben, wenn es EDV-mäßig voll dokumentiert ist. Ich denke hierbei vor allem an eine sinnvolle Programmbeschreibung. Dies erleichtert einen späteren Einstieg. Ebenso muß jede Änderung dokumentiert sein.

- Nicht jede Anforderung der Fachbereiche einfach zu akzeptieren, sondern überlegen, ob diese oder jene - nice to have - Änderung durch einen anderen Belegfluß oder aber im Fachbereich selbst abgefangen werden kann.

Oft kostet beispielsweise der Einbau einer zusätzlichen Zwischensumme in irgendeinem komplizierten Programm zwei bis drei Stunden eines Programmierers. Würde der Sachbearbeiter, der einmal im Monat diese Summe benötigt, sie durch das Zusammenaddieren von zwei bis drei anderen Summen ermitteln, brauchte er dafür vielleicht eine halbe Minute.

Fazit: Wartungsaufwand wird immer größer, man kann ihn jedoch durch saubere Programm- und Dokumentationserstellung und gewisse Standards auf ein zeitlich vertretbares Minimum reduzieren.

Siegfried Fabry, Leiter der Datenverarbeitung, ICI-Pharma Arzneimittelwerk Plankstadt

Wie wahrscheinlich in allen DV-Abteilungen, nach Abschluß der Pionierzeit, kam auch bei uns der Zeitpunkt, die steigende Programmänderungsflut eindämmen zu müssen. Nun ist nicht immer die Fachabteilung der Schuldige. Die Spezialisten, Individualisten und Künstler - genannt Programmierer - taten durch ihre immer neuen Ideen ein übriges. Ab einer bestimmten Größenordnung der zu verwaltenden Systeme und Programme, bei uns 13 Systeme mit 820 Pages, ist jeder DV-Leiter gezwungen, seine Kapazitäten personal- und computerseitig sehr genau zu planen. Laufende Ad-hoc-Aktionen kann er sich nicht mehr leisten.

Aber was tun?

Es läßt sich nicht vermeiden, ein "Bürokrat" zu werden.

Wir sind nun dazu übergegangen, nur nach Anforderung tätig zu werden. Dies hat den Vorteil, eine bessere Personalplanung und einen gezielten Personaleinsatz durchführen zu können. Hardware-Kapazitäten sind längerfristig planbar.

Wie funktioniert dies?

Mit der EDV-Anforderung wird die Fachabteilung gezwungen, ihre Wünsche schriftlich zu fixieren. Weiterhin unterliegt die Fachabteilung einem Genehmigungsverfahren durch die vorgesetzte Stelle und den Ressortleiter. Schon hier trennt sich die Spreu vom Weizen, denn der Anfordernde muß seine Anforderung plausibel begründen. Sollte dies passiert sein, laufen die Anforderungen zur Organisationsabteilung, wo jeder Antrag auf Herz und Nieren geprüft wird. Nachdem nun diese Hürden genommen worden sind, bekommt der DV-Leiter die Anforderung und nimmt sie in die Programmplanungs-Pipeline. Der Auftraggeber wird jetzt informiert, daß der Auftrag angenommen ist und wann er erledigt wird.

Sollten irgendwelche unvorhergesehenen Prioritäten auftauchen, so geht die Aufstellung der in der Pipeline befindlichen Projekte an einen EDV-Ausschuß, und dieser entscheidet über Verschiebungen.

An dieser Stelle macht sicherlich jeder die Feststellung: Dieser EDV-Leiter macht es sich ziemlich einfach! Nein. Wir verstehen unsere Arbeit als Dienstleistung für das gesamte Unternehmen, und somit wird im Normalfall nach der Methode "first in - first out" gearbeitet. In Ausnahmesituationen kann jedoch die Entscheidung nicht hoch genug angesetzt werden.

Nach erfolgter Änderung werden die Testunterlagen dem Auftraggeber vorgelegt, und dieser trägt die Verantwortung für die Freigabe an das Rechenzentrum. Für die Programmierung ist der Vorgang abgeschlossen.

Es ist vielleicht nicht jedermanns Sache, nach diesem Schema die EDV-Arbeit zu organisieren, aber aus Erfahrung kann ich sagen, für uns hat es sich bisher gelohnt. Es ist uns gelungen, die "freiwilligen" Überstunden und Wochenendeinsatz in der Programmierung total abzubauen, eine kontinuierliche Arbeitsleistung durch gezielten Einsatz zu erreichen und dabei alle notwendigen Dokumentationsanforderungen abzudecken.

Zum Schluß noch ein Satz:

Die Zeit, in der die EDV-Leute den Fachabteilungen gesagt haben, was sie brauchen, ist vorbei. Der EDV-Mann hat zwar aufgrund seines Wissens die beratende Funktion bei der technischen Umsetzung der Probleme, aber nicht mehr!

Werner Menzel, Leiter EDV und Organisation, Baumhüter GmbH, Rheda-Wiedenbrück

Bei uns werden derzeit sämtliche Programme, mit Ausnahme von Teleprocessing-Programmen, in RPG II geschrieben. Einige alte, in Assembler abgefaßte Programme wurden umgeschrieben und Assembler-Unterprogramme, früher bei RPG benötigt, wurden in RPG II eingebettet. Unsere Programmierer haben es also ausschließlich mit einer Programmiersprache zu tun, welche jedoch von uns voll genutzt wird.

Strukturierte Programmierung ist bei RPG nicht erforderlich. Es gibt allerdings bestimmte Richtlinien, an denen sich die Programmierer orientieren müssen. Zum Beispiel: Chainen nur in Rechenbestimmung, gleich große Rechenfelder für gleiche Begriffe in den einzelnen Gruppen oder Matching Record-Verarbeitung, wenn nicht anders möglich. Außerdem wird die Funktion select/sort des Autoreport-Features verwendet, um Sorts in RPG-Programme einzufügen. Für gleiche Routinen werden Sub-Programme eingesetzt, um bei Änderungen in eine geringere Anzahl Programme einsteigen zu können. Beim Schreiben der Programme werden die Statements ausreichend mit Kommentaren versehen, so daß sich die Dokumentation außerhalb der Programme im wesentlichen; auf die effektive Sache beschränkt. Die sachliche Beschreibung umfangreicher Programme muß jedoch eindeutig fixiert sein. Hier reicht nicht nur die Codierung, sondern zusätzliches Wissen ist unumgänglich. Sowohl ich als auch unsere gesamten Programmierer beherrschen das Operating. Allein durch dieses Faktum reduziert sich der Programmierungsaufwand erheblich.

Folgende Kriterien sind ausschlaggebend für das Entstehen von Programmierungsaufwand:

1. Durch Erfordernisse des Gesetzgebers, beziehungsweise der Tarifpartner, wie zum Beispiel Mehrwertsteueränderung, Lohnsteuerreform, Reform der gesetzlichen Sozialversicherung oder Urlaubsgeldabsprachen.

2. Durch Wünsche oder bestimmte Erfordernisse der Fachabteilungen. Hier untersuche ich kritisch, ob es tatsächlich erforderlich ist, auf diese Forderungen einzugehen und die Programme zu ändern. Es kommt vor, daß verlangte Daten bereits vorhanden sind, von denen die Fachabteilungen - noch keine Kenntnis haben. Oftmals ist dann nur ein minimaler Eingriff erforderlich. Vieles wird allerdings auch abgelehnt, weil der effektive Nutzen in keinem Verhältnis zum Aufwand steht.

3. Um bestehende Programme zu stabilisieren oder deren Effizienz zu verbessern. Wir nehmen uns in der Regel die Zeit, Programme gut zu schreiben, zu dokumentieren und zu testen. Fehlerbeseitigungen sind nicht nur zeitaufwendiger, sondern bringen auch meist falsche Ergebnisse für die Fachabteilungen, mit allen ärgerlichen und unangenehmen Folgen.

Mein Rezept für eine verbesserte Effizienz der Programme besteht aus einem größeren Zeitaufwand, sprich Gründlichkeit. Wir arbeiten heute mit etwa 600 Verarbeitungsprogrammen. 1970 waren es lediglich 150. Der Personalaufwand ist der gleiche geblieben.

Heinz Speth, Organisationsleiter Stuttgarter Hofbräu AG, Stuttgart

Schon sehr früh haben wir uns Gedanken darüber gemacht, wie wir mit der vorhandenen Programmierkapazität effektiver sein können. Nicht nur, daß Programmierer teuer waren und noch sind, war es damals wie auch heute schwierig, sie zu beschaffen. Ein großer Teil der vorhandenen Programmierkapazität war nicht für Neuprojekte einsetzbar, da mit zunehmender Anzahl der Programme der Aufwand für deren Wartung und Pflege immer größer wurde.

Ende der 60er Jahre haben wir den Markt abgeklappert, um nach Möglichkeiten der Vereinfachung zu suchen. Entscheidungstabellen, Precompiler und Optimierungssysteme wurden untersucht und als zu teuer, nicht effektiv genug, zu schwer erlernbar oder als nicht standardisierbar verworfen.

Im Jahre 1970 haben wir dann nach Untersuchung von verschiedenen Systemen der "Normierten Programmierung" ein für uns anwendbares und leicht erlernbares eigenes System entwickelt.

Heute, fast zehn Jahre später, wird dieses damals von uns entwickelte System in nahezu allen Programmen verwendet. Nachdem es in allen Programmiersprachen - Cobol, PL/1 und Assembler - gleichermaßen verwendet wird und von allen Programmierern, wenn auch bisweilen nach anfänglichem Sträuben, gerne benutzt wird, kann man sagen, daß wir damals den richtigen Weg beschritten haben.

Wir haben nicht nur eine schnellere Form der Programmierung gefunden - der Rahmen des Programmes steht, und nur einzelne Gruppen von Routinen wie Einlaufzweig, Postenverarbeitung, Gruppenverarbeitung, Endverarbeitung müssen programmiert werden -, sondern durch die Einheitlichkeit der Programme eine bessere Übersichtlichkeit und somit eine Möglichkeit, sich in fremden Programmen und in ungewohnten Programmiersprachen schnell zurechtzufinden. Ein weiterer nicht von der Hand zu weisender Vorteil dieses Systems war, daß wir auszubildende Programmierer wesentlich schneller zu produktiven Anwendungsprogrammierern herangebildet haben.

Außerdem waren wir bemüht, unsere Programme modular aufzubauen, um bei Änderungen kleinere Partien im Griff zu haben. Zu Zeiten, da Computerzeiten noch relevant waren, konnten wir hier einen schnelleren Durchsatz erreichen.

Mit dem Beginn der Diskussion um den Datenschutz sahen wir nicht nur erhebliche Probleme auf uns zukommen, sondern auch die große Chance, durch eine zentrale Dateidefinition sowie einmalige Satzdefinitionen mit klarer Feldbeschreibung Bezeichnungen und Beschreibungen zu standardisieren.

Heute werden zum Beispiel IS-Dateien nur noch in einer einzigen Phase verarbeitet. Die Anwendungsprogramme lesen die Datei nicht direkt, sondern rufen diese Phase mit CALL auf. Unsere Datensatzdefinitionen werden einmal erstellt - getrennt für Assembler und PL/1 - und in einer Modul-Bibliothek gespeichert und zur Umwandlungszeit eingelesen. Eine weitere Möglichkeit zur Vereinfachung unserer Programmwartung gab uns die Online-Programmierung, die uns erlaubte, unsere Programmbibliothek nur noch auf der Magnetplatte und aus Gründen der Datensicherung auf dem Magnetband zu führen. Lochkarten sind für unsere Programmierer inzwischen ein Fremdwort.

Wir glauben, daß all diese Bemühungen dazu geführt haben, mit einer kleineren Programmkapazität sehr effektiv arbeiten zu können. Trotz steigender Anzahl der Programme ist unsere Haupttätigkeit immer noch neue Projekte einzuführen und nicht in der Wartung alter Programme zu ersticken.

Siegfried Stemper, Prokurist in Uhde GmbH, Dortmund

Zur Reduzierung dieses drückenden Problems wohl aller EDV-Abteilungen haben wir uns seit Jahren bemüht, unsere Programme möglichst autorenunabhängig zu gestalten, unter anderem durch verschiedene Standardisierungen wie zum Beispiel die der Ablaufsteuerung.

Erst mit Einführung der strukturierten Programmierung vor etwa zwei Jahren jedoch können wir eine spürbare -Verbesserung verzeichnen. Dies vor allem dadurch, daß wir uns nicht auf die Strukturierung im Programm beschränkt haben, sondern spätestens beim System-Design damit anfangen.

Das System-Design wird vom Systemanalytiker ausschließlich nach sach-logischen und nicht nach DV-spezifischen Gesichtspunkten festgelegt, in Form einer Baumstruktur dargestellt und beschrieben.

Durch diese Darstellungsweise, also Gliederung nach sach-logischen Gesichtspunkten, Heraushalten von EDV-Details, Beschreibung in allgemeinverständlicher Sprache, kann das Arbeitsergebnis auch von der Fachabteilung "verstanden" werden - sie "genehmigt" bei uns durch Unterschrift den Entwurf.

Hierdurch wird von vornherein schon der Wartungsaufwand vermieden, der sonst häufig dadurch entsteht, daß der Auftraggeber erst nach der Implementierung des Systems merkt, daß er gar nicht das erhielt, was er eigentlich wollte, weil er sich nicht EDV-gerecht ausdrückte oder falsch verstanden wurde.

Nach Freigabe des Programmentwurfs wird er nach EDV-technischen Gesichtspunkten umstrukturiert und in die für die Verarbeitung notwendige Reihenfolge gebracht - erst jetzt entsteht also ein ablaufbezogener Entwurf, der die zur EDV -technischen Lösung erforderlichen Schritte mit ihren Verbindungen aufzeigt. Die Darstellung erfolgt wiederum als Baum-Diagramm mit verbaler Beschreibung.

Der Aufbau der hieraus abzuleitenden Einzelprogramme wird mit Nassi-Shneidermann-Diagrammen vorgegeben.

Bei der Aufgliederung in Module ist zu berücksichtigen, daß Sachverhalte zu denen von vornherein mit Änderungen (zum Beispiel durch Gesetzgebung) zu rechnen ist, in eigenen Modulen erfaßt werden, selbst dann, wenn dadurch die Durchlaufzeit des Programms negativ beeinflußt wird.

Neben den Regeln der strukturierten Programmierung gelten im Programm weiterhin unsere oben erwähnten eigenen Standards. Außerdem setzen wir sowohl beim System-Design als auch bei der Programmierung zur Darstellung komplizierter Sachverhalte Entscheidungstabellen ein.

Generell geben wir der Wartungsfreundlichkeit eines Programms den Vorrang vor maschinenbezogenen Kriterien wie kurze Durchlaufzeit.

Fazit: Durch die konsequente Strukturierung vom Systementwurf bis zum Programm-Modul wird ein Teil des Wartungsaufwandes von vornherein vermieden, mit dem unvermeidbaren (immer noch großen) Rest werden wir schneller fertig.