Kapitel 4: Das Big Picture

Zum vorherigen Artikel der Reihe

Das Big Picture

(In dem wir den Gesamtprozess der Systemanalyse 3.0 betrachten)

In den ersten drei Artikeln haben wir definiert, was Systemanalyse 3.0 ist und in welchem Verhältnis sie zu jenen Methoden und Konzepten steht, auf denen sie letztlich basiert. Im nächsten Schritt wollen wir uns nun dem Inhalt von Systemanalyse 3.0 zuwenden. Das soll das Thema dieses Kapitels sein. Es werden die Basis-Elemente von Systemanalyse 3.0 erläutert - darauf aufbauend wird gezeigt, wie sich aus diesen Grundelementen der Systemanalyse-Prozess zusammenfügt.

Zu Beginn wollen wir aber die Anforderungen an den Prozess "Systemanalyse 3.0" festhalten. Was soll Systemanalyse 3.0 leisten? Das kann in den folgenden Punkten zusammengefasst werden:

1. Die Vorgehensweise soll erklären, wie Wissen über das Arbeitsgebiet aufgebaut wird.
2. Sie soll es ermöglichen, dass die betroffenen Stakeholder (= alle Personen, die von dem Vorhaben betroffen sind) einbezogen werden.
3. Es soll dargestellt werden, wie der Output der Analysetätigkeit aussieht, und wie dieser produziert wird.
4. Die Methode soll das Finden einer oder mehrerer Lösungen zum Ziel haben.
5. Sie soll den im vorangegangenen Kapitel gezeigten Schritten des kreativen Prozesses Raum geben.
6. Der Prozess soll so flexibel sein, dass er sowohl für traditionelle als auch für agile Methoden der Software-Entwicklung anwendbar ist.

Die Aufgabe der Systemanalyse

Die Aufgabe der Systemanalyse ist es, die Lösung (oder auch mehrere Lösungen) für einen Bedarf (Business Need) zu finden.

Was hier "Bedarf" genannt ist, bezeichnet die Aufgabenstellung, die im jeweiligen Vorhaben (Projekt) bearbeitet werden soll. Das kann vielerlei sein: Es kann ein Problem mit einem Prozess sein, das durch IT-Unterstützung gelöst werden soll. Es kann eine Marktchance sein, die das Unternehmen wahrnehmen möchte - und wofür die IT-Umgebung des Unternehmens erweitert werden muss. Oder es kann einfach ein IT-System sein, das in die Jahre gekommen ist und das ersetzt werden soll.

Bei der Lösung handelt es sich in der Regel um eine Lösung im IT-Kontext, d. h. um ein neues IT-System oder um die Erweiterung eines bestehenden Systems. Es ist aber auch nicht auszuschließen, dass das Ergebnis der Systemanalyse ist, dass das Problem nicht durch IT-Einsatz gelöst werden sollte, sei es, weil es nicht wirtschaftlich ist - oder weil es andere, bessere Lösungen gibt, den Bedarf zu decken.

Wenn hier von "Lösung" die Rede ist, dann ist immer "Design" der Lösung gemeint. Für die Umsetzung der Lösung durch Programmierung bzw. durch konkreten Einsatz von Software-Produkten ist nicht die Systemanalyse zuständig.

Die Basis-Elemente

Die Arbeit in Systemanalyse 3.0 besteht aus drei Basis-Elementen:

1. Analysieren
2. Kommunizieren
3. Produzieren

Diese drei Elemente spielen zusammen - und verfolgen dabei das Ziel, eine oder mehrere Lösungen zu generieren - Lösungen, die der Aufgabenstellung entsprechen, die den Bedarf decken.

Analysieren

Die Aussage, dass in der Systemanalyse analysiert wird, mag trivial erscheinen. Und doch ist es notwendig, das zu betonen - in den Konzepten der Business Analyse und des Requirements Engineering wird gerade dieser Bereich nicht besonders betont.

Was tut nun ein Systemanalytiker, wenn er analysiert? Was bedeutet eigentlich "Analyse"?

• Dem Wortsinn nach bedeutet "Analysieren" "Zerlegen" - das Arbeitsgebiet wird in überschaubare Einheiten zerlegt - Einheiten, die klein genug sind, um sie vollständig begreifen zu können.
• Damit dieses "Zerlegen" funktionieren kann, ist es wichtig, Informationen zu sammeln, wo immer man sie kriegen kann. Durch diese Informationen muss der Systemanalytiker die Essenz des Arbeitsgebiets herausfinden. Wie funktioniert dieses Arbeitsgebiet? Worauf kommt es an? Was sind die Ziele? Was sind die Rahmenbedingungen?
• Diese kleinsten Einheiten werden anschließend so zusammengesetzt und in ein System gebracht, dass die Aufgabenstellung erfüllt wird - das ist schließlich das Design der Lösung.

Kommunizieren

Der Systemanalytiker erarbeitet die Lösung nicht für sich selbst. Er hat einen Auftraggeber. Es gibt Know-How-Träger, die Informationen liefern können - und müssen. Und schließlich gibt es auch Menschen, die mit der vom Systemanalytiker erarbeiteten Lösung leben und arbeiten müssen.

Daraus ergeben sich auch die Funktionen der Kommunikation in der Systemanalyse 3.0:

• Einholen von Information
• Erheben der Anforderungen
• Abstimmung von Lösungsvorschlägen des Systemanalytikers
• Abnahme des Lösungsvorschlags des Systemanalytikers.

In Systemanalyse 3.0 ist Kommunizieren immer etwas Dialogisches. Der Systemanalytiker holt sich nicht bloß die Anforderungen ab, sondern er wird immer auch schon mit einer Idee einer Lösung zum Stakeholder gehen - die er vielleicht nicht immer präsentiert, die er aber doch als Hypothese verwendet, die durch die Aussagen des Stakeholders entweder bestätigt wird - oder modifiziert oder gar verworfen werden muss.

Produzieren

Wie jede Arbeit muss auch die Arbeit des Systemanalytikers Ergebnisse liefern. Das Ziel der Arbeit des Systemanalytikers ist das Design der Lösung. Dieses Design ist etwas Geistiges und im Prinzip nicht an materielle Artefakte gebunden. In der Praxis muss dieses Ergebnis aber auch kommuniziert werden. Da dies normalerweise nicht nur mündlich vor sich gehen kann, muss der Output des Systemanalytikers auch in irgendeiner Weise festgehalten werden. Diese Dokumentation kann verschiedene Formen annehmen. Sie kann durch natürlich-sprachige Texte erfolgen. Sehr häufig wird das Ergebnis der Analysetätigkeit aber auch in der Form von Modellen dokumentiert.

Die Art, wie die Ergebnisse dokumentiert werden, ist auch von der gewählten Methode abhängig. In traditionellen Vorgehensweisen entsteht meist ein Pflichtenheft oder eine Anforderungsspezifikation. In agilen Software-Entwicklungsmethoden wird das Ergebnis der Analyse häufig in Form von User-Stories dokumentiert.

Der Mikro-Prozess der Systemanalyse

Die drei Basis-Elemente der Systemanalyse, Analysieren - Kommunizieren - Produzieren, werden zum so genannten Mikro-Prozess der Systemanalyse zusammengesetzt. Dieser Mikro-Prozess ist für alle Vorhaben gültig - unabhängig davon, wie lange sie dauern. Das heißt, ein derartiger Mikro-Prozess nimmt vielleicht nur wenige Minuten in Anspruch - oder auch mehrere Monate; der prinzipielle Aufbau des Mikro-Prozesses bleibt davon unberührt.

Der Mikro-Prozess der Systemanalyse ist in Abbildung 2 dargestellt.

Zentrales Element ist das Analysieren. Diese Tätigkeit steuert den gesamten Prozess. Unmittelbar nach dem Start des Prozesses beginnt der Analytiker mit dem Sammeln von Informationen über das Arbeitsgebiet. Dadurch lernt er das Arbeitsgebiet kennen. In den meisten Fällen hat der Systemanalytiker dann schon eine Lösung vor Augen. Das lässt sich auch gar nicht verhindern. Die Lösung ist schließlich das, was letztendlich heraus kommen soll.

Diese "Lösungs-Hypothese" muss jedoch ständig herausgefordert werden - herausgefordert durch zusätzliche Informationen, herausgefordert auch durch die Anforderungen der Stakeholder. Im wissenschaftlichen Kontext würde man vom Versuch der Falsifizierung sprechen. Dadurch wird sich diese "Lösungs-Hypothese" verändern und weiterentwickeln. Nicht selten wird sie auch zur Gänze verworfen werden und eine neue Lösungs-Hypothese wird sie ersetzen, die nun ebenfalls wieder gegen neue Informationen und Anforderungen zu überprüfen ist.

Die wesentliche Funktion des Basis-Elements "Kommunizieren" ist die Herausforderung der Lösungs-Hypothese. Durch die Kommunikation mit Stakeholdern sammelt der Systemanalytiker Wissen. Eine spezielle Art der Information sind die "Anforderungen". Das sind Ideen und Vorstellungen, die die Stakeholder über die Lösung haben. Anforderungen haben üblicherweise große Auswirkungen auf die Lösungs-Hypothese.

Ab einem gewissen Punkt des Analysierens und damit verbundenen Kommunizierens wird der Systemanalytiker die Entscheidung treffen, jetzt "fertig" zu sein. Wann dieser Punkt erricht ist, hängt von mehreren Faktoren ab. Diese Entscheidung hat eine fachliche Komponente. Wenn alle Stakeholder befragt sind, alle verfügbaren Informationen ausgewertet, keine neuen Aspekte mehr zu erwarten sind und ein akzeptabel scheinendes Lösungsdesign vorhanden ist, dann ist dieser Punkt erreicht. Nicht zu unterschätzen ist aber auch die planerische Komponente. Wenn ein Meilenstein-Termin näher rückt oder wenn das vorgesehene Budget erschöpft ist, auch dann wird möglicherweise die Analyse-Tätigkeit beendet, auch wenn noch eine bessere Lösung denkbar wäre. Die "Lösungs-Hypothese" wird dann zur "vorgeschlagenen Lösung".

Solange die Analyse noch nicht abgeschlossen ist, muss der Analytiker weitestgehend flexibel bleiben. Es darf keinen übermäßigen Aufwand verursachen, wenn eine "Lösungs-Hypothese" geändert oder gar gänzlich verworfen wird. Wenn zu diesem Zeitpunkt schon viel Arbeitszeit in die Produktion des Ergebnisses geflossen ist, dann geht von dieser Flexibilität verloren. Deshalb sieht Systemanalyse 3.0 vor, dass mit dem "Produzieren" erst begonnen wird, wenn die Lösung gedanklich - im Kopf des Analytikers - "fertig" ist. Zu diesem Zeitpunkt sind keine gröberen Änderungen mehr zu erwarten und man kann davon ausgehen, dass die entstehenden Artefakte auch Bestand haben. Das schließt natürlich nicht aus, dass auch in der "Produzieren"-Phase noch die eine oder andere kreative Idee auftaucht. In diesem Fall sollte sich der Systemanalytiker nicht scheuen, in die Phase des "Analysierens" zurückzuschalten. Es ist eine Frage der Kosten-Nutzen-Abwägung, ob bereits produzierte Artefakte verworfen werden. Deshalb sollte die Rückkehr vom "Produzieren" - in den "Analysieren"-Status die Ausnahme bleiben.

Die fertiggestellten Artefakte müssen den Stakeholdern auch noch kommuniziert werden. Doch auch hier gilt: es sollten keine großen Änderungen mehr zu erwarten sein. Das bedingt, dass die vorgeschlagene Lösung schon in der Analyse-Phase möglichst weitgehend mit den Stakeholdern abgestimmt wurde.

Der Makro-Prozess der Systemanalyse

Manchmal kommt ein Vorhaben mit einem einzigen Mikro-Prozess der Systemanalyse aus. Das wird vor allem dann der Fall sein, wenn es sich um ein sehr kleines Vorhaben handelt und wenn nach einem strengen Wasserfall-Modell vorgegangen wird. In allen anderen Fällen wird es sehr viele derartige Mikro-Prozesse geben. Diese Summe dieser Mikro-Prozesse ergibt den Makro-Prozess der Systemanalyse. Dieser ist in Abbildung 3 dargestellt.

Der Makro-Prozess der Systemanalyse besteht im Kern aus einer Reihe von Analysieren-Kommunizieren-Produzieren-Blöcken, also von Mikro-Prozessen der Systemanalyse. Wie viele es tatsächlich sind und wie diese strukturiert sind, hängt von der Organisation des Entwicklungsprozesses ab. Der in Abbildung 3 dargestellte würde einem typischen agilen Prozess entsprechen. Nach einem Block, der einen Überblick über das gesamte Vorhaben schafft, gibt es eine ganze Reihe von kleineren Blöcken, die das iterative Vorgehen in einem agilen Projekt repräsentieren. Im Fall der Anwendung des Scrum-Prozesses würden diese Blöcke den Sprints entsprechen.

Bevor jedoch mit dem ersten Mikro-Prozess begonnen wird, sind etliche Vorbereitungen erforderlich. Dafür ist eine eigene Phase vorgesehen, die wir schlicht "Start" nennen möchten. In dieser Start-Phase werden folgende Aktivitäten durchgeführt:

• Festlegung der Ziele: es wird definiert, was mit dem Vorhaben überhaupt erreicht werden soll.
• Festlegung des initialen Scopes: es wird überblickshaft dargestellt, was sich innerhalb des Aufgabenbereichs des Vorhabens befindet und was außerhalb. Es handelt sich dabei um eine grobe Abgrenzung, die sich im Laufe des Analyseprozesses noch verschieben kann. Sie soll jedoch eine Richtlinie vorgeben, an die sich der Systemanalytiker handelt.
• Erste Abklärung der vorhandenen Stakeholder: Auch die Auflistung der Personen, die von dem Vorhaben in irgendeiner Form betroffen sind, ist eine vorläufige. Im Zuge der Analyse-Arbeiten werden häufig weitere Personen und Personenkreise eruiert, die Interesse an dem Vorhaben haben und dazu beitragen können.
• Festlegung der geplanten Vorgangsweise: es ist festzuhalten, ob agil oder traditionell vorgegangen werden wird, wie die geplanten Termine sind, welche Artefakte entstehen sollen und ähnliche Fragen mehr.

Das Thema dieses Blogs ist die Analyse. Dennoch müssen auch die Nachbardisziplinen Entwicklung und Test insofern betrachtet werden, als die Analyse damit in Beziehung steht. Einerseits liefert die Systemanalyse mit ihren Artefakten die Basis für Entwicklung und Test. Andererseits liefern diese Bereiche auch Input für das Verständnis der vom Analytiker entwickelten Lösung und sind aus diesem Grund in die Analysetätigkeit einzubeziehen.

Zum folgenden Artikel der Reihe