Das Wissen über Methoden ist diffus. Strukturierte Analyse oder der Einsatz von CASE-Tools, so Theodor Rötzheim*, sind allenfalls Teil einer Methode. Der Autor beschreibt eine in der Praxis unternehmensweit eingesetzte Methode. Schlüsselfaktoren sind Projektmanagement, Aktivitätenplanung, Werkzeuge und Technik sowie Rollen und Ergebnisse.

Die Verantwortlichen in großen deutschen Unternehmen sind sich oft voll bewußt, daß der Einsatz von CASE-Werkzeugen eine Notwendigkeit für sie darstellt. Doch ganz anders als in Amerika, wo nach dem Grundsatz "try and buy" alles, was neu ist, ausprobiert wird, sind deutsche Unternehmen ausgesprochen zurückhaltend beim Einsatz dieser Werkzeuge. Viele können sich allenfalls zu einer Einplatz-Testinstallation durchringen. Aus diesen isolierten Arbeitsplätzen sollen dann Rückschlüsse auf Prozesse gruppendynamischer Art getroffen werden.

Anwender scheuen die Methodeneinführung

Mittlerweile sind die Eigenschaften dieser Werkzeuge bekannt, doch Anwender können sich immer noch nicht durchringen, die Programmentwicklung auf breiter Basis umzustellen. Der Hauptgrund hierfür liegt in der Tatsache, daß neue Systeme im CASE-Bereich eine neue Vorgehensweise mit sich bringen. "Das haben wir noch nie so gemacht, und keiner weiß, ob es außer Kosten überhaupt etwas bringt", so die häufige Aussage von Anwendern.

Die Betroffenen spüren, daß sich etwas sehr Wesentliches an der Ablaufform ändern soll - und das bedeutet, weit mehr zu verändern, als nur ein neues Werkzeug einzusetzen. In der Tat verhält es sich so, daß auch methodenfreie CASE-Tools immer eine Spur von methodischer Führung beinhalten, und sei es nur, daß sie grundsätzlich top-down vorgehen. Der Einsatz von CASE-Werkzeugen verändert das Procedere in der Anwendungsentwicklung - deshalb sollte man das ganze Problem in erster Linie von der methodischen Seite sehen.

CASE ist im Grunde nichts weiter als das "Computer Aided" vom tagtäglichen Software-Engineering, also eine rechnerunterstützte Vorgehensweise bei der ingenieurmäßigen Anwendungsentwicklung. Der Begriff Software-Engineering ist durchaus nicht übertrieben, wie in anderen Berufen wird ingenieurmäßig geplant und ausgeführt, was die Programmierabteilungen liefern. Die Qualität des Produzierten ist stark abhängig von der Qualität der ingenieurmäßigen Ausbildung.

Gutes Software-Engineering heißt, die Komplexität von Anwendungssystemen in den Griff zu nehmen und analytisch zu zergliedern. Dabei muß man wissen, welcher Schritt nach dem nächsten folgen wird und mit welchen Techniken eine detailgenaue und anforderungsnahe Beschreibung für ein Anwendungssystem entwickelt werden kann.

Dieses Wissen ist nichts anderes als Methode: Methodenwissen ist die Fähigkeit, einen komplizierten Ablauf so zu beschreiben und zu zergliedern, daß er zielsicher nachvollzogen werden kann und damit eine Gewähr bietet, auch schwer überschaubare Projekte zu meistern. CASE ist letztlich ein Mittel der Methode. Es ist ein Werkzeug mit dem ich einige Schritte dieses Ablaufes technisch unterstützen kann.

Stellt sich also die Frage, wann denn überhaupt die Notwendigkeit besteht, eine Methode einzuführen. Der Methodeneinsatz lohnt sich grundsätzlich immer dann, wenn es darum geht, besonders komplexe Probleme zu lösen. Komplexität kann einerseits dadurch bedingt sein, daß ein Projekt sehr umfangreich ist, andererseits kann es vorkommen, daß besondere Systembedingungen erfüllt werden müssen, die nicht "aufeinander passen".

Komplexe Projekte laufen in der Regel über einen längeren Zeitraum und nehmen umfangreiche Personalressourcen in Anspruch. Allein diese beiden Kriterien machen schon eine präzisere Planung notwendig. Oft sind Projekte auch von besonders erfolgskritischer Bedeutung; je mehr von diesen Kriterien zutreffen, desto sicherer ist, daß der Einsatz einer Methode von meßbarem Nutzen sein wird.

Mit dieser Erkenntnis gerät der Anwender jedoch vom Regen in die Traufe, denn, wenn schon der CASE-Einsatz problematisch ist, so ist es der Methodeneinsatz erst recht. Werden DV-Manager gefragt, ob sie Methoden einsetzen, so wird häufig geantwortet, "strukturierte Programmierung ist durchaus ein Standard im Hause" oder "wir haben uns ein eigenes Ablaufschema vorgegeben". Im Prinzip ist diese Aussage richtig, denn jeder, der ein Projekt bereits einmal erfolgreich beendet hat, muß irgendeine Vorgehensweise gewählt haben. Die Frage ist nur, wie gut und effektiv er damit gearbeitet hat.

In der Tat ist es so, daß das Wissen über das, was Methoden beinhalten, sehr diffus ist. Hier gilt es Pionierarbeit zu leisten. Was ist eigentlich eine Methode? Es gibt sie für wenig Geld zu kaufen, in den Universitätsbüchereien als mehr oder weniger wissenschaftliche Abhandlung in Form von Büchern oder als ungebundenes Ringbuchwerk bei Software-Engineering-Beratern für einen beträchtlichen Preis. Allein diese Diskrepanz muß verunsichern: Lohnt es sich wirklich, für eine Methode viel Geld auszugeben? Wo liegt der Vorteil, bei der teureren Variante? Ist der Preis überhaupt angemessen?

Wer bereits begonnen hat, für sich selbst eine Vorgehensweise zu entwickeln und zu standardisieren, hat sicher schnell gemerkt, daß diese Arbeit mit sehr viel Aufwand verbunden ist. Aufwand führt zu Kosten, und die summieren sich zu einer beträchtlichen Höhe. Schnell kommt der Anwender zu dem Schluß, daß er es für den Preis, der am Markt verlangt wird, nicht selber machen kann. Mit der Anschaffung allein ist es aber nicht getan. Der gleiche Preis ist ebenso für Training der Mitarbeiter und Unterstützung durch Berater anzusetzen.

Bevor ich erläuterte, welche Elemente im einzelnen zu einer Methode gehören, möchte ich das vorhandene Begriffs-Wirrwarr etwas lichten. Da gibt es zum einen das Wort Methodologie. Es bedeutet im Deutschen die "Lehre von Methoden" und ist allenfalls an Universitäten gefragt.

Hin und wieder wird das Wort Methodik verwendet. Dabei handelt es sich um eine besondere Spielart von Methode: das wissenschaftlich-analytische Vorgehen bei einer Untersuchung. Wer möchte, kann diesen Begriff auch für den Software-Engineering-Einsatz verwenden. Dann gibt es noch die sogenannte Vorgehensweise. Sie ist Bestandteil einer Methode; eine Methode kann verschiedene Vorgehensweisen enthalten, die sich wahlweise benutzen lassen. Methode selbst ist als das "planvolle Vorgehen" zu bezeichnen.

In der Software-Entwicklung sollen gut funktionierende Systeme erstellt werden. Eine Methode für das Software-Engineering muß also alles enthalten, was benötigt wird, um sauber geplante Systeme erstellen zu können. Aus dem Gedanken heraus wird ersichtlich, daß strukturierte Analyse oder der Einsatz von CASE-Techniken nur Teil einer Methode sein kann. Jedem, der an einem Projekt mitgearbeitet hat, ist sofort klar, daß für die erfolgreiche Durchführung noch andere Komponenten notwendig sind

Eine Methode muß ein Projekt in zeitlicher, fachlicher und organisatorischer Hinsicht unterstützen können und dabei finanzielle und unternehmerische Rahmenbedingungen erfüllen. Das gilt gleichermaßen für kleine wie für große Projekte. Doch sind kleine und große Projekte in ihrem Ablauf nicht identisch, also muß sich auch die Methode in ihrem Ablaufschema an die Größe eines Projektes anpassen lassen.

Wie diese Aufgaben in den Griff zu bekommen sind, will ich beispielhaft anhand der Methode "Stradis" darstellen. Diese Methode ist in kleinen und großen Softwareprojekten des Flugzeugbaus eingesetzt und dabei praxisnah entwickelt worden. Der Schritt vom Einsatz im eigenen Haus zum Vertrieb auf dem Markt liegt nahe, wenn das entwickelte Instrument qualitativ hochwertig ist. Um den Anforderungen der unterschiedlichsten Entwicklergruppen gerecht zu werden und, um sich wandelnden Bedingungen anzupassen, gibt es eine Benutzergruppe, die kritisch und konstruktiv die Vorgehensweisen beurteilt und sie gegebenenfalls erweitert oder reduziert

Die Methode baut auf fünf Säulen auf: Projektmanagement, Aktivitätenplanung, Werkzeuge und Techniken, Rollen und Ergebnisse. Das Projektmanagement dient dazu, ein Projekt zeitlich und organisatorisch in den Griff zu bekommen. Zur Unterstützung dieser Planung gibt es bereits eine ganze Reihe von PC-Werkzeugen, die beim Aufbau und der Fortführung eines Zeitplans helfen.

Projektmanagement kontrolliert den Verlauf

Die Methode gibt vor, wie die einzelnen Arbeiten einzuschätzen sind, wie die damit befaßten Personen eingeplant werden, wo die Meilensteine des Projektes plaziert werden und wie der "kritische Pfad" bestimmt wird. Das Projektmanagement bietet die Kontrolle über den Verlauf der Arbeit und läßt erkennen, wann ein Eingriff in den Ablauf notwendig wird.

Die eigentliche Entwicklungsarbeit im Projekt besteht aus einer Vielzahl verschiedener Aktivitäten, die in den Zeitplan eingeordnet werden. Welche Aktivitäten in welche Phasen einzuordnen sind und wie sie aufeinander folgen müssen, legt die Methode fest. Dabei handelt es sich im Grunde um die gleichen Aktivitäten, die auch von denen durchgeführt werden, die keinerlei Methode folgen.

Der große Unterschied liegt darin, daß ein klarer Leitfaden für Übersicht sorgt und die chaotischen Entwicklungen vermeidet, die dadurch entstehen, daß in frühen Phasen etwas vergessen wurde oder geändert werden mußte, oder daß notwendige Ergebnisse aus anderen Aktivitäten noch nicht vorliegen. Der Ablaufplan ist das Herzstück der Methode, hierin werden alle Komponenten integriert.

Strukturierte Analyse ist nur eine Technik

Die dritte Säule bilden die Techniken und Werkzeuge mit denen Planungs-, Analyse-, Design- und Implementierungsaufgaben beziehungsweise -aktivitäten realisiert werden. Das sind die häufig von Software-Engineering-Päpsten gelehrten - und häufig selbst als Methode bezeichneten - Techniken wie strukturierte Analyse oder strukturierte Analyse und Design.

Jede dieser Techniken hat ihre volle Berechtigung und bietet je nachdem wie das Projekt gelagert ist, Vorteile gegenüber den anderen. Diese Techniken werden von den CASE-Werkzeugen wie eingangs erwähnt unterstützt, das heißt, sie werden mit Hilfe dieser Werkzeuge ausgeführt. Das funktioniert genauso, wie auch das Projektmanagement (PM) durch die PM-Programme unterstützt wird. Das Tool allein zeigt noch nicht, wo es lang geht, erst die Methode sagt, wann was zum Einsatz kommen soll.

Die vierte Säule ist die Verteilung der Projektaufgaben und -verantwortlichkeiten, der sogenannten Rollen. Hier werden die einzelnen Projektgruppen definiert und die Gruppenverantwortlichen bestimmt. In großen Projekten sind für eine Rolle mehrere Personen vorgesehen, während in kleinen Projekten ein Einzelner mehrere Rollen übernimmt.

Die Rolle stellt eine organisatorische Gliederung dar, die die Hierarchie des Unternehmens nicht berührt. Sie wird nicht aufgebläht, bietet aber durchaus die Möglichkeit, Mitarbeiter durch Verantwortung zu motivieren. Ein ganz wichtiges Element ist hier, daß der Endbenutzer von vornherein mit in die Entwicklung einbezogen wird und ebenfalls eine Rolle übernimmt.

Die fünfte Säule der hier skizzierten Methode sind Planung, Definition und zielgerichtetes Erreichen von Ergebnissen, den sogenannten Deliverables. Der Begriff stammt aus dem Amerikanischen und bezeichnet Ergebnisse, die zu einem bestimmten Zeitpunkt abzuliefern sind (to deliver). Das können Teil- oder Zwischenergebnisse sein, oder die letztendlich fertigen Programme.

Methoden lassen sich ständig verbessern

Die Methode gibt ganz klare Anweisungen, welche Ergebnisse zu erreichen sind, welche Qualität und welchen Inhalt sie haben müssen und bis wann sie von wem vorzulegen sind, um mit anderen Teilergebnissen konsolidiert werden zu können. Häufig werden Ziele nicht erreicht, weil sie vorher gar nicht oder nur ungenau festgelegt wurden. Die präzise Erkennung und Definition des Ziels macht erst den Erfolg und den Nutzen des Projekts aus.

Ob eine Methode, wie auch immer sie geartet sei, zu besseren Ergebnissen in der Projektarbeit führt, hängt letztendlich weniger von ihren theoretisch durchdachten Funktionen als vielmehr von ihrer Umsetzung in die Praxis ab. Hier sind zwei Faktoren ausschlaggebend: Der methodische Leitfaden muß aus den wissenschaftlichen Grundlagen in praktische Arbeit umgesetzt werden und dabei auch die naturgemäß vorhandenen menschlichen Schwächen einbeziehen. Zum anderen sollten die involvierten Mitarbeiter aus ihren Erfahrungen lernen: Die Methode läßt sich durch diejenigen, die mit dieser neu entwickelten Methode arbeiten, durch Kritik und konstruktive Vorschläge erweitern, verbessern und verfeinern.

Eine Methode erfolgreich in ein Unternehmen einzuführen, ist nicht nur eine Frage ausreichender Finanzen. Erste Voraussetzung ist, daß selbst die oberste Führungsebene mit dem Einsatz der Methode einverstanden ist und sie voll und ganz unterstützt. Im zweiten Schritt folgt direkt nach der Anschaffung eine umfangreiche Schulung aller, die mit dieser Methode arbeiten sollen.

Die Ausbildung findet in mehreren Schritten statt, denn die Methode zur Steuerung komplexer Projekte ist selbst so komplex, daß ein Leitfaden für die Anwendung unerläßlich ist. Im dritten Schritt wird die als "Standard" angebotenen Methode zu einem für das eigene Unternehmen passenden Konzept zugeschnitten, das sich an Organisation und Unternehmenskultur anpaßt. Der vierte Schritt sieht vor, einen methodenerfahrenen Berater zum ersten Pilotprojekt hinzuzuziehen. Von ihm läßt sich der Anwender mit den Regeln vertraut machen. Außerdem kennt der Berater die menschlichen Störungen, die trotz aller Leitlinien auftreten können.

Ist die Methode erst einmal von den Mitarbeitern verinnerlicht, eröffnen sich ungeahnte Potentiale der Ressourceneinsparung und Qualitätsverbesserung. Die Projekte werden schneller und besser bewältigt und man kann sich Aufgaben zuwenden, an deren Realisierung man heute nicht zu denken wagt.

Der Beweis dafür ist erbracht, wenn die erste Arbeit termingerecht zur Zufriedenheit des Benutzers und darüber hinaus noch im Rahmen des genehmigten Budgets fertig wird.