Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Projektplanung und Softwarequalität/Komplexe Systeme erfordern neuartige Modellierungsmethoden

Reduzieren ist gut, aber beherrschen ist besser

27.08.1999
von Helmut Strohmeier* Projekte sollten höchstens sechs Monate dauern, sechs Mitarbeiter beschäftigen und 750000 Dollar kosten, damit sie den größtmöglichen Erfolg versprechen. Zu diesem Schluß kam die Standish Group bei ihren langjährigen Marktforschungen zum Thema Projekterfolg. Je weiter ein Projekt diese Größenordnungen überschreite, so die Analysten, um so mehr steige das Risiko des Fehlschlags.

Der Ratschlag ist gut. Doch was ist zu tun, wenn zwei Großbanken fusionieren, wenn eine große öffentliche Verwaltung erkennt, daß ihre komplette Software einer Neuentwicklung bedarf oder wenn ein internationaler Konzern europaweit eine integrierte Standardsoftware einführen will? Ein Projektteam mit sechs Personen wäre wohl über Generationen damit beschäftigt und käme trotzdem nie zum Ende, weil die zwangsläufigen Änderungen schon nach kurzer Zeit die personelle Kapazität aufgefressen hätten.

Wie also läßt sich eine Aufgabe bewältigen, die weit komplexer ist, als daß sie von sechs Personen in einem überschaubaren Zeitraum - sagen wir, innerhalb eines Jahres - bewältigt werden könnte? Eine Möglichkeit ist: das Team aufstocken und das Risiko einfach eingehen. Die andere besteht darin, nach den Gründen zu forschen, warum ab einer gewissen Größenordnung die Projekte unsicherer werden. Vielleicht ist die Beobachtung, daß das Risiko mit der Projektgröße überproportional wächst, ja kein Naturgesetz, sondern vielmehr ein Thema, über das in der Vergangenheit nicht ausgiebig genug nachgedacht wurde.

Betrachten Sie einmal vom obersten Stockwerk eines Hochhauses aus ein großes Werksgelände. Sehen Sie zu, wie Zehntausende von Menschen zwischen Kesseln, Kränen und emsig rollenden Gabelstaplern ihre Arbeit verrichten. Wenn Sie dann an die Projekte der Informationsverarbeitung denken, wird Sie möglicherweise eine gewisse Scham überkommen: Etablierte Systeme von weit größerer Komplexität sind beherrschbar, während der Prozeß zur Entwicklung und Einrichtung von vergleichsweise kleinen Systemen offensichtlich noch immer starkes Kopfzerbrechen bereitet.

Dabei liegen praktikable Methoden vor, mit denen sich Systeme vollständig und doch überschaubar abbilden lassen. Spätestens seit den Anfängen der Datenmodellierung - und mehr noch durch die objektorientierte Betrachtung - stellten wir fest, daß Überschaubarkeit erreichbar ist, wenn im Vordergrund Objekte statt Funktionen stehen.

Um komplexen Gebilden eine überschaubare Struktur zu verleihen, empfiehlt sich folgender Weg:

1. Identifzieren Sie die Objekte eines Betrachtungsgegenstands mit ihren Beziehungen.

2. Ermitteln Sie die Merkmale und Zustände der Objekte.

3. Beschreiben Sie die Nachrichten (Ergebnisse), die sich aus diesen Zuständen ergeben.

4. Binden Sie die Nachrichten in Prozesse ein.

Den Prozeß, mit dessen Hilfe das System entstehen soll, also das Projekt, strukturieren wir jedoch anders, nämlich entlang den Aktivitäten. Herkömmliche Projekt-Management-Tools ordnen die Aktivitäten (Teilprozesse) auf Basis der Netzplantechnik in eine logische Reihenfolge ein. Im Innern des Teilprozesses verbergen sich die Objekte, um die es eigentlich geht, ihre Zustände und die Ergebnisse, die erzeugt werden sollen.

Bisweilen werden Aktivitäten festgelegt, ohne daß zumindest definiert wäre, mit welchen Objekten sie sich beschäftigen. Die Aktivität "Anforderungen sammeln" sagt nichts darüber aus, zu welchen Objekten die Anforderungen gebraucht werden. Deshalb fällt die Beurteilung, ob das Ergebnis "Anforderungskatalog" komplett ist, ebenso schwer wie das Urteil, ob die Aktivitätenliste insgesamt vollständig ist. Erst im Verlauf des Projekts zeigt sich, was fehlt. Doch dann gibt es keine geordneten Strukturen, um die neue Erkenntnis einzugliedern.

Überschaubarkeit muß erhalten bleiben

Das Einfügen einer neuen Aktivität vervollständigt zwar den Netzplan (das heißt, die Termine werden neu berechnet); es zeigt aber nicht an, wie sich eine neue Erkenntnis auf die vorhandenen Objekte auswirkt. Wenn das Projekt sehr komplex ist oder die Veränderungen häufig vorkommen, können die wenigen Personen, die alle Zusammenhänge kennen, die Auswirkungen nicht mehr in ihren Köpfen verarbeiten. Damit geht die Überschaubarkeit verloren, und das Projekt wird riskant.

Projekte verlaufen beinahe konträr zur Modellierung eines Systems. Hier heißt es:

- Definieren Sie Aktivitäten, und ordnen Sie sie Teilprozessen zu, aus denen Ergebnisse entstehen.

- Dadurch werden Objekte in gewünschte Zustände gebracht.

- Die Summe aller Zustände von Objekten ist das Projekt-Endergebnis.

Dabei stellt sich die Frage, ob die Systeme auf diese Weise so überschaubar und änderungsfreundlich werden, wie es nötig ist.

Derzeit diskutiert die Fachwelt lebhaft über komponentenbasierte Entwicklung und Architekturen. In diesem Zusammenhang wird deutlich, daß die Überschaubarkeit komplexer Systeme durch die Bildung größerer Einheiten zusätzlich steigt. Diese Erkenntnis läßt sich für komplexe Projekte nutzen.

Lassen Sie uns das Projekt als ein System verstehen und versuchen, es nach denselben Prinzipien zu modellieren wie Software. Wie sieht eigentlich die Prozeßstruktur eines Projekts aus, in dem nicht die Aktivitäten, sondern projektrelevante Objekte in geordneten Architekturen im Vordergrund stehen? Und welche Objektklassen lassen sich im System "Projekt" identifizieren?

Schon die Eingangsfrage jedes Projekts muß anders gestellt werden, als wir es gewohnt sind. Wer fragt: "Was ist zu tun?", bekommt als Antwort Funktionen, die nach logischen und zeitlichen Abhängigkeiten zu ordnen sind. Lautet die Frage aber: "Worum müssen wir uns kümmern?", erhalten wir Themenfelder, die in irgendeiner Form zu beachten oder zu bearbeiten sind.

Objekte in sauber gegliederten Strukturen

Wird diese Frage an einen erfahrenen Projekt-Manager gerichtet, so nennt er etwa die folgenden Themen:

- Zweck (Nutzen, Zielgruppen),

- Ziele,

- Ressourcen (Personen, Räume, Sachmittel),

- Regelungen (Zuständigkeiten, Kommunikation, Dokumentation) sowie

- Einflüsse (Erfolgsfaktoren und Hemmnisse).

Einer Person, die für die ordnungsgemäße Einführung des Produkts in ein bestehendes oder anzupassendes Umfeld verantwortlich ist, werden spontan Begriffe wie

- Benutzer,

- Anwendungsorganisation,

- Schnittstellen,

- Datenbestände oder

- technische Infrastruktur

einfallen - zumindest dann, wenn es sich um ein Projekt handelt, das die Entwicklung und Einrichtung einer Anwendungssoftware zum Ziel hat.

Ein verantwortlicher Entwickler antwortet auf dieselbe Frage mit den ihm bereits bekannten Objekten des Systems. Als erfahrener Software-Architekt nennt er Überschriften wie

- Benutzungsoberflächen,

- Funktionalität und

- Datenzugriffe.

Aus diesen unterschiedlichen Antworten wird ersichtlich, daß wir es üblicherweise vor allem mit drei Betrachtungsgegenständen zu tun haben: dem Produkt, der Umgebung, in die das Produkt eingepflanzt werden soll, sowie den Bedingungen und Voraussetzungen, die für den Erfolg des Projekts unabdingbar sind. Werden diese Komponenten in eine geordnete Struktur gebracht - durch die Bildung von Über- und Unterordnungen sowie die Beschreibung von Abhängigkeiten -, so entsteht eine Architektur.

Architekturen sollen zum einen dazu beitragen, daß alle Beteiligten die Sicht erhalten, die sie für ihre Arbeit benötigen. Außerdem dienen sie dazu, jeden Verantwortlichen in Kenntnis zu setzen, sobald "seine Objekte" durch Ergänzungen und Veränderungen an einer beliebigen Stelle betroffen sind. Das heißt: Die Teile der Architektur sind so miteinander zu verschachteln, daß Auswirkungen und Konsequenzen für alle Beteiligten stets erkennbar bleiben.

Die Frage: "Worum müssen wir uns kümmern?", führt zu Strukturen, die alle Themen auflisten, die aus der jeweiligen Sicht der Projektbeteiligten relevant sind. Eine derartige Struktur läßt sich vergleichen mit einem statischen Objektmodell, das die Objektklassen identifiziert und ihre Beziehungen beschreibt.

Ist eine solche Architektur gefunden, lassen sich die Objektklassen mit den Objekten und Abhängigkeiten des konkreten Projekts füllen. Dadurch entsteht ein Gebilde aus Objekten mit Wirkungs- und Abhängigkeitsbeziehungen, das allen geforderten Sichtweisen gerecht wird. Mehr noch: Das Ergebnis ist ein veritables "Framework for change".

Selbstverständlich sind zu Beginn eines Projekts nicht alle Objekte mit allen Beziehungen bekannt. Das spielt aber keine Rolle. Wichtig ist nur, daß die Objekte in sauber gegliederten Strukturen abgebildet sind, damit sich Verfeinerungen und Veränderungen geordnet einbringen und die Auswirkungen gesichert beurteilen lassen.

Dynamisiert wird das statische Projektmodell - ähnlich wie ein Softwaremodell - durch definierte Zustände. Ein Projekt hat die Aufgabe, alle Objekte der Architektur nach und nach in die vorgesehenen Zustände zu überführen. Typisch für Projekte ist, daß sich die Objekte nicht sofort in einen endgültigen Zustand versetzen lassen, sondern ihn erst über gewisse Zwischenzustände erreichen.

Auf dem Weg über die Zwischenzustände werden die notwendigen Voraussetzungen für das Projekt geschaffen (zum Beispiel: Ressourcen sind verfügbar). Auf diese Weise entsteht sukzessive das Produkt, und die Umgebung gelangt nach und nach in den Status, in dem sie das Produkt aufnehmen kann.

Festgelegte Zwischenzustände sind ein weiteres Mittel, mit dem sich Komplexität beherrschen läßt. Sie werden gebraucht, um Verantwortungsübergänge festzulegen und gezielte Qualitätssicherungs-Maßnahmen zu ergreifen oder notwendige Entscheidungen herbeizuführen.

Die definierten Zustände für alle Objekte der Architektur erzeugen Ordnung im Projekt. Sie erlauben allen Beteiligten stets einen aktuellen Überblick über den Stand des Vorhabens. Mit ihrer Hilfe wird erkennbar, ob das Projekt tatsächlich Fortschritte macht oder ob Rückfälle in vorangegangene Zustände stattgefunden haben. Darüber hinaus verdeutlichen die Zustände die Folgen der Änderungen, die gewöhnlich bewirken, daß die betroffenen Objekte in vorangegangene Zustände zurückfallen.

Um einen gewünschten Zustand zu erreichen oder den Rückfall in einen vorangegangenen Zustand festzustellen, benötigen wir definierte Ergebnisse. Sie lassen sich mit den Nachrichten in einem objektorientierten Softwaresystem vergleichen. Ein Ergebnis ist ein nach Form und Inhalten vereinbartes Dokument, das bestimmte Objekte einer Architektur (eventuell gemeinsam mit anderen Ergebnissen) in einen definierten Zustand überführt. Dieses Dokument beschreibt alle Sachverhalte, die zur Beurteilung einer Zustandsveränderung gebraucht werden.

Ergebnisse erzeugen Verständnis. Ein berechtigter Empfänger muß mit Hilfe des Resultats beurteilen können, ob die betroffenen Objekte aus seiner Sicht den angestrebten Zustand erreicht haben oder nicht. Da die Ergebnisse nach und nach entstehen und zur Beurteilung vorgelegt werden, dienen sie der permanenten Qualitätssicherung. Sie vermeiden, daß sich Fehler fortpflanzen und unzureichendes Verständnis unerkannt bleibt.

Je nach Gliederung der Architektur lassen sich

- Management-Ergebnisse (Projektarchitektur),

- Gestaltungsergebnisse (Umgebungsarchitektur) und

- Entwicklungsergebnisse (Produktarchitektur)

unterscheiden. Management-Ergebnisse überführen Objekte der Projektarchitektur in einen definierten Zustand, während sich Gestaltungs- und Entwicklungsergebnisse auf Zustände der Umgebungs- beziehungsweise Produktarchitektur beziehen. Ergänzend benötigen die Projekte noch

- Qualitätssicherungsergebnisse (Vorgaben beziehungsweise Urteile zu anderen Ergebnissen) sowie

- Konfigurationsergebnisse (Ergebnisbündelungen).

Die logische Folge aus definierten Ergebnissen eines abgegrenzten Themenbereichs mit vereinbarten Zuständigkeiten, Terminen und Budgets ist ein Prozeß. In seinem Innern sollen die Aktivitäten entstehen, aus denen sich die Entwicklungs-, Gestaltungs-, Management-, Qualitätssicherungs- und Konfigurationsergebnisse herleiten.

Klar definierte Prozesse können delegiert werden und eignen sich deshalb dazu, die "Flaschenhälse" der Projekte zu beseitigen. Der Prozeßverantwortliche sorgt dafür, daß "seine Ergebnisse" in der geforderten Qualität mit dem geringstmöglichen Aufwand an Zeit und Kosten entstehen. In seinem Verantwortungsbereich liegt die Entscheidung, welche Aktivitäten gebraucht werden, um die Ergebnisse zu erstellen. Deshalb öffnen Prozesse auch Freiräume, in denen sich Ideen und Kreativität entfalten können.

Über die Objektstruktur sind die Abhängigkeiten zu Objekten außerhalb des Prozesses für jeden Prozeßverantwortlichen jederzeit aktuell einsehbar. Deshalb können Prozesse parallel geschaltet werden, was normalerweise schneller zu Ergebnissen führt.

Neue Prozeßmodelle müssen gefunden werden

Im Gegensatz zu herkömmlichen Vorgehensmodellen, in denen die Aktivität im Vordergrund steht, ordnet das hier beschriebene Prozeßmodell die Aktivität an unterster Stelle einer imaginären Hierarchie ein. Erst wenn das "Was", also das Objekt, dessen gewünschter Zustand und das angestrebte Ergebnis bekannt sind, ergibt es einen Sinn, über das "Wie", sprich: die notwendigen Aktivitäten, nachzudenken.

Wir beweisen tagtäglich, daß sich selbst komplexeste Systeme von Menschen beherrschen lassen. Heutzutage werden die Systeme kontinuierlich komplexer, die Zeit, um sie einzurichten, wird hingegen knapper und knapper. Deshalb benötigen wir neue Methoden, die die Projektabwicklung besser beherrschbar machen.

Das ist kein unlösbares Problem. Wir kennen die für Projekte relevanten "Business-Objekte". Zudem sind geeignete Strukturen gefunden und passende Hilfsmittel vorhanden, um komplexe Zusammenhänge verständlich und nachvollziehbar abzubilden. Uns liegen Erkenntnisse über allgemeingültige Projektobjekte mit ihren Merkmalen vor: Ressourcen haben eine Verfügbarkeit und eine Befähigung, Hemmnisse eine Eintrittswahrscheinlichkeit und eine Schadenhöhe etc. Wir wissen, welche Probleme üblicherweise auftauchen, wenn wir Anwendungssoftware in ihre Umgebung einbinden. Und uns ist klar, wie Software gebaut sein sollte (Beispiel: Dreischichten-Architektur aus Oberflächen, Funktionalität und Datenzugriffen).

Deshalb lassen sich den Projekten, sobald deren Zielsetzung bekannt ist, geeignete Architektur-Frameworks zur Seite stellen, die mit spezifischen Inhalten gefüllt werden können. Auf diese Weise bleiben auch äußerst komplexe Projekte beherrsch- und steuerbar.

Sicher können kleine Unternehmen flexibler auf Veränderungen reagieren als große. Denselben Vorteil besitzen auch kleine Projekte. Deshalb ist der Vorschlag der Standish Group, die Vorhaben möglichst klein zu halten, nach wie vor sinnvoll. Aber das ist eben keine Lösung mit umfassender Gültigkeit.

Vielmehr müssen wir neuartige Prozeßmodelle strukturieren, die die Ursachen dafür beseitigen, daß komplexe Projekte so schwer zu beherrschen sind. Diese Modelle sollen - wie ein guter Schiedsrichter im Fußball - den Prozeß steuern, ohne eigentlich bemerkt zu werden.

Angeklickt

Projekte dienen dazu, mehr oder weniger komplexe Systeme entstehen zu lassen oder einzurichten. Doch im Prinzip ist das Projekt selbst ein System - wenn auch nur ein vorübergehend aktives - ,in dem Menschen und Maschinen zusammenenwirken. Wir gliedern das System "Projekt" üblicherweise nach Aktivitäten, während wir das System "Anwendungssoftware" nach Objektklassen strukturieren. Immer häufiger passen aber die aktivitätenorientierten Grundsätze der Projektstrukturierung nicht zu den objektorientierten Prinzipien des Systemmodells. Diese Diskrepanz muss aufgelöst werden, um die Überschaubarkeit der Projekte zu verbesseren.

*Helmut Strohmeier ist Geschäftsführer der Strohmeier & Partner GmbH, München.