Es wird ein einfacher Weg aufgezeigt, wie man von der Geschäftsprozessgestaltung zu den Anwendungsfällen, den darin enthaltenen durch Software unterstützten Abläufen und den benötigten Geschäftsklassenmodellen mit deren Methoden kommt. Im Ergebnis ist es möglich, von den Methoden zu den unterstützten Geschäftsprozessen und zurück zu navigieren.
War es in den Anfängen der Softwareentwicklung noch ausreichend, Daten zu speichern, zu berechnen und auszuwerten, wird heute von einer Software verlangt, ganze Geschäftsprozessabläufe in Ihrer Komplexität abzubilden. Diese Anforderung kann nicht ausschließlich durch einen einfachen Softwareentwicklungsprozess erfüllt werden, es müssen dafür die zugrundeliegenden Geschäftsprozesse betrachtet werden.
Es wird aber nach wie vor, auch von großen Softwareberatungsunternehmen, versucht die Geschäftsprozessentwicklung in einen Softwareentwicklungsprozess zu pressen. Zum Erfolg kommt man aber nur, wenn akzeptiert wird, dass die Entwicklung und Modellierung der Geschäftsprozesse ein anderes Gewerk ist, als die Modellierung einer Softwarearchitektur und deren Realisierung in einem Stück Software. Jedes Gewerk braucht seine Spezialisten und sein eigenes Vorgehen.
Dabei ist es relativ einfach mit heutigen Werkzeugen leichtgewichtig, von den Geschäftsprozessen und deren Arbeitsschritten über die Anwendungsfälle mit ihren funktionalen Anforderungen bis zu den einzelnen Funktionen bzw. Methoden und Daten einer Klasse zu gelangen.
Es ist von erheblichem Vorteil, wenn bei einer Geschäftsprozessänderung die einzelnen betroffenen Anwendungsfälle mit deren Aktivitätsdiagrammen und die betroffenen Methoden der Klassen im unmittelbaren Zugriff sind. Nur dann kann man diese den Anforderungen gemäß anpassen.
Diese Softwareänderung hat eventuelle Auswirkungen auf Arbeitsschritte in unterschiedlichen Geschäftsprozessen, welches ein unerwünschter Seiteneffekt sein kann. Mit diesem Seiteneffekte kann man jetzt unmittelbar kontrolliert umgehen. Software ist somit nicht mehr als eigenständige Sache zu betrachten, sondern ist der integrierte und nicht abzukoppelnde Bestandteil von Geschäftsprozessen.
Inhaltsverzeichnis
Vor-Vorwort
Vorwort
Um was geht es in dieser Anleitung?
Um was geht es nicht in dieser Anleitung?
Definitionen
Einleitung
Die Analytikerin
Anforderungen an die Analytikerin
Anforderungen Geschäftsprozess-Analytikerin
Anforderungen Anforderungs-Analytikerin
Anforderungen objektorientierte Analytikerin
Ineinandergreifende Aufgabengebiete
Aufgabengebiet Geschäftsprozess-Analytikerin
Aufgabengebiet Anforderungs-Analytikerin
Aufgabengebiet objektorientierte Analytikerin
Sprache als Werkzeug
Umgang mit Prozessbeteiligten
Holschuld / Bringschuld
Das Modellierungs-Werkzeug
Bei der Software-Auftraggeberin
Geschäftsprozessanalyse
Umgang
Geschäftsprozess beschreiben
Geschäftsprozess darstellen
Geschäftsprozess spielen
Geschäftsprozess ändern
Granularität des Geschäftsprozesses
Modellierungsebenen
Geschäftsprozess-Notationselemente
Prozesslandkarte
Kernprozess und unterstützender Prozess
Globaler Subprozess
Prozessname
Geschäfts- bzw. Datenobjekt
Rolle
Sequenzfluss und Entscheidungsknoten
Prozessschritt
Ist-Prozess
Reengineering von Geschäftsprozessen aus einem IT-System
Ursprüngliche Anforderungen nachdokumentieren
Verfahrensentwicklung
Prozessbeteiligte
Grobe Anforderungen
Fragenkatalog
Geschäftsobjekte
EAF-Antrag
EAF-Antragsausfüllhilfe
EAF-Bescheid
EAF-Akte
Erste Schritte
Weiteres Vorgehen
Mehr Geschäftsobjekte
EAF-Antragsarchiv
EAF-SteuerID-Anfrage
EAF-SteuerID-Antwort
Weitere Schritte
Szenarien durchspielen
Geschäftsprozess und Anforderung
Umfeldanalyse
Anforderungen
Funktionale Anforderungen ermitteln
Anforderungen im Steckbrief
Anforderungen zerhackstücken
Benutzergeschichte (User-Story)
Soll-Prozess
Lastenheft
Lastenheft nicht-funktionaler Anforderungen
Lastenheft funktionaler Anforderungen
Die 180° Drehung
Bei der Software-Auftragnehmerin
Anwendungsfallanalyse
Pflichtenheft
Pflichtenheft nicht-funktionaler Lösungen
Pflichtenheft funktionaler Lösungen
Objektorientierte Softwareentwicklung
Umgang
Modellieren und beschreiben
Der Anwendungsfall
Das Objekt
Die Klasse
Generalisierung / Vererbung
Polymorphie
Kapselung / Sichtbarkeit
Attribut
Methode
Nachricht
Objektbeziehung
Objektorientierte Analyse
Umgang
Geschäftsklassen ermitteln
Anwendungsfälle ermitteln
Anwendungsfall Akteurin
Anwendungsfälle vorbereiten
Anwendungsfälle definieren
Anwendungsfälle spezifizieren
Anwendungsfall mit technischer Akteurin
Anwendungsfall mit menschlicher Akteurin
Fazit
Objektorientiertes Design
Weiterführende Literatur
BPMN
UML
Zielsetzung & Themen
Die vorliegende Arbeit zielt darauf ab, einen praxisorientierten Weg aufzuzeigen, wie Geschäftsprozesse effektiv in objektorientierte Softwarestrukturen übersetzt werden können. Die Arbeit fokussiert sich dabei auf die methodische Modellierung und Dokumentation unter Verwendung von BPMN (für Prozesse) und UML (für technische Softwareanalysen), um eine klare Kommunikation zwischen Auftraggebenden und Softwareentwickelnden zu ermöglichen.
- Methodische Überführung von Geschäftsprozessmodellen in objektorientierte Klassendiagramme.
- Erstellung und Spezifikation von Anwendungsfällen (Use Cases) in der UML.
- Anwendung von BPMN zur Visualisierung und Klärung von Geschäftsabläufen.
- Praxisorientierte Aufbereitung der Anforderungsanalyse und Pflichtenhefterstellung.
- Integration von Rollenprofilen (z.B. Geschäftsprozess- vs. objektorientierte Analytikerin).
Auszug aus dem Buch
Die Analytikerin
In heutigen Softwareentwicklungsprojekten werden Analytikerinnen in unterschiedlichen Rollen benötigt. In jeder dieser einzelnen Rollen muss die Analytikerin zusätzliche Anforderungen erfüllen.
Eine ausgeprägte Auffassungsgabe und ein hohes Abstraktionsvermögen sind unabdingbar, um die Aufgaben Analytikerin zu erfüllen.
Die Analytikerin muss sich sehr früh gründlich in das jeweilige Fachgebiet einarbeiten. Komplexe Zusammenhänge müssen verstanden werden. Die Fachtermini des Analysegebiets muss erfasst und genutzt werden, um mit den Prozessbeteiligten kommunizieren zu können. Eine hohe soziale Kompetenz wird ihr abverlangt, um Aussagen der Prozessbeteiligten richtig zu interpretieren.
Die Fähigkeit geduldig zuzuhören und zur richtigen Zeit die richtigen Fragen zu stellen benötigt einen ausgewogenen Kommunikationsstil (Stichwort "aktives Zuhören"). Manchmal kann einfaches Zuhören ohne jemanden zu stören eine Herausforderung sein. Um Sachverhalte mit einer Gruppe auf einen Nenner zu bringen, müssen mehrere Moderationstechniken beherrscht werden.
Grundsätzlich soll versucht werden, komplexe Themen zu vereinfachen. Dies kann zu dem Missverständnis führen, dass man eine hochkomplexe Thematik nicht verstanden hat. Häufig stellt sich nämlich heraus, dass ursprünglich einfache Abläufe durch anflanschen von zusätzlichen Anforderungen immer komplexer geworden sind. Jede neue Anforderung wurde an den Ablauf angepasst, welches den Ablauf nur unübersichtlicher macht. Aus diesem Teufelskreis kommt man nur heraus, wenn der Geschäftsprozess mit der grundsätzlichen Anforderung neu gestaltet wird. Da ist manchmal sehr viel Geduld und Ausdauer notwendig, den einzelnen Mitarbeiterinnen die einfachere Struktur nahe zu bringen. Auch wenn man Konsens erreicht hat, den Prozess gänzlich neu aufzusetzen, wird oft in die alten Denkstrukturen zurückgefallen.
Als Analytikerin ist man in der jeweiligen Rolle der Methodenspezialistin.
Zusammenfassung der Kapitel
Die Analytikerin: Dieses Kapitel erläutert die notwendigen Kompetenzen und unterschiedlichen Rollenprofile von Analytikerinnen in Softwareprojekten, insbesondere im Hinblick auf soziale Intelligenz und methodisches Vorgehen.
Bei der Software-Auftraggeberin: Hier werden die Grundlagen der Geschäftsprozessanalyse beleuchtet, wobei der Fokus auf Transparenz, Dokumentation und der Bedeutung der Granularität von Prozessmodellen liegt.
Bei der Software-Auftragnehmerin: Dieses Kapitel beschreibt den Übergang zur technischen Umsetzung mittels objektorientierter Analyse und die Erstellung von Pflichtenheften basierend auf den vorangegangenen Analyseergebnissen.
Schlüsselwörter
Geschäftsprozessmodellierung, BPMN, UML, Objektorientierte Analyse, Anforderungsanalyse, Softwareentwicklung, Pflichtenheft, Anwendungsfall, Klassendiagramm, Prozessschritt, IT-System, Modellierung, Systementwurf, Geschäftsobjekte, Softwarearchitektur.
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit befasst sich mit dem methodischen Übergang von der Geschäftsprozessmodellierung (BPMN) hin zum objektorientierten Softwareentwurf (UML).
Was sind die zentralen Themenfelder?
Die zentralen Themen sind die Rolle der Business-Analytikerin, die Modellierung von Soll-Prozessen, die Ableitung von Anforderungen sowie die technische Spezifikation mittels objektorientierter Analyse.
Was ist das primäre Ziel oder die Forschungsfrage?
Das Ziel ist es, einen einfachen und nachvollziehbaren Weg aufzuzeigen, wie komplexe Geschäftsprozesse in technische Softwareanforderungen und objektorientierte Klassenstrukturen überführt werden können.
Welche wissenschaftliche Methode wird verwendet?
Es wird ein Modell-basierter, iterativer Ansatz verfolgt, der auf den Standards BPMN für Abläufe und UML für die statische und dynamische Struktur von Softwareobjekten basiert.
Was wird im Hauptteil behandelt?
Der Hauptteil beleuchtet detailliert die Analysephase, die Erstellung von Anforderungssteckbriefen, die Definition von Anwendungsfällen (Use Cases) und deren Verknüpfung mit den Prozesslandschaften.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die wichtigsten Begriffe sind Geschäftsprozessmodellierung, BPMN, UML, Objektorientierung, Requirements Engineering und Prozessdesign.
Warum ist die Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen wichtig?
Diese Trennung ist entscheidend für die Strukturierung von Lasten- und Pflichtenheften, da sie unterschiedliche Aspekte der Systemrealisierung betreffen und im Projekt unterschiedliche Verantwortlichkeiten ansprechen.
Was ist der Zweck der "180° Drehung" im Konzept?
Die 180°-Drehung beschreibt den Rollenwechsel der Analytikerin: von der fachlichen Unterstützung der Auftraggeberseite (Sicht auf den Ablauf) zur technischen Modellierung auf der Auftragnehmerseite (Sicht auf die Klassen und Methoden).
Wie hilft der Aktionskatalog bei der Modellierung?
Er hilft dabei, unklare Anforderungen zu systematisieren und sicherzustellen, dass für jeden Prozessschritt Verantwortlichkeiten, Inputs, Outputs und Zustände explizit definiert werden.
- Citar trabajo
- Helmut Jakoby (Autor), 2023, Modellbasiert vom Kundenwunsch zum Programm. BPMN <-> UML, Múnich, GRIN Verlag, https://www.grin.com/document/1309750
