Kein vernünftiger Mensch, so scheint es, diskutiert noch ernsthaft, ob Software-Engineering zum Einsatz kommen soll oder nicht - es soll Erörtert wird nur noch, welche Produkte aus dem reichlich vorhandenen Angebot genutzt werden könnten und wo ihre spezifischen Vor- und Nachteile liegen. Aber gibt es überhaupt Produkte, die so ohne weiteres auf vorhandene Organisationen und Abläufe aufgesteckt werden können?

Es ist die allgemein gestellte Aufgabe, das wahrhaft überschäumende Angebot an Produkten zu ordnen und zu gewichten. Es gilt, wieder zwischen Informationen zum gegenwärtigen Stand der Softwaretechnologie einerseits und Werbungsaussagen einer produktions- und seminarfreudigen Branche andererseits zu unterscheiden.

Wohlgemerkt, es geht nicht darum, innovative Ansätze kurzzuschließen. Im Gegenteil, nur wenn es gelingt, den bereits erkennbaren Prozeß der Verunsicherung und Verwirrung bei den potentiellen Anwendern zu stoppen, wird es möglich sein, Software-technologische Produkte so zum Einsatz zu bringen, daß Obwohl die Erzeuger als auch die Benutzer auf ihre Kosten kommen.

Schon ein flüchtiger Blick auf das Angebot an Methoden und Werkzeugen zeigt, daß zwischen mehreren Arten der Unterstützung zu unterscheiden ist. Dem ursprünglichen Ansatz des Software-Engineering am nächsten kommen die Werkzeuge zur Unterstützung der unmittelbaren Programmierung und der Tests. Hierzu gehören Struktogrammgeneratoren, diverse Editoren, Strukturkontrollmechanismen und Testdatengeneratoren.

Darüber hinaus unterstützen eine Reihe von Methoden und zugehörigen Werkzeugen bei den Analyse- und Definitionsphasen. Schließlich gibt es die Gruppe der Werkzeuge zur Unterstützung des Projektmanagements, wie zum Beispiel Planungs- und Terminierungsinstrumente.

Es ist ganz offensichtlich so, daß es Methoden und Werkzeuge gibt, deren Ziel die Sicherung der Qualität des zu erstellen Produkts ist, während andere vornehmlich die wirtschaftliche und termingerechte Abwicklung unterstützen. Daß Projektmanager und -realisierer unterschiedlicher Hilfsmittel und Tools bedürfen, ist hinlänglich bekannt wenn auch die Software-Engineering-Literatur das Thema Projektmanagement manchmal arg kurz abhandelt.

Programmier-Eigenbrötler als Hemmschuh

Bei der praktischen Anwendung der Erkenntnisse und insbesondere bei der Einführung von Methoden und Tools ergibt sich aber unter Umständen daraus eine ganze Kette von Problemen. Solange die ohnehin als Eigenbrötler apostrophierten Programmierer ihren ureigenen Bereich mit Hilfsmitteln versehen, die nur sie allein verstehen und nutzen können gibt es höchstens die Frage der Zugänglichkeit der Teamkollegen zu diesen Hilfen. (Oft als Einweihung eines bis dato Unkundigen in einen "Spezialistenzirkel".)

Aber schon wenn das Projektmanagement beginnt, plötzlich bestimmte Unterlagen anzufordern weil ein neues Werkzeug im Planungsbereich auf diese Informationen angewiesen ist, kommt es zur Unruhe im zuweilen auch überraschten Team. Bis dahin scheinbar nicht benötigte Informationen sollen auf einmal nicht nur vorhanden, sondern sogar in formalisierter Form abgeliefert werden. Die Manager ihrerseits sind verärgert, weil für sie diese Daten "selbstverständlich" vorhanden sind.

Nicht nur Insider werden sich in solchen Situationen an eigene Erlebnisse erinnert fühlen. Jeder Bereich, der mit dem Phänomen der EDV-Unterstützung konfrontiert wird, reagiert in dieser oder ähnlicher Weise. Es wiederholt sich der Umstand, daß Instrumente und Informationen des neuen Arbeitsmittels sowohl von den Managern als auch den Realisierern erwartet werden. Genau diesem Anspruch kann richtig angewandte Softwaretechnologie auch durchaus gerecht werden. Voraussetzung dazu ist aber die Einbettung in eine geeignete Betriebsorganisation.

Softwaretechnologie ist letzten Endes der Einsatz informationsverarbeitender Methoden und Werkzeuge. Deshalb muß die informationstechnische Struktur des zu unterstützenden Bereichs vor Einführung dieser Hilfsmittel definiert werden. Bei Mißachtung dieses Umstands ist rationeller Einsatz der Tools oder Toolsysteme purer Zufall und zumindest mit einer sehr teuren Erfahrungsphase verbunden.

Es bestehen also offensichtlich Parallelen bei der Einführung allgemeiner EDV-gestützter Verfahren, neuer Softwaretechnologien und neuer Kommunikationstechniken.

Mindestens für den ersten Punkt gibt es heute einen breiten Erfahrungsbereich, auf den zurückgegriffen werden kann. Die Auswahlkriterien für Tools und Toolsysteme müssen sich an den bereits vorhandenen Verfahren orientieren. Sind die Verfahren nicht definiert, also informeller Natur, sind größere Probleme bei der Einführung zu erwarten. Es besteht dann die Gefahr, daß entweder die Tools nicht auf die informelle Struktur passen und deshalb abgelehnt werden oder daß die Tools die Struktur unkontrolliert verändern. Diese Gefahr besteht natürlich auch dann, wenn die Struktur nur auf dem Papier vorhanden ist.

Zusammenfassend können folgende Thesen abgeleitet werden:

- Angewandte Softwaretechnologie dient zur Sicherung der Wirtschaftlichkeit und der Qualität.

- Angewandte Softwaretechnologie liefert Instrumente und Informationen für Manager und Realisierer.

- Ohne Einbettung in eine geeignete Betriebsorganisation ist der rationelle Nutzen Software-technologischer Ansätze nicht wahrscheinlich.

Welche Folgerungen sind für die an Softwaretechnologie Interessierten zu ziehen? Sicher ist die Gefahr nicht zu unterschätzen, daß Manager, mit Argumenten für Manager zum Software-Engineering "bekehrt", eine falsche Erwartungshaltung einnehmen; umgekehrt gilt dasselbe für die Realisierer. Aus welcher Richtung der Software-technologische Ansatz auch kommt, er darf die Tore zur Integration nicht verschließen!

Methoden und vor allem Tools müssen nicht nur in die bestehende Organisation eingepaßt werden (können!), sondern auch offen sein für den Anschluß an weitere Instrumente. Wer das nicht bedenkt, wird zwei verschiedene computergestützte Projektabwicklungsverfahren einführen: eins für das Management und eins für die Realisierer.

Eine schwierige Situation, zugegeben. Eins ist jedoch sicher, wer gar nichts tut, wird sich im kritischer und kostenbewußter reagierenden Markt nicht behaupten können - weder als eigenständiger Softwareproduzent, noch unter der nur scheinbar schützenden Decke eines Rechenzentrums.

Rainer Kniesche ist Mitarbeiter der Abteilung Software-Methodik der Nixdorf Computer AG, Paderborn.