Prototyp zur Modellierung und Generierung einer Workflow Lösung für die Anmeldung einer Abschlussarbeit

Aus Winfwiki

1 Einleitung

1.1 Begründung der Themenwahl

Die zunehmende Bedeutung des Geschäftsprozessmanagements ist in vielen Unternehmen zu erkennen. Ein permanenter Wettbewerbsdruck veranlasst das Unternehmensmanagement dazu, unnötige Prozesse im Unternehmen zu identifizieren und wenn möglich zu eliminieren. Bei dieser Geschäftsprozessoptimierung spielt die EDV (Elektronische Datenverarbeitung) eine entscheidende Rolle, da die meisten Prozesse im Unternehmen auf Informations- und Kommunikationssystemen aufbauen. Doch neben der konzeptionellen Arbeit, also dem Entwurf neuer bzw. der Überarbeitung vorhandener Arbeitsabläufe, spielt die Modellimplementierung eine entscheidende Rolle. Schwerwiegende Probleme in der Implementierungsphase können oft zum Scheitern des gesamten Projektes führen.

1.2 Zielsetzung

Um die Phase der Implementierung zu analysieren, wurde im Rahmen dieser Projektarbeit der Prozess „Anmeldung der Abschlussarbeit“ einer Hochschule modelliert und als Softwareprototyp umgesetzt. Das Ziel der Untersuchungen ist ein Erkenntnisgewinn über die Möglichkeiten und eventuellen Probleme, welche bei der Umsetzung entstehen können. Die Überführung eines definierten Geschäftsprozessmodells zu einem softwaretechnischen Prototypen ist dabei der Fokus der Analyse.

1.3 Aufbau

Zu Beginn dieser Fallstudie werden die wissenschaftlichen Grundlagen zu den Teilbereichen Geschäftsprozessmodellierung und –implementierung (aus unternehmerischer Sicht) erläutert. Die erste Phase beschäftigt sich mit der Prozessanalyse und der Modellentwicklung, im zweiten Teil wird auf die Umsetzung von Softwareprojekten mit Hilfe des Wasserfallmodells eingegangen und zusätzlich das Thema Workflow-Management-Systeme erläutert. Im Anschluss folgt die Projektdokumentation, welche die verschiedenen Projektschritte behandelt und Erkenntnisse bei der Umsetzung darlegt. Die Dokumentation ist dabei in die Kategorien Planungsphase, Anforderungen an das Projekt, Durchführungsphase und die Ergebnispräsentation aufgeteilt. In der Schlussbetrachtung werden folglich die Ergebnisse des Projektablaufs sowie die gewonnen Erkenntnisse zusammengefasst.

2 Grundlagen

2.1 Geschäftsprozessmodellierung

Die Geschäftsprozessmodellierung ist Kern des Business Process Engineering und eine der zentralen Aufgaben der Unternehmensgestaltung ^[1]. In dieser Phase werden alle Informationen erhoben, welche nötig sind, um Unternehmensvorgänge zu identifizieren, zu optimieren und kontrolliert auszuführen. Um eine gemeinsame Diskussionsbasis für alle Beteiligten zu bilden, wird meist eine informale oder semiformale grafische Beschreibungssprache verwendet ^[2].

2.1.1 Analyse

Ausgangspunkt der Geschäftsprozessanalyse ist die Identifizierung von Geschäftsprozessen. Dabei werden die Prozesse gesucht und beschrieben, die zum Erfüllen der Kundenbedürfnisse bzw. der Bedürfnisse anderer Interessensgruppen im Unternehmen benötigt werden. Dabei gibt es grundsätzlich zwei Ansätze: die Top-down und die Bottom-up-Methode. Der "Top-down-Ansatz" geht von der Geschäftsstrategie aus und definiert über die Kundenbedürfnisse, dem Leistungsangebot und der Wettbewerbsstrategie die benötigten Geschäftsprozesse. Bei dieser Methode werden genaue Kenntnisse über die Strategie, den Markt und die Kunden vorausgesetzt ^[3]. Der "Bottom-up-Ansatz" hat als Ausgangspunkt die auf unterster Ebene bereits existierenden Aktivitäten, welche zu Geschäftsprozessen gebündelt werden. Diese Methode hat sich aufgrund von mangelndem Bezug zur Unternehmensstrategie und zu Kundenbedürfnissen jedoch nicht in der Praxis bewährt ^[4].

2.1.2 Modellentwicklung

Nach der Identifizierung von Geschäftsprozessen folgt die Strukturierung. Die Zuordnung von Aufgabenträgern und die Festlegung von klaren Verantwortungen setzt eine Unterteilung des Prozesses in eine hierarchische Aufbaustruktur voraus ^[5]. Schmelzer definiert die Hierarchieebenen dabei als Teilprozess, Prozessschritt, Arbeitsschritt und ggf. Aktivität. Die Darstellungstiefe des Prozesses hängt dabei von verschiedenen Faktoren wie z.B. der Komplexität und Durchführungshäufigkeit des Geschäftsprozesses ab. Die Prozessablaufstruktur kann anschließend mit geeigneter Software dargestellt werden. Ein weit verbreitetes Programm dafür ist Microsoft Visio, jedoch gibt es heutzutage Software, die auf die Geschäftsprozessmodellierung z.B. in der aktuellen BPMN 2.0 (Business Process Modeling Notation) spezialisiert ist. Auf weitere Notationen wie die weit verbreitete EPK (Ereignis gesteuerte Prozesskette) wird im Rahmen dieser Fallstudie nicht weiter eingegangen.

2.2 Geschäftsprozessimplementierung

Aufgrund der steigenden Bedeutung bei der automatisierten Umsetzung von Geschäftsprozessmodellen soll nachfolgend kurz der Bereich Workflow-Management-Systeme erläutert werden. Zusätzlich wird das Wasserfallmodell beschrieben, da es bei der Umsetzung des Prototypen Verwendung fand.

2.2.1 Workflow-Management-Systeme

Die explizite Darstellung der Logik von Arbeitsabläufen in der Geschäftsprozessmodellierung erlaubt es, dass die Informationstechnik neben der einzelnen Anwendung auch den Prozessablauf selbst unterstützen kann ^[6]. Für diesen Zweck gibt es sogenannte Workflows bzw. WfMS (Workflow-Management-Systeme). Fischer definiert den Begriff Workflow als einen durch WfMS unterstützten Geschäftsprozess und weist auf die zentrale Bedeutung von Workflows bei der Implementierung von Geschäftsprozessen hin ^[7].
WfMS werden seit Beginn der 90er Jahre entwickelt und bilden einen zentralen Technologiebaustein in integrierten Gesamtlösungen ^[8]. Ihre Hauptaufgabe ist dabei die Definition, die Simulation, das Steuern und die Kontrolle von arbeitsteiligen Prozessen. Die verschiedenen Aufgaben für den Benutzer werden durch das WfMS in einen Ablauf gebracht und ihm inklusive der benötigten Informationen zur Verfügung gestellt ^[9]. Eine schlanke Prozessplanung führt somit zu einer schnelleren und qualitativ besseren Vorgangsbearbeitung im Unternehmen. Durch die Automatisierung von Abläufen wird zusätzlich eine Flexibilität erreicht, die es ermöglicht auf Anpassungen im Arbeitsablauf schnell reagieren zu können.

2.2.2 Wasserfallmodell

Das Wasserfallmodell ist das älteste bekannte Vorgehensmodell des Software Engineering ^[10]. Es ist durch den sequenziellen Ablauf der verschiedenen Bearbeitungsschritte Anforderungsmanagement, Design, Implementierung (Test) und Integration geprägt. In einer Erweiterungsstufe des Modells wird zusätzlich ein Rückwärtsschritt von einer Phase auf den direkten Vorgänger zugelassen. Eine zusätzliche Eigenschaft des Wasserfallmodells ist, dass ein Abwärtsschritt in eine nachfolgende Stufe erst durchgeführt werden kann, wenn alle Punkte der aktuellen Stufe abgeschlossen sind. Damit soll das Risiko bei der Bearbeitung der folgenden Stufen verringert werden ^[11]. Abbildung 1 verdeutlicht nachfolgend den vereinfachten Ablauf des Modells.

Abb. 1: vereinfachtes Wasserfallmodell

Es gibt Modelle, bei denen in detailliertere Bearbeitungsschritte gegliedert wird, dies kann im Rahmen dieser Fallstudie, aufgrund des niedrigen Komplexitätsgrades des zu entwickelnden Prototypen, jedoch vernachlässigt werden.

Trotz der unflexiblen Eigenschaften des Modells eignet es sich für kleinere Projekte, bei denen nicht mit großen Änderungen der Anforderungen zu rechnen ist. Aus diesem Grund wurde das Modell auch für die Entwicklung des Prototypen im Rahmen dieser Fallstudie herangezogen. Wie im Laufe dieser Studie beschrieben, waren keine detaillierten Anforderungen an das zu entwickelnde System gestellt, was dazu führte, dass nicht mit umfangreicheren Anpassungen während der Entwicklungsphase zu rechnen war.

3 Projekt

Das im Rahmen dieser Fallstudie durchgeführte Projekt umfasst die Modellierung des Prozesses "Anmeldung einer Abschlussarbeit" für Hochschulen und die Umsetzung dieses Modells als Softwarelösung. Der Ablauf des Anmeldeprozesses wurde dabei mit dem Projektbetreuer in Textform definiert, sodass die grafische Darstellung als eigenständiger Teil des Projektes durchgeführt werden konnte. Diese grafische Darstellung des Prozesses und die darauf folgende technische Umsetzung des Modells stehen dabei im Zentrum der Untersuchungen.

3.1 Anforderungen

Die technischen Anforderungen an den zu entwickelnden Prototypen sind die Koordination und Automatisierung des Anmeldeprozesses einer Abschlussarbeit. Die an dem Prozess beteiligten Akteure sind dabei der Studierende, welcher das gewünschte Thema einreicht bzw. anmeldet, der Dozent des entsprechenden Fachbereichs und die Prüfungsabteilung, welche alle formalen Aufgaben übernimmt. Weitere konkrete Anforderungen zu gewünschten Funktionalitäten wurden seitens des Projektbetreuers nicht gestellt. Aus diesem Grund sind die folgenden Anforderungen selbst definierte Ziele, die mit dem Prototypen erreicht werden sollen.

Tabelle 1: Anforderungen an das Projekt

Die definierten Pflichtkriterien stellen ein Grundgerüst des Systems dar, welche für die minimale Funktionalität des Prototypen vorausgesetzt werden. Darüber hinaus wurden weitere Kriterien definiert, welche nach Fertigstellung des Basissystems implementiert werden sollten. Neben den rein technischen Anforderungen soll bei der Umsetzung des Projektes die Modellumsetzung analysiert werden, um Möglichkeiten und Gefahren dieser Projektphase zu identifizieren.

3.2 Rahmenbedingungen

Das Projekt wurde im Rahmen einer Hausarbeit für das Modul Fallstudie/Wissenschaftliches Arbeiten durchgeführt. Der Bearbeitungszeitraum war vom 20.03.2011 bis zum 17.06.2011. Der Nutzen des Prototypen war nicht die Funktionalität bzw. die Einsetzbarkeit, sondern wurde zu Analysezwecken durchgeführt. Aus diesem Grund wurde der Prototyp als eigenständige Lösung implementiert, da erstmals keine Integration in bestehende Systeme angedacht wurde. Die Möglichkeit der Migration in ein Gesamtsystem wurde bei der Projektumsetzung lediglich berücksichtigt und offen gehalten.

3.3 Planung

Wie bereits angedeutet wurde das Projekt nach einem verkürzten Wasserfallmodell geplant und umgesetzt. Die Verkürzung des Modells beruht auf der fehlenden Phase der Implementierung, welche im Rahmen dieser Fallstudie nicht angedacht war. Die Wahl eines iterativen Vorgehensmodells bot sich an, da das Projekt vorab klar definiert wurde und nicht mit nachträglichen Veränderungen der Anforderungen oder Rahmenbedingungen zu rechnen war. Des Weiteren wurde der Prototyp als webbasierte Lösung geplant, da verschiedene Benutzer an unterschiedlichen Standorten mit dem System arbeiten sollen. Durch diese Entscheidung soll zusätzlich eine Plattformunabhängigkeit erreicht werden, da auf dem Client lediglich ein Internetbrowser für die Darstellung des Systems benötigt wird. Alle zukünftigen Änderungen könnten auf dem Webserver, also an zentraler Stelle, vorgenommen werden, was die Wartbarkeit vereinfacht und Kosten spart.

Für die grafische Modellierung des Prozesses wurde ein geeignetes Open-Source-Tool eingeplant, welches sich an aktuellen Standards der Geschäftsprozessmodellierung orientiert.

Die Darstellung der Seiten soll durch die Auszeichnungssprache HTML (Hypertext Markup Language), serverseitige Programmierung mit der Scriptsprache PHP (PHP: Hypertext Preprocessor) und clientseitige Programmierung mit der Scriptsprache JavaScript realisiert werden. Für Teile der JavaScript Programmierung wurde zusätzlich die Klassenbibliothek jQuery ^[12] eingeplant. Die Erweiterung und Vereinheitlichung der normalen JavaScript-Befehle durch eine zusätzliche Klassenbibliothek ist bei Internetseiten weit verbreitet. Die Wahl viel dabei auf jQuery, da es die Bibliothek mit der meisten Verbreitung für JavaScript ist ^[13]. Gerade im Bereich der asynchronen Kommunikation, der Manipulation von Seiteninhalten und dem Zugriff auf einzelne Seitenelemente wird die clientseitige JavaScript Programmierung stark erleichtert.

Zur Datenspeicherung ist eine relationale Datenbank angedacht, welche mit der Datenbanksprache SQL (Structured Query Language) abgefragt und manipuliert werden soll. Gerade im Webbereich ist SQL in Verbindung mit PHP eine weit verbreitete Lösung.

3.4 Durchführung

Nachfolgend wird die Bearbeitungsphase des Projektes geschildert. Die Beschreibung wird dazu in die Kategorien Modellerstellung und Modellumsetzung gegliedert. Wie zuvor erwähnt, stellen diese zwei Phasen bzw. der Übergang der Phasen den Fokus der Untersuchungen dieser Fallstudie dar.

3.4.1 Modellerstellung

Der erste Schritt der Umsetzung war die Erstellung des Prozessmodells. Der schriftlich definierte Ablauf wurde mit Hilfe der Bonita Open Solution, einer Open-Source Workflowsoftware, in ein Geschäftsprozessmodell umgesetzt. Dazu wurde der Anmeldeprozess in einzelne Arbeitsschritte strukturiert und in das Business Process Model überführt. Das Modell wurde in der BPMN umgesetzt und orientiert sich somit an aktuellen Standards. Neben der Darstellung der Arbeitsschritte wurden die Akteure ebenfalls in das Modell integriert. Die Darstellung der Prozessteilnehmer über sogenannte Swimlanes führt dazu, dass klar erkennbar ist, in wessen Zuständigkeit der aktuelle Prozessschritt fällt.

3.4.1.1 Modell

Folgender Prozessablauf wurde vorab mit dem Projektbetreuer abgesprochen:

Der Anmeldeprozess der Abschlussarbeit gliedert sich generell in sechs Arbeitsschritte. Zuerst wird vom Studierenden ein Themenvorschlag bei dem verantwortlichen Dozenten des Fachbereichs eingereicht. Dieser prüft, ob das Thema geeignet ist und klärt mögliche Anpassungen sowie die Gliederung der Arbeit mit dem Studierenden ab. Dies kann in persönlichen Gesprächen oder in Schriftform geschehen. Wenn der Dozent mit dem Titel und der Gliederung der Abschlussarbeit einverstanden ist und er die Betreuung übernehmen möchte, kann der Studierende den schriftlichen Anmeldeantrag ausfüllen und dem Dozenten zukommen lassen. Dieser unterschreibt den Antrag und sendet ihn an den Prüfungsausschuss. Dort werden alle formalen Prüfungsvoraussetzungen überprüft. Nach der Überprüfung wird der Antrag abgelehnt oder bestätigt und dem Studierenden das Ergebnis mitgeteilt.

Abbildung 2 zeigt die grafische Modellierung des Anmeldeprozesses:

Abb. 2: Modell des Anmeldeprozesses

3.4.1.2 Grobkonzept zur Umsetzung

Die Umsetzung des Prototypen wurde als eigenständige Internetseite geplant. Dies bedeutet die Schaffung einer Startseite, eines Impressums sowie einer Loginseite im öffentlichen Bereich. Die einzelnen Prozessschritte des Modells sollen über Phasen bzw. Status abgebildet werden. Insgesamt wurde der Ablauf der Anmeldung in neun Phasen unterteilt. Die Speicherung der Phasen des Anmeldeprozesses wird in einer MySQL-Datenbank-Tabelle vorgenommen. Studierende befinden sich zu Beginn in Phase 0 und werden nach jedem erfolgreich abgeschlossenen Schritt in die nachfolgende Phase eingebucht. Die Einbuchung erfolgt entweder durch eine Handlung des Antragstellers oder durch eine erfolgreiche Bestätigung eines Schrittes durch den Dozenten bzw. den Prüfungsausschuss. Im internen Bereich soll es eine allgemeine Willkommensseite geben, sowie für den Studierenden eine Seite auf der er den aktuellen Status seiner Anmeldung einsehen kann. Für die Dozenten ist eine Übersichtsseite geplant, die alle Studierenden mit ihrem aktuellen Status auflistet und die Möglichkeit bietet den Status eines Antragstellers zu bestätigen. Der Prüfungsausschuss soll ebenfalls alle Studierenden sehen und die Möglichkeit haben erledigte Aufgaben zu bestätigen.

Bei der Umsetzung ist darauf zu achten, dass die Möglichkeit erhalten wird, das entwickelte System später als Teil eines Gesamtsystemes wie dem Online-Campus zu benutzen. Aus diesem Grund soll das Loginsystem und die Rechteverwaltung nur sehr einfach gehalten werden. Auf die Verwendung von Sessions und der Integration von umfangreichen Sicherheitsmechanismen in das System wurde somit verzichtet.

3.4.2 Modellumsetzung

Zu Beginn der Umsetzungsarbeiten wurde eine HTML-Dokumentenvorlage erstellt. Die Definition des Designs der Webseite wurde in eine CSS-Datei ausgelagert. Dies bietet mehrerer Vorteile gegenüber Inline-Styles in HTML. Zum einen ist der spätere Quellcode besser strukturiert, die Gestaltungsmöglichkeiten sind mit CSS größer und eventuelle Designumstellungen können später an zentraler Stelle vorgenommen werden, wenn sich der grundlegende Aufbau der Webseite nicht ändert. Im nächsten Schritt wurden die einzelnen Funktionalitäten der Seite in der Reihenfolge ihrer späteren Benutzung umgesetzt.

3.4.2.1 Die Phasen der Anmeldung

Zu Beginn befindet sich jeder Studierende in Phase 0. Dies wird durch die Datenbank automatisch beim Anlegen neuer Benutzer gewährleistet.

Phase 0

In dieser Phase befindet sich jeder neu angemeldete Hochschüler zu Beginn. Sie bietet die Möglichkeit, über den Menüpunkt Abschlussarbeit, den Anmeldevorgang zu beginnen. Das gewohnte FOM-Design der Anmeldemaske soll dabei durch den Wiedererkennungswert die Akzeptanz der Studierenden für das neue System erhöhen. Eine Orientierung an bestehenden FOM-Systemen, wie dem Online-Campus, hilft zusätzlich bei der intuitiven Bedienung des Systems.

Der Wechsel in Phase 1 erfolgt automatisch.

Phase 1

In dieser Phase hat der Antragsteller die Aufgabe Themenvorschläge für seine Abschlussarbeit an den Dozenten zu senden. Bei Aufruf der Studierenden-Ansicht wird ihm deshalb ein Formular zur Eingabe des Themas angezeigt. Die eingetragenen Vorschläge sollen dann per E-Mail an den Dozenten geschickt werden. Die Funktionalität des E-Mail-Versands wurde aus zeitlichen Gründen jedoch noch nicht implementiert. Sobald der erste Vorschlag eingereicht wurde, wird der Studierende automatisch in die darauf folgende Phase umgebucht. (⇒ Phase 2)

Phase 2

Eine weitere Abstimmung mit dem Dozenten erfolgt in dieser Phase per E-Mail oder persönlich. Ist der Dozent mit dem Antrag einverstanden, bucht er den Kandidaten in die Phase 3 um. (⇒ Phase 3)

Phase 3

Dieser Bearbeitungsschritt stellt den formalen Antrag dar. Der Anmeldeantrag wird vom Studierenden ausgefüllt und dem Betreuer zugeschickt. (⇒ Phase 4)

Phase 4

Der Betreuer bestätigt und unterschreibt die Anmeldung, der Antrag wird damit an den Ausschuss weitergeleitet. (⇒ Phase 5)

Phase 5

In diesem Schritt kontrolliert der Prüfungsausschuss die formalen Kriterien der Anmeldung das eingereichte Thema bzw. die Zulassungsvoraussetzungen des Studierenden. Die nachfolgende Phase hängt nun von dem Ergebnis der Überprüfung ab. (⇒ Phase 7, falls nicht erfüllt, ⇒ Phase 6 falls der Antrag genehmigt wurde)

Phase 6

Der Anmeldeantrag wurde angenommen, aber der Antragsteller noch nicht angeschrieben. Dies kann aus zeitlichen Gründen o.Ä. verzögert geschehen. Sobald der Ausschuss die nächste Phase genehmigt, wird der Antragsteller benachrichtigt (⇒ Phase 8)

Phase 7

In dieser Phase wird der Studierende über die Ablehnung des Antrags in Kenntnis gesetzt, um die Möglichkeit weiterer Abstimmungen wahrnehmen zu können.

Phase 8

Der Studierende wird über die Antragsannahme informiert. Die Bearbeitungszeit der Bachelor-Thesis beginnt.

Phase 9

Dieser Status wird nach einiger Zeit automatisiert oder von Dozenten eingetragen. Dies dient der Protokollierung der Prüfungsanträge, auch wenn der Prüfling nicht mehr an der Universität tätig ist.

Der Zusammenhang der Phasen gliedert sich in der nachfolgenden Grafik in das ursprüngliche Prozessmodell ein und verdeutlicht den zuvor beschriebenen Ablauf.

Abb. 3: Modell des Anmeldeprozesses mit Phasen

3.4.2.2 Datenbankentwurf

Um einen personalisierten Login zu ermöglichen, müssen für jeden Benutzer (Studierenden, Dozent und Prüfungsausschuss) Zugangsdaten in einer Tabelle gespeichert werden. Die Anmeldeinformationen bestehen aus einem Passwort und der Matrikelnummer als weiteres Identifikationsmerkmal. Die Passwörter werden wie üblich nur verschlüsselt in der Datenbank gespeichert. Die einzelnen Phasen des Anmeldevorgangs werden ebenfalls in der Datenbank abgelegt. So kann innerhalb des Systems eindeutig die Phase referenziert und die Zuständigkeit ermittelt werden.

Die eingereichten Prüfungsanträge, die zum formalen Anmeldeprozess gehören, werden in einer weiteren Tabelle gespeichert. Dies dient der Übergabe an den Ausschuss sowie der dauerhaften Speicherung.

Als vierte Tabelle muss das System eine Art Logbuch enthalten. Diese dient dazu eindeutig zu belegen, wann der Studierende welche Phase erreicht hat.

Die folgenden Abbildung (Abbildung 4)' stellt die Verknüpfung der einzelnen Tabellen mit Hilfe des EER-Modells dar:

Abb. 4: EER-Modell der MySQL Datenbankstruktur

Tabelle: status

Die Struktur der gewählten Tabellen richtet sich stark an das umzusetzende Modell. Dies wird besonders durch die Tabelle Status deutlich, in der die einzelnen zu durchlaufenden Stationen des Anmeldeprozesses dargestellt sind. Die direkte Übertragung der Vorgaben als Datensätze in dieser Tabelle bietet dabei einige Vorteile. Hier ist vor allem die Erweiterbarkeit des Systems zu nennen. Um die Berechtigungsstufe und Zuständigkeit der einzelnen Status darzustellen, wurde das Feld aufgabenbereich hinzugefügt. Die Umsetzung der Berechtigungsstufen wurde über integrierte ENUM und SET Felder realisiert.

Tabelle: user

Die user Tabelle dient zur Abbildung aller angemeldeten Studierenden, Dozenten und Prüfungsabteilungsmitgliedern sowie deren Zugangsdaten. Der aktuelle Status der Anmeldung ist über das Feld abschlussarbeit mit der Tabelle status verknüpft.

Tabelle: log

Die Tabelle log dient der Protokollierung und Überprüfung der gewechselten Status. Eine eindeutige Zuordnung ist durch die Verknüpfung mit den Tabellen user und status über einen zusammengesetzten Fremdschlüssel jeder Zeit möglich. Beim Einfügen eines neuen Datensatzes über die Datenbank sorgt die automatische Abspeicherung der Uhrzeit dabei für eine exakte und manipulationssichere Protokollierung. Vor allem bei Vorgängen wie der Einreichung des Antrags, die mit besonderen Fristen verbunden sind, muss dies sichergestellt sein. Die Manipulationssicherheit wird dabei durch das Entziehen der Rechte eines Update-Statements innerhalb der Datenbank geschaffen.

Tabelle: arbeiten

Diese Tabelle dient der Speicherung der eingereichten Themen. Es wurde explizit darauf geachtet auch mehrere Anträge pro Benutzer zu ermöglichen und abgelehnte Anträge nicht zu überschreiben.

3.4.2.3 Programmierung

Die Erstellung des Programms wurde in Anlehnung an das Top-Down-Prinzip durchgeführt. Charakterisiert ist diese Methode durch ein Grobkonzept, welches im Laufe des Projektes durch detailliertere Programmteile erweitert wird ^[14].

Die Hauptbereiche der Implementierung bestanden aus der serverseitigen PHP- und der clientseitigen JavaScript-Programmierung, welche nachfolgend auszugsweise erläutert werden.

Das Login-Konzept basiert auf einem übergebenen md5-Hash, der bei jedem Login für jedes Mitglied neu generiert wird, dem sogenannten Token. Gibt ein Mitglied seine Zugangsdaten, bestehend aus Matrikelnummer und Passwort, in das Login-Formular ein und authentifiziert sich damit am Server, generiert der Login-Mechanismus ein eindeutiges Token. Das Token besteht aus dem aktuellen Datum und einer zufällig generierten Zeichenfolge, die zu jeder Zeit einzigartig ist.

$token = md5( date('Ymd') . $rand)

Anschließend wird nur die zufällige Zeichenkette an den Benutzer übergeben. Durch eine erneute Verknüpfung des Benutzer-Tokens mit dem aktuellen Datum wird ein automatischer Ablauf aller eingeloggten Benutzer um 0 Uhr erreicht. Bei einem expliziten Ausloggen des Benutzers wird das Token aus der Datenbank gelöscht und ist somit nicht mehr zu gebrauchen. Um bei einem späteren Seitenaufruf den Benutzer zu identifizieren, müssen nicht erneut die Zugangsdaten an den Server übertragen werden. Dies wird durch das Token gewährleistet, welches bei jedem Seitenaufruf an den Server übergeben werden muss. Auf eine Speicherung des Tokens über Sessions oder in lokalen Speichern wurde verzichtet.
Die Wahl fiel auf dieses Verfahren, da es die Möglichkeit bietet die bestehenden Scripte später in ein anderes System zu integrieren, ohne große Änderungen daran vornehmen zu müssen. Die geschützten Seiten überprüfen bei jedem Aufruf, ob ihnen das Identifizierungstoken per POST, GET oder als PHP-Variable übergeben wurde und identifizieren auf diese Weise, welcher Benutzer sich angemeldet hat.
Die Schwachstellen dieses Verfahrens sind, dass die Möglichkeit für Dritte besteht den zuvor angemeldeten Benutzerlogin zu Übernehmen. Diese Problematik ensteht da der normale Netzwerkverkehr beim Aufzeichnen durch Dritte im Klartext mitgelesen werden kann. Da es sich dabei jedoch um ein generelles Problem bei unverschlüsselter Übertragung handelt, wird es in dieser Arbeit nicht explizit behandelt. Eine verschlüsselte Datenübertragung über SSL bzw. TLS ist jedoch bei einem späteren Einsatz dringend zu empfehlen, um zu gewährleisten, dass weder die Zugangsdaten gestohlen, noch ein temporärer Login ermöglicht wird.

Studierendenansicht ( abschlussarbeit.php )
Die wechselnde Ansicht dieser Maske wird durch den eingetragenen Status in der Datenbank hervorgerufen. Beim Seitenaufruf findet zuerst die Abfrage des Status statt, in deren Abhängigkeit dann veränderter Inhalt dargestellt wird. Exemplarisch ist dies in dem folgenden Quelltext dargestellt. Die Programmlogik zeigt bei eingetragenem Status 0 die Anmeldemaske an. Sobald das enthaltene Formular verschickt wird, findet ein Upgrade in die nachfolgende Stufe statt.

Auszug aus PHP-Quellcode
if ( loggedIn() )
{
    $user = getUser();
    $status = getStatus( $user['matnr'] ) ;
    
    $text = htmlentities( $status['text'] ) ;

    switch( $status['id'] )
    {
        case 0:
            if( isset( $_REQUEST['anmelden'] ) )
            {
                $sql = 'UPDATE user SET abschlussarbeit = 1 WHERE matrikelnr = ' . $user['matnr'];
                mysql_query( $sql , $conid );
                echo mysql_error( $conid );
                $zusatz = 'Erfolgreich angemeldet';
            }
            else
            {
                $zusatz = ' Sie haben noch nicht mit der Anmeldung begonnen. ';
                $zusatz = '
                <form action = "abschlussarbeit.php?t=' . $token . '" method = " post ">
                < table class = "anmeldung"> 
                <tr>
                   <th> Auswahl: </th>
                   <th> Datum: </th>
                   <th> Uhrzeit: </th>
                   <th> Dozent/en: </th>
                   <th> Prüfungsort: </th>
                   <th> Prüfungsleistung: </th> 
                </tr> 
                    <tr> 
                        <td style=" text-align: center; "> 
                                <input type = "radio" name = "anmeld" value = "481328" onclick="" class = "form anmeld"> 
                        </td> 
                        <td>' . date('Y-m-d') . '</td> 
                        <td>' . date('H:i:s') . '</td> 
                        <td>
                            <select name = "dozent">
                                <option> Dozent </option>
                            </select>
                        </td> 
                        <td> Düsseldorf </td> 
                        <td> Abschlussarbeit </td> 
                    </tr> 
                </ table >
                zur ausgewählten Prüfung verbindlich
                <input type = "submit" name = "anmelden" style = " padding: 10px; color: green; font-weight: bold; font-size:  17px" value = "anmelden">
                </form> ' ;
 
            }
        break;
        case 1:
        ...

Funktionssammlung (inc/funktionen.inc.php)
Dieses Skript ist eine selbst gestaltete PHP-Funktionssammlung zum Schnellzugriff auf projektspezifische, häufig genutzte Funktionen.

Enthalten sind unter anderem zentrale Funktionen zur Login-Verwaltung, sowie eine viel genutzte Funktion zur Status-Abfrage. Nachfolgend werden Auszüge aus dieser Sammlung dargestellt.

Auszug aus der PHP-Funktionssammlung

   if( !isset( $token ) || $token == ) $token = cleanInput ( $_REQUEST['t'] );

   function loggedIn()
   {
       global $conid, $token;
       $sql = 'SELECT * FROM user WHERE token = \ . md5( date('Ymd') . $token ) . '\' LIMIT 1';
       $res = mysql_query( $sql, $conid );
       if( $rec = mysql_fetch_array( $res ))
       {
           return true;
       }
       else return false;
   }

   ...

   function getStatus( $user )
   {
       global $conid;
       $sql = 'SELECT s.id, s.name, s.aufgabenbereich
               FROM user 
               LEFT JOIN status as s ON abschlussarbeit = id 
               WHERE matrikelnr = '.$user;
       $res = mysql_query( $sql , $conid );
       if( $rec = mysql_fetch_array( $res ))
       {
           $status['id'] = $rec['id'];
           $status['text'] = $rec['name'];
           $status['aufgabenbereich'] = $rec['aufgabenbereich'];
       }
       return $status;
   }

JavaScript Klassenbibliothek jQuery (inc/jquery-1.5.1.min.js)
Einbindung der Bibliothek:

   <script type = "text/javascript" src = "inc/jquery-1.5.1.min.js"> </script>

Die Einbindung ist auf allen Seiten notwendig in denen JavaScript verwendet wird.

Funktionen der Dozentenansicht mit Phasenwechsel über AJAX (prueflinge.php)
Alle Studierenden werden in der Dozentenansicht als Liste Dargestellt. So kann ein Dozent den aktuellen Fortschritt der einzelnen Studierenden verfolgen. Bei möglichen Aktionen des Dozenten wird ein Link zum Upgrade erstellt.

Zur besseren Übersichtlichkeit werden die Studierenden in Phasen, die für Dozenten relevant sind, farbig markiert.

Bei einem späteren Einsatz des Systems ist weiterhin zu empfehlen, dass Studierende die sich in Phase 0 oder Phase 9 befinden nicht mehr in der Liste angezeigt werden. Die Anschaulichkeit der Ansichtsmaske wird dadurch klarer und weiterhin verbessern.

Quellcode der AJAX-Funktion zur asynchronen Kommunikation zwischen Benutzer und Server:

Auszug aus JavaScript-Quellcode:

var matnr = ;
function do_upgrade( user ) 
{
    var conf = confirm( "Sind alle Voraussetzungen für die nächste Stude erfüllt?" );
    matnr = user;
    if ( conf )
    {
        $('#upd_' + user).empty();
        $('#upd_' + user).html( '<img src = "img/ajax-loader.gif" />' );
        $.ajax({
            type: "POST",
            url: "ajax.php",
            data: "data=" + user + "&t=' . $token . '",
            success: function( rtn )
            {
                var obj = jQuery.parseJSON( rtn );
                $('#upd_' + user).html( obj.text );
                $('#upd_' + user + '_nr').html( '['+obj.nr+']' );
                $('#upd_' + user + '_status').html( obj.status );
                $('#tr_' + user + ' td').removeClass();
                if(obj.class == 'doz')
                {                                
                    $('#tr_' + user + ' td').addClass( obj.class );
                    $('#upd_' + user).addClass( 'pointer' );
                    $('#upd_' + user).html( obj.text+'<a onclick = "do_upgrade(' + user + ')"> [Upgrade] </a>' );
                }
            }
        } );
    }
}

Zur Übertragung der asynchronen Kommunikation wurde das JSON-Format verwendet. JSON ist eine besondere Art der Formatierung, welche im Vergleich zu anderen Formatierungsarten ohne viele Formatierungszeichen auskommt. Dies macht sie besonders attraktiv für asynchrone Verbindungen.

Das serverseitige Gegenstück liest, sofern die nötigen Berechtigungen vorhanden sind, die übertragene Matrikelnummer aus und leitet sie an die Funktion upgrade weiter.
Diese Funktionalität ist in die Datei ajax.php ausgelagert.

Auszug aus PHP-Quellcode:

function upgrade( $matnr ) 
{
   $text = ;
   
   // Gueltigkeit der Matrikelnummer ueberpruefen
       $matnr = (int)$matnr;
       if( $matnr < 9999) $text = 'false';
   
   $user = getUser( $matnr );
   $status = getStatus( $matnr );
   
   // Upgraden
       if( strpos( $status['aufgabenbereich'], 'Dozent') === false) $text = 'Sie haben nicht die nötigen Rechte';
       else
       {
           global $conid;
           $sql = 'UPDATE user SET abschlussarbeit = abschlussarbeit + 1 WHERE matrikelnr = ' . $user['matnr'];
           if( mysql_query( $sql, $conid )) $text = 'Studierenden in die nächste Stufe überführt.';
           else $text = 'Fehler';
       }
   
   $status_neu = getStatus( $matnr );
   // Ermitteln der neuen  CSS-Klasse
       $class = ;
       if( strpos( $status_neu['aufgabenbereich'], 'Dozent') !== false) $class .= 'doz';
       $class = trim( $class );
   
   // Rueckgabe im JSON-Format
   return ( '{"text":"' . utf8_encode( $text ) 
              . '", "nr":"' . utf8_encode( $status_neu['id'] ) 
              . '", "status":"' . utf8_encode( $status_neu['text']) 
              . '", "class":"' . utf8_encode( $class ) . '"}' );
}

Die Rückgabe des Aufrufs gibt dabei Informationen über Erfolg oder Misserfolg des Statuswechsels. Nach erfolgreicher Übertragung wird zusätzlich der neue Status, sowie die CSS-Style-Information der Tabellenzeile übertragen.

3.4.2.4 Probleme

Bei der Projektumsetzung traten keine besonderen Probleme auf.

3.5 Ergebnisse

3.5.1 Resultat der Modellumsetzung

Um das entwickelte System benutzen zu können, muss sich der Benutzer authentifizieren. Dies geschieht durch ein einfaches Login-System mit Benutzernummer und Passwort. Nach der erfolgreichen Anmeldung können die gewünschten Bearbeitungsschritte durchgeführt werden. Der Dozent kann eingereichte Themenvorschläge einsehen und nach Absprache mit dem Studierenden die Themenbestätigung durchführen. Die Status des Anmeldeprozesses bilden dabei stark die Arbeitsschritte des Geschäftsprozessmodells ab. Der Studierende kann somit genau nachvollziehen, in welchem Bearbeitungsschritt sich sein Themenvorschlag gerade befindet.

Die einzelnen Komponenten des Systems werden nachfolgend kurz veranschaulicht:

Der Loginbereich In Abbildung 5 ist erkennbar, dass für den Login im System die gleichen Daten wie im Online-Campus der FOM genutzt werden. Ein kompletter Abgleich der Logindaten könnte bei einer Integration in ein Gesamtsystem umgesetzt werden. Wie zu sehen ist, ist das Formular in das Seitenmenü integriert, sodass sich von jeder Seite aus eingeloggt werden kann.	Abb. 5: Login des Systems
Die Anmeldeseite Nach dem Einloggen in den geschützten Bereich gelangt der Benutzer auf die Anmeldeseite. Über diese Seite können aktuelle Informationen veröffentlicht werden. Auch diese Seite orientiert sich an dem Layout des FOM Online-Campus. Zusätzlich werden für den Benutzer noch interne Menüpunkte auf der linken Seite angezeigt. Zur besseren Präsentation der Seiten sind bis zur Nutzung des Systems alle Menüpunkte für jedes Mitglied eingeblendet.	Abb. 6: Anmeldung der Abschlussarbeit
Die Statusseite Abbildung 7 zeigt die Statusseite des Studierenden. Hier kann sich über den aktuellen Bearbeitungsstand des Antrags informiert werden. In Abhängigkeit vom aktuellen Status eines Studierenden wird hier eine andere Maske angezeigt. Im oberen Bereich der Seite wird zu jeder Zeit der aktuelle Status eingeblendet. So wird Übersichtlichkeit und Transparenz geschaffen. Je nach Bedarf wechseln die angezeigten Elemente im Mittelteil.	Abb. 7: Status der Anmeldung
Liste der Studierenden In dieser Übersicht werden die Studierenden in Listenform dargestellt. Bei rot gekennzeichneten Positionen ist eine Aktion des Dozenten nötig. In diesem Fall ist ein Themenvorschlag für den Dozenten eingegangen. Bei der Umbuchung eines Studierenden wird über AJAX der Status gewechselt und der Inhalt der Seite, ohne neu zu laden, verändert. Bei umfangreichen Listen führt dies zu weniger Datentransfer und Ladezeiten.	Abb. 8: Liste der Studierenden

3.5.2 Soll-/Ist-Vergleich

Die folgende Tabelle soll den Fertigstellungsgrad des Prototypen durch die Gegenüberstellung von geplanten und umgesetzten Zielen verdeutlichen:

Tabelle 2: Gegenüberstellung geplanter und umgesetzter Ziele

Eine E-Mail-Benachrichtigung in das System zu integrieren wurde erst im Laufe des Projektes als sinnvolle Erweiterung erkannt. Da die Umsetzung der Datenbankstruktur zu dieser Zeit schon abgeschlossen war, wurde die Funktionalität als spätere Erweiterungsmöglichkeit vermerkt. Sie erfordert eine Erweiterung der Mitgliederdaten um die E-Mail-Adresse der Benutzer. Die Umsetzung im Programmierbereich gestaltet sich durch eine Reihe von vorgefertigten PHP-Funktionen sehr einfach. Des Weiteren ist zu beachten, dass bei einer Portierung des Systems in ein Gesamtsystem evtl. bereits ein Nachrichtensystem existiert. Die Verwendung bestehender, einheitlicher Ressourcen würde die Implementierung und spätere Benutzung auf jeden Fall erleichtern.

Auf die Möglichkeit, die gesamte Themenabsprache mit dem Dozenten über das System abzubilden, wurde aus mehreren Gründen verzichtet. Ein fehlendes Benachrichtigungssystem auf der einen Seite würde zu einer stärkeren Verzögerung der Absprachen von Gliederung und Thema führen. Auf der anderen Seite wäre eine mündliche Absprache mit dem Dozenten nur durch Ausnahmen möglich.

3.5.3 Beurteilung

Insgesamt ist das Projekt als erfolgreich zu bewerten. Die zuvor definierten Pflichtziele wurden im zeitlichen Rahmen umgesetzt und auch zweitrangige Anforderungen konnten teilweise implementiert werden. Bei der Umsetzung konnte der Übergang von einem Geschäftsprozessmodell hin zur Entwicklung eines Softwareprototypen untersucht werden. Dabei wurde erkannt, dass durch die im Modell bereits definierte Ablauflogik Zeit bei der Entwicklungsarbeit eingespart werden kann. Vor allem die Abbildung des Prozessstatus der Anmeldung ermöglichte eine starke Orientierung am Modell. Dabei ist jedoch zu erwähnen, dass die korrekte und realitätsnahe Modellentwicklung ausschlaggebend für folgende Softwareentwicklung ist. Zu häufige Änderungen am Prozess könnten die Umsetzung stark beeinträchtigen, da in Unternehmen eine flexible Reaktion auf Anpassungen je nach Komplexität des Projekts nicht gewährleistet ist. Eine Überschreitung von zeitlichen und finanziellen Vorgaben wäre die Folge.

4 Schlussbetrachtung

Die Erarbeitung eines Modells vor der Umsetzungsphase bietet vor allem bei vielen aufeinander folgenden Prozessschritten einige Vorteile. Die Abschnitte der Umsetzung und die verschiedenen Status, die eingenommen werden können, sind durch ein solches Modell strukturiert und übersichtlich dargestellt. Diese Steigerung der Übersichtlichkeit rechtfertigt die zur Aufstellung des Modells verwendete Zeit in jedem Fall. Besonders ist bei der Umsetzung eines Modells zu beachten, dass man einen stetigen Abgleich von Modell und Umsetzung gewährleisten muss, da das Ergebnis direkt an dem Modell gemessen wird. Dies lässt sich bei umfangreicheren Projekten besser durch ein modernes Softwareentwicklungsmodell, wie dem Spiralmodell oder Prototyping, gewährleisten. Diese Modelle sind durch die mehrfachen Planungs- und Vergleichsphasen besonders gut geeignet. Bei der Umsetzung dieses Projektes führte das Wasserfallmodell, in Verbindung mit regelmäßigen Absprachen zwischen den Projektmitgliedern zu dem gewünschten Ergebnis. Diese Absprachen sind Charakteristiken des Pair-Programming, welches ein weiteres mögliches Entwicklungskonzept darstellt. Die stetige Absprache würde eine engere Orientierung am Modell, sowie eine höhere Softwarequalität ermöglichen.

Abschließend ist zu erwähnen, dass ein gut abgestimmtes und durchdachtes Prozessmodell viel Arbeit der Implementierungsphase vorwegnimmt, jedoch keine Softwareplanung vollständig ersetzt.

5 Verzeichnisse

5.1 Abkürzungsverzeichnis

5.2 Abbildungsverzeichnis

5.3 Tabellenverzeichnis

5.4 Fußnoten

1. ↑ Vgl. Hammer (1993)
2. ↑ Vgl. Wittges (2005), S. 30 f.
3. ↑ Vgl. Schmelzer (2007), S. 121
4. ↑ Vgl. Schmelzer (2007), S. 122
5. ↑ Vgl. Schmelzer (2007), S. 130 f.
6. ↑ Vgl. Richter von Hagen (2001), S. 137
7. ↑ Vgl. Fischer (2006), S. 105
8. ↑ Vgl. Weber (2001), S. 176
9. ↑ Vgl. Hastedt-Marckwardt (1999), S. 100
10. ↑ Vgl. Versteegen (2002), S. 30
11. ↑ Vgl. Grechenig (2009), S.374
12. ↑ Weitere Informationen und Download unter http://docs.jquery.com/Main_Page
13. ↑ Vgl. http://w3techs.com/technologies/overview/javascript_library/all
14. ↑ Vgl. Levi (2002), S.345

5.5 Literaturverzeichnis