Die hier festgehaltenen Überlegungen wurden am 7. März bei einem IBM-Journalisten-Seminar zum Thema "Software - Ein Entwicklungsproblem" von Helmut Lamparter, dem Leiter des IBM-Programmentwicklungszentrums in Böblingen, vorgetragen.
Produktivität ist laut Brockhaus das Verhältnis zwischen dem Produktionsergebnis und dem Produktionsaufwand. Es ist allerdings nicht einfach, diese Definition auf die Produktivität bei der Erstellung von Softwareprodukten zu übertragen, denn weder lassen sich das Ergebnis noch der Aufwand hier leicht messen und in Zahlen ausdrücken. Das Produktionsergebnis der Softwareentwicklung ist ein Programm. Eine überzeugende Maßeinheit für Programme gibt es aber bis jetzt noch nicht. Verhältnismäßig einfach läßt sich die Anzahl der Instruktionen messen, die ein Programm enthält. In Abhängigkeit von der verwendeten Programmiertechnik und der Geschicklichkeit des Programmierers kann jedoch ein und dieselbe Programmieraufgabe zu Programmen führen, die sich um mehr als den Faktor 10 in der Anzahl ihrer Instruktionen unterscheiden. Die Instruktionsanzahl berücksichtigt auch nicht die Schwierigkeit der zu lösenden Programmieraufgabe. Programme gleichen Umfangs werden gleich bewertet, auch wenn sie so unterschiedlich schwierige Aufgaben lösen wie das Auflisten und Formatieren einer Kartei oder die Simulation der Auslastung eines Telefonnetzes.
Eine vernünftige Maßeinheit für Programme sollte sich an dem Nutzen orientieren, den der Benutzer von dem Programm hat, oder an dem Umfang des Problems oder der Aufgabe, die das Programm löst. Solche "Nutzen-Einheiten" oder "Lösungs-Einheiten" gibt es aber noch nicht.
Der Produktionsaufwand für die Ersterstellung eines bestimmten Programms ist relativ leicht zu messen. Die Frage ist jedoch, wie weit dabei die Kosten für nachfolgende Korrekturen und Ergänzungen berücksichtigt werden. Ein bei der Ersterstellung preiswertes Programm kann letzten Endes doch teuer sein, weil aufgrund seiner Struktur nachfolgende Ergänzungen aufwendig sind.
Obwohl es also zur Zeit noch nicht möglich ist, die Softwareproduktivität exakt zu messen, ist man sich doch darüber einig das sie verbessert werden muß. Diese Forderung wird besonders verständlich, wenn man sich als nochmals daran erinnert, daß sich in den letzten 20 Jahren die Kosten für die Ausführung von Programmen auf einem Rechner um den Faktor 1000 reduziert haben. Dadurch könnten heute sehr viel mehr Aufgaben wirtschaftlich von einer Datenverarbeitungsanlage ausgeführt werden, wenn diese Aufgaben auch programmiert wären. Die Programmierproduktivität hat sich jedoch in den letzten Jahren nicht in dem gleichen Umfang verbessert wie die Hardware und konnte deshalb mit den viel schneller wachsenden Programmieraufgaben nicht Schritt halten. Es entstand ein ständig wachsender Rückstau an möglichen Anwendungs- und Einsatzmöglichkeiten, eine Situation, die sowohl für die Hersteller als auch für die Anwender von Datenverarbeitungsanlagen sehr unbefriedigend ist. Deshalb ergibt sich als zweite wichtige Entwicklungsaufgabe das Schließen der Schere "Rechnerproduktivität - Programmierproduktivität", das heißt die Erhöhung der Produktivität bei der Erstellung von Programmen (Abbildung).
Hilfen von zwei Seiten
Man geht diese Aufgabe von zwei Seiten an. Einmal werden in der System-software Funktionen angeboten, die ein produktiveres Arbeiten mit dem System erlauben. Zum anderen wurden und werden von Software-Herstellern und von Hochschulen Methoden und Hilfsmittel entwickelt, die den Entwurfs- und Programmierprozeß zunehmend rationalisieren.
Die Erhöhung der Programmierproduktivität verlangt daß die Systemsoftware Aufgaben übernimmt, die sonst der Anwendungsprogrammierer oder der Endbenutzer hätte "von Hand" durchführen müssen. Dadurch wächst der Umfang der Systemprogramme, und es besteht die Gefahr, daß Übersichtlichkeit und Erlernbarkeit darunter leiden. Im Extremfall kann das dazu führen, daß man auf einem System zwar sehr produktiv programmieren kann, wenn man alle Funktionen und Regeln beherrscht, daß es aber für den Durchschnittsbenutzer nicht mehr möglich ist, diese Funktionen und Regeln zu erlernen. Dieser Weg zu einer höheren Produktivität verbietet sich verständlicherweise. Der ständig wachsende Benutzerkreis bringt immer mehr Menschen, die aufgrund ihrer Ausbildung und ihrer Aufgabe nichts über die Programmierung wissen, die also weit davon entfernt sind, Softwareexperten zu sein, mit der Software in Berührung. Deshalb ist es die dritte wichtige Aufgabe der Softwareentwicklung, der Tendenz, immer komplexere und kompliziertere Systeme zu entwickeln, rechtzeitig entgegenzuwirken. Dabei ist zwischen interner und externer Komplexität zu unterscheiden.
Interne und externe Komplexität
Die interne Komplexität betrifft die Innenstruktur des Systems, also primär der Systemprogramme. Diese Struktur wird mit steigender Leistungsfähigkeit der System komplizierter. Der Benutzer ist allerdings nur indirekt davon betroffen, er muß diese Struktur nicht verstehen. Die Systeme selbst werden aber in ihrem Bedarf an Speicherplatz, Maschinenzeit etc. aufwendiger.
Die externe Komplexität dagegen ist die Komplexität der Funktionen, mit denen der Endbenutzer arbeiten muß. Sie kann durch mindestens drei Methoden reduziert werden:
- Man sollte möglichst die Funktionen anbieten, die der Endbenutzer benötigt. Wenn man jemandem, der eigentlich einen Schraubenzieher braucht, eine Beißzange liefert, so kann er zwar die meisten Schrauben anziehen und lösen, aber doch nicht so bequem wie mit einem Schraubenzieher. Man muß deshalb die Anforderungen des Benutzers genau erkennen und durch einen sorgfältigen Planungs- und Entwicklungsprozeß dafür sorgen, daß das entwickelte Produkt diesen Anforderungen entspricht.
- Mit wachsendem Benutzerkreis steigt die Anzahl der geforderten und im System verwirklichten Funktionen. Wenn man jedem Benutzer diesen großen Gesamtvorrat an Funktionen anbietet, muß er sich zunächst mit allen Funktionen vertraut machen, um dann schließlich herauszufinden, daß für seine Aufgaben nur ein Bruchteil davon nötig ist. Diesen unnötigen Lernaufwand kann man vermeiden oder wenigstens reduzieren durch Spezialsysteme, die nur eine Untermenge der Gesamtfunktionen des Universalsystems enthalten, aber mit dieser Untermenge genau den Anforderungen bestimmter Benutzergruppen entsprechen.
Solche Spezialsysteme sind keine neuen Betriebssysteme; sie sind als Untermengen in einem Universalsystem enthalten. Der Benutzer kann aus einem solchen Spezialsystem in erweiterte Anwendungsbereiche hineinwachsen, indem er zusätzliche Funktionen aus dem Universalsystem übernimmt, ohne dabei seine bestehenden Anwendungen umstellen zu müssen.
Bei solchen Spezialsystemen ist es auch möglich, die Schnittstelle Betriebssystem/Anwendungsprogramm sehr weit in Richtung Endbenutzer zu verschieben und dem Benutzer ein System zu liefern, das ohne oder mit nur sehr geringem Aufwand an Anwendungsprogrammierung einsatzfähig ist.
- Die verteilte Datenverarbeitung erlaubt es, das Konzept "Spezialsysteme" noch weiterzuführen und auch dort einzusetzen, wo große Benutzergruppen bis heute mit einem zentralen und deshalb sehr universellen Supersystem arbeiten mußten. Solche Gruppen können jetzt mit kleinen spezialisierten und deshalb einfacheren Systemen arbeiten. Der Informationsaustausch zwischen den Untersystemen wird durch die im Gesamtsystem angebotenen Funktionen für verteilte Datenverarbeitung möglich.
* Helmut Lamparter ist seit 1977 Leiter des IBM-Programmentwicklungszentrums in Böblingen