Manfred Domke, Diplom-Mathematiker, GMD*

Die Hersteller großer Softwaresysteme, wie zum Beispiel von Informationssystemen, ist ein interdisziplinäres Unternehmen. Wenn mehrere Gruppen mit unterschiedlichen Einstellungen, Werten, Rollen, Interessen, Kenntnissen und Zielen an der Herstellung eines Softwareproduktes zusammenarbeiten, ist eine gut funktionierende Kommunikation das Wichtigste am gesamten Produktionsprozeß. Den kommunikativen Handlungen im Softwareprozeß und der Herstellung des Zusammenhangs zwischen den Arbeitsplätzen aller Beteiligter durch Informationstechnik wurde bisher jedoch zuwenig Aufmerksamkeit geschenkt.

Betrachtet werden hier Prozesse zur Konstruktion und Rekonstruktion von Informationssystemen, die Organisationen als Kommunikations- und Informationsinfrastruktur dienen. Charakteristisch für derartige Zielsysteme ist, daß sie Gesamtlösungen, Einzelprodukte (keine Standardprodukte) und verteilte Systeme sind, an deren Entwicklung und Anpassung eine Reihe von Interessen- und Fachgruppen kooperativ beteiligt sind. Charakteristisch ist auch, daß hier Informationsprozesse, die zur Zeit noch nicht richtig verstanden werden, mit Informationstechnik unterstützt werden sollen.

Verhandlungen sind nützlich und notwendig

Die folgenden Argumente sollen dazu beitragen, Verhandlungen und Abstimmungen als nützliche und notwendige Kommunikationsformen im Softwareproduktionsprozeß zu sehen. Die Argumentation mündet in einen Ansatz für ein kommunikationsorientiertes Modell der Softwareproduktion.

Soziales Verhalten ist ausgerichtet an persönlichen Werten, Einstellungen, Interessen sowie an Erwartungen und Vorstellungen anderer. Es basiert ebenso auf dem wirklichen oder angenommenen Verhalten der anderen wie auf allgemein akzeptierten Spielregeln (Normen). Individuen und Gruppen streben nach Verwirklichung ihrer Ziele und Durchsetzung ihrer Interessen. Interessengegensätze und Zielkonflikte können dann durch Diskussion, Verhandlungen, Abstimmungen und Vereinbarungen aufgelöst werden, wenn davon auszugehen ist, daß eine gemeinsame Lösung erwartet wird und diese Lösung von gemeinsamem Vorteil ist.

Kommunikationsprobleme treten überall da auf, wo die sachlichen und sozialen Aspekte nicht verträglich sind. Beiträge einer Gruppe A, die sachlich in Ordnung sind, werden zum Beispiel von einer Gruppe B abgelehnt, wenn sich die Werte und Interessen von A und B wesentlich unterscheiden. Total unterschiedliche Werte und Interessen machen eine Kommunikation unmöglich.

Man kann einwenden, daß Softwareproduktion weniger mit Soziologie und Politik, sondern mehr mit Mathematik gemeinsam hat. De Millo, Lipton und Perlis behaupten jedoch in "Social Processes and Proofs of Theorems and Programs", daß das Anfertigen und Validieren mathematischer Beweise letztendlich ein sozialer Prozeß sei. Beweise werden nämlich vom Verfasser nicht einfach formal korrekt hingeschrieben, sondern sie werden in Seminaren vorgestellt, diskutiert, begutachtet, vereinfacht, überarbeitet und schließlich aufgrund dieses sozialen Prozesses als gültig akzeptiert. Die Autoren folgern daraus, daß eine Konstruktion korrekter Programme aber nur über solche sozialen Prozesse zu erreichen ist.

Wenn man akzeptiert, daß Softwareproduktionsprozesse auch soziale und politische Prozesse sind, wird man die heutigen Probleme der Kommunikation und Kooperation besser verstehen können.

Bei der Entwicklung von Informationssystemen ist man ständig mit schlecht definierten Situationen konfrontiert.

" ... we can say that in physical sciences we are primarily interested in the existing and in computer science we are primarily concerned with that which is possible, with what can exist." **Unsicherheiten bezüglich Information und Verhalten der Umgebung, Fehler und Unvollständigkeiten in den zugehörigen Softwareproduktionsprozessen sind somit nicht verwunderlich.

In Softwareproduktionsprozessen erarbeiten Individuen und Gruppen mit unvollständigem Wissen für inkonsistente und unvollständige Zielsetzungen fehlerhafte und unvollständige Teilergebnisse. Die Forderung, korrekte und vollständige Resultate zu produzieren, ist so gesehen eine ziemlich unrealistische. Viel realistischer erscheint die Erwartung, daß zunächst widersprüchliche, fehlerhafte, unvollständige Ziele, Pläne, Lösungen produziert werden, die dann zu Abstimmungszwecken untereinander ausgetauscht werden sollten. Wenn sich Reviews und Inspections auf der Code-Ebene bewährt haben, sollten sie sich auch auf der Ziel- und Aktionsplanebene bewähren.

Rechner übernehmen mehr und mehr Tätigkeiten, die bisher weitgehend Personen vorbehalten waren. Programmierung läßt sich daher auffassen als Konstruktion von Softwareinstanzen und Delegierung von Aufgaben an diese Softwareinstanzen. Bei der Übertragung von Aufgaben von einer personalen auf eine nichtpersonale Instanz durch Programmierung wollen wir zunächst nur von einer teilweisen Delegierung sprechen, weil sich Verantwortung nicht auf Informationstechnik übertragen läßt. Führungsverantwortung und Handlungsverantwortung verbleiben bei der delegierenden Instanz. Sie kann zur Rechenschaft gezogen werden, wenn bei der Erledigung von Aufgaben durch den Rechner Fehler auftreten, die auf einen Verstoß gegen die "Delegationsregeln" zurückzuführen sind. Während Rechner im Auftrag und nach Plan handeln, handeln und entscheiden personale Instanzen im delgierten Aufgabenbereich im Rahmen ihrer Handlungsspielräume.

Spezielle Instanz

Es ist zweckmäßig, die Aufgabe Softwareproduktion auf eine spezielle Instanz mit der dafür erforderlichen Qualifikation zu übertragen. Dies führt zu einer Aufteilung von Verantwortung sowohl für die Aufgabenerledigung als auch für die Softwareproduktion.

Die Führungsverantwortung für die Aufgabe Softwareproduktion trägt die Instanz, die auf die Projektgruppe "Softwareproduzenten" delegiert. Die Handlungsverantwortung für die Softwareproduktion tragen die Softwareproduzenten.

So gesehen enthält Softwareproduktion immer eine Delegierung von Aufgaben an personale und nichtpersonale Instanzen.

Fortsetzung folgt.

* Manfred Domke, Institut für Informationssysteme und Grafische Datenverarbeitung, GMD mbH, Bonn

* * J. F. Traub (ed), "Quo Vadimus: Computer Science in a Decade"; CACM, Vol. 24, No. 6, June 1981, pp. 351 - 369