"Wenn wir nur zuerst herausfinden könnten, wo wir stehen und wohin wir tendieren,
dann könnten wir besser beurteilen, was zu tun ist und wie es zu tun ist."
(Abraham Lincoln)

Analyseaspekte

Der Anbieter wird in dieser Phase zum Analytiker, der das Fachkonzept des Kunden strukturiert aufbereitet und in vielen Interviews ganz viele Fragen stellt, um die Antworten systematisch und strukturiert in die Analyse einzuarbeiten. Der Analytiker prüft alle Informationen auf Auslassungen, Widersprüche, Mehrdeutigkeiten, Ungenauigkeiten, Prioritäten und Irrelevanz. Stellt er Mängel fest, muss er Informationen nachfordern und nachbessern. Die Analysetätigkeit verlangt also extrem viel Diszipliniertheit und Konsequenz. Es geht zunächst noch immer ausschließlich um die Fachlichkeit - also das Geschäftsmodell - des Kunden: alles, was die Software "wissen" muss, um die reale Welt des Kunden nachzubilden, gehört in das Analysedokument - aber mehr nicht! Das System soll ja auch nicht mit überflüssigen Funktionen überlastet und dadurch unbenutzbar werden! Es ist häufig extrem schwer zu beurteilen, was rein gehört und was nicht, d.h. zu bewerten ob es nötig ist, ein Detail zu spezifizieren, oder nicht. In [B4] gibt es phantastische Beispiele für softwareintensive Systeme, in denen Fehler teilweise mehrere Jahre gelauert haben, bis sich Mechanismen außerhalb des Systems oder implizite Voraussetzungen geändert haben, so dass die Fehler endlich zum Vorschein kommen konnte.

Was zur Analyse angeboten wurde.

Ein Beispiel aus [B4]: "Der höheren Sicherheit wegen rüstete British Rail ihre Züge von Backenbremsen auf Scheibenbremsen um. Die neuen Bremsen arbeiteten gut, aber der Austausch verwirrte das Signalsystem gründlich. Das Signalsystem ist sicherheitskritisch, da sein Zweck die Verhütung von Zusammenstößen ist. Dabei greift es auf drei redundante computerisierte Systeme zurück, die die Position jedes Zugs über Sensoren in den Schienen ermitteln, die mit den Rädern des Zugs in Kontakt kommen. Die Position sämtlicher Züge ist im Stellwerk als Markierung auf einem Display verfügbar. Das Problem entstand im Herbst, als das Laub von den Blättern fiel und feuchtes Wetter herrschte. Nasse Blätter bildeten auf den Schienen eine breiige Masse und überzogen als isolierende Paste die Räder, die von den Scheibenbremsen nun nicht mehr wie von den Backenbremsen blank poliert wurden. Die Paste bildete eine immer dickere Schicht, bis die Züge keinen elektrischen Kontakt mehr zu den Sensoren im Gleis hatten. Aus Sicht des Signalsystems waren die Züge einfach verschwunden. Am Montag, den 11.11.1991 warteten Hunderte von Passagieren stundenlang auf ihre Züge, während die Betriebsleitung bei British Rail herauszufinden versuchte, welche Züge wo waren."

Dies belegt auch sehr schön, dass sich jedes Gesamtsystem aus Teilsystemen ("Weltausschnitten") zusammen setzt, die sich gegenseitig beeinflussen. Selbst wenn die Entwickler des Signalsystems in ihrer Analyse der Anforderungen die Voraussetzung definiert hätten, dass die Räder immer Kontakt zu den Gleisen haben müssen, wäre dieser Fehler aufgetreten, weil die Verantwortlichen des Bremssystems vor dem Umbau der Bremsen bestimmt nicht die Spezifikation des Signalsystems gelesen hätten. Hier hatte eine unbeabsichtigte und unbewusste Funktion des alten Bremssystems (nämlich das sauber halten der Räder) zufällig zu einer unbedingten Voraussetzung der Funktionalität des Signalsystems geführt - und da hilft auch die Redundanz von drei Computern nicht weiter. Es gibt wohl auch kaum keine Möglichkeit, solche Zusammenhänge in die Spezifikation des Gesamtsystems mit aufzunehmen, weil diese zufälligen Zusammenhänge niemandem bewusst sind.

Sehr wohl zeigt sich gerade in solchen Fällen, ob professionell gearbeitet wird: "Professionalität" setzt sich hier aus strenger Formalität, viel Systematik, noch mehr Test auf Vollständigkeit und Widerspruchsfreiheit sowie das Einnehmen verschiedener Positionen zur Ausübung verschiedener Sichten zusammen. Hier sei schon mal der besondere Charakter von "Fehlern" vorweg genommen, das sie umso billiger sind, je eher man sie findet und beseitigt [B16].

Die Analysephase wird wie jede Phase und der gesamte Software-Erstellungsprozess iterativ inkrementell durchlaufen, d.h. die Analyse wächst in mehreren Schritten. Bei jedem Schritt werden alle Bestandteile in Form von Anwendungsfällen genauer beschrieben. So werden zunächst alle Bestandteile konzeptionell betrachtet, indem nur kurz erläutert wird, welche Anforderung überhaupt dazu gehört. Danach wird konzeptionell kurz beschrieben, worum es bei jedem Bestandteil geht. Als nächstes wird spezifiziert, wie der Bestandteil genau aussieht (Szenarien). Schließlich werden erstmalig Realisierungsaspekte ins Spiel gebracht. So wird aus einer sehr rohen Liste von Anforderungen eine detaillierte Leistungsbeschreibung im Sinne einer Spezifikation. Diese kann dann zum Bestandteil des Realisierungsangebots werden.

Ziel der Analyse ist also einerseits eine Leistungsbeschreibung, die genau genug für eine Abschätzung zum Angebot der Realisierungsphase ist, und andererseits die daraus abgeleitete präzise Aussage zur Machbarkeit.