Kapitel 3: Die Quellen

Zum vorherigen Artikel der Reihe

Die Quellen

(In dem wir vorstellen, was die Quellen von Systemanalyse 3.0 sind und wo die Gemeinsamkeiten und Unterschiede liegen)

Systemanalyse 3.0 - das ist nicht die Neuerfindung des Rades. Auf der Basis des Verständnisses eines Arbeitsgebiets Lösungen entwickeln - das gehört seit jeher zum Handwerkszeug in der Software-Entwicklung. Systemanalyse 3.0 bringt jedoch verschiedene Ansätze unter ein gemeinsames Dach. Verschiedene Konzepte werden neu kombiniert, sodass letztlich doch etwas Neues entsteht.

In diesem Kapitel werden die Grundzüge der einzelnen Quellen dargestellt, es wird diskutiert, inwieweit deren Konzepte in Systemanalyse 3.0 eingehen - und worin sie sich von Systemanalyse 3.0 unterscheiden. Dadurch wollen wir die Grundlage dafür legen, dass in den Folgekapiteln die Vorgehensweise in Systemanalyse 3.0 näher dargestellt werden kann.

Folgende Konzepte und Methoden werden im Folgenden behandelt:

• klassische Systemanalyse
• Business Analyse
• Requirements Engineering
• Agile Softwareentwicklungs-Methoden
• Kreativitätsprozess.

Systemanalyse

Bis etwa zum Jahr 2000 war "Systemanalyse" auch die gängige Bezeichnung für die "frühen Phasen" in einem Software-Projekt. Zu diesem Zeitpunkt kam es in der Disziplin des Projektmanagements zu Standardisierungsbestrebungen. Damit verbunden war die Möglichkeit, sich auf diese Standards zertifizieren zu lassen.

Diese Möglichkeit sollte auch für Systemenalytiker geschaffen werden und so entstanden - quasi als Abspaltung von der Systemanalyse - die Disziplinen der Business Analyse und des Requirements Engineering.

Systemenalyse 3.0 greift die Tradition der Systemanalyse wieder auf und integriert dabei die neuen Entwicklungen der Business Analyse und des Requirements Engineering.

Inhalt

"Die Systemanalyse ist ein systematischer und systemischer Ansatz zur modellbasierten Analyse eines Unternehmensbereichs. Dabei werden für eine definierte Problemstellung im Kontext der Wirtschaftsinformatik, wie z. B. Anforderungsanalyse, Softwarekonzeption, Prozessverbesserung, Umstrukturierungen, Anforderungen an eine Lösungsgestaltung definiert oder eine Lösung im Sinne einer Intervention gestaltet." [KRALLMANN2013]

Auch in der klassischen Systemanalyse geht es also um die Analyse von definierten Problemstellungen und um die Gestaltung von Lösungen dafür.

Es gibt eine Reihe von Beschreibungen des Prozesses in der Systemanalyse, die sich jedoch alle rund um die Schritte "Istanalyse" und "Sollkonzept" gruppieren. Das gilt auch für den in Abbildung 1 dargestellten Prozess.

Nach dem Schritt "Projektbegründung", in dem das Projekt gestartet wird, wird der aktuelle Zustand des Arbeitsgebietes aufgenommen und analysiert. Auf diesem aufbauend wird das zukünftige System entworfen - es wird ein "Sollkonzept" erstellt. Dieses wird im Anschluss realisiert, d.h. konkret, es wird die Software entwickelt. Unter Implementierung wird dann schließlich die Inbetriebnahme des neuen Systems verstanden.

Systemanalyse und Systemanalyse 3.0

Das hier dargestellte Konzept der Systemanalyse 3.0 hat mit der klassischen Systemanalyse nicht nur den Namen gemeinsam. Auch der Inhalt, dass auf Basis des Problemverständnisses eine Lösung (oder auch mehrere Lösungen) für eine Problemstellung gefunden werden soll, findet sich sowohl in der klassischen Systemanalyse als auch in Systemanalyse 3.0.

Und doch gibt es auch folgende Unterschiede:

• Realisierung und Implementierung liegen nicht im Aufgabenbereich von Systemanalyse 3.0. Die Lösung ist zwar das Hauptziel von Systemanalyse 3.0 - die Aufgabe endet aber bei der Konzeption der Lösung. Die Implementierung einschließlich der Konzeption der System-Architektur liegt nicht im Kompetenzbereich von Systemanalyse 3.0.
• Die Analyse des Ist-Systems ("Ist-Analyse") kann ein bedeutender Schritt für das Verständnis des Arbeitsgebiets sein und hat dadurch auch einen Platz in Systemanalyse 3.0. Es wird aber immer auch Situationen geben, wo das nicht erforderlich ist. Deshalb ist die "Istanalyse" kein eigener Punkt in der Beschreibung von Systemanalyse 3.0.
• Der Prozess in Abbildung 1 ist ein typisches Beispiel für die "Wasserfall"-Vorgehensweise - zuerst Projektbegründung, dann Istanalyse, dann Sollkonzept, dann Realisierung, dann Implementierung. Systemanalyse 3.0 bekennt sich zum agilen Paradigma, wie es durch das Agile Manifest ausgedrückt wird.
• Systemanalyse 3.0 legt einen deutlicheren Schwerpunkt auf das Finden der Lösung - insbesondere auf die Kreativität, die dafür erforderlich ist.

Business Analyse

Begriff und Inhalt der Business Analyse sind untrennbar mit dem "International Institute of Business Analysis" (IIBA) verbunden. Das IIBA wurde 2003 in Toronto gegründet und hat sich folgende Aufgabenstellungen gesetzt:

• Förderung der Wahrnehmung und Anerkennung des Berufsbilds des Business Analysten
• Schaffung eines Standards für die Business Analyse durch Herausgabe des Business Analysis Body of Knowledge (BABOK-Guide)
• Förderung der öffentlichen Anerkennung qualifizierter Business Analysten durch international anerkannte Zertifikate.

Inhalt

Mit dem BABOK-Guide hat das IIBA einen anerkannten Standard für die Business Analyse geschaffen. Der BABOK-Guide (Version 3) definiert den Inhalt der Business Analyse durch die Beschreibung von Tasks, die zu sechs Wissensgebieten (Knowledge Areas) zusammengefasst werden:

• Business Analysis Planning and Monitoring: In diesem Wissensgebiet geht es darum, festzulegen, welche Inhalte der Business Analyse-Prozess haben wird. Es regelt die Identifikation der Stakeholder, die Auswahl von Business Analyse-Techniken, den Prozess für die Verwaltung der Anforderungen und die Messung des Arbeitsfortschritts.
• Elicitation and Collaboration: beschreibt, wie die Business Analysten mit den Stakeholdern zusammenarbeiten, um deren Bedarf zu identifizieren und zu verstehen.
• Requirements Life Cycle Management: beschreibt, wie der Business Analyst Anforderungen während ihres Lebenszyklus behandelt, wie die Anforderungen verfolgt, verwaltet und priorisiert werden.
• Strategy Analysis: beschreibt, wie Business Analysten einen Bedarf identifizieren und davon eine Strategie ableiten.
• Requirements Analysis and Design Definition: beschreibt die Modellierung der Anforderungen und wie die Anforderungen in ein Design übergeführt wird.
• Solution Evaluation: beschreibt, wie Business Analysten Lösungen bewerten und wie deren Beitrag zum Geschäftswert gesteigert wird.

Mit diesen Wissensgebieten wird kein Prozess festgelegt. Vielmehr bieten sie ein Framework, das individuell in einem Vorhaben verwendet werden kann. Die Zusammenhänge der Wissensgebiete sind in Abbildung 2 dargestellt.

Business Analyse und Systemanalyse 3.0

Die Business Analyse, wie sie im BABOK-Guide dargestellt ist, ist die Basis für Systemanalyse 3.0. Es wird allerdings ein besonderer Schwerpunkt auf den IT-Kontext gelegt, sodass man Systemanalyse 3.0 als "Business Analyse im IT-Kontext" bezeichnen kann.

Darüber hinaus gibt es einige weitere Besonderheiten in Systemanalyse 3.0:

Die Wissensgebiete und Aufgaben des BABOK-Guide sagen sehr wenig über den Weg aus, wie ein Business Analyst Lösungen, wenn möglich originelle Lösungen, findet. Es steht hier viel über das Finden der Anforderungen und über das Bewerten der Lösungen, aber kaum etwas über die Lösungsfindung. Durch Integration des Kreativitätsprozesses versucht Systemanalyse 3.0, dieses Manko zu beheben.

In der Version 3.0 des BABOK-Guides wird in einer der so genannten "Perspektiven" auf Agile Softwareentwicklungs-Methoden eingegangen. Außerdem wurde vom IIBA eine "Agile Extension to the BABOK-Guide" herausgegeben. Systemanalyse 3.0 baut die Ideen aus dem Agilen Manifest direkt in sein Vorgehensmodell ein.

Requirements Engineering

Es war ein langer Prozess, der die Anforderungen mehr und mehr ins Zentrum der Systemanalyse rückte und schließlich auch eine eigene Disziplin begründete - das Requirements Engineering. Die ersten diesbezüglichen Veröffentlichungen reichen bis in die 70er-Jahre zurück. Zu einem regelrechten Boom kam es nach der Jahrtausendwende. In diese Zeit fällt auch die Gründung des "International Requirements Engineering Boards" (IREB), das sich ebenso wie das IIBA in Sachen Business Analyse für eine Standardisierung einsetzt und Zertifizierungen für Ausübende dieser Disziplin anbietet.

Inhalt

Das "International Requirements Engineering Board" (IREB) hat mit seiner Zertifizierung zum "Certified Professional in Requirements Engineering" (CPRE) einen de-facto-Standard im Requirements Engineering geschaffen. Die Inhalte sind in den entsprechenden Lehrplänen abgebildet.

Der IREB-Lehrplan sieht folgende Hauptaktivitäten im Requirements Engineering:

• Ermitteln der Anforderungen
• Dokumentieren der Anforderungen
• Prüfen/Abstimmen der Anforderungen
• Verwalten der Anforderungen.

Requirements Engineering und Systemanalyse 3.0

Die Anforderungen sind eine wichtige Grundlage für jede IT-Lösung - wenn nicht sogar die wichtigste. Das ist auch in Systemanalyse 3.0 so. Die Wege, wie man zu diesen kommt, sind in Systemanalyse 3.0 die gleichen wie im Requirements Engineering. Es gibt also große Gemeinsamkeiten.

Der wesentliche Unterschied besteht aber darin, dass in der Systemanalyse 3.0 das Design der Lösung explizit als Aufgabe gesehen wird, ja als eigentliches Ziel aller Bemühungen. Die Tätigkeit endet also nicht mit der Erhebung und Dokumentation der Anforderungen, eigentlich beginnt sie damit erst.

In Systemanalyse 3.0 sind die Anforderungen nur insofern von Bedeutung, als sie wichtig für das Verständnis des Arbeitsgebietes sind - und unter Umständen auch in die Lösung eingehen. Das tun sie dann, wenn der Systemanalytiker nicht einvernehmlich mit dem Stakeholder eine Alternative für die Anforderung findet, die den eigentlichen Bedarf des Stakeholders in besserer Art und Weise deckt.

Die von den Stakeholdern genannten Anforderungen werden festgehalten, damit sie nicht verloren gehen. Ein darüber hinaus gehendes "Management" oder "Engineering" der Anforderungen wird im Allgemeinen nicht erforderlich sein. Das "Engineering" gilt der Lösung - und nicht den Anforderungen.

Wobei hier jedoch nicht bestritten werden soll, dass es durchaus auch Situationen gibt, wo die Ermittlung der Anforderungen im Zentrum steht. Ein Beispiel dafür ist die Erstellung von Ausschreibungsunterlagen, wo es zunächst gar nicht darum geht, eine Lösung zu entwickeln, sondern wo ein Lieferant gefunden werden soll, dessen Produkt die ermittelten Anforderungen erfüllt. In diesem Fall sind Anforderungen tatsächlich das Endprodukt der Arbeit des Systemanalytikers.

Agile Software-Entwicklung

Systemanalyse 3.0 ist Business Analyse im IT-Kontext. Und man kann nicht über Analyse im IT-Kontext sprechen, ohne auch über Agile Softwareentwicklungs-Methoden zu sprechen, die vor über zehn Jahren ihren Siegeszug angetreten haben. Die Agilen Methoden haben den Softwareentwicklungs-Prozess erfolgreich und unwiderruflich verändert.

Auf Basis des Agilen Manifests, das im Jahr 2001 veröffentlicht wurde, hat sich eine Reihe von konkreten Agilen Methoden entwickelt, die alle in gewisser Weise Auswirkungen auf die Arbeit des Systemanalytikers haben.

Inhalt

Hier sollen nicht die einzelnen Agilen Methoden behandelt werden. Vielmehr soll deren gemeinsame Grundlage - nämlich das besagte Agile Manifest aus dem Jahr 2001 dargestellt werden.

In der Agilen Softwareentwicklung schätzt man:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als Befolgen eines Plans.

Zu beachten ist, dass auch die Werte auf der rechten Seite wichtig sind, die Werte auf der linken Seite werden jedoch höher eingeschätzt.

Kennzeichen aller Agilen Methoden ist es auch, einen Gegensatz zum so genannten Wasserfall-Modell der Software-Entwicklung zu bilden. Durch den Einsatz von iterativ-inkrementellen Vorgehensweisen soll die notwendige Flexibilität erreicht werden, um auf sich ändernde Anforderungen schnell und adäquat reagieren zu können.

Agile Methoden und Systemanalyse 3.0

Systemanalyse 3.0 ist neutral in Bezug auf die Vorgehensweise in der Software-Entwicklung. Der Prozess ist skalierbar und kann gleichermaßen für traditionelle und für Agile Methoden der Software-Entwicklung eingesetzt werden.

Die Unterstützung für die Agilen Methoden ist in Systemanalyse 3.0 unmittelbar integriert und wird nicht nur durch wiederholtes Ablaufen einzelner Prozessschritte abgebildet.

Der kreative Prozess

Das Finden einer Lösung für eine Problemstellung ist die zentrale Aufgabe des Systemanalytikers. Diese Lösung ergibt sich nicht gleichsam automatisch aus den erhobenen Anforderungen, sondern dazu bedarf es einer kreativen Anstrengung. Jetzt ist Kreativität nicht etwas, das man verordnen kann oder das durch Befolgen eines Prozesses sichergestellt werden kann.

Dennoch gibt es mehrere wissenschaftliche Ansätze, wie der kreative Prozess verläuft. Einer der ältesten - und dennoch bis heute gültigen - stammt von Graham Wallas, der im Jahr 1926 Ideen des deutschen Physiologen Hermann von Helmholtz und des französischen Mathematikers Henri de Poincaré zu einer systematischen Theorie des kreativen Denkens zusammengefasst hat.

Inhalt

Graham Wallas definiert vier Schritte im kreativen Prozess:

• Vorbereitung: In der ersten Phase wird die Aufgabenstellung definiert. Durch Aneignung von Kenntnissen und Sammlung von Informationen wird die Basis für das Finden der Lösung gelegt.
• Inkubation: Hier reifen die Ideen auf Basis der in der Vorbereitungsphasen gesammelten Informationen. Der Kreative entfernt sich bewusst von dem Problem, tut gar nichts, oder beschäftigt sich mit den Themen, die nichts mit dem zu lösenden Problem zu tun haben. Die Kenntnisse, die in der ersten Phase aufgebaut wurden, können ins Unterbewusstsein absinken und dort schwebend weiterverarbeitet werden.
• Illumination: Hier kommt das, was in der Inkubationszeit wächst, zum Vorschein. Das kann in der Form eines Heureka-Erlebnisses, eines Geistesblitzes, sein. Sehr häufig aber wächst die Idee langsam, konkretisiert sich immer stärker, so lange bis - zunächst im Kopf - ein fertiges Konzept vorhanden ist, das schließlich festgeschrieben werden kann.
• Verifikation: In dieser Phase werden die meist noch unstrukturiereten Ideen aus der Illuminations-Phase zu einem durchgängigen Konzept ausgearbeitet. Darin enthalten ist auch die Prüfung auf Machbarkeit.

Der kreative Prozess und Systemanalyse 3.0

Das Finden von Lösungen ist Aufgabe des Systemanalytikers. Deshalb gibt jede gute Vorgehensweise Raum für die genannten vier Phasen der Kreativität. Systemanalyse 3.0 tut dies, indem sie keinen strikten Prozess vorgibt, sondern Tätigkeiten beschreibt, die einen groben Rahmen bieten, innerhalb dessen sich der Systemanalytiker sehr frei bewegen kann. Die vier Phasen des kreativen Prozesses können sich innerhalb dieser Tätigkeiten entfalten, sodass die Voraussetzung für kreative Lösungen geschaffen wird.

Zum folgenden Artikel der Reihe