Manfred Domke, Diplom-Mathematiker, GMD*, Teil 2
Software wird für ganz bestimmte Zwecke konstruiert. Softwarekonstruktionsaufgaben an Programmierer und Tätigkeiten an Rechner müssen so delegiert werden, daß die ursprünglich angestrebten Zwecke nicht verändert oder sogar ins Gegenteil verkehrt werden. Die bisher erreichte Zuverlässigkeit und der ursprüngliche Systemzusammenhang müssen erhalten bleiben.
Adäquate und formal präzisierte Regeln zur Delegierung von Aufgaben in Zusammenhang mit der Produktion von Software fehlen jedoch.
Delegierung ist ein ständiger Prozeß
Unter Delegierung ist ein ständig ablaufender kommunikativer Prozeß zu verstehen, nicht etwa, was nur einmal geschieht. Der Kommunikation zwischen den betroffenen Instanzen ist eine hohe Bedeutung beizumessen. Zwischen den Beteiligten ist ein weitgehendes Einverständnis bezüglich Aufgabengebiet, Kompetenzen und Aufgabenerfüllung zu erreichen. Einerseits kommt es durch Delegation zu einer Entlastung der Kommunikationskanäle, weil die Entscheidungen da getroffen werden, wo die entsprechende Qualifikation und Information verfügbar ist. Andererseits erfordert die Koordination der Entscheidungen und erbrachten Leistungen ein gut funktionierendes Informationssystem.
Ein Grundproblem bei der Softwareproduktion ist die Zerlegung eines Problems in überschaubare Teile.
Die Wahl der Zerlegung ist abhängig vom Blickwinkel und Wissen, von der Rolle, den Werten und Instanzen des Zerlegers, vom anvisierten Zweck. Durch eine einzige Hierarchie von Systemabstraktionen können nicht alle relevanten Aspekte verschiedener Interessengruppen dargestellt werden.
Wenn verschiedene Instanzen während der gesamten Entwicklungsdauer unterschiedliche Aspekte des Konstruktionsprozesses oder Zielsystems betrachten, sind auch ihre Bedingungen, Terminologien und Schlußfolgerungen verschieden. Eine wesentliche Schwierigkeit im Softwareproduktionsprozeß liegt in der Integration der unterschiedlichen Sichten der Beteiligten. Verschiedene Sichten integrieren heißt, Terminologie, Begriffe, Objekte, Operationen, Argumente, logische Schlußweisen der verschiedenen Sichten zueinander in Beziehung zu setzen und verträglich zu machen. Der Konstruktionsprozeß wird so auch zum Abstimmungsprozeß.
Das Phasenmodell verdeckt
Das traditionelle Phasenmodell verdeckt vollkommen den interdisziplinären Charakter der Softwareproduktion sowie die schlecht definierten Situationen der am Konstruktionsprozeß Beteiligten. Das Phasenmodell als Denkmodell der Softwareingenieure verhindert damit, daß die Probleme der Kommunikation im Softwareproduktionsprozeß voll erkannt werden.
Charakteristisch für das herkömmliche Phasenmodell sind
a) sequentielle Durchführung von Aktivitäten, die abgesehen von den Rückkopplungen an bestimmte seitliche Phasen gekoppelt sind,
b) die Entwicklung einer Hierarchie von Zielsystemabstraktionen mit einer A-priori-Topdown-Ordnung von Entscheidungen.
In einem polyhierarchischen Modell der Softwareproduktion hat der Raum der Entwurfsentscheidungen mehr Struktur als in einem monohierarchischen, denn Entscheidungen werden nun nicht nur unterschiedlichen Abstraktionsebenen, sondern auch unterschiedlichen Sichten zugeordnet. Bei monohierarchischen Entwurfsverfahren werden Entscheidungen zu unterschiedlichen Aspekten vermischt, so daß der Entscheidungsprozeß komplexer erscheint, als er in Wirklichkeit ist.
Die Produktion großer Softwaresysteme ist ein interdisziplinäres Unternehmen. Eine Lösung der damit zusammenhängenden Probleme erfordert ein Umdenken bezüglich der Rollte des Rechners im Softwareproduktionsprozeß. Bei der Lösung der schwierigen Probleme im Konstruktionsprozeß können personale Instanzen eher von anderen beteiligten personalen Instanzen Hilfe und Unterstützung erwarten als vom Rechner. Statt den Rechner als Kommunikationspartner anzusehen, sollte er als Kommunikationsmedium, das zwischen den Partnern im Softwareproduktionsprozeß steht, begriffen werden. Weil der Nutzen von programmierten Werkzeugen und Techniken nur beschränkt sein kann, sollte bei der Entwicklung von Softwareproduktionsumgebungen primär als Ziel angestrebt werden, die Fähigkeit der am Softwareproduktionsprozeß beteiligten Menschen, insbesondere die der Anwender, Benutzer und sonstigen Betroffenen, besser zu nutzen.
Wenn man den Softwareproduktionsprozeß als Verhandlungs- und Abstimmungsprozeß auffaßt, so wird ein Schritt in die beschriebene Richtung getan. Voraussetzung für die Entwicklung und den Einsatz einer Informationstechnik zur adäquaten Unterstützung von Verhandlungs- und Abstimmungsprozessen ist jedoch ein allgemein akzeptiertes kommunikations-orientiertes Modell der Softwareproduktion.
* Manfred Domke, Institut für Informationssysteme und Grafische Datenverarbeitung, GMD mbH, Bonn
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. (Teil 1)