MÜNCHEN (CW) - Wenn man ohnehin den Hardware-Hersteller wechseln will, kann man in der Software auch gleich einen Neuanfang machen. Die Tchibo AG, Hamburg, erkannte die Chance und fing fast wieder von vorn an. Heiner Göhlmann* beschreibt in dem folgenden Beitrag, was man sich erhoffte und was alles so passierte.
Im Jahre 1979 entschied die Firma Tchibo, ihren Handwarelieferanten zu wechseln und von einer ICL-Anlage auf eine IBM 4341 (DOS/VSE) umzusteigen. Gleichzeitig mit der Hardwareumstellung beschloß man, in Zukunft bei der Softwareentwicklung neue Wege zu gehen. Die Vergangenheit hatte gezeigt, daß die Anwendungssysteme durchschnittlich 5 Jahre eingesetzt wurden. Setzte man die Gesamtentwicklungs- und Wartungskosten eines Systems mit 100 Prozent an, so beliefen sich die Entwicklungskosten auf etwa 30 Prozent, während die Wartungskosten
mit rund 70 Prozent in die Gesamtkosten eingingen Zielsetzung war, die Gesamtkosten aller Anwendungssysteme für die Entwicklung und Wartung zu minimieren, wobei der Hauptansatzpunkt zur Kostenreduzierung im Bereich der Wartung zu suchen war.
Kosten minimieren
Zuerst wurden die Gründe für den hohen Anteil der Wartungskosten in der Vergangenheit gesucht. Es zeigte sich, daß im allgemeinen keine aktuelle Dokumentation der Systeme mehr vorlag und daß auch keine Möglichkeit bestand, zu prüfen, welche Fernwirkungen über Schnittstellen zu anderen Systemen bestimmte Änderungen hervorrufen könnten. Trotz des hohen betrieblichen Wartungskostenanteils war es nicht möglich gewesen, auch die Programmdokumentation/-vorgaben bei Änderungen mit auf dem aktuellen Stand zu halten. Bei jeder Änderung mußte man sich auf das Wissen des Programmierers um das bestimmte Anwendungsgebiet verlassen. Wollte man also in der Zukunft seine Gesamtkosten minimieren, so mußte man schon im frühen Bereich der Systemanalyse und des Systemdesigns mit anderen Methoden als in der Vergangenheit arbeiten, um in der Zukunft in der Lage zu sein, bei der Wartung die Dokumentation auf einem aktuellen Stand halten zu können.
Im wesentlichen wurden dabei folgende Anforderungen an ein oder mehrere zusammenarbeitende Softwarewerkzeuge gestellt:
1. Die einzelnen Teile eines Gesamtsystems sind bereits in der Phase der Systemkonzeption zu beschreiben. Aus den Begriffsverzeichnisse erstellt werden.
2. Schon in dieser Phase sind die Beschreibungen mit groben Zeit-, Personal- und Kostenschätzungen zu verbinden, die von einem geeigneten Projektplanungssystem verwaltet werden können.
3. In der Phase der Systemdetaillierung sind die einzelnen Elemente und deren Verknüpfungen zu beschreiben (Schlüsselsysteme, Dateien, Listen, Vordrucke, Bildschirmmasken, Programme und Jobabläufe).
4. Die Beschreibung der Programme und Jobabläufe sollen in einer formalisierten und strukturierten Sprache vorgenommen werden, aus denen automatisch der Programmcode (Cobol) generiert werden kann.
5. Es darf nicht möglich sein, Programme zu ändern, ohne die entsprechende Dokumentation zu ändern. Umgekehrt muß jede Änderung der Dokumentation in allen Programmen wirksam werden.
6. Ein Testdatengenerator stellt Einzel- und/oder Massendaten bereit, unterstützt die Simulation von Schnittstellen zwischen aufrufenden und aufgerufenen Moduln, kann erwartete Ergebnisse verwalten und errechnete Ergebnisse mit vorgegebenen vergleichen.
Im Rahmen einer Untersuchung der am Markt angebotenen Softwarewerkzeuge erkannte man schnell, daß kein Anbieter heute diesen Gesamtkomplex mit einem Werkzeug abdeckt, sondern daß man gezwungen war, mehrere angebotene Programmpakete miteinander zu kombinieren. Als Softwarewerkzeuge, die in allen gewünschten Anforderungsbereichen Unterstützung geben konnten, erwiesen sich Data Dictionaries. Diese eigneten sich einerseits zur projektbegleitenden Dokumentation und waren andererseits auch in der Lage, bei der Softwareerstellung über Generierungsfunktionen Teile des Programms zu erstellen. Vorteilhaft beim Einsatz eines Data Dictionaries zeigte sich insbesondere die Möglichkeit, die Dokumentation aus der Systementwicklungshase (teilweise ohne weitere Neucodierung) automatisch in Programmcode umzusetzen. Bei Tchibo entschied man sich, als Data Dictionary den Datamanager von MSP Rellingen, einzusetzen.
Hauptkriterien für die Wahl waren dabei, daß man ein ausgereiftes und flexibles Dokumentationssystem erhielt (damals bereits über 300 Benutzer weltweit). Über die selbstdefinierbaren Dokumentationsstrukturen und Modelle konnte man das System an die speziellen Benutzerwünsche im Hause Tchibo anpassen. Insbesondere waren eine Abbildung der geplanten Strukturen im Bereich der Entwicklung, DV und Organisation sowie die Beschreibung der bisherigen konventionellen Verarbeitung in einem einzigen Dokumentationssystem möglich. Es unterstützt dabei sowohl das gewählte Datenbanksystem DLI und den TP-Monitor CICS sowie die Programmiersprache Cobol. Auch wenn in der Zukunft andere Datenbanksysteme oder TP-Monitore eventuell zusätzlich zum Einsatz kommen würden, wären diese durch Datamanager abgedeckt. Über die Benutzerschnittstelle war darüber hinaus die Verbindung der gespeicherten Dokumentation zu anderen Softwarewerkzeugen gewährleistet.
Strukturiert programmieren
Im Bereich der Programmentwicklung entschloß man sich, in Zukunft strukturiert zu programmieren. Hierbei sollten dem Programmierer nicht nur Kenntnisse über diese Programmiermethode vermittelt werden, sondern auch ein Softwaretool zum Einsatz kommen. Zur Unterstützung der strukturierten Programmierung wurde Metacobol (ADR, Hamburg) als maschinelles Hilfsmittel eingesetzt. Mit Hilfe von Metacobol kann die formatierte Beschreibungssprache für strukturierte Programmierung automatisch in Cobolcode umgesetzt werden. Metacobol bietet damit schon heute die Möglichkeiten, die als neue ANSI-Norm vielleicht erst Mitte der 80er Jahre von den Cobolcompilern der Hardwarehersteller bereitgestellt werden. So kann der Programmierer im Hause Tchibo strukturiert in einer Sprache programmieren, die noch über den sogenannten höheren Programmiersprachen wie Cobol steht.
Nach Auswahl dieser beiden Hauptsoftwarepakete ging man daran, die Dokumentationsmodelle für die einzelnen Bereiche im Data Dictionary zu entwickeln. Es war dabei halbwegs einfach, das DV-Modell zu finden und dieses mit dem Konventional-Modell zu verknüpfen. Hier zeigte sich dann auch gleich der Vorteil des Einsatzes eines Data Dictionaries: Bei einer Abfrage, wo zum Beispiel überall die Kundennummer benutzt wird, würde man nicht mehr nur wie bisher im DV-Sinne an Listen, Dateien, Segmente oder Gruppen denken, sondern gleichzeitig Hinweise auf nicht DV-technisch gespeicherte Daten wie Vordrucke und Nummernsysteme erhalten.
Kundennummer oder Kunden-Nummer
Durch die feste Strukturierung von Elementen im Systemanalyseteil und der Vorgabe einer formalisierten Beschreibung, die für die einzelnen Typklassen zu erstellen ist, erreicht man eine einheitliche Systembeschreibung über Projekte hinweg unabhängig von den Mitarbeitern, die diese Projekte durchführen. Hierbei wurde großer Wert darauf gelegt, im Entwicklungsmodell schon konkrete Zeitschätzungen anzugeben. Neben der Verbindung der Arbeitsaufträge mit den einzelnen Anwendungen und Mitarbeitern aus dem Organisations-Modell sind gleichzeitig eine Zeitschätzung für den Gesamtauftrag und eine Zuordnung auf einzelne Mitarbeiter gegeben. Durch die direkte Verbindung zwischen Mitarbeitern (oder indirekt über Org-Gruppen) zu Vorgängen, Transaktionen, Jobs und Programmen ist es beispielsweise möglich, vor Vergabe eines Arbeitsauftrages Mitarbeiter für einen Auftrag über das Data Dictionary zu suchen, die schon in der Vergangenheit für diese Anwendung gearbeitet haben. Insbesondere ist es nachträglich immer möglich, festzustellen, welche Mitarbeiter wann an Aufträgen für welche Anwendungen gearbeitet haben. Die Zeitschätzungen und Vorgaben gehen dann in das Projekt-Planungssystem PEAC (IBM) ein. Dieses System überwacht dann unter Benutzung von Netzplantechnik die einzelnen Arbeitsaufträge und den Projektfortschritt.
Im sogenannten Help-Modell erhält der Data Dictionary Benutzer Vorgaben für die verschiedenen Definitionen, die am Bildschirm den Benutzer bei der Eingabe der Beschreibung führen. Um andere Zugriffsmöglichkeiten zu haben als nur den eigentlichen Membernamen, wurden über die Membertypen CAI-Gruppe und CAT-Wort (CAT = Catalogue oder Descriptor) zusätzliche beschreibende Deskriptoren vorgegeben, die den Membern in Abhängigkeit vom Membertyp zwingend oder optional mitzugeben sind. Hiermit wird erreicht, daß die Kundennummer, die vielleicht im Data Dictionary als Kunden-Nummer (mit Bindestrich) gespeichert ist, gefunden werden kann, indem man nach den Deskriptoren Kunde und/oder Nummer sucht.
Einheitliches Entwicklungskonzept
Um den Gleichlauf zwischen der Dokumentation im Data Dictionary und der Programmdokumentation sicherzustellen, wurde eine Verbindung zwischen den Benutzerschnittstellen des Metacobol und Datamanager geschaffen, die Dokumentation ist nur noch im Data Dictionary gespeichert und wird in die Programme automatisch eingefügt. Durch das Verbindungsprogramm werden die Identification, Environment und Data-Division aller Cobol-Programme vollständig automatisch aus dem Data Dictionary generiert. Ohne eine Änderung der Programmvorgabe (wie Ausgabe einer neuen Datei) im Data Dictionary ist es nicht möglich, die notwendigen Dateideklarationen im Cobolprogramm zu erzeugen. Auch die Dokumentation für jede Section innerhalb des Cobolprogrammes wird im Data Dictionary gespeichert und zur Umwandlungszeit aus dem Data Dictionary in die Programmliste eingefügt. Dadurch kann die Dokumentation aus der Programmvorgabe sehr oft schon benutzt werden, um später das Cobolprogramm direkt ohne weitere Umsetzung zu dokumentieren. Jede Umsetzung von Informationen bedeutet eine mögliche Fehlerquelle. Durch den Einsatz eines Data Dictionary als projektbegleitendes Dokumentationshilfsmittel hat man erreicht, daß Beschreibungen durch Verknüpfungen an die nächste Entwicklungsphase weitergegeben werden können und so in der Systemanalyse vorgegebene Feldbeschreibungen ohne weitere Umsetzung direkt für die Generierung von Dateibereichen verwendet werden.
Die Einführung dieses Softwareentwicklungsmodells war mit einigem Aufwand verbunden. Im Hause Tchibo hat man aber für die Zukunft ein über alle Bereiche einheitliches strukturiertes Systementwicklungskonzept, das projektbegleitend von der Systemanalyse bis hin zur Umwandlung des Programmes unterstützend mitwirkt. Auch wenn man Abstriche an dem ursprünglichen anspruchsvollen Anforderungskatalog hat machen müssen, so hat man doch durch den Einsatz des Data Dictionaries zumindestens die Möglichkeit geschaffen, andere Softwarewerkzeuge auf die vorhandenen Daten zugreifen zu lassen.
Die feste Vorgabe aller Beschreibungselemente erfordert sicherlich von den Mitarbeitern viel Disziplin, andererseits wird es ihnen dadurch aber ermöglicht, auch die Vorteile eines Data Dictionaries voll zu nutzen: Definitionen von Feldern brauchen nicht mehr redundant für verschiedene Anwendungen in der Systemanalysephase gemacht werden, eine einfache Verbindung erlaubt, die Verkettung der Felder mit den entsprechenden Anwendungen. Die Definition aus der Systemanalysephase kann dann direkt nach Definition der Listen oder Gruppen zum Generieren von Code für die Dateibeschreibung benutzt werden. Wenn die Vorteile des Einsatzes eines Data Dictionaries auch in der Systemanalysephase auf Anhieb nicht so gewichtig erscheinen mögen, so dürften sie speziell im Bereich der Wartung allen klar werden. Es ist jetzt möglich, bei Änderungen in Programmen die notwendigen Dokumentationsänderungen ebenso am Bildschirm durchzuführen wie die darauf folgenden Programmänderungen.
Vor dem endgültigen Einsatz dieser Softwaresysteme im Hause Tchibo hat man natürlich eine Kostenschätzung durchgeführt. Der Einsatz der Softwarewerkzeuge, der ja sicherlich zusätzlich Maschinenzeit kosten wird, wurde dabei, für einen 5-Jahreszeitraum gesehen, mit etwa 1 Million Mark geschätzt. Dem gegenüber gestellt wurden die Ersparnisse, die sich eigentlich auch im ungünstigsten Falle aus der Benutzung des Data Dictionaries und der anderen Softwaretools ergeben, wie die erhebliche Unterstützung im Bereich der Programmwartung und Vermeidung von Schnittstellenproblemen. Die überschlägige Schätzung hierfür belief sich auf rund 2 Millionen Mark. Unter Berücksichtigung dieser geschätzten Kosten und Ersparnisse entschied man sich für den Einsatz der Softwarewerkzeuge, um der Zielsetzung der Minimierung der Gesamtkosten für die Entwicklung und Wartung näher zu kommen.
*Heiner Göhlmann ist bei der Tchibo Frischröstkaffee AG, Hamburg, für die Systemmethoden und Arbeitstechnik der Organisationsabteilung verantwortlich.