Nicht selten versuchen DV-Anwender - nachdem ingenieursmäßige Entwicklungskonzepte als Folge der sogenannten Softwarekrise einen enormen Boom verzeichnen - die Fülle der angebotenen Methoden, auf einen Schlag einzuführen. Unterstützt durch eine Flut von Tagungen und Veranstaltungen, verleitet insbesondere die technische Innovation den Engineering-Newcomer leicht zu einem unüberlegten Einstieg in diese Ingenieursdisziplin. Der erwünschte Erfolg tritt nicht ein: Verwirrt arbeitet der User so weiter, wie er es gewohnt ist: es bleibt bei der "interessanten Informationsaufnahme". Die Konsequenz ist ein nicht angewendeter, verstaubender "Methodenberg".

Methoden wurden zu Beginn der Ära des Software-Engineering mit "Bleistift und Papier" - und sinnvoll - eingesetzt. Recht bald machten sich die SW-Strategen das Zielobjekt - den Rechner selbst - auch für diesen Zweck zum Gehilfen. Man entwickelte Tools zur Unterstützung der Engineering-Konzepte.

Softwarehäuser erkannten hierin bald einen Wachstumsmarkt. Der Anwender sieht sich heute mit einem breiten Angebot von Tools für das SW-Engineering konfrontiert. Aber nur richtige Auswahl und sinnvoller Einsatz verhelfen zu einer Optimierung der eigenen Software-Entwicklung.

Nur ganz wenige dieser angebotenen Werkzeuge sind geeignet, ohne methodisches Konzept und die entsprechende Anwendung dieser Methoden mit Nutzen eingesetzt zu werden. In den meisten Fällen ist der Einsatz eines Werkzeuges zudem noch an die Anwendung einer ganz bestimmten Methode gebunden.

Oft aber werden einige, manchmal viele dieser Tools für die gleiche Entwicklungsumgebung angeschafft, ohne daß an die dazu notwendigen Methoden gedacht wird. Es entsteht der "Tool-Zoo".

Ungenutzte Werkzeuge, noch mehr zu erlernende Schnittstellen, umständliche Übergänge von einem Werkzeug zum anderen bis zur unproduktiven Spielerei" enthusiastischer Entwickler mit den Werkzeugen sind die Folge.

Nur der konzipierte und koordinierte Einsatz von Methoden und entsprechenden Tools bringt den optimalen Erfolg. Nur wenige Tools mit entsprechender Breitenwirkung können sinnvoll auch ohne Festlegung der Methoden eingesetzt werden. Diese können dann auch helfen, den Methodeneinsatz vorzubereiten.

Jedoch wird häufig mit einem sinnvollen Werkzeug, einer nutzbringenden Methode oder einer vernünftigen Sprache in der falschen Situation operiert.

Methoden nicht überfordern

Software-Entwicklung ist der Entstehungs- und Reifeprozeß von einer Anwendungsidee zur realisierten Anwendung. Sie ist in der digitalen Welt des Rechners - für den Benutzer verborgen - realisiert. Die optimale Organisation des Softwareprojektes berücksichtigt die Unterschiedlichkeit dieser beiden unter Umständen sich extrem fremden Welten in der Auswahl der Methoden und Werkzeuge.

Eine - für ihren speziellen Zweck sinnvolle und zielführende - Methode darf nicht überfordert werden. Nicht die Auswahl und Anwendung einer Methode ist das Allheilmittel.

Die Durchgängigkeit der Technologie muß erreicht werden durch eine abgestimmte Auswahl von durchaus verschiedenen, auf das entsprechende Teilziel der Projektphase ausgerichteten Methoden zusammen mit definierten Übergängen und - im Idealfall automatisierten - Umsetzungsprozessen.

Phasenmodell in Verruf

Phasenmodelle sind bei einzelnen Mitgliedern der Software-Engineering-Szene etwas in Verruf geraten. Dennoch sind sie für die Abwicklung und Kontrolle von DV-Projekten in kommerzieller und industrieller Umgebung immer noch eine unabdingbare Voraussetzung.

Dabei hängt ihr Werk nicht von der sklavischen Trennung der einzelnen Phasen oder gar dem Verbot der "Rückkehr" in schon abgeschlossene Phasen ab. Im letzten Fall liegt der Wert des Phasenmodells unter anderem darin, zu wissen und zu erkennen, daß man zum Beispiel einen Schritt zurückmacht und eine Korrektur vornimmt oder neue Erkenntnisse einbringt.

In jeder Phase eines Phasenmodells sind bestimmte Tätigkeiten oder Aktivitäten durchzuführen. Das ist richtig so. Solche Tätigkeiten werden benannt und definiert, oft aber nicht durch Ergebnisse dieser Tätigkeit "fixiert".

Damit verliert das Phasenmodell einen seiner entscheidenden Vorteile: Die Tätigkeiten sind nicht mehr kontrollierbar. Die Aussage des Entwicklers, er habe sein Modul schon fast fertig, bleibt ohne Aussagekraft.

Ein weiterer Effekt der reinen Definition von Tätigkeiten in einem Phasenmodell ist eine aufkommende und sehr schnell wachsende Unsicherheit, was denn konkret hinter dieser Tätigkeit "steckt". Schnell kann man ja auch wieder das Gewohnte unter diesem neuen Namen machen. Der gewünschte Effekt bleibt aus.

Fixiertes Ergebnis definieren

Die reine Definition von Tätigkeiten oder Aktivitäten verfehlt ihr Ziel. Sie muß gepaart werden mit der Definition eines fixierten Ergebnisses dieser Tätigkeit. Form des Ergebnisses und die Erwartungen an dasselbe sind in einem Produktmuster vorzugeben. Das Produktmuster leitet Entwickler und Designer bei ihren Tätigkeiten. Es gibt ihnen die Möglichkeit, den Stand ihrer Tätigkeit korrekt zu beurteilen.

Selbst wenn die Methoden und die dazugehörigen Werkzeuge "stimmen", kann die fehlende Akzeptanz den Erfolg zunichte machen. Häufig wird unter dem Titel "Methodeneinführung" die Entwicklungsumgebung komplett - einschließlich der eingeführten Begriffe - umgestellt. Damit werden dann gleichzeitig gewohnte Dinge durch neue ersetzt.

Positive Methoden- und Verfahrensansätze werden verschüttet, deren "Einsatz" keineswegs besser erscheint. Naturgemäß werden durch Akzeptanzprobleme, die bei jeder Umstellung und Neueinführung aufkommen, verstärkt.

Dieses Problem tritt insbesondere dann auf, wenn sich der Anwender ein "Methoden-Korsett" mit passenden Werkzeugen "von der Stange" aufzwingen läßt.

Positive Ansätze müssen. vor einer Neueinführung in einer Analyse berücksichtigt und in die Gestaltung und Auswahl der Methoden sowie der Einführungsstrategie mit einbezogen werden.

Dr. Hans-Martin Meyer ist Leiter der. Abteilung

Technologieberatung und Informationssysteme bei der Softlab GmbH, München.