Praxisprojekte Sommersemester 2012[Bearbeiten]

Die Stakeholder (= Projekteigner = Kunden) haben gesprochen und wir müssen handeln. Alle identifizierten Projekte brennen den Projekteignern unter den Nägeln, d.h. sie verlassen sich auf die Güte Ihrer Arbeit!

Update: wir machen jetzt doch nur BPMN und Use Cases (Anwendungsfälle) aus der UML, d.h. Aktivitätsdiagramme sind nicht notwendig. Der Grund überhaupt UML zu machen bestand nur deshalb, weil die Referenzprozesse der HIS in UML modelliert sind—aber bei denen von uns ausgewählten Prozessen haben wir keine Referenzprozesse dabei.

Bitte tragen Sie sich (Nachname genügt) in der Tabelle unter dem entsprechenden Projektprozess schon einmal ein. Die Erläuterungen finden Sie unter der Tabelle noch einmal. Die endgültigen Teams teilen wir dann noch ein. Sie müssen nicht als Team arbeiten, das ist aber natürlich sinnvoll und erwünscht.

E-Media Unterprojekte[Bearbeiten]

Name:	T1: E-Learning mit E-Books	T2: Hochschulschriftenverwaltung	T3: Publikationsbestellung
Koordinator/in	Britta Letz	Feride Aktas	Lars Reimer
Teammitglied	Danny Weihs	Elina Ovcinnikova	Patrick Gorre
Teammitglied	Martin Koltermann	Dirk Rosenau	Sascha Wittenberger
Teammitglied		Sarah Zell
Teammitglied		Kristian Hildebrandt	Paul Eberhard
Teammitglied			Mario Welke

Projektbeteilligte (HWR): C Rupp/B Skerka

Schnittstelle E-Books und E-Learning: wie werden die E-Books beim E-Learning verwendet (z.B. Moodle) — für bereits vorhandene (via DB) E-Books.
Verwaltung von Hochschulschriften: HWR Publikationen; Veröffentlichung usw. verschiedene Schnittstellen im Haus.
Publikationsbestellung: E-Publikation — Prüfung ob vorhanden; Herstellung/Lieferung an Kunden (Lehrenden)
Integration von E-Books in die Bibliothek: Kaufen von E-Books, die noch nicht in Datenbanken vorliegen; dazu gehört auch Rechteverwaltung und Lagerung, Verwendung und Integration in Moodle-Kurse.

E-Books für Studierende: PaperC CRM

E-Learning Unterprojekte[Bearbeiten]

Name:	T5: Belegdaten nach Moodle	T6: Supportorganisation	T7: Wissensmanagement	T8: RZ Kommunikation
Koordinator/in	Falco Bartsch	Tobias Ebbing	Romano Koch	Alexander Niemeier
Teammitglied	Daniel Kölsch	Daniel Kraus	Michael Luksch	Pascal Jung
Teammitglied	Michael Darko	Robert Kuls	Sophia Karge	Anh-Tuan Nguyen
Teammitglied		Jérôme Dülger		Jens F.
Teammitglied		Michael Groß	Kai Naß	Marco Müller
Teammitglied		Leon Lowitzki
Link				T8: Kommunikation

Projektbeteilligte (HWR): D Schild/S Mey/K Drasdo/A Freiberg

Übertragung von Beleg- und Nutzerdaten nach Moodle (Lern- und Lehrplattform)
Support organisieren und erhalten für Studenten und Dozenten, einschließlich Einführungsveranstaltungen (übertragbar auf andere Abteilungen)
Wissensmanagement im E-Learning Team (Job- und Informationsübergabe; Lessons Learnt, Dokumentationserstellung) — übertragbar auf andere Abteilungen
Kommunikation zwischen E-Learning Team und Rechenzentrum (übertragbar auf andere Abteilungen)

Vorbereitung auf die Kundeninterviews[Bearbeiten]

In der letzten Sitzung kam die Frage auf, ob und wie Sie sich am Besten auf die Kundeninterviews am 04.05. vorbereiten können. Ich werde in dieser Woche drüber nachdenken, aber in der Zwischenzeit können Sie vielleicht hier schon einige Ideen (oder Fragen) parken (wie immer gerne anonym)! Werde das auch über unser Moodle Forum anstossen...--Birkenkrahe 10:32, 21. Apr. 2012 (CEST)

Suche nach vergleichbaren Prozessen und Best-Practice-Beispielen.

Beispiel: IT Service Support (Prozesslandkarte der Information Technology Infrastructure Library, ITIL)

Brainstorm in der Gruppe > Mindmap von Objekten und Akteuren (Menschen und Systeme), um Ideen für zu modellierende Klassen zu erhalten.

Beispiel: Innovative Anwendungen von Mindmaps

"Frisch, fromm (?) und frei" ein paar Use Cases aufmalen wie in der Vorlesung gesehen: Schwerpunkt liegt auf den Konzepten und der richtigen System-Brille (d.h. richtige Granularität).

Beispiel 1: Bankautomat—schreiben Sie ein "Visions-Dokument" wie eingangs erläutert, das ihre ersten Gedanken und Informationen zum Anwendungsbereich und -Prozess widerspiegelt. Modelle wie Organigramm und Funktionenbaum sind auch nützlich, aber führen aus der UML heraus (wie wir besprechen werden, ist das nicht nützlich).

Beispiel 2: im nebenstehenden Use Case wurde versuchsweise das 'E-Learning Team' skizziert, mit zwei Akteuren und einigen Use Cases, wie dem Notieren von Erfahrungen oder dem Prüfen des eigenen Job-Profils (wie hinterlegt, falls es existiert) durch das Teammitglied, das geht, oder das Notieren von Stärken und Schwächen dieses Teammitglieds durch die Teamleitung. So eine Skizze hat den Vorteil, dass damit schon Bereiche abgegrenzt werden, bzw. genauere Fragen formuliert werden können (z.B. "gibt's das schon?") bzw. gruppiert werden kann ("Stärken und Schwächen" ist auch ein Erfahrungsbericht, d.h. beide Akteure erstellen Erfahrungsberichte—eine gemeinsamer Use Case).

BPMN Tutorial und Vorlesung mit Übungen erneut lesen und Übungen nachvollziehen.

Sich mit Ihrem Team treffen und das gemeinsame Vorgehen diskutieren.

Planung des ersten Workshops[Bearbeiten]

Am 27.04. haben wir (im Beisein von D Schild, der von Seiten des RZ bereits andere Workshops mit Mitarbeitern begleitet hat) das ungefähre Vorgehen während des ersten Mini-Workshops mit den Kunden besprochen und sind zu folgendem Plan gelangt:

Wir werden ausschließlich Use Cases (Anwendungsfälle) modellieren anstatt die Kunden mit BPMN zu langweilen (obwohl langfristig auch ein Kunden-Lernprozess angestossen werden muss: die HWR plant Erstellung eines Prozesshandbuchs, das die Mitarbeiter auch ohne IT-Kenntnisse dann lesen können müssen). Empfehlenswert, sich über die Use Cases nochmal zu belesen, z.B. in diesem Tutorial.

Voraussichtlich werden wir die Kundengespräche während des Workshops nach einer Begrüßung in zwei oder drei Untergruppen führen, je nach Zahl der Kunden, so dass leichter kommuniziert werden kann. Zur Aufnahme der Gespräche (informell, aber mit Einwilligung der Kunden) wird geraten. Ich werde den Kunden ein paar Tage vor dem Termin (04.05.) noch eine Nachricht schicken, die ich auch im Forum an die Studierenden schicke.

Die Kommunikation mit den Kunden zwischen den Workshops muss explizit verhandelt werden—Möglichkeit und Interesse an Zwischenergebnissen und Kommunikation. Ich werde in Moodle für jedes der Praxisprojekte ein Forum einrichten, in dem die Kunden dann mit Ihnen nach eigenen Zeitplan kommunizieren können.

Die Frage kam auf: wann ist Schluss mit modellieren, das heißt welchen Umfang sollen die Modelle haben? — Antwort: das hängt vom Kundenauftrag ab (d.h. sollte verhandelt werden) ist aber auch durch den Endpunkt (den zweiten Workshop am 29.06.) vorgegeben, wenn Ergebnisse vorgestellt werden sollen. Die Idee ist, die besten Ergebnisse dann mit ins nächste Semester zu nehmen, und andere Studierende daran arbeiten zu lassen.

Bedingungen für die Ergebnisse (Prozessmodelle):

Fehlerfreiheit (benutze auch den Signavio Checker)
Vollständigkeit bzw. Aussage über Vollständigkeit des Modells
Soll enthalten Use Case (Anwendungsfälle) und Prozessdiagramme in BPMN 2.0. Kollaborationsdiagramme, Konversationen und Choreographien (aus der BPMN 2.0) sind optional.

Zu den Projekten gehört auch ein gerütteltes Maß an Projektmanagement, das Sie in den vergangenen Semestern an verschiedenen Projekten bereits geübt haben, auch in größeren Gruppen wie diesmal. Dazu gehört ein Plan (einschl. Zeitplan) sowie evtl. einige Werkzeuge, die den Austausch von Daten und die Organisation einfacher machen. Außerdem ist in Signavio für jedes Projekt bereits ein eigener Modellierungsraum hinterlegt.

Projektcoaching[Bearbeiten]

Ort: Gebäude B, Raum 5.18 (Büro Prof Birkenkrahe). Zeitplan:

Zeit	11.05.	25.05.	01.06.	08.06.	15.06.
08:30-09:00	n.V	T5	n.V.	T5	n.V.
09:00-09:30	T2	T6	T1	T6	T3
09:30-10:00	T3	T7	T3	T7	T1
10:00-10:30	T1	T8	T2	T8	T5
10:45-11:15	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	T8
11:15-11:45	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	T7
12:30-13:00	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	T6
13:15-13:45	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	Plenum (Rm 1.42)	T2

(Sie können gerne untereinander Zeiten tauschen — dann die Tabelle selbst aktualisieren, bitte.

Der Termin "n.V." steht jeder Gruppe bei Bedarf zur Verfügung: bitte anmelden).

Am 15.06. bereiten wir im Plenum gemeinsam den zweiten Stakeholder Workshop vom 29.06. vor, bei dem die Ergebnisse präsentiert werden.

Use Case Beschreibung[Bearbeiten]

Use-Cases können mehr oder weniger komplex strukturiert sein. Für die Anforderungsaufnahme wie in unserem Stakeholder-Workshop benötigen Sie zunächst vor Allem:

Anwendungsfallsystem (betrachtetes System), z.B. "Bibliotheksausleihe"
Namen des Use Cases, z.B. "Buch ausleihen"
Namen der zugehörigen Akteure (Systeme oder Personen), z.B. "Dozent", "Gastdozent" (Spezialfall), "Student", "Bibliotheksangestellter/in"
Vorbedingungen, z.B. "Buch verfügbar", "Buch ausleihbar"
Nachbedingungen, z.B. "Buch ausgeliehen"
Ausnahmen, z.B. "Buch gesperrt"

Der Schwerpunkt der Use-Case Beschreibung liegt auf der Darstellung der an einer Schnittstelle stattfindenden Kommunikation bzw. erbrachten Dienstleistung. Welche Daten manipuliert werden, sagt der Use Case nicht; nur Auslöser und Kommunikation zwischen Akteuren (z.B. "Wer leiht das Buch?", "Wer registriert die Ausleihe?", "Wer muss was wann tun?" usw.) sind von Interesse. Die Use-Case Beschreibung wird dann als vollständig erkannt, wenn ein Ablauf zur Ruhe gekommen ist, weil im Rahmen des Anwendungsfalls keine Interaktion mehr stattfindet.

Die <<include>> Beziehung zwischen Use Cases indiziert ein Enthaltensein; z.B. schließt die Änderung von Nutzerdaten eine Änderung in der Datenbank ein (aber nicht umgekehrt). Dies können Sie einsetzen, wenn verschiedene Use Cases einen gemeinsamen (allgemeinen) Vorgang benutzen.
Die <<extend>> Beziehung zwischen Use Cases indiziert eine Erweiterung: z.B. kann die Heirat eines Nutzers in eine Änderung des Namens erweitert werden (muss aber nicht). Dies können Sie z.B. zur Darstellung von Sonderfällen einsetzen.

Erster Mini-Workshop[Bearbeiten]

Beide Workshop-Teile liefen gut und alle Teams kamen zu einem vernünftigen Ergebnis im Sinne von Informationen "was" (sollen wir modellieren), "wer" (sind die Akteure), "wann" (können wir die Kunden erreichen und) "wie" (geht es weiter). Der Prozess: Diskussion mit allen Kunden im Plenum, dann Aufteilung der Kunden auf die verschiedenen Teams für Spezialfragen. Abschließend kurze Abstimmung wie weiter zu verfahren ist.

Kritikpunkt aus der 1. Gruppe ("E-Media"): die Gruppe hätte sich mehr Informationen vorab gewünscht (nächstes Mal: kurze Stellungnahme zu jedem Beispielprozess von einem Experten).

In der zweiten Gruppe stellten die Teams sich kurz vor (gut!) und es gab einen Freiwilligen, der begann, ein Organigramm (siehe Fig. 2) zu zeichnen: nach ca. 1/2 Stunde des Fragenstellens und Diskussionen wurde daraus dieses Tafelbild, "das wir überhaupt nicht verwenden können" (Teilnehmerzitat). Es ist aber kein schlechtes Abbild der prozessualen Verwirrung, die zwischen Standorten und z.T. organisch gewachsenen Strukturen in einem sich schnell entwickelnden Bereich (E-Learning) leicht entsteht-und in dem Prozessmodellierung viel leisten kann!

Hausaufgaben[Bearbeiten]

Hausaufgaben zur nächsten Sitzung: (1) eigene Projektorganisation (Zeitplan, Ziel usw.) (2) Auftragsklärung mit Hilfe von Use Cases wie im Workshop besprochen — für beide Gruppen! Bitte legen Sie Ihre Ergebnisse/Zwischenergebnisse in dem für Ihr Projekt bereits angelegten Ordner in Signavio ab (in: /UMO LV 316101/Projekte). Wenn Sie das am Donnerstagmittag tun, dann kann ich mir die Ergebnisse auch angucken, was das Coaching noch sinnvoller macht. Wichtige Ergebnisse evtl. auch lokal speichern bis wir mehr Erfahrungen mit dem Werkzeug gemacht haben.

Kundenkommunikation[Bearbeiten]

Wie Sie gehört und gesehen haben, habe ich in Moodle sieben Foren eingerichtet, die wiederum den einzelnen Teams T1-T3 und T5-T8 zugeordnet sind. Abbonieren Sie diese Foren (Klick oben rechts auf der Forum-Startseite) Hinterlegen Sie dort Nachfragen und Zwischenergebnisse für die Kunden. Idealerweise sind Fragen dort gebündelt und Texte redigiert (Rechtschreibung! Fehlerhafte Texte erwecken kein Vertrauen beim Kunden—Schludrigkeit kann kaum wieder wettgemacht werden!).

Sie sind bei der Kommunikation auf sich selbst angewiesen, ich übernehme kein Haftung…alle Kunden haben signalisiert, dass sie auch gerne mit ihnen sprechen mögen (was einfacher ist als das Forum, aber ebenfalls organisiert werden muss: mit so wenig Aufwand für den Kunden wie nötig und so viel Resultaten wie möglich)—ein (gutes) Zeichen, dass hier Dampf im Kessel ist.