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
Der Analytiker
Anforderungen an den Analytiker
Anforderungen Geschäftsprozess-Analytiker
Anforderungen Anforderungs-Analytiker
Anforderungen objektorientierter Analytiker
Ineinandergreifende Aufgabengebiete
Aufgabengebiet Geschäftsprozess-Analytiker
Aufgabengebiet Anforderungs-Analytiker
Aufgabengebiet objektorientierter Analytiker
Sprache als Werkzeug
Umgang mit Prozessbeteiligten
Holschuld / Bringschuld
Das Modellierungs-Werkzeug
Beim Software-Auftraggeber
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
Beim Software-Auftraggeber
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 Akteur
Anwendungsfälle vorbereiten
Anwendungsfälle definieren
Anwendungsfälle spezifizieren
Anwendungsfall mit technischem Akteur
Anwendungsfall mit menschlichem Akteur
Fazit
Objektorientiertes Design
Weiterführende Literatur
BPMN
UML
Zielsetzung & Themen
Das vorliegende Buch verfolgt das Ziel, einen strukturierten, verständlichen Weg aufzuzeigen, wie Geschäftsanforderungen effizient von der Prozessmodellierung (BPMN) in eine objektorientierte Softwarearchitektur (UML) überführt werden können, ohne sich in komplexem Fachjargon oder theoretischen Abstraktionen zu verlieren.
- Methodische Überführung von Geschäftsprozessen in IT-Systemanforderungen
- Einsatz von BPMN zur Prozessmodellierung und UML zur Systembeschreibung
- Rollenprofile und Aufgaben des Analytikers in Softwareentwicklungsprojekten
- Praxisnahe Definition von Anforderungen, Anwendungsfällen (Use Cases) und Benutzergeschichten
- Qualitätssicherung durch systematische Strukturierung während der Analyse- und Designphase
Auszug aus dem Buch
Die 180° Drehung
Bislang wurden die Tätigkeiten des Geschäftsprozess- und Anforderungs-Analytikers beschrieben, welcher überwiegend mit dem Kunden zusammen arbeitet, also mehr die auftraggebende Sicht hat.
Wenn an der Umsetzung der Arbeitsschritte in den Anwendungsfällen mitgearbeitet werden soll, muss in die Rolle des Objektorientierten-Analytikers gewechselt, also die auftragnehmende Sicht eingenommen werden.
Zusammenfassung der Kapitel
Der Analytiker: Beschreibt die notwendigen Kompetenzen und Anforderungen an verschiedene Analytiker-Rollen in Softwareprojekten.
Geschäftsprozessanalyse: Erläutert die Grundlagen, den Nutzen und die Methoden zur Modellierung und Dokumentation von Geschäftsprozessen.
Beim Software-Auftraggeber: Detailliert die Erwartungen und Prozesse auf Seiten derer, die eine Software beauftragen.
Beim Software-Auftragnehmer: Beleuchtet die Arbeitsweise und methodischen Anforderungen aus Sicht der Softwareentwickler.
Objektorientierte Softwareentwicklung: Führt in die Konzepte von Objekten, Klassen, Vererbung und Polymorphie ein, um Code-Strukturen verständlich zu machen.
Objektorientierte Analyse: Zeigt den methodischen Übergang von Geschäftsobjekten zu technischen Klassen und Anwendungsfällen auf.
Objektorientiertes Design: Erklärt, wie technische Rahmenbedingungen und Programmierparadigmen in die Entwurfsphase einfließen.
Schlüsselwörter
Geschäftsprozessmodellierung, BPMN, UML, Objektorientierte Analyse, OOA, Objektorientiertes Design, OOD, Anwendungsfall, Use Case, Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Geschäftsklassen, Softwarearchitektur
Häufig gestellte Fragen
Worum geht es in diesem Buch grundsätzlich?
Das Buch vermittelt einen methodischen Ansatz, um Geschäftsprozesse (mittels BPMN) nahtlos und nachvollziehbar in objektorientierte Softwaremodelle (mittels UML) zu übersetzen.
Welche zentralen Themenfelder behandelt der Autor?
Die Schwerpunkte liegen auf der Schnittstelle zwischen fachlicher Prozessmodellierung und technischer Softwareentwicklung sowie auf der methodischen Spezifikation von Anforderungen.
Was ist das primäre Ziel der Arbeit?
Ziel ist es, Softwareentwicklern und Analytikern einen pragmatischen, dokumentierbaren Pfad an die Hand zu geben, um Kundenwünsche präzise in funktionierende IT-Programme umzusetzen.
Welche wissenschaftliche Methode wird primär verwendet?
Es wird kein rein akademischer, sondern ein stark an der Praxis orientierter methodischer Ansatz gewählt, der auf etablierten Standards wie BPMN und UML beruht, diese aber durch eigene Vorgehensweisen ergänzt.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil umfasst die verschiedenen Analytiker-Rollen, Techniken zur Prozessaufnahme (Ist-Prozess), die Erstellung von Soll-Konzepten, die Arbeit an Lasten- und Pflichtenheften sowie die methodische Transformation in objektorientierte Anwendungsfälle und Klassenmodelle.
Welche Schlüsselwörter charakterisieren das Werk?
BPMN, UML, Geschäftsprozessanalyse, objektorientierte Analyse, Anwendungsfall, Requirements Engineering und Prozessmodellierung sind die tragenden Säulen.
Warum erfolgt die Unterscheidung zwischen auftraggebender und auftragnehmender Sicht?
Diese Perspektivänderung (die "180°-Drehung") ist entscheidend, da der Analytiker während der Anforderungsphase eine vermittelnde Rolle einnimmt, während er bei der technischen Umsetzung spezifische objektorientierte Implementierungsentscheidungen treffen muss.
Wie geht das Buch mit fiktiven Beispielen wie dem "EAF-Verfahren" um?
Das EAF-Verfahren dient als durchgängiges Fallbeispiel, anhand dessen jeder beschriebene Modellierungsschritt – von der ersten Prozessskizze über die Anwendungsfallbeschreibung bis hin zur Klassendiagramm-Erstellung – konkret illustriert wird.
- Arbeit zitieren
- Helmut Jakoby (Autor:in), 2023, Modellbasiert vom Kundenwunsch zum Programm. BPMN <-> UML, München, GRIN Verlag, https://www.grin.com/document/1309757
