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.

30.04.1981

Überlegungen bei IBM, durch Systemsoftware-Änderungen keine Kundeninvestitionen zu gefährden:Die Fehler sucht ein Gutachtergremium

Wie in allen anderen Ingenieurdisziplinen soll auch bei der Software der Herstellungsprozeß planbar und müssen die Eigenschaften des Produktes voraussagbar sein. Es ist in der Softwareentwicklung nicht ungewöhnlich, daß als erreichbar angesehene Ziele nicht eingehalten werden können.

Verantwortlich für die Fehleinschätzungen dieser Art sind vor allem die Anforderungen an die Software und die damit verbundene Komplexität, die nicht selten das geistige Vermögen vieler Menschen übersteigt. Daneben gibt es eine - vor allem interne - Komplexität, auf die im folgenden näher eingegangen wird. Software hat charakteristische Eigenschaften, die sie im Laufe der Zeit kompliziert machen.

A. Lebensdauer

Software lebt meistens länger als ursprünglich geplant. Dies gilt bei Systemsoftware - wie beim DOS/VSE - vor allem deshalb, weil viele Kunden Funktionen des Betriebssystems benutzen und keine kostspieligen Änderungen an ihrer eigenen Software vornehmen wollen. In dieser Kundensoftware ist ungewöhnlich viel Kapital gebunden, das durch neue Entwicklungen nicht wertlos werden darf.

B. Kompatibilität

Zusätzliche Eigenschaften sind bei einem neuen Release zwar erwünscht, doch müssen die bereits existierenden gleich bleiben. Kritisch wird Kompatibilität vor allem dann, wenn die Benutzerzahl sehr hoch ist. Denn jede einmal dem Kunden angebotene Funktion ist für die gesamte Lebenszeit des Softwaresystems festgelegt und kann im Normalfall, wenn nicht besondere Umstellungshilfen zur Verfügung stehen, nicht mehr entfernt werden.

C. Änderbarkeit

Software ist extrem leicht zu verändern. Mit nur wenigen Instruktionen kann die Aufgabe eines Programms völlig geändert werden. Die Schwierigkeit liegt darin, daß die Software nicht anschaulich ist. Fachleute können zwar den Entwurf bestehender Software verstehen lernen, aber auch diese Aufgabe ist sehr schwierig. Wenn Änderungen an Software durchzuführen sind, wird man sie deshalb eher als lokale und nicht, wie vielleicht notwendig, als globale, tiefgreifende Änderungen durchführen. Lokale Änderungen wirken aber wie Flickwerk und machen die Software kompliziert, weil sie zu Wucherungen führen.

D. Reproduzierbarkeit

Das Teuere bei der Software sind die Entwicklungskosten, das Reproduzieren ist trivial. Es besteht nur im Kopieren von Informationen. Daher wird von der Reproduktion her kein Zwang ausgeübt, die Software im Umfang klein zu halten.

Belady und Lehmann (1) stellten Softwaregesetze auf, die statistisch gültige Aussagen über Software im Laufe der Zeit machen. Stark vereinfacht lauten diese:

1. Benützte Software wird geändert.

Da Software zur Lösung realer Probleme herangezogen wird, bleibt sie von Änderungen nicht verschont.

2. Die Unstrukturiertheit von Software wächst im Laufe der Zeit, außer es wird explizit etwas dagegen getan.

3. Über einen längeren Zeitraum gesehen wachsen Softwaresysteme kontinuierlich.

Diese Gesetze gelten natürlich auch für DOS/VSE. Sie zeigen einen Teil der Schwierigkeiten und Probleme des Software-Engineering auf.

Beherrschung von Komplexität

Mit genügender Erfahrung wird auch Komplexität beherrschbar. (Ein Beispiel dafür bietet unsere, Umgangssprache.) Schaffen von Erfahrung und Ausbau der handwerklichen Fähigkeiten nehmen im IBM-Programmentwicklungszentrum eines hohen Stellenwert ein.

Dazu einige Beispiele:

Leitung von Teilprojekten durch Personen mit langjähriger Entwicklungserfahrung; Erfahrungsaustausch mit anderen Laboratorien, Kunden und der wissenschaftlichen Welt; eine gutbestückte Bibliothek und ein umfassender Literaturdienst.

Ein weiteres wichtiges Prinzip ist Teilen und Beherrschen: Das System wird in Komponenten unterteilt, Komponenten in Software-Moduln, Funktionen in Teilfunktionen.

Ein anderer Aspekt ist das Abstrahieren, das heißt, das für ein Problem Unwesentliche bei der Betrachtung weglassen. Abstrahieren ist ein wichtiges technisches Konzept von Software-Engineering. Zum Beispiel sollte man als Benutzer von Software immer nur die für ein

Problem wichtigen Aspekte sehen; interne Belange sollten versteckt sein.

Schnittstellen dieser Art bezeichnet man als hohe oder logische. Schnittstellen. Man versucht, wo immer es geht, sie zu erreichen, weil sie einfach und übersichtlich bleiben.

Ein verwandter Gesichtspunkt ist das Vereinfachen, das Weglassen von unwichtig gewordenen Details.

Bei DOS/VSE bemüht man sich die Benutzerschnittstellen und interne

Schnittstellen zu vereinfachen, überflüssig gewordene Funktionen und Codeteile zu eliminieren und damit der Unstrukturiertheit zu begegnen.

Als letzter genereller Punkt soll der Einsatz von technischen Hilfsmitteln hervorgehoben werden, über die das Böblinger Rechenzentrum des IBM-Programmentwicklungszentrums in großem Umfang verfügt.

In Böblingen beschäftigt man sich auch mit Softwareentwurf und Softwarebeschreibung im allgemeinen Dabei ist vor allem die Kommunikation innerhalb der Softwareentwicklung zu einer Kernfrage geworden. Die langfristigen Überlegungen gehen dahin, Produktveränderungen durchzuführen, ohne damit Kundeninvestitionen zu gefährden.

Der Softwareentwicklungszyklus beginnt mit dem Schreiben der externen Spezifikationen. Diese Spezifikationen werden in Zusammenarbeit mit Planungs- und Release- Verantwortlichen geschrieben, inspiziert und zur allgemeinen Begutachtung verteilt. Schon zu Zeitpunkt überprüft eine unabhängige Kontrollinstanz das Produkt; sie steht außerhalb des Programmentwicklungsbereichs.

Das Produkt wird in Teile, Komponenten, Moduln und Funktionen zerlegt. Für jeden dieser Teile ist ein Mensch - man nennt ihn Besitzer - voll verantwortlich. An ihr werden alle Fragen herangetragen; er koordiniert und hilft, Probleme zu lösen.

An Hilfsmitteln werden neben dem Textverarbeitungssystem "Script" Online-Programmierung und Dialog-Programmierung verwendet. Jeder Programmierer hat über eine Datenstation Zugriff zum Rechner.

Assembler-Code nur selten

Jeder neu zu schreibende Code muß nach den Richtlinien der strukturierten Programmierung und in einer höheren Programmiersprache geschrieben werden. Lediglich extrem zeit- oder speicherplatzkritischer Code wird in der maschinennahen Assemblersprache geschrieben.

Es steht dem Programmierer nicht frei, seine Programme nach eigenem Gutdünken zu entwerfen und zu schreiben; er muß sich an interne Normen halten, die ihm die Art der Dokumentation, die Verwendung von Schnittstellen, die Programmiersprache und anderes mehr zwingend vorschreiben.

Bei fast allen Entwicklungsaufgaben trifft man auf den Begriff der Inspektion: Der Autor eines Programms oder eines Entwurfs trifft sich - unter der Anleitung eines Moderators - mit Fachkollegen und geht anhand einer Prüfliste des Produkt durch. Dabei stellt nicht der Autor, sondern ein sogenannter "Leser" das Produkt vor. Der Leser und die Begutachter haben die Aufgabe, Fehler zu finden oder Verbesserungen aufzuzeigen. Je früher ein Fehler gefunden wird, um so weniger kostet seine Reparatur.

Testumgebung VM

Von den technischen Hilfsmitteln soll noch ein wesentliches herausgegriffen werden: Das Betriebssystem VM (Virtuelle Maschine), das eine Basis für den Test neuer Betriebssysteme legt. Man kann in VM an einer Maschine gleichzeitig fast beliebige Betriebssysteme laufen lassen, wobei jeder Benutzer die Vorstellung hat, nur an seiner eigenen Maschine zu arbeiten. Der Programmierer kann sich mit VM sein eigenes Betriebssystem als Testumgebung schaffen und unabhängig von anderen Personen seine Programme austesten.

Literatur:

(1) Belady, L. A. u. Lehmann, M. M.: A model of large program development. IBM Systems Journal 15 (1976) Nr. 3.

*Dr. Otto Buchegger arbeitet seit 1973 in den IBM-Laboratorien Böblingen. 1973 bis 1975 Prozessorenentwicklung, ab 1975 DOS-Entwicklung.