≡ Ziemers
BHT-Vorlesungen

• Software Engineering 1 + 2 (BHT)
• ... Software Engineering - Formales
• ... Software Engineering 1 - Manuskript
• ... Software Engineering 2 - Manuskript
• ... Software Engineering - Fachvorträge
• ... Software Engineering 2 - Vortragsvorschläge
• ... Hinweise zu den Meilensteinen
• ... Kommentare zu Software Engineering
• ... Software Engineering - Benotung
• ... Vorbereitungen auf diese Lehrveranstaltung
• Softwarequalität und -test
• Masterprojekt
• Qualitäts- und Projektmanagement
• Communication Systems Bachelor
• Human Factors in Informatics
• Softwareprojekt 1 + 2
• Systemanalyse

Hinweise zum Meilenstein Geschäftsprozesse

Bei einer schriftlichen Abgabe (z.B. zu Corona-Zeiten):

Deckblatt mit dem Namen der Lehrveranstaltung und des Meilensteins, mit den Namen der Gruppenteilnehmenden und einer Mailadresse, über die der Dozent die Gruppe erreichen kann. Darüber hinaus alle drei unten beschriebenen Teile des Meilensteins:

Bei einer Präsentation:

Dieser Meilenstein wird von den einzelnen Übungsgruppen wie üblich in zehn bis zwölf Minuten präsentiert. Zusätzlich zu den Informationen, die Sie in den Übungen erhalten haben, besteht der Meilenstein aus folgenden drei Teilen:

Geschäftsprozessüberblicksdiagramm (Teil 1)

Viele "rote Fäden" verbinden den Inhalt dieses Meilensteins mit dem Pflichtenheft. Um diese Fäden zu visualisieren, wurden die entsprechenden Pflichtenheft-Kapitel im folgenden Text grün markiert (nicht rot, weil das eine Warnfarbe ist).

Es wird auch Use-Case-Chart genannt und enthält eine Übersicht aller Geschäftsprozesse (im Falle einer Präsentation: ... die Sie in der Präsentation zeigen möchten).
Diese Prozesse können aus der Zielbestimmung des Pflichtenhefts (1. Kapitel) abgelesen werden. Die Abgrenzungskriterien werden hierbei natürlich nicht berücksichtigt.
Die Akteure werden aus den im Pflichtenheft beschriebenen Zielgruppen (2. Kapitel) abgelesen. Beachten Sie hierbei den Vererbungspfeil, der im Manuskript (bzw. Video) erwähnt wird. Durch ihn kann die inflationäre Verwendung von Linien zwischen Akteuren und Prozessen vermieden werden.
Die drei Beziehungstypen «extends» (Sonderfall), «uses» (Prozess-Orchestrierung) und «includes» (Redundanzvermeidung durch Auslagerung) mittels derer Beziehungen zwischen Geschäftsprozessen modelliert werden, können aus der Funktionalitätsbeschreibung des Pflichtenhefts (4. Kapitel) abgeleitet werden:

• Immer dann, wenn aus einem gerade ablaufenden Prozess  heraus unter bestimmten Bedingungen ein anderer Prozess aufgerufen wird, handelt es sich um einen Sonderfall. Vergessen Sie bei den Sonderfällen nicht, die Extension Points mit ihren Conditions zu modellieren.
• Wenn zu der Bewältigung einer Aufgabe mehrere Prozesse erforderlich sind, müssen diese orchestriert werden.
• Enthalten mehrere Prozesse teilweise identische Arbeitsabläufe, lagert man diese aus.

Geschäftsprozess-Schablonen (Teil 2)

Achtung! Die Geschäftsprozess-Schablonen sind nicht in jedem Semester ein Bestandteil des Meilensteins. Bitte beachten Sie, was Ihr Dozent in der Vorlesung und in der Übung hierzu erzählt.

Gemäß der Folien (bzw. Video) aus der Vorlesung dokumentiert.
Hinweis: Die Aufzählung einzelner Verarbeitungsschritte ist in einer Geschäftsprozess-Schablone nicht (mehr) erforderlich.
Hierzu dienen heutzutage allein die Aktivitätsdiagramme (siehe unten).
Aus historischen Gründen hat man die Verarbeitungsschritte früher sowohl in den Schablonen als auch in den Aktivitätsdiagrammen dokumentiert.
Jedes Gruppenmitglied erstellt die Geschäftsprozess-Schablone ihres/seines Prozesses aus der Funktionalitätsbeschreibung des Pflichtenhefts (4. Kapitel).

Aktivitätsdiagrammen (Teil 3)

Die Aktivitätsdiagramme (Präsentation: ... die Sie in der Präsentation zeigen möchten) modellieren die einzelnen Verarbeitungsschritte eines Geschäftsprozesses.
Aktivitätsdiagramme bieten die Möglichkeit, mittels Synchronisationsbalken die möglichen Parallelitäten in den Arbeitsabläufen zu modellieren.
Ferner kann man einzelne Verarbeitungsschritte einzelnen Verantwortlichen (Akteuren) des Geschäftsprozesses zuordnen. Hierzu dienen die Swimlanes, die auch dann (einer) zu modellieren sind, wenn es nur einen Akteur gibt.
Werden Berechnungen, Prüfungen, Verarbeitungen etc. von der Software selbst ausgeführt, kann man diese in einer Swimlane namens "System" visualisieren.
Hinweis: Natürlich ist "System" in diesem Fall kein Akteur im eigentlichen Sinne, da Akteure sich immer außerhalb des Systems befinden. Dennoch dürfen Sie die Verarbeitungsschritte des Systems so modellieren.
Jedes Gruppenmitglied erstellt das Aktivitätsdiagramm ihres/seines Prozesses.
Berechnungen, Prüfungen, Validierungen etc. wurden in den Datenbeschreibungen des Pflichtenhefts (5. Kapitel) dokumentiert.
Geben Sie für jedes Aktivitätsdiagramm den vollständigen Namen derjenigen Person in Ihrer Übungsgruppe an, die für dieses Diagramm verantwortlich ist. Sollte es größere Qualitätsunterschiede in der Modellierung der einzelnen Diagramme geben, wird dies in der Note des Meilensteins berücksichtigt.