Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.12.1977 - 

Anwenderbericht: Jenaer Glaswerke Schott & Gen.

Dokumentation kein "lästiges Anhängsel" mehr

MAINZ - "Schon immer positiv" stand man bei den Jenaer Glaswerken Schott & Gen. in Mainz neuen Methoden und Techniken zur Entwicklung von Anwendungssoftware gegenüber. So liegt es für Heinrich Krummenauer, Leiter der Schott-Abteilung DV-Anwendung/-Entwicklung, auch auf der Hand, daß "wir Methoden wie HIPO, EVA, strukturierte Programmierung oder Chief Programmers Concept schon während der Planungsphase eines Projektes einsetzen und auch zur Dokumentation ein Werkzeug benutzen, um solche Methoden sinnvoll anwenden zu können." Bei der Auswahl eines solchen Dokumentationswerkzeuges tat man sich bei Schott allerdings schwer.

Bisher hatte man mit selbstentwikkelten Formularen weitgehend konventionell dokumentiert und sich trotz einiger Kontakte zu Anbietern von maschinellen Dokumentationssystemen noch nicht zu einem Kauf entschließen können. Dann stießen wir aber - so Krummenauer - ,"mehr oder weniger zufällig", auf das System "Autodok" des Mainzer Zentrums für Datenverarbeitung und Organisation (ZDO). Das EDV-Projekt "Kundenstrukturanalyse" für den Marketing-Bereich benötigte nämlich noch zusätzliche Manpower, die, da die eigene Personalkapazität fehlte, wie schon öfter von der naheliegenden ZDO ausgeliehen wurde. Die ZDO-Leute erstellten mit Hilfe ihrer Eigenentwicklung "Autodok" eine programmierfähige Dokumentation. Nach etwa drei bis vier Wochen lag eine grobe Beschreibung des Gesamtprojektes vor, hierarchisch gegliedert in Haupt- und Unterblöcke mit einem Eingabe- und einem Ausgabeteil, wie es den Prinzipien der "verbesserten Programmiertechniken" entspricht. Auf dieser Grundlage aufbauend, wurden die Blöcke weiter untergliedert und mit Pseudocode-Anweisungen versehen. "Etwa acht Wochen nach Beginn des Projektes waren wir in der Lage, dem Fachbereich eine programmierfähige Dokumentation vorzulegen", erinnert sich Krummenauer. Dadurch war die Möglichkeit gegeben, daß sich sowohl die Sachbearbeiter, als auch die Vorgesetzten in die Problematik je nach ihrer Aufgabe einarbeiten oder nur einen Überblick verschaffen konnten, indem sie - entsprechend der Hierarchiestufen - tiefer oder auch weniger tief in die Beschreibung einstiegen.

"Dieser Programmiervorgabe, die in unserer Source Library steht und jederzeit und beliebig oft abrufbar ist, wurden die entsprechenden Programmieranweisungen hinzugefügt, so daß die Programmlisten gleichzeitig auch die Dokumentation enthalten," skizziert Krummenauer das weitere Vorgehen mit dem Dokumentationssystem. So war Schott & Gen. sehr schnell in der Lage, von Teilproblemen einen strukturierten Output zu erzeugen. "Schwach fanden wir nur, daß alles, was in die Dokumentation einfließen soll, erst einmal niedergeschrieben werden muß", kritisiert Krummenauer den Erfassungsaufwand bei "Autodok" und wünscht sich eine Online-Version des Dokumentationssystems, das unter CMS gefahren werden könnte." Außerdem würden ein Data Dictionary - so Krummenauer - oder eine zentral verwaltete Bibliothek aller Funktionsalgorithmen, vielleicht auch die Generierung von Listbildern und Satzbeschreibungen anhand von Datenstrukturen den Komfort eines solchen Dokumentationssystems wesentlich erhöhen. Dennoch überwiegen anscheinend die Vorteile: "Wir haben schnell erkannt, daß Autodok keine langen Einarbeitungszeiten benötigt und leicht zu handhaben ist", lobt Krummenauer und sieht darüber hinaus vielfältige Anforderungen, die von verschiedenen Seiten an eine gute Software-Dokumentation gestellt wurden, erfüllt: "Da bei der Entwicklung eines Programmsystems der spätere Benutzer aktiv mitarbeiten sollte, darf die Dokumentation zwar das Problem und dessen funktionale Lösung zeigen, soll sich aber nicht in Programmdetails verlieren", weiß Krummenauer beispielsweise die wichtigen Fachabteilungsbelange einzuschätzen. Andererseits wird seiner Meinung nach aber auch gewährleistet, daß Spezifikationen auch von Programmierern vorgenommen werden können, die mit der Problemstellung nicht oder nur sehr wenig vertraut sind. Hinzu käme noch, - so meint der DV-Entwicklungs-Praktiker - "daß Autodok auch eine ganze Reihe von Forderungen des Bundes-Datenschutzgesetzes erfüllt und zwar nicht nur im Hinblick auf neu zu entwickelnde Programme, sondern auch durch Sanierung bereits bestehender Programme". Die positiven Erfahrungen nach Abschluß des Pilotprojektes, für das ZDO in Mainz das Dokumentationssystem kostenlos zur Verfügung stellte, haben die Systementwickler bei Schott bewogen, mit "Autodok" weiterzumachen: "Wir wollen mit Autodok neu zu entwickelnde Programme möglichst online dokumentieren und auch bestehende Programme sanieren", steckt der Schott-EDVer die weitere Marschrichtung ab und resümiert: "Die Dokumentation entsteht parallel zur Entwicklungsarbeit und kann nicht mehr als lästiges Anhängsel abgetrennt werden."

DV-lnstallation bei den Jenaer Glaswerken

IBM 370/158 mit 3 MB, 3350 Platteneinheiten, 2 IBM 1403 Druckern sowie Local- und Remote-Bildschirmen. Als Systemsoftware sind im Einsatz VM/370 Rel. 3, OS/VS1 Rel. 6.0/CICS Rel. 1.1.1., IMS-DB Rel. 1.0.1. In der Programmierung stehen 6 Bildschirme zur interaktiven Programmentwicklung unter CMS zur Verfügung; dabei werden PL/I- Optimizing und Checkout-Compiler unterstützend verwendet. CA-Sort, Easy-Trieve, Fast Dump Restore, PROKOS als Programmsystem in der Kostenrechnung und SAP-Software in Materialwirtschaft und einer Auftragsabwicklung ergänzen das Dienstleistungsprogramm zum Anwender hin.