Systemanalyse

Bei mir ist alles anders!
Wahrscheinlich kommt Ihnen dieser Satz bekannt vor. Meist schon in den ersten Workshops eines Projektes hat jeder Anwender viele spezielle Anforderungen.

Will man ein auf Dauer instabiles oder nicht wartbare IT-Systeme vermeiden, gilt es, die Prozesse kritisch zu hinterfragen, nach Gemeinsamkeiten zu suchen und diese in robuste Prozessmodelle umzusetzen. Dies gilt umso mehr für die Anforderungen eines Real-Time Unternehmens.

Die Systemanalyse beinhaltet folgende Elemente:

• Prozessanalyse (Prozessklassifizierung in Prozesshierarchien)
• Architektur (Komponenten, Schnittstellen)
• Glossar (Muster, Strukturen)
• User Interface (Masken, Workflow)

Beispiel einer Prozessklassifizierung:

Hierachie	Beispiel
Geschäftsprozess	Der Substanzlogistik Geschäftsprozess ist „Aufnahme, Lagerung, Konfektionierung und Verteilung“ von Substanzen.
Hauptprozess	Zu den Hauptprozessen gehören z.B. · „Wirkstoffe und Formulierungen bestellen“ · „Wirkstoffe und Formulierungen nachfordern“ Ein Hauptprozess besteht aus mehreren Teilprozessen
Teilprozess	Z.B. „384er MTP’ nachfordern“: Ein Teilprozess kann mehrere Anwendungsfälle enthalten.
Workflow-Prozess (WFP)	Ein Workflow-Prozess kann aus mehreren Hauptprozessen > Teilprozessen > Anwendungsfällen bestehen.
Anwendungsfall	Z.B. „Arbeitsrack leeren“: Dieser Anwendungsfalle ist z.B. im Teilprozess „384er MTP’ enthalten“
Servicefall	Der Begriff des Servicefalles wird im Rahmen des System Designs verwendet. Ein Anwendungsfall wird in der so genannten Business Logik durch ggf. mehrere Servicefälle abgebildet (siehe service-orientierte Architektur)

Grundlage für alle weiteren Arbeiten ist ein tragfähiges Modell der Prozessklassifizierung, mit dem ein Geschäftsprozess in Stufen unterschiedlicher Granularität abgebildet wird. Die dargestellte Tabelle zeigt das Beispiel einer Prozessklassifizierung aus dem Bereich der Forschung der chemischen und pharmazeutischen Industrie.

Glossar:
Begriffe werden in einem Glossar gesammelt, klarer gefasst und anhand ihrer Prozesse an einer konsistenten Verwendung über alle Prozesse hinweg überprüft. Es werden Klassifizierungen und Relationen zwischen den Begriffen definiert. Die Begriffe werden während der Workshops schriftlich festgehalten, die Eigenschaften der Begriffe werden visualisiert und etwaige Relationen zu anderen Begriffen dargestellt. Damit wird ein erster Schritt zu einem späteren Relationenmodell oder Objektmodell getan.

Systemarchitektur:
Anhand der Prozesse und der Begriffswelt werden Komponenten, d.h. „Kästchen“ gebildet mit deren Hilfe man Prozesse „fassbar“ macht. Sicherlich ist es möglich, den Prozess „Schlage Nagel in Holzbalken“ auf einer gewissen Abstraktionsebene ohne direkten Bezug zu einem Werkzeug zu erläutern, jedoch wird der Prozess erst wirklich „fassbar“, wenn man hierzu ein konkretes Werkzeug benennt. Analog bilden die Komponenten die Werkzeuge, mit denen man die Prozesse abbildet. Die Menge aller Komponenten, ihre Beziehungen untereinander, sowie die Schnittstellen über die Systemgrenzen hinweg, dies bezeichnen wir als (Analyse-) Systemarchitektur. Wichtig ist, jedem der Kästchen einen Namen zu geben und wesentliche Funktionen, aus den Prozessen ermittelt, diesen zuzuordnen. Alle internen und externen Schnittstellen werden dargestellt. Dies vermittelt ein unmittelbares Gefühl für die Komplexität des Systems.

Masken und Workflow:
Wenn sich innerhalb des Kernteams das Verständnis bzgl. Prozessen, Begriffswelt und Systemarchitektur angenähert hat, ist es Zeit, die gewonnenen Erkenntnisse an Hand von zentralen Masken zu überprüfen und einige wesentliche Prozesse an Hand von Maskensequenzen „durchzuspielen“. Auch hier wird sich herausstellen, dass die Gestaltung der Masken die Prozesse, die Begriffswelt und die Systemarchitektur beeinflusst und umgekehrt.

"ENDE":
In den meisten Fällen beeinflussen sich Prozesse, Begriffe, Architektur und Masken gegenseitig, der Klärungsprozess wird mehrmals durchlaufen und ergibt am „Ende“ ein in sich konsistentes System.
Bei dem Wort „Ende“ ist Vorsicht geboten, denn wie das Bild Vorgehensmodell erkennen lässt, kann man nur von einem vorläufigen Abschluss sprechen. – Es gibt diverse rückkoppelende Verbindungen in die nachfolgende Phase „System Design & Codierung“. Die Phase wird im Kontext einer auftragsorientierten Abarbeitung als beendet angesehen, als Arbeitsergebnis liegt eine System Analyse Spezifikation, ein Pflichtenheft, vor, das vom Projektleiter des Kunden abgenommen wird.
Die Abnahme ist eine rein kaufmännische Entscheidung, da während des nachfolgenden Prozesses immer wieder Rückkopplung in die Analysephase erfolgen.