Systemanalyse 3.0 – Kapitel 5

Kapitel 5 – Analysieren I

(In dem wir zeigen, was die wichtigste Tätigkeit eines Systemanalytikers ist)

Nachdem wir uns im vierten Kapitel einen Gesamtüberblick über Systemanalyse 3.0 verschafft haben, wenden wir uns nun den einzelnen Elementen zu.

Analysieren als Basis-Element in Systemanalyse 3.0

Abbildung 1: Analysieren als Basis-Element in Systemanalyse 3.0

Das zentrale Element in Systemanalyse 3.0 ist – wohl keine große Überraschung – das Analysieren. In diesem Element entwickelt sich die Lösung aus einer ersten „Lösungs-Hypothese“. Durch Sammeln und Verarbeiten von Information und laufende Abstimmung durch Kommunikation mit den Stakeholdern reift die Lösung so lange, bis sie so stabil ist, dass die erforderlichen Artefakte produziert werden können.

Wenn wir dem Inhalt des Wortes „Analysieren“ auf den Grund gehen, stellen wir fest, dass das Wort aus dem Altgriechischen kommt und wörtlich „Auflösung“ bedeutet. Analyse ist eine „systematische Untersuchung, bei der das untersuchte Objekt in Bestandteile zerlegt wird und diese anschließend geordnet, untersucht und ausgewertet werden. Insbesondere betrachtet man Beziehungen und Wirkungen.“ (http://de.wikipedia.org/w/index.php?title=Analyse).

Diese – allgemeine – Definition beschreibt auch die Arbeit eines Systemanalytikers sehr gut. In diesem Artikel werden wir betrachten, was im Fall der Systemanalyse die „Bestandteile“ sind, in die das Objekt, also das Arbeitsgebiet, zerlegt wird. Die Methode, Komplexität durch Zerlegung zu reduzieren, ist nicht erst in den letzten Jahrzehnten – seit es IT und Software-Entwicklung gibt – erfunden worden, sondern ist ein altes Prinzip für das Verstehen von komplexen Sachverhalten. So gehörte die Analyse in diesem Sinne auch zu den Methoden des Philosophen René Descartes.

„Lösungsorientierte Analyse“ oder „Über rosarote Elefanten und braune Kühe“

Das Verhältnis zur Lösung unterscheidet Systemanalyse 3.0 von anderen Methoden. Requirements Engineering betrachtet die Lösung überhaupt nicht als zu seinen Aufgabenbereich gehörend. Requirements Engineering, so wie es in den Lehrplänen des IREB beschrieben ist, will Anforderungen erheben und sie entsprechend dokumentieren. Die Lösung soll anschließend auf Basis dieser Anforderungen von Designern bzw. auch den Entwicklern entworfen und realisiert werden. In Business Analyse lt. IIBA ist hingegen schon auch von der Lösung, bzw. vom Design der Lösung die Rede. Es wird von einem Lösungsansatz (Solution Approach) gesprochen, von den Anforderungen und schließlich vom Bewerten und Validieren der Lösungen. Wie eine Lösung aber zustande kommt, wie der Prozess der Lösungsfindung ist, das wird vom „Business Analysis Body of Knowledge“ (BABOK-Guide) kaum behandelt.

Systemanalyse 3.0 verfolgt hier einen anderen Ansatz, den wir Lösungsorientierte Analyse“ nennen wollen. Dieser Ansatz besagt, dass der Systemanalytiker vom ersten Moment seiner Aktivität in einem Vorhaben eine Lösungsidee im Kopf hat. Dieses Faktum lässt sich auch gar nicht verhindern. Wer ist schon einmal zu einem Gedankenexperiment eingeladen worden, in dem man aufgefordert wird, jetzt nicht an einen rosaroten Elefanten zu denken? Jeder wird bestätigen, dass das nicht möglich ist; der erste Gedanke in dieser Situation wird der an einen rosaroten Elefanten sein.

Genauso verhält es sich mit dem Gedanken an eine Lösung in einem Analysevorhaben. Nehmen wir an, Sie sollen Analyseaufgaben in einem Projekt übernehmen, in dem es um die Entwicklung eines Web-Shops für ein Handelsunternehmen geht. Sie werden kaum umhin kommen, an den Web-Shop des Online-Buchhändlers Ihrer Wahl zu denken, ob Sie es wollen oder nicht.

In Systemanalyse 3.0 stehen wir auf dem Standpunkt, dass dieses Faktum – das sich ohnehin nicht vermeiden lässt – produktiv genutzt werden sollte, anstatt es zu verdrängen. Natürlich besteht die Gefahr, dass man sich frühzeitig auf eine Lösung festlegt und die Flexibilität für neue Anforderungen und Erkenntnisse verliert. In Systemanalyse 3.0 wird dieser Gefahr dadurch begegnet, dass das „Produzieren“ aus dem „Analysieren“ ausgelagert wird – und tendenziell erst sehr spät im Prozess durchgeführt wird – dann, wenn mit keinen Informationen zu rechnen ist. Zum anderen liegt diese Flexibilität auch im Aufgabenbereich bzw. im Mindset des Analytikers – er muss lange Zeit offen für Neues sein – und bereit, sein Konzept auch zur Gänze über den Haufen zu werfen, wenn neue Informationen oder Stakeholder-Anforderungen dies erfordern.

Wenn wir von „Lösung“ sprechen, müssen wir verschiedene Dimensionen unterscheiden:

  • technisch/fachlich (how/what): es muss jeweils klar sein, ob man von der technischen Lösung spricht oder von der fachlichen Lösung. Die technische Lösung betrifft Themen, wie das exakte Screen-Design, für die Entwicklung verwendete Systeme, Datenbanken, Middleware-Systeme und dergleichen. Die fachliche Lösung wird in Konzepten ausgedrückt, wie etwa Prozessmodelle, fachliche Datenmodelle und ähnliche Darstellungsmöglichkeiten.
  • der Zeitaspekt (now/future): es muss zwischen der aktuellen und der geplanten Lösung unterschieden werden.

Suzanne und James Robertson haben diese Dimensionen im so genannten „Brown Cow“-Modell zusammengefasst [ROBERTSON2013]. Der doch etwas merkwürdige Titel dieses Modells kommt von einer englischsprachigen Aussprache-Übung, mithilfe der Englisch-Lernende die Aussprache der Vokale üben sollen – der Text dieser Übung lautet: „How Now Brown Cow“. Die aktuelle technische Lösung wird in diesem Modell als „How Now“ bezeichnet – der Rest des Aussprach-Spruchs hat dem Modell den Namen gegeben.

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Abbildung 2: Das Brown-Cow-Modell [ROBERTSON2013]

Die vier Quadranten des Brown-Cow-Modells haben folgende Bedeutung für den Systemanalytiker:

  • How Now: damit wird die aktuelle Implementierung der Lösung bezeichnet. Diese ist oft die erste Informationsquelle des Systemanalytikers. Es zeigt, wie die betrieblichen Prozesse derzeit unterstützt werden. Häufig sind Dokumentationen (Benutzerhandbücher usw.) über das Ist-System vorhanden, die einen guten Einstieg in die Analyse-Tätigkeit bilden.
  • What Now: das sind die Konzepte und Modelle, die hinter der aktuellen Lösung stehen. Eine entsprechende Dokumentation ist nicht immer verfügbar. Wenn jedoch diesbezügliche Informationen vorhanden sind, sind diese neben den Anforderungen der Stakeholder die wichtigste Informationsquelle für den Systemanalytiker.
  • What Future: dieser Quadrant ist der wichtigste für den Systemanalytiker, er bezeichnet das eigentliche Ziel der Arbeit des Systemanalytikers: die fachliche Lösung. Das Konzept wird im Basis-Element „Analysieren“ erstellt, unter Berücksichtigung der Informationen, die im Basis-Element „Kommunizieren“ gewonnen werden. Im Basis-Element „Produzieren“ erfolgt schließlich die Ausarbeitung im Format, das im jeweiligen Vorgehensmodell gefordert wird.
  • How Future: damit wird die zukünftige technische Lösung bezeichnet. Diese ist nicht Aufgabe des Systemanalytikers. Sehr häufig gibt es jedoch dennoch Beziehungen zu diesem Bereich. Die Entwickler sind wichtige Stakeholder im Analyse-Prozess. Wenn die Technik schon bekannt ist, mit der das Vorhaben letztendlich umgesetzt werden soll, wird das der Systemanalytiker in seinen Konzepten entsprechend berücksichtigen.

Das Brown-Cow-Modell ist eine Hilfe für den Systemanalytiker, Gedanken und Ideen richtig einzuordnen, sodass schließlich das Ziel – das „What Future“ erreicht wird. Es ist jedoch kein Prozess in dem Sinne, dass die verschiedenen Quadranten in einer bestimmten Reihenfolge durchlaufen werden müssen.

Analyse ist Zerlegen – aber in was?

Wie wir oben schon festgestellt haben, bedeutet „Analysieren“ dem Wortsinn nach „Zerlegen“ in Elemente. Dabei stellt sich jetzt die Frage, was sind denn die Elemente, in die wir in der Systemanalyse zerlegen?

Im Bereich der IT-Analyse haben wir es nahezu immer mit zwei Themenkreisen zu tun: mit der Welt der Daten auf der einen Seite und mit der Welt der Funktionen auf der anderen. Die Welt der Daten beschreibt die Informationen, die bearbeitet und festgehalten werden (statische Sicht), die Welt der Funktionen, welche Tätigkeiten bzw. Algorithmen diese Informationen erzeugen und bearbeiten (dynamische Sicht).

Die Objektorientierte Analyse, die vor einiger Zeit sehr modern war, wollte diese beiden Bereiche in einem Konzept vereinen. Dabei werden die Daten in Klassen gegliedert, die die Funktionen in der Form von so genannten Methoden inkludieren. Die Trennung in Daten und Funktionen wäre aufgehoben gewesen. Nur – anders als in der Welt der Programmiersprachen – hat sich in der Analyse dieser objektorientierte Ansatz nicht durchgesetzt. Es entspricht eben doch nicht der Realität, dass die Objekte von sich aus etwas tun. Vielmehr wird – durch die Funktionen – mit ihnen etwas getan.

Aus diesem Grund wollen auch wir in unserer weiteren Betrachtung der Elemente in der Systemanalyse von dieser Trennung in Daten und Funktionen ausgehen. In jeder der beiden Bereiche wollen wir ein „Primäres Analyse-Objekt“ definieren. Das ist nicht notwendigerweise das kleinstmögliche Element. Es ist vielmehr das Objekt, das im Zentrum der Analyse-Überlegungen steht, aus denen sich das Gesamtsystem zusammensetzt – auch wenn eine noch detailliertere Betrachtung möglich ist.

Das Primäre Daten-Analyse-Objekt

Jedes Arbeitsgebiet, das wir als Systemanalytiker untersuchen, setzt sich aus vielen „Dingen“ zusammen. „Dinge“ – das ist jetzt im weitesten Sinne zu sehen. Selbstverständlich können das auch Menschen sein, man denke nur an ein Personal-Informationssystem. Diese Dinge sind häufig materiell, sehr häufig auch immateriell, z. B. eine Reise oder eine andere Dienstleistung. Ja, sie können darüber hinaus auch abstrakt sein, also etwas, das es so in der Realität überhaupt nicht gibt, etwa ein Konto (wobei man jetzt diskutieren könnte, ob es einen Unterschied gibt zwischen immateriell und abstrakt). Da man unter einem „Ding“ allgemein doch etwas versteht, das man angreifen kann – und das kein Mensch ist, wollen wir allgemeiner von „Objekten“ sprechen. Und da uns auch weniger diese Objekte an und für sich interessieren, sondern alles was mit Informationen über diese Objekte zusammenhängt, sprechen wir von „Informationsobjekten“.

Aufgabe des Systemanalytikers ist es, diese Informationsobjekte zu finden – das Arbeitsgebiet in diese Informationsobjekte zu zerlegen. Das Primäre Daten-Analyse-Objekt ist also dieses Informationsobjekt.

Bis zu einem gewissen Punkt ist das auch recht einfach und bedarf weder viel Wissens noch Erfahrung. Viele der Informationsobjekte sind ganz offensichtlich – ein IT-System, das Fahrzeuge verwaltet, wird eben diese Fahrzeuge als Informationsobjekte haben. Daneben wird es jedoch auch etliche Informationsobjekte geben, die erst auftauchen, wenn der Systemanalytiker einiges an Wissen über das Arbeitsgebiet gesammelt hat. Und schließlich kommt dann der Punkt, wo man tiefer in die Analyse eintauchen wird müssen. Da geht es dann um Fragen, wie: Ist es zweckmäßig, ein Informationsobjekt, das auf den ersten Blick wie eines erscheint in zwei aufzuteilen? Es wird auch etliche Informationsobjekte geben, die keinerlei Entsprechung in der Realität haben, die der Systemanalytiker erfindet, um die erforderlichen Informationen in sauberer Form verwalten zu können.

Mit der Identifikation der Informationsobjekte ist es jedoch nicht getan. Die Informationsobjekte sind Träger von Informationen, wie ja der Name schon sagt. Herauszufinden, welcher Art und welchen Umfangs die Informationen sind, die ein Informationsobjekt trägt, ist eine weitere Aufgabe des Systemanalytikers. Die gefundenen Informationsobjekte werden um Attribute ergänzt. Die Attribute für das Objekt „Person“ sind z. B. Vorname und Zuname und – je nach Arbeitsgebiet – eine Menge weiterer Attribute.

Die dritte Art von Information, die mit den Informationsobjekten verbunden ist – neben den Objekten und ihren Attributen, sind die Beziehungen zwischen den Objekten. Diese herauszufinden und zu dokumentieren gehört ebenfalls zu den Aufgaben des Systemanalytikers. Sehr viel Wissen über das Arbeitsgebiet steckt in diesen Beziehungen.

Abbildung 3: Aus "Dingen" werden Informationsobjekte

Abbildung 3: Aus „Dingen“ werden Informationsobjekte

Alles zusammen – das Informationsobjekt, seine Attribute und die Beziehungen zwischen den Informationsobjekten – wird das Datenmodell des Arbeitsgebietes genannt. Es gibt mehrere Möglichkeiten, dieses Datenmodell darzustellen.

Lange Zeit waren die so genannten Entity-Relationship-Diagramme vorherrschend. Diese bezeichnen die Informationsobjekte als Entities und die Beziehungen als Relationships. Seit vielen Jahren hat sich auf dem Gebiet der Modellierung jedoch die UML (Unified Modeling Language) durchgesetzt. Diese sieht für die Datenmodellierung die Klassendiagramme vor. Die Klassendiagramme kommen aus der Objektorientierten Analyse, d. h. es wäre an und für sich vorgesehen, dass in den Informationsobjekten, die in diesem Fall ‚Klassen‘ genannt werden, auch die Methoden – also die Funktionen – modelliert werden. In der Praxis werden die Methoden aber zumeist weggelassen, sodass die Entity-Relationship- und Klassen-Diagramme in ähnlicher Weise verwendet werden und sich lediglich in der Syntax unterscheiden.

Wir fassen also zusammen: Aus der Datensicht zerlegt die Systemanalyse ein Arbeitsgebiet in Informationsobjekte. Diese werden durch die Attribute beschrieben und durch Beziehungen in ein Gesamtsystem gebracht. Das ist die statische Sicht eines Arbeitsgebietes.

Zur vollständigen Beschreibung muss die dynamische Sicht ergänzt werden. Wir müssen also herausfinden, was mit den Daten der statischen Sicht geschieht. Wie entstehen sie, wie werden sie modifiziert und bearbeitet, sodass letztlich Geschäftsnutzen entsteht. Was sind die Primären Funktions-Analyse-Objekte?

Das Primäre Funktions-Analyse-Objekt

Es gibt eine Menge an Tätigkeiten und Aufgaben, die in einem zu analysierenden Arbeitsgebiet anfallen, es werden neue Daten erfasst (Bestellungen, Aufträge, Kunden, …), es müssen Änderungen an bestehenden Daten vorgenommen werden und es gibt Informationsbedürfnisse, die befriedigt werden müssen. Analyse bedeutet, Ordnung in diese zunächst ungeordnete Menge an Aktionen zu bringen.

Dafür sind verschiedene Möglichkeiten vorstellbar. Die gängige und häufig empfohlene Gliederung dieser Aktivitäten sind jene nach Prozessen. Es werden die Arbeitsabläufe mit ihren einzelnen Schritten beschrieben, die zu einem bestimmten Ergebnis führen und ihrer Gesamtheit Wert schaffen sollen.

Ein Begriff, der in diesem Zusammenhang weite Verbreitung gefunden hat, ist der „Use-Case“. Ein Use-Case beschreibt die Reaktion des Systems auf ein externes Ereignis. Beispiel für Use-Cases wären: „Ein Buch entlehnen“, „Geld abheben“, „Kontostand abfragen“. Use-Cases und Prozesse stehen in einem Zusammenhang, sind aber nicht ident. Ein Use-Case stellt das Verhalten eines Systems aus der Außensicht dar, während der Schwerpunkt eines Prozesses auf den einzelnen Prozessschritten liegt und diese in Beziehung zueinander setzt. Die Detaillierung eines Use-Cases erfolgt durch die Beschreibung des dazugehörigen Prozesses.

Die Arbeit des Systemanalytikers muss jedoch über die Use-Case- bzw. Prozess-Ebene hinausgehen. Ein Prozess besteht aus mehreren Schritten. Jeder Prozess-Schritt beinhaltet eine Aktion, die von einem Akteur ausgeführt wird. Jede derartige Aktion kann Prozessschritt in mehreren Prozessen sein. Zum Beispiel kann die Aktion „Kontostand abfragen“ in mehreren Prozessen vorgesehen werden. Diese Mehrfach-Verwendung von Aktionen muss in der Systemanalyse berücksichtigt werden.

Das Hauptaugenmerk des Systemanalytikers liegt auf dieser Aktion, die in einem Prozessschritt ausgeführt wird. Sie ist das „Primäre Funktions-Analyse-Objekt“. Diese Aktion kann wiederum aus mehreren Handlungen bestehen. Herausforderung ist es nun, die Aktionen so voneinander abzugrenzen, dass kompakte Einheiten entstehen, die klar nach außen abzugrenzen sind.

Ein Beispiel für eine derartige Aktion könnte „Kundendaten erfassen“ heißen. Die Aktion kann in mehreren Use-Cases bzw. Prozessen vorkommen und besteht aus mehreren Einzelhandlungen, z. B. „Vorname erfassen“, „Zuname erfassen“, „Adresse erfassen“.

In Systemanalyse 3.0 wollen wir diese Aktion „Transaktion“ nennen. Dieser Begriff wird ursprünglich in der Software-Technik verwendet und bedeutet, dass eine bestimmte Funktion mit allen Schritten ganz oder gar nicht durchgeführt wird. So soll verhindert werden, dass etwa bei einer Bank-Überweisung nur die Abbuchung, nicht jedoch die Zugangsbuchung durchgeführt wird.

Im Bereich der Systemanalyse 3.0 wird der Begriff „Transaktion“ in ähnlicher Weise gebraucht; er bezeichnet ebenso eine Funktion, die eine Einheit darstellt und (in der Regel) ganz oder gar nicht durchgeführt wird. Diese fachliche Transaktion kann, muss aber nicht mit der technischen Transaktion übereinstimmen.

Transaktionen sind also die Bausteine, aus denen die Prozesse zusammengesetzt werden.

Abbildung 4: Aus Handlungen werden Transaktionen

Abbildung 4: Aus Handlungen werden Transaktionen

Aus dynamischer Sicht ist es also Aufgabe der Systemanalyse, die Menge an Tätigkeiten und Aufgaben, die in einem Arbeitsgebiet anfallen, in Transaktionen zu gliedern und zusammenzufassen. Die Transaktionen stehen in einer Beziehung zueinander. Diese Beziehungen bilden die Prozesse. Aus der Außensicht entsprechen diese Prozesse den Use-Cases.

Daten und Funktionen – eine Einheit

Daten und Funktionen müssen letzten Endes in der Lösung eine Einheit bilden. Dennoch können sie in der Analyse bis zu einem gewissen Grad getrennt behandelt werden. Und dann stellt sich natürlich die Frage nach der Reihenfolge. Sollen zuerst die Daten oder zuerst die Funktionen analysiert werden?

Im Prinzip ist das ein Henne-Ei-Problem. Daten sind wertlos, wenn sie in keinen Funktionen verwendet werden. Ebenso sind Funktionen ohne Daten nicht denkbar. Deshalb besteht auch eine enge Abhängigkeit zwischen der Funktions- und der Datenanalyse. Aber trotz dieser Abhängigkeit zeigt die Erfahrung, dass die Welt der Daten wesentlich stabiler ist als jene der Funktionen.

Wenn ein durchdachtes, stabiles Datenmodell vorliegt, dann ergeben sich die dazugehörigen Funktionen häufig wie von allein. Aus diesem Grund sprechen wir die Empfehlung aus: Konzentrieren Sie sich zunächst auf das Datenmodell. Finden Sie die Informationsobjekte, die Attribute zwischen den Informationsobjekten. Und suchen Sie eine klare, auf einfache Grundprinzipien basierende Struktur. Wenn die Basis-Struktur bereits sehr komplex ist, wird es Ihnen schwer fallen, die Komplexität, die sich im Laufe der Analyse zwangsläufig ergeben wird, abzubilden.

Eine Technik, mit der der Zusammenhang formal dargestellt werden kann, ist die so genannate CRUD-Matrix – CRUD steht dabei für „Create – Read – Update – Delete“ – die Basis-Aktionen für die Bearbeitung von Daten.

Die CRUD-Matrix gibt Auskunft darüber, welche Informationsobjekte in welchen Transaktionen wie angezeigt und bearbeitet werden. Zu diesem Zweck werden die Transaktionen, die das Ergebnis der Funktionsanalyse sind, in den Zeilen dargestellt und die ermittelten Informationsobjekte in den Spalten der Matrix. In den Schnittpunkten der Zeilen und der Spalten wird jeweils angegeben, ob und wie das jeweilige Informationsobjekt in der Transaktion behandelt wird, wobei das „C“ für „Create“ (Neuanlage), das „R“ für „Read“ (Lesen), das „U“ für „Update“ (Ändern) und das „D“ für „Delete“ (Löschen) steht.

Das gibt nur einen sehr guten Gesamt-Überblick über die Primären Analyse-Objekte, sondern es kann auch auf einfache Art und Weise festgestellt werden ob noch Lücken in der Analyse bestehen. Wenn etwa ein Informationsobjekt in keiner Zelle ein „C“ stehen hat, so muss sich der Analytiker die Frage stellen, wo dieses Informationsobjekt herkommt. In Einzelfällen kann es gute Gründe dafür geben, häufig ist das aber auch ein Indiz dafür, dass noch eine Transaktion fehlt.

Umgekehrt – falls für ein Informationsobjekt nur ein „C“ eingetragen ist, wird man sich die Frage stellen, ob es überhaupt benötigt wird.

Abbildung 5: CRUD-Matrix

Abbildung 5: CRUD-Matrix

Zusammenfassung

In diesem Artikel haben wir uns mit dem ersten Basis-Element der Systemanalyse, dem „Analysieren“ beschäftigt. Wir haben festgestellt, dass in diesem Basis-Element die Lösung entwickelt und ausgearbeitet wird. Mithilfe des Brown-Cow-Modells werden die verschiedenen Dimensionen der Lösung dargestellt.

Analysieren bedeutet Zerlegen. In Systemanalyse 3.0 sind die Elemente, in die zerlegt wird, die Informationsobjeke aus datenorientierter Sicht und die Transaktionen aus funktionsorientierter Sicht. Mithilfe einer CRUD-Matrix können die beiden Sichten vereinheitlicht dargestellt werden.

Im nächsten Artikel werden wir noch beim Analysieren bleiben. Es soll konkret dargestellt werden, wie der Prozess der Zerlegung in die Primären Analyse-Objekte abläuft. Dabei soll vor allem auch darauf eingegangen werden, wie der Systemanalytiker eine kreative Lösung finden kann.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: