Im Mittelpunkt die Lösung

Systemanalyse 3.0

von Josef Falk

Analyse ist Denken!

So einfach ist es – im Prinzip. Das Objekt des Nach-Denkens kann vielerlei sein. Das Denken kann sich auf Gott und die Welt beziehen – oder man kann seine persönliche Situation analysieren. Nach einem Fußballspiel im Fernsehen tritt der Chef-Analytiker auf, der uns das Ergebnis seines Nach-Denkens über das eben gesehene Spiel erläutert. Um all das geht es in diesem Artikel nicht. Wir wollen hier über Analyse in IT-Projekten sprechen.

Auch das ist in erster Linie Denken. Es ist das Nach-Denken über eine Aufgabenstellung im IT-Kontext. Dieses Nach-Denken hat ein Ziel: Nämlich den Entwurf einer Lösung, die der Aufgabenstellung gerecht wird. IT-Analyse ist also das systematische Nachdenken über ein Problem, mit dem Ziel, eine Lösung für eben dieses Problem zu entwerfen.

Schon früh haben sich verschiedene Best Practices für diesen Vorgang herausgebildet, die zu Beginn des Jahrtausends zu Standards verdichtet wurden. Auf der einen Seite wurde in Kanada vom International Institute for Business Analysis (IIBA®) der Business Analysis Body of Knowledge (BABOK®-Guide) herausgegeben. Der BABOK®-Guide beschreibt Aktivitäten und Techniken für den IT-Analytiker und nennt diese Vorgehensweise „Business Analyse“. Nahezu gleichzeitig wurde in Deutschland das International Requirements Engineering Board (IREB®) gegründet, das ebenfalls verschiedene Prozesse und Techniken für den IT-Analytiker beschreibt. Hier wird diese Tätigkeit „Requirements Engineering“ genannt.

Es geht um die Lösung

Wie oben erwähnt, ist es die Hauptaufgabe des Analytikers, eine Lösung zu finden – oder auch mehrere. Sowohl Business Analyse als auch Requirements Engineering beschreiben eine ganze Reihe von Techniken. Aber gerade das Finden von Lösungen ist dabei stark unterrepräsentiert. In besonderem Maße gilt das für das Requirements Engineering, das die Lösung explizit außerhalb seines Bereiches sieht.

Der Ansatz Systemanalyse 3.0 setzt auf diesen Standards auf, geht aber darüber hinaus, indem er das Finden der Lösung in den Mittelpunkt stellt. Ein weiterer Schwerpunkt von Systemanalyse 3.0 ist die Integration der Methoden der agilen Softwareentwicklung. Fünf Quellen sind es, auf denen das Konzept von Systemanalyse 3.0 beruht:

  • Die klassische Systemanalyse
  • Business Analyse
  • Requirements Engineering
  • Der kreative Prozess
  • Agile Softwareentwicklung
Systemanalyse 3.0 - Die Quellen

Drei Hauptelemente

Der Prozess in Systemanalyse 3.0 setzt sich aus drei Hauptelementen zusammen: Analysieren – Kommunizieren – Produzieren.

Analysieren

Analysieren ist Denken – so haben wir eingangs festgestellt. Nun wollen wir es etwas detaillieren: Analysieren bedeutet „durch Zerlegung in Bestandteile genau untersuchen“. Diese Definition trifft auch sehr gut, was in der IT-Analyse passiert. Ein Problem wird in seine Bestandteile zerlegt und neu zu einem System zusammengesetzt.

Kommunizieren

Um Analyse durchführen zu können, ist Wissen erforderlich. Der Systemanalytiker muss das Arbeitsgebiet, für das er eine Lösung entwickeln soll, kennen. Der Aufbau dieses Wissens ist zumeist der erste Schritt in der Tätigkeit des Analytikers. Analyse ist kein Selbstzweck. Die Lösung wird für jemandem entwickelt – sie soll Wert für eine Organisation schaffen – und jemand wird damit arbeiten. Sowohl für den Wissensaufbau als auch für das Herausfinden des Bedarfs (der Anforderungen) muss der Analytiker mit Leuten reden. Diese Kommunikation ist jedoch keine Einbahnstraße. Schon bald werden im Kopf des Analytikers eine oder mehrere Ideen zur Lösungsfindung entstehen. In der Kommunikation mit den Stakeholdern wird der Systemanalytiker diese auf ihre Tauglichkeit prüfen.

Produzieren

Das Ergebnis der Arbeit des Systemanalytikers liegt zunächst in dessen Gehirn. Das ist aber zu wenig. Es muss anschaulich gemacht werden. Die Stakeholder müssen die Möglichkeit haben, das Ergebnis zu prüfen und dazu Stellung zu nehmen. Die Entwickler müssen auf Basis dieses Ergebnisses die Software schreiben. Aus diesem Grund muss das Ergebnis in irgendeiner Form konkretisiert und festgehalten werden. In der Praxis geschieht das durch verschiedene Modelle oder auch einfach durch Text, meist aber in einer Kombination aus beidem. Das Herstellen dieser Artefakte nennen wir „Produzieren“.

Der Mikroprozess der Systemanalyse

Der Mikroprozess der Systemanalyse 3.0

Die beschriebenen Hauptelemente – Analysieren, Kommunizieren, Produzieren – setzen sich zum Mikroprozess der Systemanalyse zusammen. Zentrales Element ist das Analysieren – also das Denken (wie eingangs erwähnt). Dieses Denken braucht Input. Unmittelbar nach dem Start des Prozesses beginnt der Analytiker mit dem Sammeln von Informationen über das Arbeitsgebiet.

Diese Informationen liegen teilweise in Papier- oder in elektronischer Form vor. Andererseits ist schon in dieser Phase die Tätigkeit des Kommunizierens erforderlich – ein Teil der erforderlichen Information ist nur durch persönlichen Kontakt mit Stakeholdern zu eruieren. Das Analysieren passiert – so wie das damit verbundene Kommunizieren – in einem iterativen Prozess, in einer Schleife.

Die erste Idee über die Lösung – die Lösungs-Hypothese – wird gemäß dem wachsenden Wissenstand des Systemanalytikers modifiziert, verworfen, neu entwickelt – immer wieder, so lange bis eine akzeptable Lösung erreicht ist. Während dieser Phase des Verfeinerns der Lösung werden eine Menge von Arbeitspapieren entstehen. Die endgültigen Dokumente, die die Lösung repräsentieren, werden erst dann erstellt, wenn die Lösung, bzw. die Lösungs-Hypothese, eine gewisse Stabilität erreicht hat – bzw. erst dann, wenn die Phase des Analysierens abgeschlossen ist.

Sinn dieser Vorgangsweise ist es, die Flexibilität des Analytikers zu bewahren. Während des Analysierens soll jederzeit die Möglichkeit und die Bereitschaft bestehen, die aktuelle Lösungs-Hypothese komplett über den Haufen zu werfen. Diese Bereitschaft nimmt mit der Menge an bereits produzierten Dokumenten ab – die dann umgeschrieben werden müssten. Deshalb soll mit deren Produktion erst dann begonnen werden, wenn Änderungen unwahrscheinlich geworden sind (gänzlich auszuschließen sind sie allerdings auch dann nicht).

Der Makroprozess der Systemanalyse

Der Makroprozess der Systemanalyse 3.0

Mehrere – und oft viele – Mikroprozesse setzen sich zum Makroprozess der Systemanalyse 3.0 zusammen. Wie diese Gliederung aussieht, ist von Fall zu Fall verschieden. Eine mögliche Variante stellt Abbildung 3 dar. 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.

Zusammenfassung

Systemanalyse 3.0 ist ein Ansatz, der die Standards von Requirements Engineering und Business Analyse verbindet und um Aspekte der Lösungsfindung ergänzt.

 

Artikel teilen
SEQIS News RSS
Autor
SEQIS Autor Josef Falk

Josef Falk

Senior Consultant
IT Analyse

Newsletter

Um neue Beiträge per E-Mail zu erhalten, hier die E-Mail-Adresse eingeben.

Unsere Autoren

Informieren Sie sich über unsere Autoren und erfahren Sie mehr über unsere Spezialisten und ihre Fachbereiche:

Zu den Autoren

Sie haben eine Frage?

Zurück

Kommentare
(Bitte geben Sie eine gültige URL mit "http://" ein.)
  • SEQIS
  • Im Mittelpunkt die Lösung
Zum Seitenanfang navigieren