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.

19.08.1983 - 

DV-Laie hat mit DDP eine reelle Chance:

Software-Engineering wird zur Gretchenfrage

Durch die weite Verbreitung des Distributed Data Processing sind die Chancen für den Endbenutzer, einen nennenswerten Teil seiner Probleme durch Entwicklung von Anwendersoftware selbst zu lösen, erheblich gestiegen, in vielen Fällen sogar erst greifbar geworden. Aber eine Chance ist noch keine Erfolgsgarantie und vor den Erfolg haben die Götter den Schweiß gesetzt. Eüphorie ist daher nicht angebracht. Jeder DV-Laie, der mit dem Gedanken spielt, auf seinem DDP-System Anwendungssoftware zu entwickeln, sollte außer den Chancen auch die Gefahren sehen und nüchtern abwägen, ob einerseits er selbst die notwendigen Voraussetzungen für ein solches "Abenteuer" mitbringt, und ob andererseits "sein" System (geplant oder schon installiert) Methoden und Hilfsmittel bietet, die ein ordentliches Software-Engineering unterstützen. Denn das gilt für DV-Laien genauso wie für den "Profi": Langfristig kann man nur mit nach ingenieurmäßigen Methoden erstellter und gepflegter Software glücklich werden.

Vorsicht ist geboten: Es wäre naiv, anzunehmen, daß die Verfügbarkeit einer "Software-Werkbank" jeden Benutzer gleich automatisch zum Software-Ingenieur macht, der jetzt wie vom Fließband Software-Produkte erzeugen kann. Zum sinnvollen Einsatz von Werkzeugen und Methoden gehört ingenieurmäßiges Denken und Kenntnisse, die je nach angebotenen Methoden schnell oder zumindest schrittweise erworben werden können. Das Wesentliche ist aber die Einstellung, sich mit unbekannten Konzepten und Methoden auseinandersetzen zu wollen, mit dem Bewußtsein, dabei Probleme meistern zu müssen, die sich von den gewohnten Problemen grundsätzlich unterscheiden.

Was macht denn die Software-Entwicklung so problematisch (und nicht nur für DV-Laien)? Der Rechner ist ein System, das mit unübertrefflicher Sturheit (und Geschwindigkeit!) Dienst nach Vorschrift macht - die Vorschrift ist die Software. Entwicklung von (Anwendungs-) Software heißt also, eine Vorschrift zu erzeugen, die den Rechner dazu bringt, eine Dienstleistung zur Lösung einer Aufgabe nach den Vorstellungen des Auftraggebers zu erbringen.

Eine Vorschrift so vollständig und präzise zu fassen, daß unter allen Umständen das gewünschte Ergebnis erzielt wird, ist das eigentliche Problem: Ein Problem, das sich in anderen Bereichen des täglichen Lebens nicht mit der Härte stellt, da die natürlichen Sprachen so viel Redundanz enthalten, daß nicht sinnverändernde Fehler tolerierbar sind (wahrscheinlich daher die Redundanz, da der Mensch nun mal unter keinen Umständen ein fehlerfreies System ist).

Fachabteilung muß umdenken

Der DV-Laie, der sich mit diesem Problem immer konfrontiert sieht, muß sich umgewöhnen. Er muß sich jederzeit darüber im klaren sein, daß die von ihm erzeugte Vorschrift "buchstabengetreu" vom Rechner ausgeführt wird, daß auch der kleinste Fehler nicht toleriert wird. Natürlich arbeitet er mit Kunstsprachen, die diese Notwendigkeit der präzisen Formulierung durch eindeutige Zuordnung von Sprachelement und Funktion unterstützen. Dennoch braucht es Gewöhnung, bis man ohne Zähneknirschen akzeptiert (ja es sogar wegen der Reproduzierbarkeit begrüßt), daß sich der Rechner stur an die Buchstaben der Vorschrift hält, obwohl aus dem normalen Umgang mit Sprachen "klar sein müßte, was gemeint ist".

Diese Umgewöhnung fällt leichter, wenn der positive Aspekt ins Auge gefaßt wird, daß nämlich endlich mal einer tut, was ihm gesagt wird und sich nicht mit Mißverständnissen herausredet. Dazu muß man genau wissen, was man möchte: Hier hat eigentlich jeder, der eigene Probleme lösen will, einen erheblichen Vorteil vor jenem, der die Probleme erst von "außen" analysiert. Aber selbst wenn man die Aufgabe "im Schlaf" kennt, bedarf es einer gewissen Disziplin, alle Möglichkeiten abstrakt durchzuanalysieren. Hierbei kommen die geforderten "Ingenieurstugenden" zum Tragen für die man kein Ingenieurstudium braucht, sondern die großenteils eine Frage der persönlichen Fähigkeiten und fast noch mehr der Einstellung sind.

Hierzu zählt die Fähigkeit zum analytischen Denken, die Bereitschaft, ein Problem systematisch und vollständig zu analysieren, bevor die Codierung begonnen wird. Wenn man sich nicht mehr daran stört, daß "Ausnahmefälle" und interne Konsistenzprüfung oft den Löwenanteil bei einem Programm ausmachen, dann ist man auf dem richtigen Weg. Wenn man alles, auch die "unwahrscheinlichen" Fälle mit Geduld und Präzision codiert, dabei auch noch das Programm ordentlich dokumentiert, kann eigentlich nicht mehr viel danebengehen.

Fähigkeit des Rechners ausnutzen

Allerdings sollte nicht verschwiegen werden, daß auch bei professionellen Programmierern die Zusammenballung aller notwendigen Tugenden äußerst selten ist. Es liegt nahe, zur Unterstützung die Fähigkeiten des Rechners auszunutzen. Dabei ist wesentlich, daß aufeinander abgestimmte Methoden und Werkzeuge im Rahmen eines Software-Engineering-Konzepts zur Verfügung stehen und nicht nur voneinander isolierte Codierhilfen.

Wenn im Rahmen eines solchen Gesamtkonzeptes zum Beispiel Applikationsgeneratoren vorhanden sind, die den Anfänger beziehungsweise DV-Laien zu schnellen Erfolgserlebnissen kommen lassen, um so besser. Es muß aber für den Anwender möglich sein, sich schrittweise von den "vorgedachten" Strukturen zu entfernen und eigene Strukturen zu erzeugen, ohne Methode und Werkzeug wechseln zu müssen. Nur so läßt es sich vermeiden, daß der Einsteiger bald an Grenzen stößt, die zwar normalerweise nicht so eng sind wie bei Standard-Anwendungspaketen, aber doch vielleicht die optimale Ausnutzung des DDP-Systems verhindern.

Daher ist eine kontinuierliche Übergangsmöglichkeit von der Maßkonfektion auf soviel Maßarbeit wie nötig ein wichtiges Kriterium bei der Bewertung von angebotenen Methoden. Gerade für DV-Laien, die damit sicherstellen können, daß anfänglich mit relativ wenig Aufwand erstellte Software mit später (oder extern) erzeugter Software methodenkompatibel bleibt.

Softwarekrise im Keim erstickt

Ein solches Software-Engineering sollte folgende Struktur haben: als Basis eine Methode, wie etwa die strukturierte Programmierung, mit definitiven Vorschriften für Entwurf und Programmierung. Darauf aufbauende, komfortable Codierhilfen, Masken- und Codegeneratoren mit Bibliotheken von Codebausteinen, Applikationsgeneratoren (zum Beispiel auf Skelettprogrammbasis) sowie Online-Testhilfen, Unterstützung der Programmpflege und weitgehend automatische Programmdokumentation. Sämtliche Werkzeuge und Bausteine sollten mit der Basismethodik so abgestimmt sein, daß die Einhaltung der Programmkonventionen praktisch die Voraussetzung für ein effizientes Arbeiten mit den Software-Werkzeugen ist. Wenn die Einhaltung der Konventionen der Weg des geringsten Widerstandes (sprich der maximalen Arbeitsersparnis.) ist,

fällt jedem die notwendige Selbstdisziplin leichter. Die Folge sind einheitliche und transparente Programme, die mit entsprechend geringem Aufwand gepflegt und erweitert werden können. Darin liegt der Hauptnutzen des Software-Engineering, und gerade der von "Altsoftware" unbelastete Einsteiger sollte größten Wert darauf legen, von vornherein alle Ansätze einer eigenen "Software-Krise" im Keim zu ersticken.

Gerade für den Einsteiger sind Applikationsgeneratoren ein guter Einstieg, der ihm erlaubt, mit wenig Aufwand nützliche und einwandfreie, strukturierte Software zu erzeugen. Außerdem kann er die Fälle als Beispiele studieren, sich Schritt für Schritt eigene Strukturen konstruieren und damit einen kontinuierlichen Übergang zu spezielleren Applikationen erreichen. Ebenfalls für den Einstieg sofort einsetzbar ist ein Bildschirmgenerator, der aus einem vom Anwender in der gewünschten Weise gefällten Bildschirm automatisch den entsprechenden Quellencode erzeugt, der dann in beliebige Programme hineingeneriert werden kann.

Dokumentation aus dem Quellcode

Neben Online-Testhilfen und Up-date-Programmen zur kontrollierten Softwarepflege soll besonders die automatische Programmdokumentation erwähnt weiden. Die Dokumentationswerkzeuge basieren auf den Programmierkonventionen und erzeugen direkt aus dem Quellencode (ohne Zusatz von Pseudocode) eine modulweise Dokumentation, die für jedes Modul alle dort verwendeten Datenfelder samt zugehöriger Quellencode-Kommentierung umfaßt, sodann die Funktionsstruktur als Diagramm ausgibt und die Ausgabe einer Cross-Referenc-Liste mit Modulreferenz (statt Zeilenreferenz) ermöglicht. Um eine vollständige interne Programmdokumentation zu gewährleisten, genügt die übliche Kommentierung des Quellencodes.

Da die Dokumentation auf Datenträger ausgegeben wird und ein Ausdrucken ohne Nacherfassung die endgültige Form liefert, bietet sich die Möglichkeit, bei jeder Änderung oder Erweiterung eines Programms sofort die aktuelle Dokumentation zu erzeugen beziehungsweise im Zweifelsfall einfach eine neue Dokumentation zu generieren. Das gibt nicht nur dem Einsteiger die Chance, den Überblick über seine Software langfristig zu sichern.

*Dr.Klaus Müller ist Hauptabteilungsleiter Software bei MDS-Deutschland GmbH, Köln.