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.

06.12.1985

Tools können Nachlässigkeit bei Programmdokumentation aufwiegen

Da aktuelle und zeitkritische Probleme in der Regel eine Vorrangstellung einnehmen, stellt die Software-Dokumentation in der DV nach wie vor eine "Quantite negligeable" dar. Erschwerend kommt hinzu, daß eine Programmbeschreibung auch immer einen "Schuß" journalistischer Begabung erfordert. Abhilfe schaffen können bei diesen Mängeln für Planed-Geschäftsführer Alexander Cramer sowie den Org./DV-Chef bei Fiat, Jörg Spranger, in erster Linie Tools oder Utilities, die automatisch dokumentieren. Dabei sollte Jedoch, so Spranger, die Erstellung solcher Werkzeuge auf per Gesetzgebung bestimmten, klaren und verständlichen Vorschriften basieren. Eine weitere Möglichkeit, das Problem in den Griff zu bekommen, zeigt Otto Kurmann von der Touristik Union auf. Der TUI-Datenadministrator der Abteilung Verwaltungsservice plädiert dafür, selbstgestrickte Auswertungsprogramme auf ein Tool "aufzusetzen".

Heinrich Adolphs Kreisverwaltungsdirektor und Leiter des Rechnungs- und Gemeindeprüfungsamtes bei der Kreisverwaltung Siegburg

Wenn man es richtig bedenkt, sind die Klagen über fehlende oder unzulängliche Programm- und Verfahrensdokumentationen so alt wie die Datenverarbeitung selbst. Alle sind sich einig über die Notwenigkeit von Software-Beschreibungen; es gibt darüber DIN-Normen und inzwischen auch eine Menge von DV-Werkzeugen für die Erstellung von Dokumentationen. Und doch hören die (berichtigten) Klagen über den Mangel nicht auf.

Wahrscheinlich ist die Ursache von verhältnismäßig einfacher Natur: Programm- und Verfahrensbeschreibungen in ihrer vielfältigen Art und für ihren unterschiedlichen Verwendungszweck herzustellen, bedeutet immer ein Stück schriftstellerischer Arbeit. Es setzt beim Autor sehr gute Kenntnisse des zu beschreibenden Verfahrens didaktisches Einfühlungsvermögen, die notwendige Zeit und einen Schuß journalistischer Fähigkeiten voraus. Diese Eigenschaften sind vermutlich nicht allzuoft bei demjenigen gepaart die DV-Verfahren entwickeln (organisieren und programmieren).

Nach eigener 15jähriger Erfahrung auf diesem Gebiet kann ich sagen, wo sie dennoch vorhanden waren oder durch geschickte Zusammensetzung von Entwicklungsteams herbeigeführt wurden, sind oft gute Verfahrensbeschreibungen entstanden.

Man darf sich aber keiner Täuschung über den hohen Zeit- und Kostenaufwand für solche "Systemliteratur" hingeben. " Mit links" läßt sich so etwas nicht machen. Ich selbst habe vor einigen Jahren an einem Handbuch für ein großes DV-Verfahren im kommunalen Haushalts- und Kassenwesen ("Gemeindliches Integriertes Finanz-Informationssystem-GINFIS" ) mitgearbeitet. Das dreibändige Werk konnte nur deshalb gelingen, weil die eingangs geschilderten Voraussetzungen bei dem Autorenteam gegeben waren.

Alexander Cramer Geschäftsführer bei der Planed Gesellschaft für Planung, Entwicklung und Vertrieb von Dialog-Systemen mbH, Köln

Der zunähende EDV-Einsatz in vielen ökonomischen, technischen und wissenschaftlichen Bereichen und die damit verbundene Übernahme von Aufgaben durch Computer jeder Größenordnung erfordern in zunehmendem Maße Problemlösungen auf programmtechnischer Ebene. DS Umsetzung von Arbeitsabläufen gleich welcher Art stellt wachsender Komplexität immer gröbere Anforderungen an den Software-Entwickler und den Anwender. Die Kurzlebigkeit von DV-Konzepten - in Detail - bedingt entsprechend häufig Programmänderungen. Diese Änderungen gestalten dich aufgrund verschiedener Kriterien zu zeitaufwendigen und kapazitätsintensiven Vorgängen. Eine dieser Ursachen ist die oft immer noch als überflüssig angesehene und deshalb nachlässig ausgeführte oder überhaupt unterlassene Dokumentation. Insbesondere bei Anlassen wie zum Beispiel Programmänderungen, Personalwechsel Revision, Rekonstruktion, Systemwechsel oder für Bedienungsanweisungen und Fehlersuche muß eine vollständig detaillierte Programm- beziehungsweise Systemdokumentation vorliegen. Es ist von untergeordneter Bedeutung, welchem Aspekt ein DV-Anwender Priorität einräumt. Wichtig ist allein die Einsicht in die Notwendigkeit des Vorhandenseins von aktuellen Dokumentationsunterlagen aus folgenden Gründen:

- Der Umfang der am Arbeitsplatz zur Verfügung stehenden DV-Funktionen nimmt ständig zu, damit nimmt die Häufigkeit der Benutzer einer bestimmten Funktion durch den Anwender zwangsläufig ab.

- Wahrend früher die" Benutzer-Schnittstelle" in mehr oder weniger lesbaren Auswertungen und Statistiken bestand, stehen selbst einem PC-Anwender heute neben Auswertungen in Listenform eine kaum überschaubare Fülle an Möglichkeiten zur Informationserfassung, -verarbeitung und -Auswertung am Bildschirm zur Verfügung.

- Die Anzahl der Personen, die maßgeblich an jeder Art von Sofware-Entwicklung beteiligt sind, nimmt weiter zu.

Immer mehr Software-Entwickler stellen also einer ständig zunehmenden Zahl von Anwendern immer mehr Programme und DV-Funktionen zur Verfügung.

Mit der Dokumentation hapert es aber offensichtlich, obwohl alle Beteiligten sich der Bedeutung derartiger Unterlagen bewußt sind. Offensichtlich muß der (DV-)Mensch - wie in vielen anderen Bereichen - zu seinem Gluck gezwungen werden. Kein noch so simples technisches Produkt wird heute noch ohne Bedienungsanleitung und Servicedokumentation verkauft. Warum also werden die gleichen Qualitätsanforderungen nicht an ein technisch so hochwertiges Produkt wie Software gestellt? Aus der Vielzahl der möglichen Gründe soll an dieser Stelle nur ein Aspekt besonders hervorgehoben werden, den es dringend zu verbessern gilt, nämlich den der Revision.

Wie in vielen anderen Bereichen des wirtschaftlichen Lebens wird offensichtlich bei den Beurteilungsmaßstäben Qualität durch Quantität erseht. Dies ist nicht nur einfacher, sondern auch noch effektiv, da die Meinung offensichtlich verbreitet ist, daß eine umfangreiche Dokumentation zwangsläufig alle Kriterien einer detaillierten und vollständigen Programm- beziehungsweise Systemdokumentation erfüllt.

Hier fehlen eindeutige, klare und verständliche Richtlinien, egal aus welcher Richtung (zum Beispiel Gesetzgebung oder Verbände), die auf der Grundlage von minimalen Anforderungen endlich zu der notwendigen Dokumentationsdisziplin von Software-Entwicklern führen. Dabei sollten durchaus maßvolle Forderungen an alle Hersteller enthalten sein, diese Dokumentationsprobleme durch geeignete Utilities lösen zu helfen.

Die hinlänglich bekannten Karikaturen in allen DV-Büros, in denen Chaos mit Genialität und Ordnung mit Kleingeistigkeit assoziiert werden, haben mit Sicherheit einen realistischen Hintergrund: Die wenigsten der sogenannten DV-Spezialisten unserer Software-Branche sind Genies. . .

Otto Kurmann Datenadministrator in der Abteilung Verwaltungs-Service bei der Touristik Union International GmbH & Co KG, Hannover

Bei der Touristik Union International (TUI) wurden mehrfach Versuche unternommen, die Daten und Informationen der DV-Anwendungen mittels eigenentwickelter Programme organisatorisch in den Griff zu bekommen. Da diese Bestrebungen trotz einiger Teilerfolge nicht zu einem zufriedenstellenden Ergebnis führten, wurde Anfang 1983 ein Projekt mit der Aufgabe eingesetzt, Data Dictionary (DD) einzuführen. Über den Einsatz einer Unternehmensberatung versuchte man, möglichst viel Know-how in das Projekt zu bringen. Diese Entscheidung erwies sich so der Einführung als sehr vorteilhaft. Das von dem Projekt vorgeschlagene Konzept für den Einsatz eines DD und der Aufbau einer zentralen Datenadministration (DA) wurde vom Management der TUI verabschiedet. Danach wurde ein DD - Datamanager (DMR) - gekauft und die Freigabe vorbereitet. Die gesamte Projektlaufzeit ging über ein Jahr.

Der DMR ist bei der TUI ein Tool, das die Durchführung bestimmter Aktivitäten und Arbeitsschritte in der jeweiligen Entwicklungsphase unterstützt. Das heißt, dem Software-Entwickler wird auf der Basis der Vorgehensweise (Methode) vorgegeben, wann und bei welchen Aktivitäten und Arbeitsschritten er "toolunterstützt" vorzugehen hat, so daß die Eingaben im DMR projektbegleitend durchgeführt werden. Die Attribute innerhalb der einzelnen Membertypen sind so konzipiert, daß die Beschreibungsteile sukzessiv entsprechend der zu bearbeitenden Projektphase im DMR abgelegt werden können. Damit bildet der DMR für die Entwicklungs- und Systemdokumentation das zentrale Dokumentationstool.

Die standardmäßig von der DMR-Software gelieferten Auswertungen sind in bezug auf die Aufbereitungsform und die Anwenderfreundlichkeit unbefriedigend. Aus diesem Grund hat die TUI spezielle Auswertungsprogramme geschrieben, die auf die Anforderung der Entwicklungs- und Systemdokumentation eingehen und den Projekten ein großes Maß an Flexibilität bezüglich Auswertungsvarianten bieten. Damit werden bei der TUI zum Beispiel Benutzerhandbücher, Programmhandbücher und Phasendokumentationen direkt aus dem DRM generiert.

Einer der wesentlichen Vorteile des DMR liegt in der Generierung von Datenstrukturen (Copystrecken) für die bei der TUI verwendeten Programmiersprachen Cobol, Assembler und Siros. Des weiteren werden in unserem Unternehmen aus dem DMR die Meldungen für die zentrale Meldungsdatei generiert. Zusätzlich wird an verschiedenen Stellen Konsistenzsoftware eingesetzt, die die Dokumentation gegenüber der Softwarequalität prüft (zum Beispiel Source von Programm gegenüber der Programmdokumentation).

Mit der Freigabe des DMR nahm auch die DA ihre Arbeit auf.

Im wesentlichen soll hier auf die Hauptfunktion der DA "Anwenderunterstützung "

eingegangen werden. Deren Aufgaben können stichwortartig wie folgt definiert werden:

- Schulung und Einführung der Projektmitarbeiter im DMR,

- Informationsbereitstellung für das Projekt,

- Koordination und Abstimmung von projektübergreifenden Informationen,

- Unterstützung bei der Generierung von Datensätzen und der Erstellung von Handbüchern,

- Sicherung der Qualität der eingestellten Daten.

Mit der Wahrnehmung dieser Aufgaben nimmt die DA den Projekten einen nicht zu vernachlässigenden Aufwand ab. Eine frühzeitige enge Zusammenarbeit zwischen Projekt und DA ist dafür eine wesentliche Voraussetzung.

Akzeptanzprobleme gibt es durch den einmaligen Lernaufwand, um Konzept und Syntax des DMR zu verstehen. Auch scheint vielen der Erfassungsaufwand für die Dokumentation im DMR durch seinen formalen Aufbau und die zugrundeliegenden Standards zu aufwendig.

Dies wird aber schnell kompensiert durch quantifizierbare Vorteile wie

- Verwendung bereits existierender Datenelemente und -strukturen,

- rasche und vollständige Aktualisierung von Datenstrukturen und Dokumentationsteilen, programmgestützte Erstellung von Handbüchern,

- Generierung von Datenbeschreibungen und

- vollständige Übersicht über Änderungsauswirkungen.

Daneben gibt es noch eine Reihe nicht quanitifizierbarer Vorteile in bezug auf die Kriterien Vollständigkeit (Strukturen, Referenzen, Attribute), Transparenz (Projektstatus, Informationsübersichten) sowie Qualitätssicherung und Standardisierung.

Sobald diese Vorteile auch von den Anwendern direkt erlebt werden, wird das DD auch innerlich akzeptiert.

Es zeigt sich bei der TUI sehr deutlich, daß alle Informationen, die wieder aus dem DD in das Umfeld des Entwicklers als Arbeitsgrundlage gelangen, (Copys, Handbücher und Meldungen) eine hohe Qualität haben. Alle anderen Teile sind kritisch in bezug auf die Qualität und Korrektheit. Deshalb wird bei der TUI die Verwendung der DMR-Ausgaben forciert.

Nach zwei Jahren DA kann als Fazit gezogen werden, daß ein DD, erst wenn es in den organisatorischen und technischen Abläufen integriert ist, sich als von wirksam bezeichnen läßt. Deshalb wird von uns die Integrationverstärkt betrieben.

Jörk Spranger Leiter der Abteilung Org./DV, Fiat Automobile AG, Heilbronn

Immer wieder wurde und wird die enorme Bedeutung einer lückenlosen, ausführlichen und aktuellen Dokumentation in der Datenverarbeitung hervorgehoben. In Handbüchern und Richtlinien werden die Minimalanforderungen an eine Programmdokumentation detailliert und liebevoll beschrieben. Jeder Mitarbeiter der Datenverarbeitung bekennt sich vorbehaltlos dazu, daß eine gute Dokumentation unerläßlich und der Verzicht darauf sträflicher Leichtsinn ist.

Schauen wir uns dagegen die Wirklichkeit an, so stellt man fest, daß die allseits gepriesenen und geforderten Standards nur ungenügend und oft unwillig eingehalten werden. Der Grund dafür ist eigentlich immer der gleiche - man habe sich in der spezifischen und sehr kritischen Situation zunächst einmal darauf konzentrieren müssen, das anstehende, höchst zeitkritische Problem zu lösen, die geforderte Dokumentation könne man ja später immer noch nachholen sobald man neunmal etwas mehr Ruhe dabei. Meiner Meinung nach hat es wenig Sinn immer wieder mit Druck und guten Worten gegen die oben geschilderte Verhaltensweise anzugehen.

Auf Dauer hilft hier nur ein Tool mit "automatischer" Dokumentation, das heißt parallel zur Programmerstellung muß eine begleitende Dokumentation erstellt werden, die es einem Programmierer ermöglicht zu erkennen, was, wann, wo und von wem erstellt beziehungsweise geändert wurde. Natürlich können diese Dokumentationen nicht den in Richtlinien und Handbüchern geforderten Idealen entsprechen, aber sie geben einem Fachmann genügend Information für eventuell erforderliche Eingriffe und sie sind - dank der Automatik - immer auf dem aktuellen Stand. Auch die Programmiersprachen der vierten Generation bieten heute übrigens die Möglichkeit, Dokumentationen einfacher Art automatisch zu erstellen. Das Optimum wäre in meinen Augen jedoch der Einsatz eines Entwicklungssystems, was über die automatische Dokumentation hinausgehend einen sofortigen Überblick über den augenblicklichen Projektstand bietet.