Ein One-Stop-Shop für Smartcard-basierte Dienstleistungen DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Medieninformatik und Visual Computing eingereicht von Jonas Engl, BSc Matrikelnummer 01226658 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Ao.Univ.Prof. Mag. Dr. Horst Eidenberger Wien, 10. August 2018 Jonas Engl Horst Eidenberger Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng A one stop shop for smartcard based services DIPLOMA THESIS submitted in partial fulfillment of the requirements for the degree of Diplom-Ingenieur in Media Informatics and Visual Computing by Jonas Engl, BSc Registration Number 01226658 to the Faculty of Informatics at the TU Wien Advisor: Ao.Univ.Prof. Mag. Dr. Horst Eidenberger Vienna, 10th August, 2018 Jonas Engl Horst Eidenberger Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Jonas Engl, BSc Obere Amtshausgasse 45/14, 1050, Wien Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 10. August 2018 Jonas Engl v Danksagung An dieser Stelle möchte ich mich bei all jenen bedanken, welche mich bei der Umsetzung dieser Diplomarbeit und dem Abschluss des Studiums unterstützt und begleitet haben. An erste Stelle gilt mein Dank meinem Betreuer Ao.Univ.Prof. Mag. Dr. Horst Eidenber- ger, welcher mit Geduld, Hilfsbereitschaft und konstruktiver Kritik die Erstellung dieser Arbeit ermöglicht hat. Des Weiteren möchte ich mich bei meinem Vorgesetzten Dipl.-Ing. Wolfgang Spreicer bedanken, welcher das Thema zur Verfügung gestellt hat und mich während der Erstellung immer begleitet und unterstützt hat. Auch möchte ich mich bei all meinen Kollegen der Stabstelle CSD bedanken, welche mich vor allem beim Erstellen des praktischen Teils beratend unterstützt haben. Vor allem zu erwähnen ist Andreas Nussbaum, welcher mich bei der Planung und Umsetzung maßgeblich unterstützte, Angela Bruck, welche den Kundenkontakt organisierte und Juri Berlanda, Luca Maestri und Stefan Paula, welche bei auftretenden Problemen halfen. Für die Interviews möchte ich mich bei der Abteilung für Gebäude und Technik, der Studienabteilung und der TU.it bedanken. Außerdem danke ich all meinen Freunden, welche mich während der Studienzeit unter- stützt und begleitet haben, insbesondere Christoph Braun und Zeno Casellato für das Korrekturlesen. Abschließend danke ich meiner gesamten Familie, besonders meinen Eltern, welche das Studium ermöglicht und mich während der Studienzeit begleitet und unterstützt haben. vii Kurzfassung Das Ziel der vorliegenden Diplomarbeit war zu untersuchen, welche Auswirkungen die Ein- führung eines One-Stop-Shops für die Aufnahme von Studierenden und Mitarbeiter/innen an der TU Wien, auf die betroffenen Stakeholder hat. Dabei wurde ein besonderes Augenmerk auf die von der TU Wien ausgestellte Smartcard gelegt, die sogenannte TUcard. Dafür wurde ein neues Modul für die Ausstellung und Verwaltung der TUcard im Informations-System der TU Wien implementiert und anschließend über Interviews und eine technische Auswertung analysiert. Zu Beginn wird auf den ursprünglichen Prozess der Aufnahme von Studierenden und Mitarbeiter/innen, der Ausgabe der TUcard und die dabei aufgetretenen Probleme eingegangen. Anschließend folgt eine Einführung in die verwendeten Technologien, in Smartcards und in das Konzept des One-Stop-Shops. Mit den dadurch erworbenen Wissen und den Anforderungen der Stakeholder wird das Design des neuen Prozesses beschrieben und dessen Implementierung erläutert. Abschließend folgt die Auswertung der gefundenen Ergebnisse. Die Notwendigkeit der Umstellung wird mit Hilfe der aufgetretenen Probleme verdeut- licht, welche im Rahmen der Ausgangslage beschrieben werden. Um anschließend eine wissenschaftliche Auswertung zu ermöglichen, wird anfangs eine Forschungsfrage definiert, welche nach der Auswertung der Daten beantwortet werden soll. Basierend auf der Aus- gangslage und deren Probleme, werden Anforderungen aufgestellt, welche eine möglichst positive Beantwortung dieser Frage ermöglichen sollen. Die Anforderungen geben das Design vor, welches anschließend erzeugt und implementiert wird. Die Implementierung wird mit Hilfe von Experteninterviews und einer technischen Auswertung analysiert. Die Auswertung ergab, dass viele Stakeholder, vor allem Studierende und Mitarbei- ter/innen, von der Umstellung profitieren und deren Aufnahme maßgeblich erleichtert wird. ix Abstract The aim of this diploma thesis was to investigate the effects of the introduction of a one-stop-shop for the admission of students and employees at the TU Wien. Special attention was paid to the smartcard issued by the TU Vienna, the so-called TUcard. A new module for the issuing and administration of the TUcard was implemented in the information system of the TU Wien and subsequently analysed via interviews and a technical evaluation. At the beginning, the previous admission process is discussed, its workflows are described, and the problems encountered are listed. This is followed by an introduction to the technologies used, smartcards and one-stop shops. The knowledge acquired and the requirements of the stakeholders are used to describe the design of the new process and its implementation. Finally, the results are evaluated. The need for the adjustment is clarified by the problems encountered, which are described in the context of the initial situation. In order to allow a scientific evaluation afterwards, a research question is defined at the beginning, which is to be answered after the evaluation of the data. Based on the initial situation and its problems, requirements are set which should allow to evaluate the research question. The requirements define the design, which is then generated and implemented. The implementation is analyzed with the help of expert interviews and a technical evaluation. The evaluation showed that most stakeholders, especially students and employees, benefit from the changeover and that the first admission is much easier for them. However, there were also complications in the planning and redistribution of tasks. xi Inhaltsverzeichnis Kurzfassung ix Abstract xi Inhaltsverzeichnis xiii 1 Einleitung 1 1.1 Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Fragestellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Überblick über die Diplomarbeit . . . . . . . . . . . . . . . . . . . . . 8 2 Technischer Hintergrund 11 2.1 Verwendete Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 One-Stop-Shops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3 Projekt-Design 39 3.1 Analyse der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Notwendige Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4 Implementierung 47 4.1 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 Kommunikation mit anderen Systemen . . . . . . . . . . . . . . . . . . 55 5 Ergebnisse 61 5.1 Abgrenzung: Mein Beitrag im gegenständlichen Projekt . . . . . . . . . 61 5.2 Evaluierung der Forschungsfrage . . . . . . . . . . . . . . . . . . . . . . 61 5.3 Probleme und weitere Verbesserungsmöglichkeiten . . . . . . . . . . . 68 5.4 Vergleich mit anderen Umstellungen . . . . . . . . . . . . . . . . . . . 70 6 Zusammenfassung und Ausblick 71 Literaturverzeichnis 73 xiii KAPITEL 1 Einleitung 1.1 Ausgangslage 1.1.1 Einführung Die TU Wien verwendet für die Organisation von Studierenden, Lehrenden, Mitarbeitern und Forschung das hauseigene TU Wien Informations-Systeme & Services.1 Am 1. März 2016 wechselte die Entwicklung, Betrieb und Instandhaltung dieses Systems vom Zentralen Informatikdienst2 in eine eigene Stabstelle, den Campus Software Development.3 Im Zuge dieser Umstellung stellte sich die TUcard, deren Produktion und Wartung / Organisation, als kritischer Themenpunkt heraus. Mehrere Stakeholder drückten ihre Unzufriedenheit mit dem aktuellen Workflow aus und forderten eine Veränderung. Mit dieser Ausgangslage wurde ein Projektteam erstellt, welches sich um mögliche Lösungen kümmern sollte und dadurch wieder alle Stakeholder zufrieden zu stellen. 1.1.2 Die TUcard Die TUcard wurde 2012 an der TUWien eingeführt. Zu diesem Zeitpunkt war sie allerdings lediglich für Mitarbeiter verfügbar und diente primär als Ausweis zur Identifizierung. 2015 wurde die TUcard dann auch für Studenten vorgestellt, als offizieller Studentenausweis. 1kurz TISS, https://tiss.tuwien.ac.at/, 28.09.2018 2kurz TU.it, https://www.it.tuwien.ac.at/, 28.09.2018 3kurz CSD, https://www.tuwien.ac.at/dle/campus_software_development_tiss/, 28.09.2018 1 1. Einleitung Seitdem erfüllt sie zusätzlich dazu noch folgende Zwecke: • Identifizierung: Durch den Vorweis der TUcard kann eine Person identifiziert wer- den. Dies findet derzeit vor allem bei Prüfungen, zur Identifizierung der Studenten, Anwendung. • Fortmeldung: Mit Hilfe des an der Rückseite vorhandenen Thermostreifens, kann das aktuelle Gültigkeitsdatum immer wieder neu aufgedruckt werden und so die Validität festgestellt werden. • Schließsystem: In einigen Gebäuden der TU Wien wurde ein Schließsystem installiert, welches eine automatische Zugangskontrolle ermöglicht. Mit Hilfe des RFID-Chips auf der TUcard können den Nutzer Rechte zugewiesen werden, mit denen bestimmte Bereiche der Gebäude betreten werden dürfen. • Gäste: Als Gastvortragender an der TU Wien erhält man eine Gästekarte, mit welcher auch diese Personen die Funktionen (vor allem das Schließsystem) nutzen können. • Bibliothek: Studenten und Mitarbeiter können ihre TUcard noch zusätzlich für die Bibliothek aktivieren lassen, wodurch man sie auch zum Entlehnen von Büchern verwenden kann. • Drucken: An einigen Standorten ist es möglich, sich mit der TUcard an den Druckern zu identifizieren und damit Dokumente zu drucken. 1.1.3 Aktueller Workflow Um die vorher angesprochene, unzufriedenstellende Situation, besser verständlich zu machen und anschließend die Probleme zu verdeutlichen, wird im folgenden der aktuelle Produktionsprozess für Mitarbeiter- und Studentenkarten beschrieben. TUcard für Studierende 1. Personen, welche sich für ein Studium an der TU Wien anmelden möchten, müssen zu Beginn eine Online-Vorerfassung ausfüllen. 2. Anschließend muss die Person in der Studienabteilung erscheinen, wo nach Einsicht aller benötigter Dokumente und Daten der Student aufgenommen wird. 3. Nach der erfolgreichen Aufnahme wird eine Kartenbestellung erzeugt, welche dann in gewissen Zeitabständen zur TU.it synchronisiert wird. 4. Da jederzeit neue Bestellungen erzeugt werden können, müssen die Personen in der TU.it regelmäßig auf aktive Kartenbestellungen abfragen, verknüpfte Bilder der Personen auf alle benötigten Voraussetzungen überprüfen und je nach Anzahl, diese in eine Wochenbestellung zusammenfassen. 2 1.2. Fragestellung 5. Diese Wochenbestellung wird dann wiederum in einzelne Druckaufträge getrennt und bearbeitet. 6. Nach erfolgreichem Druck, müssen die Karten nochmals synchronisiert und für jede einzelne ein Aktivierungsbrief generiert und gedruckt werden. 7. Die TUcard wird anschließend auf den Aktivierungsbrief geklebt, zusammen in ein Kuvert verpackt und verschickt. 8. Nach dem Erhalt muss der/die Student/in den Aktivierungscode in TISS eingeben, um diese zu aktivieren und dadurch eine missbräuchliche Verwendung zu verhindern. TUcard für Mitarbeiter 1. Mitarbeiter müssen sich im TISS einloggen und dort zum Menüpunkt TUcard navigieren. Dort kann eine Karte bestellt werden. 2. Es muss ein valides Bild hochgeladen werden. 3. Der Produktionsprozess ist ident zur Studierendenkarte. 4. Anschließend wird die Karte via Hauspost versendet. 1.2 Fragestellung 1.2.1 Aktuelle Probleme Durch das aktuelle System und die verwendeten Workflows, welche im vorherigen Kapitel beschrieben worden sind, entsteht eine Vielzahl an Problemen; diese führen zu der Unzufriedenheit bei den einzelnen Stakeholdern. Im Folgenden wird auf die Schwierigkeiten genauer eingehen, wo und wieso diese auftreten, um dadurch die aktuelle Situation zu verdeutlichen. 1. Durch die unterschiedlichen Orte der Bearbeitung (Studienabteilung4, TU.it, TISS), werden viele Daten unnötigerweise mehrfach gespeichert und müssen immer wieder synchronisiert werden. 2. Die Bestellungen müssen immer wieder manuell abgefragt und bearbeitet werden. 3. Der Kartendruck gestaltet sich immer mehr zu einem Problem, da die Drucker, vor allem zu Beginn, sehr wartungsintensiv sind und keinen effizienten Workflow zulassen. 4. Das Ausdrucken der Aktivierungsbriefe, deren Zusammenführung mit der passenden TUcard und anschließendem Versenden ist sehr zeitintensiv. 4Kurz STAB, https://www.tuwien.ac.at/dle/studienabteilung/, 05.10.2018. 3 1. Einleitung 5. Die Zeitspanne zwischen Bestellung und Erhalt der Karte ist in den meisten Fällen nicht optimal (mindestens zwei Wochen). 6. TUcards für Studierende können nur an österreichische Adressen versendet werden, andernfalls muss die Karte persönlich in der TU.it abgeholt werden. 7. Das Versenden der TUcard ist kostspielig und garantiert keine sichere Zustellung. 8. Beim Versand der Mitarbeiterkarte via Hauspost wird nur an die Hauptadres- se des Institutes versendet. Dies ist problematisch bei Mitarbeitern in externen Laboratorien. 1.2.2 Lösungsvorschläge Wie vorher angesprochen, wurde das Projektteam beauftragt verschiedene Lösungsmög- lichkeiten auszuarbeiten. Diese werden im Folgendem kurz vorgestellt: 1. Interne Optimierung: Beim ersten Vorschlag wird der gesamte Prozess der Kar- tenproduktion und Kartenorganisation umgestellt. Die komplette Erstanmeldung soll in One-Stop-Shops abgewickelt und prinzipiell vereinfacht werden, neue Karten und Kartendrucker werden angeschafft und die Organisation für Administratoren wird optimiert. Dies soll mit der neu geschaffenen Stabstelle CSD umgesetzt werden. Dieser Vorschlag ist der für die TU Wien aufwandreichste, setzt die Bedürfnisse aber bestmöglichst um. 2. Beibehaltung Status Quo: Beim zweiten Vorschlag wird das System so weiter- geführt und nur dringend notwendige Änderungen eingebaut. Durch diese kleineren Änderungen soll die Zufriedenheit gesteigert werden, ohne viele Kapazitäten zu verbrauchen. Auch für diese Änderungen wäre die Stabstelle CSD verantwortlich. Hier können natürlich nicht alle Wünsche der Benutzer umgesetzt werden, ist dafür aber mit geringeren Kosten verbunden. 3. Outsourcing: Der letzte ausgearbeitete Vorschlag ist die Auslagerung der Pro- duktion und Wartung an einen externen Dienstleister. Die Karten würden somit extern codiert, bedruckt und versendet um den Aufwand für die TU Wien mög- lichst zu reduzieren. Natürlich bringt eine Weitergabe solcher Verantwortungen auch Risiken mit sich, besonders im Sicherheitsbereich. Aufgrund dieser Bedenken, wurde beschlossen, dass die Verwaltung der Schlüssel im Haus bleibt und diese dort verwaltet werden. Zusätzlich dazu würden auch hohe Implemtierungs- und Wartungskosten anfallen Nach ausgiebiger Analyse beschloss man den ersten Vorschlag umzusetzen. Trotz der höheren Implementierungskosten und Resourcenaufwand überwogen die Vorteile und es kann damit die Zufriedenheit der Benutzer optimal gesteigert werden. Die konkrete Umsetzung wird in den nächsten Kapiteln erläutert. 4 1.3. Anforderungen 1.2.3 Forschungsfrage Durch die nun klar definierte Problemstellung und Beschreibung des derzeit verwendeten Systems kann folgende Forschungsfrage definiert werden: Wie wirken sich die Einführung eines One-Stop-Shops bei der Erstaufnahme und die dazu notwendigen Optimierungen auf die Stakeholder des Systems aus? Die Forschungsfrage soll untersuchen, ob und wenn ja welche Veränderungen auftreten, wenn das bisherige System durch einen One-Sop-Shop ersetzt wird, welcher die Aufnahme von Studenten und Mitarbeitern regelt. Dies soll vor allem in jenen Bereichen analysiert werden, welche im direkten Kontakt mit der Produktion und der allgemeinen Handha- bung der TUcard stehen, da diese den Hauptteil des Projektes bildet. Im Rahmen der Umstellung auf einen One-Stop-Shop werden zudem noch eine Vielzahl an Optimierungen umgesetzt, um auch die Organisation und Wartung der TUcard zu verbessern. Diese Anpassungen und die Einführung des One-Stop-Shops sollen auf eine optimale Benutzer- zufriedenheit ausgelegt sein und alle Stakeholder berücksichtigen. Um anschließend die Froschungsfrage auswerten zu können, werden einige Benutzer mithilfe quantitativer und qualitativer Methoden befragt und die Verwendung des Systems untersucht (mehr dazu in Abschnitt 1.4). 1.3 Anforderungen Mit der Entscheidung das System intern zu optimieren, wurden Anforderungen aufge- stellt, welche das System erfüllen muss um die benötigten Funktionen bereitzustellen. Diese Funktionen bzw. Anforderungen sind Grundlage für die Steigerung der Benutzer- Experience und um dadurch eine möglichst effiziente und zufriedenstellende Applikation zur Verfügung zu stellen. Die wichtigsten werden hier aufgelistet und kurz beschrieben: 1. Die Erstaufnahme für Studierende wird zu einem One-Stop-Shop. Damit kann der gesamte Aufnahmeprozess an einer Stelle abgehandelt werden und der/die Student/in verlässt bereits mit TUcard und aktivem TISS-Account die Studienab- teilung. Dieser Echtzeitdruck der Karte wird auch für alle anderen Kartentypen verwendet. 2. Durch den Echtzeitdruck entfällt der Aktivierungsbrief und die damit zusammen- hängenden Tasks in der TU.it. Auch das regelmäßige Überprüfen der Bestellungen, Aufteilung nach Wochen und manueller Druck werden damit überflüssig. 3. Jede Abteilung verwaltet nur die für sie relevanten Daten, da der Kartendruck nach Personentypen aufgeteilt wird. Dies verhindert unnötiges Synchronisieren und mehrfache Speicherung der Daten. 5 1. Einleitung 4. Gäste, welche für einen längeren Zeitraum an der TU Wien lehren bzw. forschen, erhalten eine personalisierte “weitere Mitarbeiterkarte”. Diese soll für alle Stakehol- der die Organisation verbessern und vor allem dem Gast die Zeit an der TU Wien so angenehm wie möglich gestalten. 5. Administratoren sollen verschiedene Übersichtsseiten erhalten, um Geschäftsprozes- se beobachten, falls notwendig eingreifen und den Benutzern helfen zu können. 6. Die Usability soll stark gesteigert werden. Viele Workflows sind derzeit nicht optimal und können noch verbessert werden. 7. Der Kartenverbrauch soll durch zuverlässigere Drucker und eine Deaktivierungs- funktion für Karten reduziert werden. Das Deaktivieren ermöglicht ein Reaktivieren beim Wiederauffinden der Karte, wobei diese in der Zwischenzeit nicht verwendet werden kann. Dadurch muss die TUcard nicht sofort gesperrt und nachproduziert werden. Vergleicht man nun die Probleme mit den hier aufgelisteten Zielen, findet man für alle eine passende Lösung. Punkt 1 wird durch die Aufteilung der Verantwortung auf die passende Abteilung gelöst. Die Studienabteilung ist für die Studentenkarten zuständig, die Personalabteilung für Mitarbeiterkarten. Alle Probleme, die beim Versand aufgetreten sind, werden durch den Echtzeitdruck und das sofortige Ausgeben der Karte gelöst. Hier wird auch der Arbeitsaufwand weitgehend verringert, da die Bestellungen sofort bearbeitet werden können und sich nicht in einer Abteilung anhäufen. Durch zusätzliche Kartentypen (weitere Mitarbeiter, Gäste), bessere Usability und Administrierungsoberflächen kann das gesamte System einfacherer gewartet werden und bietet dem Benutzer eine optimierte Dienstleistung. In Bezug auf die gestellte Forschungsfrage wird eine Verbesserung in allen Bereichen angestrebt. Der One-Stop-Shop soll den neuen Studenten und Mitarbeitern das Einsteigen wesentlich vereinfachen und ein sofortiges Beginnen ermöglichen. Auch für die Stakeholder, welche das System steuern und bedienen, werden die neuen Organisationsstrukturen (Aufteilen der Zuständigkeiten), Benutzeroberflächen und Workflows hoffentlich eine positive Entwicklung darstellen. Die Bedienung und Wartung wird intuitiver und eine gesamte Weiterentwicklung bieten, welche den Benutzer im Zentrum sieht. 6 1.4. Vorgehen 1.4 Vorgehen Um die neue Applikation möglichst korrekt und effizient implementieren zu können, wird folgendermaßen vorgegangen: 1. Analyse der Anforderungen: Für die Umstellung des Workflows und Erweite- rung des gesamten TUcard-Bereichs wurde von der TU Wien bzw. den zuständigen Personen ein umfangreiches Konzept mit Anforderungen erstellt. In einem ers- ten Schritt wird dieses Dokument ausgewertet, analysiert und in Arbeitspakete eingeteilt. 2. Analyse Status Quo: Um den derzeitigen Workflow besser zu verstehen und um ihn für die Benutzer nachhaltig zu optimieren, wird dieser genau beobachtet und Gespräche mit den zuständigen Personen geführt. Dabei wird versucht, zusätzlich zu den Anforderungen des Konzeptes, auch auf Wünsche und Empfehlungen einzugehen. Wichtiger Ansprechpartner werden jene Personen sein, welche zur Zeit für die Kartenproduktion zuständig sind. Die Erfahrung dieser Angestellten in der TU.it ist sehr wichtig für die Verbesserung dieses Systems, da sie schon viele Jahre damit gearbeitet haben und die Schwächen und Stärken am Besten kennen. Ein weiterer wichtiger Stakeholder sind jene Personen, welche zukünftig mit dem System arbeiten werden, wie bspw. die Studienabteilung. Hier werden sich die Gespräche vor allem um ihren aktuellen Workflow drehen und wie man den Echtzeitdruck in diesen einbauen kann. Ein wichtiger Punkt wird das Einbinden der neuen Elemente, in einen sonst möglichst ähnlichen Arbeitsprozess sein. 3. Design: Nachdem ein für möglichst alle Stakeholder optimiertes System konzipiert wurde, wird der nächste Schritt das Designen der Software sein. Es werden Requi- rements und Entwicklertickets im Projektmanagementsystem angelegt, Strukturen überlegt und Abläufe besprochen. Für eine möglichst effiziente Implementierung und ein gutes Endergebnis ist das gute Planen und Designen ein fundamentaler Schritt. Die grundlegenden Workflows und geforderten Funktionalitäten sind zu diesem Zeitpunkt klar und werden beim erneuten Durchdenken des Systems noch erweitert bzw. angepasst. Es werden benötigte Datenstrukturen überlegt und nach geeigneten Frameworks gesucht. Dies ist wichtig, da zu Beginn schon bekannt ist, welche technische Anforderungen an das System gestellt werden (Geschwindigkeit, Zuverlässigkeit etc.) und basierend auf diesen können diese grundlegenden Entschei- dungen getroffen werden. Ein passendes Framework und eine gute Struktur der Daten werden die Implementierung maßgeblich beeinflussen. 4. Prototypische Implementierung: Der nächste Schritt ist der Start der Imple- mentierung. Die klar definierten Requirements und Strukturen geben den Ablauf, Ziele und Zeitplan vor, um möglichst effizient Code von hoher Qualität zu erzeu- gen. Der erste Schritt ist das Aufsetzen des gewählten Frameworks. Es bildet die Grundlage für den darauf optimierten Code und jegliche weitere Schritte. 7 1. Einleitung Anschließend wird mit der Implementierung der ersten Features begonnen. Hier wird versucht immer einen Workflow von Backend bis Frontend zu programmieren, damit die Stakeholder schnell Ergebnisse sehen und bei Bedarf eingreifen können, falls das Resultat sich vom gewünschten Produkt zu stark unterscheidet (user-centered design). Würde man mit dem kompletten Backend bzw. Frontend beginnen, wäre ein großer Aufwand nötig, um die Anwendung später nochmals zu ändern. Um die Implementierung zu überprüfen wird natürlich auch auf automatisierte Tests gesetzt, welche zu jedem Zeitpunkt den Stand des Systems überprüfen können. Zwi- schenstände der Applikation werden auf Testservern deployed, um den Stakeholdern den Fortschritt zeigen zu können und gleichzeitig echte Testdaten und Feedback zu erhalten. Ein wichtiger Schritt der Implementierung wird die Kommunikation mit dem Kartendrucker sein. Diese muss einwandfrei funktionieren und alle möglichen Testfälle abdecken. Auch hier werden dem Benutzer bestimmte Oberflächen geboten um Fehler beheben und aktuelle Zustände überwachen zu können. 5. Evaluierung der Forschungsfrage: Sobald die neue Applikation prototypisch implementiert ist, kann die Forschungsfrage untersucht werden. Hierfür werden qualitative Interviews mit den Stakeholdern geführt und Evaluierungen mit Frage- bögen durchgeführt. Besonders auf die Benutzer-Experience soll hier eingegangen werden, da mit dem System möglichst einfach und effizient interagiert werden soll. Zusätzlich werden auch die Logdateien des Systems analysiert und auf Muster untersucht, um durch die Ausgaben der Applikation die Workflows besser betrach- ten zu können oder auch auf mögliche Fehler zu stoßen. Wurden alle notwendigen Daten gesammelt, können diese ausgewertet und damit die gestellte Forschungsfrage beantwortet werden. 1.5 Überblick über die Diplomarbeit Technischer Hintergrund: Dieses Kapitel führt den Leser in die Grundlagen der ver- schiedenen verwendeten Technologien, Konzepte und Artefakte ein. Zu Beginn werden software-relevante Begriffe eingeführt und beschrieben, dahinterliegende Konzepte er- läutert und verwendete Bibliotheken erklärt. Anschließend folgt eine Einführung in das Konzept der Smartcards. Deren Entstehungsgeschichte wird kurz angesprochen, sowie auch Aufbau und Funktionsweise. Zum Schluss folgt eine Einführung in das Konzept des One-Stop-Shops. Zusätzlich wird auch noch die Umstellung auf One-Stop-Shops besprochen. Projekt-Design: Hier wird dem/der Leser/in ein Einblick in den Designprozess des Projek- tes gegeben. Zu Beginn werden die Anforderungen analysiert, welche im ersten Kapitel aufgelistet worden sind. Anschließend folgt die Analyse des derzeitigen Arbeitsablaufes und Gespräche mit den Benutzern. Abschließend wird noch das resultierende Design beschrieben; hier werden Entscheidungen zu den Frameworks und Workflows erläutert und diese entsprechend präsentiert. 8 1.5. Überblick über die Diplomarbeit Implementierung: Im Kapitel Implementierung wird auf die eigentliche Applikation, deren Quellcode und Aufbau eingegangen. Der Leser bekommt ein Einblick wie das System aufgebaut ist, wie die internen Arbeitsabläufe funktionieren und wie während der Entwicklung getestet wurde. Ein kurzer Einblick zur Datenschutzverordnung wird aus gegebenen Anlass auch noch angehängt. Ergebnisse: Abschließend werden hier die gefundenen Daten ausgewertet und versucht, die gestellte Forschungsfrage zu beantworten. Das Projekt wird mit anderen ähnlichen Umsetzungen verglichen und auf Vorzüge der implementieren Lösung bzw. weitere mögliche Verbesserungen eingegangen. 9 KAPITEL 2 Technischer Hintergrund 2.1 Verwendete Technologien Für die Umsetzung des Projektes wurde eine Vielzahl an Technologien und Bibliotheken verwendet, welche den Entwicklungsprozess maßgeblich vereinfachten. In der folgenden Auflistung können nicht alle Artefakte erwähnt werden, da dies nicht das Ziel dieser Arbeit ist. Zu den relevantesten Technologien wird es im Folgenden aber eine kurze Einführung geben, da dies zum Verständnis der Projektstruktur fundamental ist. 2.1.1 Java-Technologie Die Java-Technologie ist eine von Sun1 entwickelte Sammlung von Spezifikationen, welche ursprünglich für Geräte in der Heimunterhaltungsbranche geplant war; dafür wurde sie aber als zu komplex und fortgeschritten eingestuft. Zur ungefähr gleichen Zeit wurde das Internet für einen größeren Teil der Bevölkerung erreichbar, weshalb erste Webbrowser entwickelt wurden, bspw. von Netscape (Netscape Navigator [Hei]). Die Entwickler dieses Browsers wurden auf Java aufmerksam und gaben 1995 bekannt, dass sie zusammen mit der neuen Java-Technologie ihr Projekt umsetzten würden [Oraa]. Seitdem hat sich Java weiterentwickelt und verbreitet. Eine große Anzahl an Versionen wurde veröffentlicht und es wird auf über einer Milliarde an Geräten verwendet; von mobilen Kleingeräten bis zum Smart TV [Sun]. Die Java-Technologie besteht grundsätzlich aus vier Komponenten: Plattform, Program- miersprache, Entwicklungswerkzeugen und Laufzeitumgebung [ZKG13]. 1Nun Teil von Oracle, https://www.oracle.com/sun/, 11.11.2018. 11 2. Technischer Hintergrund Plattform Eine der Spezifikationen befasst sich mit der Plattform, der sogenannten Java Virtual Machine (JVM) [Orae]. Die JVM ist ein virtuelles System, welches für die Ausführung und das Speichermanagement von Java-Programmen zuständig ist. Durch diese Grundlage kann das Konzept Write once, run anywhere angewandt werden, d.h. dass der gleiche Code, ohne zusätzlichen Anpassungen, auf unterschiedlichsten Geräten laufen kann. Die Einführung der JVM war eine große Erleichterung für die Entwickler. Durch das automatische Speichermanagement musste Speicher nicht mehr manuell freigegeben werden, und es konnte unabhängig von Betriebssystem entwickelt werden. [Tysc]. Programmiersprache Eine weitere Spezifikation ist die Programmiersprache selbst, genannt Java. Ihr zufolge ist die Sprache “a general-purpose, concurrent, classbased, object-oriented language. It is designed to be simple enough that many programmers can achieve fluency in the language“ [GJS+14, 1] [Orac]: • General-purpose bedeutet, dass sie für eine Vielzahl an verschiedensten Applikatio- nen eingesetzt werden kann • Concurrent steht für Nebenläufigkeit. Die Sprache soll in der Lage sein, mehrere Tasks gleichzeitig ausführen zu können. • Object-Oriented / Class-Based ist ein Programmierparadigma, welches die Pro- grammstruktur auf Basis von Objekten aufbaut. Daten werden in Feldern von Objekten gespeichert, Funktionalität als Prozeduren. Geschätzte neun Millionen Entwickler arbeiten zur Zeit mit Java; der häufigste Einsatz- zweck, wie auch bei dem hier beschriebenen Projekt, sind Web-Applikationen [McM]. Durch die Übernahme von Oracle gab es eine große Anzahl an Veränderungen, mit dem Ziel noch mehr Entwickler für die Technologie zu begeistern. Vor allem der Veröffentli- chungszyklus wurde angepasst. Halbjährlich soll nun eine neue Version verfügbar sein, mit einem eingeschränkteren Support-Zeitraum. Zwischenzeitlich wird es ein Long term support release mit längeren Support-Zeiten geben [Orag]. Entwicklungswerkzeuge Um Java-Applikationen zu entwickeln wird das Java Development Kit (JDK) benötigt. Es bietet eine Vielzahl an Werkzeugen, darunter bspw. den Compiler. Er ist dafür ver- antwortlich, den geschriebenen Code zu kompilieren, damit eine ausführbare Applikation zu erzeugen, welche dann auf der JVM ausgeführt werden kann. Außerdem bringt das JDK eine Vielzahl an Bibliotheken mit sich, welche vom Entwickler verwendet werden können, um somit das Erzeugen neuer Projekte zu erleichtern [Tysa]. 12 2.1. Verwendete Technologien Laufzeitumgebung Die letzte und zugleich wichtigste Komponente, um Java-Programme ausführen zu können, ist die Java-Laufzeitumgebung.2 Sie gilt als Orchestrator der einzelnen Komponenten und ist dafür zuständig, dass diese ordnungsgemäß funktionieren können. Genauer gesagt unterstützt sie das Laden der Klassen bzw. externen Bibliotheken, damit diese zum richtigen Zeitpunkt verfügbar sind und unterstützt die JVM bei Speicherzugriffen und beim Bereitstellen anderer Systemressourcen. Die JRE gilt als eine Abstraktion des Betriebssystem; sie liegt auf der obersten Architekturschicht und stellt ein Meta- Betriebssystem dar. Damit können unabhängig von der darunterliegenden Architektur Applikationen ausgeführt werden. Beim Ausführen einer Java-Applikation lädt die JRE also zuerst alle benötigten Klassen und startet anschließend die JVM, welche dann das eigentliche Java-Programm startet [Tysb]. 2.1.2 Java Platform Enterprise Edition Java Platform Enterprise Edition (JavaEE) ist eine von Java veröffentlichte Sammlung an Spezifikationen, welche mit Hilfe von Java-Entwicklern, verschiedenen Industriepart- nern und Open-Source Organisationen entwickelt wurde. Sie ist, wie der Name schon sagt, auf die Entwicklung von Enterprise-Applikationen ausgelegt, und soll somit helfen Geschäftsprozesse einfacher umzusetzen [Orab]. Bei Enterprise-Applikationen handelt es sich um speziell für Unternehmen ausgelegte Projekte. JavaEE soll dem/der Entwick- ler/in helfen, skalierbare, zuverlässige und sichere Web-Applikationen zu erzeugen [Orad]. Da es sich hier lediglich um eine Spezifikation handelt, gibt es eine große Anzahl an Implementierungen zwischen welchen der/die Entwickler/in, je nach Bedarf, wählen kann [Orab]. 2.1.3 Wildfly Eine dieser Implementierungen, auf welcher auch das hier beschriebene Projekt basiert, nennt sich Wildfly.3 Wildfly ist ein Open-Source Server, welcher von JBoss entwickelt wurde und die JavaEE-Spezifikationen umsetzt. Ein wichtiger Punkt welcher diese Implementierung von anderen unterscheidet und der für unser Projekt besonders wichtig ist, ist die Offenheit und Konfigurierbarkeit (leightweight). Dadurch kann sie optimal an den benötigten Kontext angepasst werden und erzielt eine vergleichbar höhere Performanz [JBo]. Wildfly ist ein Community-Projekt, d.h. es wird unentgeltlich von einer Gruppe von Entwicklern weiterentwickelt und steht jedem, auch Unternehmen, kostenlos zur Verfügung. Dies bedeutet allerdings auch, dass man sich auf den Support der Community verlassen muss, was aber bei so großen und viel verwendeten Projekten meist problemlos ist [Ran]. 2auch java runtime environment oder kurz JRE 3Früher JBoss, http://wildfly.org/, 16.11.2018 13 2. Technischer Hintergrund 2.1.4 Java Server Faces Java Server Faces4 ist ein Web-Framework, welches die Erstellung von Benutzeroberflächen erleichtern soll. Dies wird dadurch erreicht, dass es eine Vielzahl an wiederverwendbaren Komponenten anbietet, welche vom Entwickler, unabhängig vom Kontext, eingebunden werden können. Außerdem stellt es eine Verbindung zwischen der Oberfläche und der Funktionalität im Code her, sodass mit einfachen Ereignissen und Funktionsaufrufen kommuniziert werden kann [Tut]. JSF ist der Standard für komponentenbasierte Benut- zeroberflächen in JavaEE und wurde deshalb und da es alle Anforderungen erfüllt für unser Projekt gewählt [Oraf]. Um die Komponenten von JSF zu erweitern wurde die Bibliothek Primefaces im Projekt eingesetzt. Primefaces bietet angepasste Lösungen für Unternehmen an, erweitert die Funktionalität von Komponenten und bietet zusätzliche neue Komponenten an. Durch das Angebot sehr geeigneter Artefakte und die positive Beurteilung von Entwicklern, wurde es im Projekt eingeführt [Pri]. 2.1.5 Oracle Database Oracle Database5 ist eines der meist verwendeten relationalen Datenbanksysteme in Unternehmen. Es wird seit 1977 von Oracle entwickelt und bietet mittlerweile vor allem netzwerkbasierte Datenbank-Lösungen für verteilte Systeme an [Tecb]. In TISS6 wurde dieses Framework bereits verwendet und als sehr zuverlässig befunden. Durch die gesammelten positiven Erfahrungen und das bereits laufende System entschied man sich, für dieses Projekt, auch dieses System zu verwenden. 4Kurz JSF, https://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html, 22.2.2019 5Kurz Oracle DB, https://www.oracle.com/database/, 16.11.2018 6https://tiss.tuwien.ac.at/, 22.2.2019 14 2.2. Smartcards 2.2 Smartcards 2.2.1 Einführung Smartcards gehören zu den am häufigsten verwendeten Technologien unserer Zeit, auch wenn sie als solche nicht immer erkannt werden. Durch die Möglichkeit sehr kleine Smartcards zu produzieren, hat die Bevölkerung sie teilweise aus den Augen verloren. Dennoch sind sie immer noch eine der wichtigsten Technologien für Sicherheitssysteme, da sie den Zugang zu kritischen Bereichen beschränken können. In den letzten Jahren sind auch noch andere Einsatzzwecke hinzugekommen, welche vor allem Reisepässe, Ausweise, Tickets usw. betreffen und dadurch wieder vermehrt in den Medien auftreten [MM07]. Eine Smartcard ist, wie der Name schon sagt, mehr als eine normale Karte. Smart steht in diesem Zusammenhang dafür, dass sie auch selbst Prozesse ausführen und Daten speichern kann oder die Benutzung eines anderen Systems überhaupt ermöglichen. Card kann in diesem Sinn auch falsch verstanden werden, weil man dabei eher an eine Karte in Kreditkartenformat denkt. Im Kapitel 2.2.3 wird dann aufgezeigt, dass dies aber stark variiert. Nach [MM07] muss eine Smartcard aber grundsätzlich folgende Eigenschaften erfüllen, um als solche angesehen zu werden: • Sie kann in einem automatisierten elektronischen Prozess partizipieren. • Sie wird grundlegend dazu verwendet, um Sicherheit zu einem Prozess hinzuzufügen. • Sie kann nicht einfach kopiert werden. • Sie kann Daten abgesichert speichern. • Sie kann mehrere verschiedene Sicherheitsalgorithmen ausführen. Um einen kurzen Ausblick auf die Folgekapitel zu ermöglichen, werden hier die jeweils behandelten Themengebiete kurz erläutert. • Geschichte: In diesem Kapitel wird die Entstehungsgeschichte der Smartcard aufbereitet. Es wird vor allem die Entwicklung von der ersten Smartcard bis zum heutigen Standard aufgezeigt und versucht, die einzelnen Entscheidungsschritte zu erläutern. • Aufbau, Design und Bestandteile: Hier werden die einzelnen Komponenten, aus welchen eine moderne Smartcard besteht, vorgestellt. Es werden verschiedene Designs diskutiert und wie die Smartcard darauf basierend kategorisiert werden kann. 15 2. Technischer Hintergrund • Funktionsweise und damit verbundene Sicherheitsaspekte: Anschließend wird die Funktionsweise der Smartcard beschrieben. Vor allem wird es hier um die Zusammenarbeit der einzelnen bereits vorgestellten Komponenten gehen und wie dadurch eine Smartcard mit einem Lesegerät kommuniziert. Abschließend folgt noch ein Abschnitt über Sicherheitskonzepte in Bezug auf Smartcards und deren Kommunikation mit Lesegeräten, da dies in der heutigen Zeit von besonderer Wichtigkeit ist. • Anwendungszwecke: In diesem Kapitel werden die wichtigsten Anwendungs- zwecke beschrieben, d.h. in welchen Bereichen sie verwendet werden und welchen Zweck sie dort erfüllen. Anschließend folgt noch eine Diskussion über mögliche Vor- und Nachteile, welche durch ihre Verwendung auftreten. • Smartcards in universitären Einrichtungen: Abschließend folgt noch eine genauere Untersuchung über Smartcards in universitären Einrichtungen, da dies für das Projekt von besonderer Bedeutung ist. 2.2.2 Geschichte Vor der Erfindung der Smartcard waren die Menschen auf Ausweise aus Papier und Karton angewiesen. Diese hielten allerdings den meisten Wetterbedingungen nicht stand. Nach der Entwicklung von PVC und dessen Industrialisierung, wurden um 1950 die ersten plastifizierten Karten für High-End-Kunden produziert; diese bildeten die erste Form der bargeldlosen Bezahlung. Allerdings war diese Art von Karten nur für eine gehobenen Schicht der Bevölkerung zugänglich und galt somit als ein Statussymbol. Da noch keinerlei Sicherheitsmechanismus in der Karte implementiert war, bezahlte man mit seinem “angesehenen Namen“, welcher auf der Karte aufgedruckt war. Diese wurden allerdings auch nur in ausgewählten Restaurants und Hotels akzeptiert, wo die Personen auch bekannt waren und daher identifiziert werden konnten [HYC+11] [MT98] [RE10]. Mit Maestro und Visa wurde diese Möglichkeit der Bezahlung einem wesentlich größeren Teil der Bevölkerung zugänglich. Von den USA ausgehend, einige Jahre später auch in Europa und der restlichen Welt, boten sie Reisenden eine komplett neue Erfahrung; es war kein Geldwechsel mehr nötig und man fühlte sich sicherer als vorher mit Bargeld. Durch diese und noch viele andere Vorteile etablierten sich Kreditkarten schnell und sind heute kaum mehr wegzudenken [MT98] [RE10]. Zu Beginn wurden nur sehr einfache Sicherheitsmechanismen verwendet. Der Name und die Kartennummer wurden eingestanzt und es gab meist noch ein Unterschriftfeld, auf dem der/die Besitzer/in unterschreiben musste. Mit der folgenden Ausbreitung war dies aber nicht mehr ausreichend; Verbrecher wurde auf die Sicherheitslücken aufmerksam, wodurch die Hersteller der Karten zum Handeln gezwungen waren. Auch Banken forder- ten Veränderung, da alle Transaktionen mit der Karte noch manuell abgebucht werden mussten. Viele dieser Probleme wurden mit dem Anbringen eines Magnetstreifens auf der Rückseite der Karte behoben. Alle Transaktionen konnten nun rein elektronisch durchge- führt werden und für zusätzliche Sicherheit wurde ein PIN eingeführt. Am Magnetstreifen 16 2.2. Smartcards wurden persönliche Daten gespeichert, welche durch ein Lesegerät ausgelesen werden konnten. Da solche Magnetstreifen manipulierbar waren, wurde der PIN auf eigenen Systemen der Anbieter gespeichert und bei Bedarf abgefragt und verglichen [RE10]. In den Jahren nach 1970 wurden gleichzeitig auch große Fortschritte im Bereich der Mikroelektronik erreicht. Es konnten Chips hergestellt werden, welche nur noch wenige Quadratmillimeter groß waren und dennoch genug Speicher und Prozessorleistung boten, um sie für verschiedenste Zwecke einsetzen zu können. Dadurch kamen mehrere Forscher auf die Idee, diese Chips in Karten einzubauen. Die ersten waren die deutschen Erfinder Jürgen Dethloff und Helmut Grötrupp7; sie gelten bis heute als die Erfinder der Smartcard. Im Jahre 1974 veröffentlichte der Franzose Roland Moreno ein weiteres Patent8, welches als große Weiterentwicklung galt, da die Mikroelektronik nun soweit war, die benötigte Hardware massentauglich anzubieten. Allerdings war man von einer Veröffentlichung für die breite Masse noch weit entfernt, weil die produzierten Artefakte noch zu unzuverlässig waren [RE10]. Der große Durchbruch kam dann mit den Telefonkarten, zuerst in Frankreich und kurz später auch in Deutschland. Dies war ein komplett neuer Einsatzzweck für Smartcards und generell ein neues Gebiet, welches erschlossen wurde. Somit konnten alle Funktionalitäten der Smartcards ausgenutzt werden, und sie überzeugte in vielen Bereichen. Nachdem die Telefonkarte in Frankreich und Deutschland so erfolgreich angenommen wurde, folgte auch die restliche Welt. Im Jahre 1990 waren weltweit fast 60 Millionen Karten im Einsatz [HYC+11] [MT98] [RE10]. Diese Telefonkarten basierten auf integrierten Schaltkreisen, da diese noch kleiner und leichter zu produzieren waren; allerdings dauerte es auch hier nicht lang, bis erste Fälschungen und Manipulationen auftraten. Somit wurde vermehrt auf Karten mit Mikroprozessoren gesetzt. Diese kamen in großer Anzahl im deutschen C-Netz vor, einem ersten mobilen, aber noch analogen Telefonsystem. Dies ebnete den Weg für das heute noch verbreitete GSM-Netzwerk, wo die Smartcard, oder in diesem Einsatzzweck unter SIM-Karte9 bekannt, weltweit die größte Ausbreitung erlebte [RE10]. Da das Thema Sicherheit bei Smartcards eine extrem wichtige Rolle spielt, geht die Wei- terentwicklung von Kryptographie damit Hand in Hand. Anfangs beruhte die Sicherheit meist nur auf dem Unwissen der Benutzer, wie und welche Prozesse ablaufen. Dies war aber wie vorher schon angemerkt, nicht mehr ausreichend. Durch die Einführung von Mikroprozessoren konnten auch komplexere Algorithmen implementiert werden, welche echte Sicherheit boten, auch wenn man das darunter liegende System kannte. Jegliche Weiterentwicklung in der Mikroelektronik macht neue, ausgereiftere Sicherheitsmecha- nismen möglich, da immer mehr Rechenleistung benötigt wurde, um gegen Angriffe geschützt zu sein. Durch die große Verbreitung von Smartcards war dies notwendig, um den Benutzern ein Gefühl der Zuverlässigkeit zu bieten und ein Medium mit unzähligen Einsatzzwecken zu schaffen [RE10]. 7Patent-Nr. DE1945777C3 8Patent-Nr. DE2512935A1 9kurz für subscriber identity module 17 2. Technischer Hintergrund Durch die erhöhten Sicherheitsmaßnahmen wurden die Karten auch zunehmend im Finanzsektor verwendet. Nach den erwähnten Kreditkarten folgte ein E-Purse-System bis hin zu den heutigen Bankomatkarten. Heute besitzt fast jeder österreichische Bürger mindestens eine Smartcard; mit der Gesundheitskarte und oft mehreren SIM- und Bankomatkarten hat sich die Smartcard in unser tägliches Leben eingegliedert [RE10]. 2.2.3 Aufbau, Design und Bestandteile Standardisierung Wie es bei der Entwicklung von neuen Technologie üblich ist, werden von unterschiedlichen Teams unterschiedliche Lösungen konstruiert, wobei jede meist ihre Vor- und Nachteile hat. Nachdem sich die Smartcard etablierte und in der Gesellschaft akzeptiert wurde, wurden dafür immer mehr Applikationen entwickelt und es entstand eine eigene Gemein- schaft von Programmierern. Zu dieser Zeit war es noch sehr mühsam neue Programme für Smartcards zu entwickeln, da jeder Hersteller seine eigene Architektur und Kompo- nenten besaß und somit konnte immer nur für einen gewissen Kartentyp programmiert werden. Um dieses Problem zu lösen wurden Standards eingeführt, darunter ISO-718610. Dieser legt fest welche physischen, elektronischen und funktionellen Eigenschaften eine Smartcard aufweisen muss, sprich welche Dimensionen, welches Layout, welche Hardware, welche Protokolle, welche Schaltungen usw. verwendet werden sollen; dies bietet eine gute Grundlage für Programmierer. Dennoch bleibt die Programmierung teils eine sehr komplexe Aufgabe, da Befehle oft unterschiedlich interpretiert werden und trotz der Standards noch Unterschiede zwischen einzelnen Herstellern bestehen [Chi14]. Komponenten Im Folgenden werden die einzelnen Komponenten beschrieben, welche auf einer Smartcard vorkommen können. Diese Komponenten werden dann anschließend zur Kategorisierung verwendet und ermöglichen die grundlegende Funktionsweise der Smartcard. Eine Smart- card ist so gesehen eine Sammlung verschiedener Technologien, welche auf einer Karte mit Hilfe von Schaltungen zusammengeschlossen sind, zusammenarbeiten und eine oder mehrere gewünschte Funkionen ausführen [Hen07] [Chi14]. • Integrierter Schaltkreis. Bei einem integriertem Schaltkreis handelt es sich um eine Sammlung von verschiedensten elektrotechnischen Elementen, welche auf einem Chip miteinander verlötet sind und eine unteilbare Einheit darstellen. Durch ihre sehr kompakte Bauweise und verschiedensten Einsatzzwecke sind sie aus der modernen Elektrotechnik nicht mehr wegzudenken. [JED]. 10https://www.iso.org/standard/54550.html, 02.12.2018 18 2.2. Smartcards • Mikroprozessor. Ein Mikroprozesoor ist ein spezieller integrierter Schaltkreis, welcher eine arithmetische Einheit, eine logische Einheit und eine Steuerungseinheit besitzt. Dadurch kann ein Mikroprozessor Programme interpretieren und ausführen. Es handelt sich also lediglich um eine kleinere, teils vereinfachte Version eines normalen Prozessors [oEB]. • RAM. RAM steht für Random Access Memory und stellt ein Speichermodul dar. Es besteht aus mehreren Speicherchips (wiederum integrierte Schaltungen), welche zu einem Modul zusammengefasst werden. Der RAM dient zum Zwischenspeichern von Daten, um auf diese schneller zugreifen zu können [Chrb]. • ROM. ROM hingegen steht für Read-Only Memory. Es dient zum Starten eines Systems, da darin Instruktionen gespeichert sind, welche vor dem eigentlichen Betriebssystem ausgeführt werden, damit dieses geladen werden kann. Es kann nur einmal beschrieben werden, da die Daten teils eingebrannt werden [Chrc]. • EEPROM. Eine Weiterentwicklung eines solchen Systems stellt EEPROM dar. EEPROM steht für erasable programmable read-only memory. Im Gegensatz zu ROM kann es immer wieder neu beschrieben werden, um so Änderungen und Updates einzuspielen [Chra]. • Elektronischer Kontakt. Ein elektronischer Kontakt bezeichnet eine Schaltung, welche bei Berührung mit einem anderen Kontakt eine elektronische Spannung weiterleitet, um so bestimmte Aktionen einzuleiten [How]. • Antenne. Eine Antenne dient als Wandler zwischen Frequenzen und elektrischen Spannungen, in beide Richtungen. Dieses Konzept wird verwendet, um Signale über die Luft an andere Empfänger senden zu können und dort weiter zu verarbeiten [Teca]. • Magnetstreifen. Ein Magnetstreifen dient zum Speichern der Daten. Er ist in der Produktion sehr billig, bietet aber im Vergleich zur Größe nur geringe Speicherkapa- zität. Aufgrund der geringen Produktionskosten und der hohen Kompatibilität mit unterschiedlichsten Lese- und Schreibgeräten wird er dennoch oft benutzt [RE10]. Kategorisierung Anhand dieser Komponenten ist es nun möglich, die unterschiedlichen Typen von Smart- cards näher zu beschreiben, ihren Aufbau zu erklären und ihren Einsatzzweck zu skizzieren. Da unterschiedlichste Kombinationen, je nach Einsatzbereich, möglich sind, werden hier lediglich die wichtigsten bzw. am meist genutzten Arten beschreiben. 19 2. Technischer Hintergrund • Magnetic-Stripe Card. Eine Magnetstreifenkarte besitzt (meist auf der Rückseite) einen Magnetstreifen mit einer ungefähren Größe von 1000 Bits. Er dient meist nur zum Speichern der aufgedruckten Daten, damit diese automatisch ausgelesen werden können. Auch ist es relativ einfach, die Daten am Magnetstreifen zu manipulieren, weshalb man hier auf sensible Daten verzichtet [RE10]. • Memory Card. Memory Cards dienen zum reinen Datenspeichern. Sie besitzen sonst keinerlei eigene Funktionalität, sondern können nur durch geeignete Lese- und Schreibgeräte ausgelesen bzw. mit neuen Daten beschrieben werden. Dieser Lese- und Schreibprozess wir durch ein spezielle Sammlung an Funktionen ermög- licht, welche in einer ROM hardcodiert abgelegt worden sind. Diese Funktionen garantieren auch Sicherheit, sodass Daten nicht manipuliert werden können; eine der wichtigsten Eigenschaften der modernen Smartcard. Mit nur einem verbautem Speicherchip (1 bis 8 KBytes), sind diese simplen Karten relativ günstig in der Produktion und werden dadurch oft für Kundenkarten o.Ä. verwendet [Chi14]. • Microprocessor-based Card. Microprocessor-based Cards besitzen zusätzlich zum Speicherchip noch einen Mikroprozessor. Dieser erlaubt es der Karte eigenständig komplexe Operationen auszuführen, um die darauf gespeicherten Daten zu bearbei- ten. Auf der ROM befindet sich hier ein eigens entwickeltes Betriebssystem, welches anhand von Berechtigungen die Zugriffe auf Lese- und Schreibprozesse regelt und die Daten auch eigenständig mit kryptografischen Algorithmen ver- und entschlüsseln kann. Durch das angebrachte Betriebssystem können auch Anpassungen mittels eigens geschriebenen Programmen gemacht werden, um so noch mehr Kontrolle zu erlangen. Durch diese Eigenschaften sind solche Karten vor allem in Bereichen mit hohen Sicherheitsanforderungen sehr beliebt [Chi14]. • Contact Card. Eine Contact Card besitzt zusätzlich zum Mikroprozessor noch ein Kontakt-Array, durch welches die Karte mit einem Lesegerät kommunizieren kann. Durch den physischen Kontakt ist zwar die Abnutzung größer, aber Daten können schneller und zuverlässiger gelesen und geschrieben werden [Chi14]. • Contactless Card. Contactless Cards besitzen eine Antenne, mit welcher die Kom- munikation nach außen möglich ist. Hier besteht keine Abnutzung, allerdings sind die Übertragungsraten nicht so gut wie bei physischem Kontakt. In den letzten Jahren hat sich hier vor allem die NFC-Technologie durchgesetzt, eine Weiter- entwicklung von RFID. Diese bietet auch bessere Übertragungsraten und höhere Distanzen, wodurch kontaktlose Karten sich immer mehr durchsetzen [Chi14]. • Dual Interface Card. Dieser Typ von Karten bietet beide vorher genannten Kom- munikationswege an, um so, je nach Einsatz, den geeignten wählen zu können. Hier können auch komplexere Prozesse umgesetzt werden, welche höhere Sicherheitsstu- fen erfordern [Chi14]. 20 2.2. Smartcards Dimensionen Smartcards können auch basierend auf ihrer Größe klassifiziert werden. Neben dem vorher erwähntem Standard ISO-7186 gibt es noch einen spezifischeren, welcher genau die Größe regelt, nämlich ISO 7810 (siehe Abbildung 2.1). Neben der klassischen Kreditkartengröße ID-3 gibt es noch mehrere kleinere Varianten. Die bekannteste dürfte ID-000 sein, welche die klassische SIM-Karte darstellt, wobei es hier mit Micro- und Nano-SIMs noch weitere Unterteilungen gibt [Chi14]. Abbildung 2.1: Smartcard Dimensionen nach ISO-7186 [ So13]. 2.2.4 Funktionsweise und damit verbundene Sicherheitsaspekte Smartcards besitzen also mittlerweile die selben Komponenten, welche auch Computer bzw. Mikrokontroller auszeichnen und stellen somit eine komplett eigenständige Recheneinheit dar. Allerdings hat, abgesehen von neuesten Entwicklungen, die klassische Smartcard keine interne Stromversorgung und funktioniert nur, wenn eine externe Spannung hinzugefügt wird. Um die auf der Smartcard programmierten Funktionen benutzen zu können braucht es Terminals und diese Kommunikation muss auch dementsprechend geschützt werden [Hen07] [RE10] [KMN15]. 21 2. Technischer Hintergrund Terminals Um mit einer Smartcard kommunizieren zu können wird ein Terminal benötigt. Unter einem Terminal versteht man grundsätzlich ein Lesegerät für Smartcards. Die einfachste Version besteht aus einer Kontakteinheit zum Kommunizieren mit der Karte und einem Mikroprozessor. Auch hier, wie bei Smartcards selbst, gibt es große Unterschiede zwischen den einzelnen Herstellern und man es war erneut notwendig sich auf Standards zu einigen. Dennoch, aufgrund der vielen verschiedenen Einsatzzwecke, gibt es mehrere Arten von Terminals, welche von der deutschen Kreditwirtschaft11 eingeführt wurden [Hen07] [RE10]: • Terminal der Klasse 1. Ein Terminal der Klasse 1 besitzt lediglich ein Lesegerät und einen Anschluss zu einem anderen Gerät. Meist ist dies ein USB-Anschluss für einen Computer [RE10]. • Terminal der Klasse 2. Ein Terminal der Klasse 2 besitzt zusätzlich die Option, eine Tastatur anzuschließen, um Daten zu bearbeiten. Dies ist aber optional und es kann auch direkt am Computer interagiert werden [RE10]. • Terminal der Klasse 3. Die Klasse 3 besitzt zusätzlich noch ein Display. Diese Terminals werden vor allem für Benutzer verwendet, damit eine bessere Interaktion möglich ist [RE10]. • Terminal der Klasse 4. Die letzte Klasse besitzt alle vorherigen Eigenschaften und noch ein Sicherheitsmodul, welches RSA unterstützt [RE10]. Terminals, in ihren unterschiedlichen Ausführungen, werden vom Entwickler und Benutzer verwendet. Der Entwickler programmiert mit ihnen die Karte und überträgt die benötigten Kundendaten darauf. Der Benutzer hingegen verwendet Terminals um die Funktionen der Smartcard zu nutzen. Bspw. kann man hier einen Bankomat nennen, welche die Bankomatkarte ausliest und auf deren Basis Funktionen zur Verfügung stellt. Sicherheitsmechanismen Wie bereits angedeutet, ist eine der wichtigsten Eigenschaften der Smartcard die Sicherheit. Konkret bedeutet das, dass Daten auf der Smartcard nicht manipulierbar sind und nur von berechtigten Personen ausgelesen bzw. geschrieben werden können. Um dies zu gewährleisten, müssen die Daten mit passenden kryptographischen Algorithmen verschlüsselt werden und zusätzliche Programme und andere Kommunikationspartner diese Sicherheitsaspekte auch korrekt umsetzen. Natürlich ist auch die Smartcard, wie kein anderes System weltweit, nicht zu hundert Prozent sicher gegenüber Angriffen. Hier gilt aber, dass der Aufwand, um in ein System einzudringen bzw. in diesem Fall eine Smartcard zu manipulieren, größer sein muss, als die möglichen Vorteile, die ein Angreifer davon haben könnte [KMN15] [RE10]. 11kurz DK, früher Zentraler Kreditausschuss (ZKA) 22 2.2. Smartcards Um eine möglichst ausreichende Sicherheit für Smartcards zu gewährleisten, müssen diese Aspekte in allen Produktionsstufen betrachtet werden: • Sicherheitsmechanismen während der Entwicklung. Um schon während der Entwick- lung ausreichend Sicherheit zu gewährleisten, werden hier strengste Vorkehrungen getroffen. Einen neuen Chip zu entwickeln benötigt in der Regel mehrere Monate. Nur wenige Entwickler arbeiten daran, damit die Anzahl der Personen, welche die genauen Designs kennen, möglichst gering bleibt; solche Informationen könnten nämlich bei möglichen Angriffen, welche später stattfinden könnten, sehr hilfreich sein. Außerdem werden die Chips später noch von unabhängigen Experten/innen komplett getestet, um eventuelle Schwachstellen zu entlarven. Zusätzlich gibt es noch einige Kriterien, die immer erfüllt sein müssen: Alle Funktionen müssen komplett definiert und dokumentiert sein, sodass sie unter jeglichen für die Karte bestimmten Zuständen funktionieren. Sie dürfen auch nicht einzeln ausschaltbar / zerstörbar sein, damit dadurch Sicherheitsmechanismen umgangen werden können [RE10]. • Sicherheitsmechanismen während der Produktion. Auch hier gelten strenge Si- cherheitsrichtlinien. Jegliche Zugänge zu den Produktionshallen sind gesperrt und nur für wenige Personen zugänglich und werden zusätzlich noch streng überwacht und aufgenommen. Während der Produktion sind die Karten meist für niemanden zugänglich, damit sie nicht ausgetauscht werden können [RE10]. • Sicherheitsmechanismen im Einsatz. Zu diesem Zeitpunkt treten die meisten Angriffe auf, da hier die Karte im freien Umlauf ist. Deshalb sind hier die Sicher- heitsvorkehrungen besonders wichtig und es gibt eine Vielzahl an Techniken, um Missbrauch zu verhindern. Ein möglicher Angriffspunkt ist der Chip selbst, d.h. die physikalische Ebene. Dies erfordert allerdings viel Erfahrung, Fachwissen und geeignete Geräte, wodurch ein solcher Angriff eher selten auftritt. Dennoch schützt man sich einerseits durch die geringe Größe der Chips, welche Manipulationen sehr schwierig macht, andererseits durch das Verstecken der Datenübertragungswegen, Verschlüsseln jeglicher Daten usw. Ein anderer Angriff, welcher nicht so viel Wissen über die Hardware voraussetzt, ist jener auf Softwareebene. Hier wird die Kom- munikation mit Terminals ausgenutzt und versucht, darüber sensible Daten zu bekommen. Um dies zu verhindern setzen die Entwickler vor allem auf sichere Au- thentifizierungsmechanismen (bspw. PIN), sichere Betriebssysteme, Überwachung von Datenströmen, Analyse und Vergleich aller Vorgänge, um Angriffe zu erkennen [RE10]. 23 2. Technischer Hintergrund 2.2.5 Anwendungszwecke Um gewisse Punkte und Aussagen zu unterstreichen, wurden schon einige Anwendungs- zwecke angedeutet bzw. kurz beschrieben, um den jeweiligen Kontext besser verständlich zu machen. Im Folgenden werden diese und noch weitere wichtige Anwendungszwecke genauer beschrieben und erklärt, warum Smartcards für gewisse Bereiche besonders vorteilhaft sind bzw. warum sie sich gut für einen bestimmten Anwendungszweck eignen. Im Rahmen der Arbeit kann dies natürlich nur zu einem gewissen Ausmaß passieren, weshalb die Aufzählung nicht vollständig ist und für andere Bereiche andere Anwen- dungszwecke wichtiger sind. Die für uns besonders wichtige Anwendung als Ausweis und Zugangskontrolle wird im folgenden Kapitel 2.2.6 im Detail beschrieben. Zahlungssystem Obwohl die Smartcard ursprünglich für die mobile Telekommunikation ausgelegt war (mehr dazu im Abschnitt 2.2.5), ist eine der häufigste Verwendungsarten nun jene in Zahlungssystemen. In den letzten Jahren hat sich hier ein riesiger Markt erschlossen. Beim Abschluss nahezu jeden Bankkontos ist eine Bankomatkarte inbegriffen. Das florierende Online-Geschäft bietet eine valide Grundlage für Kreditkarten, wobei auch der Verzicht auf Bargeld ein Argument dafür darstellt. In einigen Geschäften / Lokalen wird oft sogar nur noch die Zahlung mit Kreditkarte akzeptiert. All dies führt zu einem noch immer wachsenden Markt, für den die Smartcard bestens geeignet ist [Hen07] [RE10]. Diese Eignung ist durch die von der Smartcard vorhandenen Eingenschaften gegeben, welche im Finanzsektor dringend benötigt werden. Einerseits können sie Daten speichern, sie vor unerwünschter Modifikation schützen und bei gegebener Berichtigung abrufen, andererseits haben sie die gewünschte Größe und Robustheit, damit man sie immer bei der Hand hat und sie dennoch dem täglichen Gebrauch standhalten. Zudem ermöglicht ihre Eigenschaft, selbst Funktionen ausführen zu können, vollständig neue Anwendungen [Hen07] [RE10]. Die Verwendung in diesem Sektor bringt Vorteile für die Bank selbst, aber auch für deren Kunden. Banken profitieren vor allem von [RE10]: • Handhabung von Bargeld: Durch die Vermeidung von Bargeld und das Abschließen von Transaktionen in digitaler Form, wird die oft komplizierte Handhabung vom Bargeld vermieden. • Sicherheit: Wenn weniger Bargeld verwendet wird, zahlen sich auch keine Raub- überfälle oder sonstige Arten von Angriffen aus, wodurch an Sicherheit gewonnen wird. 24 2.2. Smartcards Auch für den Kunden bringt die Verwendung einige Vorteile [RE10]: • Handhabung von Bargeld: Auch hier ist die Vermeidung von Bargeld ein Argument für Smartcards. Benutzer sind nicht immer angewiesen, Bargeld bei sich zu tragen, um sich Produkte oder Dienstleistungen kaufen zu können; zudem erhöht man ihr Sicherheitsgefühl. • Abwicklung von Transaktionen: Transaktionen können viel schneller und sicherer abgewickelt werden, da sofort auf größere Mengen Geld zugegriffen und übertragen werden kann. • Automatisierter Verkauf: Verkaufsautomaten können durchgehend autonom be- trieben werden und bieten durch die Möglichkeit der Kartenzahlung noch mehr Komfort für den Benutzer. Für die Abwicklung von Transaktionen beim Kauf von Produkten oder Dienstleistungen gibt es im Prinzip drei Möglichkeiten [RE10]: • Nachher bezahlen: Mit Hilfe von Kreditkarten ist es möglich, Transaktionen ohne jegliches Bezahlen durchzuführen. Diese Transaktionen werden dokumentiert und am Ende eines Zeitraums (meist ein Monat) von dem Konto des Benutzers abgebucht oder in Rechnung gestellt. • Sofort bezahlen: Bankomatkarten hingegen greifen direkt auf das Konto des Be- nutzers zu und buchen den Betrag sofort ab. • Vorher bezahlen: Die letzte Möglichkeit ist es, eine Karte mit einem gewissen Geldbetrag aufzuladen und dann damit zu bezahlen. Mobilkommunikation Wie wichtig die Smartcard in der Telekommunikation ist, wurde anhand ihrer Geschichte in Kapitel 2.2.2 beschrieben. Um sich in ein modernes Netzwerk einzuwählen und dieses zu verwenden, wird eine SIM-Karte benötigt, welche lediglich eine Variation einer Smartcard darstellt. Normalerweise wird sie von einem Mobilfunkbetreiber ausgestellt und in den dafür vorgesehen Slot am Mobiltelefon gesteckt, damit dessen Funktionalität vollständig genutzt werden kann. 25 2. Technischer Hintergrund Um dies zu ermöglichen, bietet die SIM-Karte folgende Funktionen an: • Authentifizierung. Eine der wichtigsten Funktionen der SIM-Karte ist die sichere Authentifizierung für das gewünschte Netzwerk. Die SIM-Karte besitzt eine einzig- artige Identifikationsnummer12, auf Basis derer jegliche Funktionen durchgeführt werden können. Meist wird aber eine neuer Nummer generiert, welche im lokalen Netzwerk einzigartig ist, um mehr Sicherheit zu gewährleisten. Die IMSI-Nummer wird zusätzlich für die Ver- und Entschlüsselung von Daten verwendet. Dies passiert allerdings am Mobiltelefon selbst, da die SIM-Karte nicht die dazu benötigten Kapazitäten besitzt [EBF+13] [RE10]. • Speicher. Der Speicher einer SIM-Karte wird für Rufnummern, Kurznachrichten, Einstellungen am Mobiltelefon, andere notwendige Informationen der SIM-Karte und des Mobilfunkbetreibers verwendet. Dafür besitzt sie ein spezielles hierarchi- sches Dateisystem, welches basierend auf Berechtigungen gelesen und beschrieben werden kann [EBF+13] [RE10]. • Verwaltung. Der Benutzer selbst kann direkt in den Einstellungen am Mobiltelefon Änderungen durchführen, um die Funktionalitäten der SIM-Karte anzupassen. Aber auch ein Fernzugriff des Anbieters ist möglich, um gewisse Änderungen, wie bspw. geänderte Spezialrufnummern, einspielen zu können [EBF+13] [RE10]. Gesundheitssystem In Deutschland und Österreich besitzt jede krankenversicherte Person eine Gesundheits- karte, welche auf einer Smartcard basiert. Hier werden vor allem Daten der versicherten Person gespeichert, welche durch spezielle Geräte in der Arztpraxis ausgelesen werden können; dies passiert mit einem speziellem Lesegerät, welches mit einem Computer ge- koppelt ist. Somit erspart man sich viel Schreibarbeit und das manuelle Auslesen der Karte vermeidet menschliche Fehler und ermöglicht das automatische Organisieren der Patienten [RE10]. Öffentlicher Verkehr Viele Betreiber des öffentlichen Verkehrs sind auf Smartcards für ihre Benutzer umge- stiegen. Grundsätzlich sind sie dafür gedacht, die geforderten Tarife für den jeweiligen Benutzer, auf Basis der Fahrten, in Rechnung zu stellen. Durch diese Abrechnung werden aber eine Vielzahl an Daten produziert, welche sehr hilfreich für die Betreiber sind. Bspw. erhält der Betreiber einen genauen Überblick, wie ausgelastet die jeweilige Fahrt ist. Dadurch können Fahrpläne angepasst werden und es kann zur strategischen Langzeit- planung des gesamten Netzwerkes dienen. Auch für den Benutzer bietet die Einführung einer Smartcard eine Vielzahl an Vorteilen [PTM11]: 12Englisch: International mobile sub-scriber identity kurz IMSI 26 2.2. Smartcards • Besseres und angepassteres Serviceangebot durch genaue Nutzungsdaten • Vereinfachte Bezahlung und dadurch schnelleres Einsteigen • Reduzierung der Preise durch optimierte Fahrpläne Ein wichtiger Punkt, der bei vielen anderen Anwendungszwecken natürlich auch zu beachten ist, ist die Privatsphäre. Durch die genaue Aufzeichnung der Daten für die Abrechnung weiß der Betreiber über die Position bzw. die Routen, welche täglich gefahren werden, genau Bescheid. Deshalb muss dem Benutzer hier strengste Geheimhaltung geboten und veröffentlichte Studien strikt anonymisiert werden [PTM11]. 2.2.6 Smartcards in universitären Einrichtungen Viele universitäre Einrichtungen haben weltweit auf Smartcard-basierte Lösungen um- gestellt. Der Hauptgrund für eine Umstellung ist meist, alle im Studium benötigten Funktionen mit einer Karte anbieten zu können, um so das Nutzererlebnis maßgeblich zu verbessern. Durch den rapiden Anstieg von Studierenden und somit auch Mitarbeitern, mit einem oft sehr beschränkten Budget, bietet sie auch eine kosteneffiziente und einfach zu verwaltende Option an. Auch die steigenden Sicherheitsbedenken werden in Kombina- tion mit den sensiblen Daten zu einem Problem, welches durch die korrekte Einführung von Smartcards bewältigt werden kann [SP16]. Eine der wichtigsten und meist verwendeten Funktionen in diesem Zusammenhang ist das Identitätsmanagement. Unter einem Identitätsmanagementsystem versteht man eine Applikation, welche personenbezogene Daten speichert und deren Modifikation ermöglicht. Smartcards ermöglichen hier den ersten Schritt, nämlich die Identifikation des Benutzers, auf Basis derer dann die jeweils berechtigten Funktionen ermöglicht werden [RJ11]. Weitere Einsatzzwecke variieren je nach Universität. Einige wichtige bzw. viel verwendete werden im Folgenden kurz aufgelistet und beschrieben, um den Einsatzzweck verständli- cher zu machen: • Autorisierung auf universitären Rechnern. Universitäten bieten oft Computerräume an, in denen Studierende Computer und andere Geräte benutzen können. Um zu garantieren, dass es sich um aktive Studierende handelt, welche die benötigten Berechtigung besitzen, werden die Computer mit Lesegeräten ausgestattet. Beim Einschalten wird das Einführen der Karte gefordert und meist noch ein PIN, um die Identität zu bestätigen [RJ11]. 27 2. Technischer Hintergrund • Zutritt. Ein wichtiger Punkt ist die Zugangskontrolle. Verschiedene Studierende und auch Mitarbeiter/innen sollen basierend auf ihrer Anstellung bzw. Verpflich- tungen nur Zutritt für jene Bereiche besitzen, welche benötigt werden. Um dies zu ermöglichen, wird jede Karte mit Berechtigungen verbunden, welche beim Auslesen überprüft werden und dann den Zutritt gewähren, oder im Fall von fehlender Rechte verweigern [SP16]. • Bibliothek. Durch die gespeicherte Identität auf der Smartcard kann sie verwendet werden, um in der Bibliothek Bücher auszuleihen. Die Identität der Person kann ausgelesen, ins System übertragen und verwaltet werden. Dadurch wird dieser Prozess automatisiert und beschleunigt, und die Einführung einer zusätzlichen Bibliothekskarte vermieden [RJ11]. • Einkauf. Manche Universitäten bieten die Möglichkeit an, die Karte mit Geld aufzuladen, um damit in den universitären Geschäften und Lokalen zu bezahlen [RJ11] • Anwesenheit. Da bei vielen Vorlesungen bzw. Übungen Anwesenheitspflicht besteht, kann mit einem Lesegerät beim Eingang diese einfach bestätigt werden. Dadurch können gefälschte Unterschriften auf Anwesenheitslisten vermieden werden, und es besteht eine gewisse Arbeitserleichterung für den Vortragenden [RJ11]. • Transport. Vor allem amerikanische Universitäten haben eigene Transportmöglich- keiten, welche ähnlich wie in 2.2.5 verwendet werden können [RJ11]. 28 2.3. One-Stop-Shops 2.3 One-Stop-Shops 2.3.1 Einführung Unter dem Konzept eines One-Stop-Shops versteht man eine Strategie, welche man vor allem im Marketing- und Management-Bereich findet. Das Konzept ist vor allem in jenen Bereichen bzw. Forschungsgebieten präsent, in welchen es um Kundenzufriedenheit und Optimierungen geht; man spricht hier auch von einem “Full Service“-Angebot. Dies leitet sich davon ab, da es sich grundsätzlich um ein Paket an Leistungen bzw. Produkten handelt, welche alle an einem einzelnen Ort abgerufen werden können und das Problem bzw. die Anfrage des Kunden vollständig und noch über die eigentlichen Wünsche hinaus löst [SWF01]. Abbildung 2.2: Verschiedene Konzepte von Produkt/Service-Angebot [SWF01] Wie man in Abbildung 2.2 erkennen kann, unterscheidet man zwischen den verschiedenen angebotenen Leistungen. Links unten sieht man das Basisprodukt, um welches es im Eigentlichen geht. Der X-Achse entlang werden zusätzliche, separate Leistungen angeboten, welche im Zusammenhang mit dem Basisprodukt interessant sein können. Eine Zeile darüber (in Y-Richtung), wird diese Leistung mit dem Produkt gebündelt angeboten. Bei einem “Full Service“-Angebot werden alle zusätzlichen Leistungen in Einem angeboten und es gibt keine Möglichkeit der Aufspaltung [SWF01]. Um einen Ausblick auf die folgenden Abschnitte zu ermöglichen, werden hier die jeweils behandelten Themengebiete kurz erläutert. • Geschichte: In diesem Kapitel wird beschrieben, wann und wie die ersten One- Stop-Shops entstanden sind und inwiefern sie sich von der heutigen Variante unterscheiden. Es soll hier vor allem erläutert werden, aus welcher Notwendigkeit sich dieses System entwickeln konnte. 29 2. Technischer Hintergrund • Funktionsweise und Eigenschaften: Nach der Entstehungsgeschichte wird hier genau auf die Eigenschaften eingegangen, welche einen One-Stop-Shop auszeichnen. Basierend auf den Eigenschaften wird erläutert, wie dieses Konzept funktioniert bzw. auf welchen Abläufen es aufbaut. • Verwendung: In diesem Kapitel werden die verschiedenen Szenarien beschrieben, in welchen ein One-Stop-Shop zum Einsatz kommt. Dies wird vor allem auf realen Projekten untersucht werden, um damit die Praxis dieses Konzeptes näher zu bringen. • Vergleich von One-Stop Shops mit verteilten Services im Gesundheitsbe- reich: Nachdem dem Lesenden ein genauer Einblick in das Konzept One-Stop-Shop gegeben wurde, wird in diesem Kapitel das Konzept des One-Stop-Shops mit ei- nem verteilten System verglichen. Dies wird anhand eines Fallbeispieles aus dem Gesundheitsbereich verdeutlicht. 2.3.2 Geschichte Basierend auf verschiedenen Quellen, wurde der Begriff One-Stop-Shop als erstes von einer amerikanischen Autowerkstatt verwendet. “The Lincoln Star“ in Lincoln, Nebraska warb im Sommer 1930 damit, dass seine Werkstatt nicht nur Reparaturen durchführe, sondern auch Autos bzw. Autoteile verkaufe. Damit würden dem Kunden alle Services an einer Stelle geboten und man müsse nicht ständig verschiedene Anbieter suchen. In der Anzeige wurde der Begriff “One-Stop-Shop“ auch erklärt und fand großen Anklang. Seit diesem Erfolg wurde der Begriff von einer großen Anzahl anderer Betriebe aufgenommen und schnell übersättigt. Deshalb spricht man in dieser Art von Gewerbe nun oft von einem “Full Service“-Angebot [KEN][The][Mar]. Im universitären Bereich wurden seit Ende der 1990er Jahre auch immer mehr One-Stop- Shops eingerichtet. Dies lag vor allem daran, dass die Anzahl von Studienanfängern rapide stieg, die Finanzierung vom Staat allerdings gleich blieb. Universitäten mussten daher mehr Services mit gleich viel Budget anbieten. Dadurch wurde das Konzept interessant, da an Kontaktpunkten eingespart werden konnte und dennoch ein angemessener Service möglich war. Dies wurde erstmals im Frühling 2001 am Onondaga Community College genauer untersucht. [Wal03]. 30 2.3. One-Stop-Shops 2.3.3 Funktionsweise und Eigenschaften In der Einleitung dieses Kapitels wurden die Eigenschaften eines One-Stop-Shops bereits kurz angeschnitten. Im Folgenden werden diese Eigenschaften ausführlicher beschrieben, um einen besseren Einblick in das Konzept zu erhalten und um im Anschluss die Funktionsweise analysieren zu können: • Verbindung von Leistungen: Darunter versteht man das Bündeln von Leistungen bzw. Produkten zu einem einzelnen Angebot. Konkret bedeutet dies, dass durch den Kauf eines Produktes bzw. die Inanspruchnahme einer Leistung, verschiedenste andere inkludiert werden, die meist in einem direkten Zusammenhang zueinander stehen [VR88]. • Erweiterte Erfüllung der Kundenwünsche: Dadurch versucht man Wünsche der Kunden über deren eigentlichen Vorstellungen hinaus zu erfüllen. Man geht davon aus, dass der Kunde beim Kauf eines Produktes oder der Inanspruchnahme einer Leistung noch zusätzliche Wünsche hat, die in einem zweiten Moment an einer anderen Stelle erfüllt werden müssten und versucht, diese sofort zufrieden zu stellen [VR88]. In verschiedenen Sektoren wird, wie bereits vorher erwähnt, also ein Eingangsprodukt angeboten und mit zusätzlichen Services verkauft, sodass der Kunde nur einen einzelnen Anlaufpunkt benötigt, falls es je zu Problemen oder Schwierigkeiten kommt. Dem Kunden soll ein Gesamtpaket geboten werden, welches alle Wünsche erfüllt. Beispielsweise bieten Wartungsunternehmen Services an, in welchen vor, während und nach den Arbeiten Hilfe geboten wird. Telekommunikationsfirmen bieten vollständige Pakete für Firmen an, welche die Organisation, Wartung, Inbetriebnahme und Bereitstellung der Technologien für deren Kommunikation bieten; oder eine ähnliche Umsetzung für den gesamten IT- Bereich von darauf spezialisierten Firmen. Dies wird z.B. damit beworben, dass sich die Firma auf ihre eigentliche Aufgabe konzentrieren kann und die Verantwortung für die Infrastruktur weitergibt [SWF01]. Der Kunde möchte nicht mehr nur das Produkt kaufen, er möchte sich auch nicht mehr um die Inbetriebnahme und Wartung kümmern. Die Einschulung der Angestellten und die Erreichbarkeit bei Problemen wird speziell bei IT-Produkten mittlerweile fast überall mit angeboten und es werden enge Verbindungen mit den Vertragspartnern aufgebaut, wodurch eine einzelne Schnittstelle entsteht. Wo früher noch viele Beteiligte notwendig waren (Wartung, Schulung usw.) und man sich selbst darum kümmern musste, wird durch das Konzept des One-Stop-Shops alles mit einem Vertragspartner erledigt [SWF01]. Neben dem Verkauf von Leistungen und Produkten werden One-Stop-Shops auch bei der Abwicklung bürokratischer Angelegenheiten eingesetzt. Sie sollen die Komplexität und das Planen solcher Prozesse stark vereinfachen und dem Kunden nicht notwendige Prozesse ersparen. Hierfür sind vor allem Abläufe interessant, welche für den Kunden neu (bspw. Studien- oder Arbeitsbeginn) oder sehr komplex sind. Durch die Möglichkeit, 31 2. Technischer Hintergrund alles an einem Ort zu erledigen, kann sofort geholfen werden, ohne unangenehme Zwi- schenschritte. Dies ist eine sehr wichtige Eigenschaft, um Prozesse zu beschleunigen und Kundenzufriedenheit zu erhöhen [Wal03]. 2.3.4 Verwendung Im Folgenden werden einige, wissenschaftlich belegte, Umsetzungen von One-Stop-Shops aufgelistet und beschrieben. Hier soll die Vielfältigkeit der Einsatzzwecke und möglichen Umsetzungen aufgezeigt und dadurch das Verständnis des Konzeptes vertieft werden. Wie vorher erwähnt, handelt es sich bei den Beispielen um wissenschaftlich untersuchte Umsetzungen, damit ein möglich realistisches Bild entsteht. One-Stop-Shop in der Universität Das Onondaga Community College wollte das Konzept des One-Stop-Shops für ihre Studenten anwenden. Sie sahen die Vorteile vor allem in der Steigerung der Zufriedenheit der Studenten und deren erhöhtem Engagement. Die Universität war vor allem auf der Suche nach einer Steigerung der Effizienz, der Qualität der angebotenen Services an die Studenten und der Verantwortung ihnen gegenüber. Auf der Suche nach einen Prozess stießen die Verantwortlichen auf das Konzept des One-Stop-Shop und versuchten damit eine bessere Interaktion mit den organisatorischen Einheiten zu ermöglichen [Wal03]. Bei der Planung für die Einrichtung des Konzeptes wurde klar, dass eine maßgebliche Verbesserung bei der Kommunikation und Zusammenarbeit zwischen den einzelnen Abtei- lungen notwendig ist. Im Konkreten ging es hier um studentische Services, akademische Angelegenheiten, informationstechnische Bereiche und Gebäudemanagement. Es wurden verschiedene übergreifende Schulungen angeboten und passende Gebäude und Betriebszei- ten mussten gefunden werden, um mit möglichst geringem Aufwand eine möglichst hohe Studierendenzahl zufrieden zu stellen [Wal03]. Dazu ein Aussage von Shari Piotrowski, eine der Initiatorinnen [Wal03, 42]: “As a community college, it is our mission to provide quality educational opportunities for all those in our community. Often the decision to attend a community college is made close to the beginning of a term. Having a One-Stop Shop Center that provides the services students need to plan, enroll, and successfully begin their studies is central to this mission... In order to provide this quality service, planning and coordination across divisions of the college must occur. This endeavor is a campuswide effort that begins with a coordinating committee comprised of staff from advisement and testing, admissions, financial aid, registrar, bursar, student life, health services, and the office of students with special needs. Planning begins and the effort to successfully run the center extends throughout the campus to all offices, from academic faculty staff to custodial staff.“ 32 2.3. One-Stop-Shops Frau Piotrowski sagt hier, dass es besonders wichtig ist, den Studenten eine hohe Qualität zu bieten, um die Organisation im Studium möglichst einfach zu machen. Einer der wichtigsten Punkte sei die Aufnahme und der Beginn des Studiums. Hier entstünden meist viele Probleme, welche mit Hilfe des One-Stop-Shops gelöst werden sollen. Alle Ab- teilungen müssen zusammenarbeiten, um einen Plan für ein möglichst zufriedenstellendes System zu erzeugen. Dieser Plan erfasste beim Onondaga Community College folgende vier Punkte: 1. Analyse der Wünsche und Ziele von Studierenden: Hier sollen Probleme, welche in der Vergangenheit oft aufgetreten sind analysiert werden. Dafür muss nicht nur die Sicht der Studierenden betrachtet werden, sondern auch der Fakultäten und zuständigen Personen im Aufnahmeprozess [Wal03]. 2. Festlegung der zentralen Abteilungen: Hier müssen alle beteiligten Abteilungen betrachtet und deren bisherigen Aufgaben analysiert werden. Besonders geht es hier darum, wer wie viel Einfluss auf die Aufnahme hatte und wie die Aufgaben nach der Einführung aufgeteilt werden sollen [Wal03]. 3. Übergreifendes Training: Abteilungen müssen die Aufgaben der anderen Abteilungen im Aufnahmeprozess kennenlernen und verstehen. Nur so kann eine optimale Zusammenarbeit gewährleistet werden [Wal03]. 4. Ressourcenplanung: Hier geht es um die Festlegung der Ressourcen. Wie viel an Personal, welche Infrastrukturen und Technologien werden benötigt um den Service optimal zu betreiben [Wal03]? Nach der Einführung wurden einige Untersuchungen über die Zufriedenheit bei Studie- renden und Mitarbeitern durchgeführt; das Ergebnis fiel durchaus positiv aus. Vor allem Studierende fanden das neue System sehr ansprechend und einfach in der Nutzung. Von 1064 Studierenden gaben fast 80% an, dass sie zufrieden mit dem neuen Prozess sind und 75% gaben an, weniger als zwei Stunden für die Erstanmeldung benötigt zu haben, was eine große Verbesserung darstellt. Im Vergleich gaben vor der Umstellung nur 56% an mit dem System zufrieden zu sein. Auch Angestellte akzeptierten das neue System und stellten eine gesamte Verbesserung in den Arbeitsabläufen fest [Wal03]. Abschließend wurde festgestellt, dass durch die immer schwieriger werdenden Bedingungen für Universitäten, diese umso flexibler und proaktiv auf Neuerungen reagieren müssen, damit den Studierenden immer noch eine angemessene Qualität geboten werden kann. Auch wurde festgestellt, dass die Umsetzung des neuen Konzeptes nicht einfach sei, da Veränderungen meist neue Problemen und Herausforderungen mit sich bringen. Ebenfalls soll es keine universale Lösung darstellen, mit welcher man gegen alle Probleme in der Zukunft abgesichert ist, sondern auch hier muss immer weiter verbessert werden, um weiterhin bestehen zu können. Es war dennoch ein interessanter Prozess, welcher Grenzen aufzeigte und für zukünftige Projekte wichtig sein könnte [Wal03]. 33 2. Technischer Hintergrund One-Stop-Shop in der öffentlichen Verwaltung In Italien gibt es eine relativ hohe Anzahl an kleinen und mittelständischen Unternehmen. Durch ihre geringe Größe kämpfen sie oft mit dem vergleichbar hohen Aufwand an administrativen Prozessen, vor allem der Kommunikation mit dem öffentlichen Sektor. Um dies zu vereinfachen und das System zu optimieren, wurden in den späten 1990er Jahren One-Stop-Shops für Unternehmen eingeführt. Diese sollen für den privaten und öffentlichen Sektor maßgebliche Verbesserungen bezüglich Prozessmanagement bringen [Ong04] [WM10] [20110]. Um dies besser verständlich zu machen, werden vorher noch wichtige Begriffe erläutert. • Geschäftsprozess: Unter einem Geschäftsprozess versteht man verschiedene einzelne Aufgaben, welche zusammen ausgeführt zu einem geschäftlichen Ziel führen. [HS99]. • Prozessmanagement: Prozessmanagement fokussiert auf solche Geschäftsprozesse. Es ist ein Managementansatz zur Betriebsgestaltung und dem Zuordnen von Ver- antwortungen. Dieser Ansatz hat sich in den 1990er Jahren auch im öffentlichen Sektor durchgesetzt und half bei vielen Reformen in Bezug auf Kundenorientierung und innerbetrieblicher Organisation und Koordination. Die wichtigsten Punkte sind die Verbreitung einer prozessorientierten Kultur im Betrieb, die Identifikati- on der Prozessinhaber (Personen für welchen Prozess die Verantwortung tragen), Reorganisation der Hierarchie bzw. Anpassung an die damit zusammenhängende Prozesse für höhere Effizienz und Optimierungen im Bereich der Versorger/Kunden- Kommunikation und internen Kommunikation (Delegieren und Teamarbeit) [HS99]. Die italienische Verwaltung wollte im Zuge der Reduktion von unnötiger bzw. zu aufwen- diger Bürokratie solch ein Prozessmanagement einführen; im konkreten Fall entschied man sich hier für einen One-Stop-Shop. Zu Beginn sollte es einen einzelnen Punkt geben, an dem Betriebslizenzen beantragt und ausgegeben werden können und allgemeine Fragen im Bereich der Kommunikation zwischen privaten und öffentlichen Einrichtungen gestellt werden können. Um dies zu ermöglichen, wurde eine Vielzahl an Analysen durchgeführt, verschiedene öffentliche Entitäten mussten zusammenarbeiten, Prozesse wurden unter- sucht und so kam man auf ein ausgereiftes Prozessmanagement, welches noch weit über den One-Stop-Shop hinausgeht. Ein großes Problem, welches man im Zuge dieser Analyse feststellte, war die mangelnde Kommunikation mit den privaten Unternehmen. Es wurde erst hier klar, welche Schwierigkeiten es gibt und wo der Bedarf an mehr Koordination besteht [WM10] [20110]. Um die Kommunikation mit den Kunden zu verbessern bzw. insgesamt kundenorientierter zu arbeiten, gilt es folgende Punkte zu beachten: • Die interne Organisation muss besonders flexibel sein, um sich schnell an die oft komplexen und rapide verändernden Anforderungen anpassen zu können [20110] [Ong04]. 34 2.3. One-Stop-Shops • Eine besondere Priorität muss auf der Bearbeitungszeit liegen; diese muss so stark wie möglich reduziert werden. Besonders im öffentlichen Dienst ist dies ein kritischer Faktor [20110] [Ong04]. • Es müssen Modelle entwickelt werden, welche das Potential an vorhandenen Tech- nologien optimal ausnützen [20110] [Ong04]. Diese Punkte wollte die italienische Verwaltung umsetzten, da, wie vorher erwähnt, vor allem kleine und mittelständische Betriebe Probleme mit der bürokratischen Abwicklung verschiedener Geschäftsprozesse haben. In den 1990er Jahren wurde eine umfangreiche Reform im Bereich der öffentlichen Verwaltung umgesetzt; diese beschäftigt sich vor allem mit der Stärkung der lokalen und kleineren Verwaltung. Dort sollten leistungsorientierte Prozesse und ein optimiertes Personalmanagement eingeführt werden. Im Rahmen dieser Reformen drängten auch immer mehr Betriebe die Regierung dazu, die administrativen Hürden in der Wirtschaft zu verringern; dies führte dann zu den One-Stop-Shops. Diese stellen Anlaufstellen dar, welche von den Gemeinden selbst geführt werden. Ihnen steht dann frei, ob sie den gesamten Prozess selbst durchführen wollen oder vor allem kleinere Gemeinden über ein Konsortium [Ong04] [WM10]. Die verantwortliche Gemeinde ist somit die Leiterin der jeweiligen Anlaufstelle und des damit zusammenhängenden Prozessmanagements. Sie muss alle Prozesse koordinieren, die Berechtigungen überprüfen und auf die Wünsche der Privatwirtschaft eingehen [20110]. Im Folgenden werden zwei besonders interessante Umsetzungen näher betrachtet, welche von der Wirtschaftsuniversität Luigi Bocconi untersucht worden sind: • Modena: Modena war eine der ersten Gemeinden, in welcher das Konzept des One-Stop-Shops eingeführt worden ist. Der Bürgermeister und andere Verwalter der Gemeinde waren schon vorher sehr bemüht, kundenorientierter zu arbeiten und verschiedene Verbesserungen zu implementieren, sodass die Reform auch dement- sprechend motiviert umgesetzt worden ist. Zu Beginn wurden alle Prozesse analysiert und versucht mit dem One-Stop-Shop zu vereinen. Mit Hilfe einer Beratungsfirma wurden alle beteiligten Organisationen koordiniert, um eine bestmögliche Integrati- on zu erzielen, die Verbesserungen ständig überprüft und schließlich das Konzept umgesetzt [Ong04] [LC00]. • Bologna: Die Provinz Bologna war für die Umsetzung der One-Stop-Shops in kleineren Gemeinden besonders wichtig. Kleinere Gemeinden hatten nämlich die Möglichkeit, bestimmte Aufgaben in die nächst größeren zu verlegen, da sich vor Ort eine Umsetzung oft nicht auszahlte. Ein konkretes Problem war hier die Anzahl an Ressourcen, die bei der geringen Häufigkeit an Anfragen meist überdimensioniert waren, aber zur Service-Bereitstellung doch benötigt wurden, die fehlenden Experten, welche sich meistens in den größeren Gemeinden befanden und die Schwierigkeit externe Einheiten zu integrieren, da sie, aufgrund ihrer Größe, im Gesamtbild nicht als besonders wichtig erscheinen. Aus diesem Grund wurde ein Netzwerk 35 2. Technischer Hintergrund entworfen, in welchem die kleineren Gemeinden mit den größeren kommunizieren, komplexere Aufgaben delegieren konnten und allgemein mit Problemen geholfen wurde. Dadurch wurde die Leistung maßgeblich verbessert und das Konzept war unabhängig von der Größe der leitenden Gemeinde [Ong04] [LC00]. Resultierend wurde festgestellt, dass in beiden Fällen die Bearbeitungszeit maßgeblich ver- bessert worden ist und die Umsetzung erfolgreich durchgeführt wurde. Beide Gemeinden nutzten die Möglichkeit der Umgestaltung und der Verbesserung ihrer Kommunikation mit dem privaten Sektor. Auch die Kunden selbst, die Privatindustrie und andere Sta- keholder befürworten das System und profitieren stark von der Reform und dem neuen Konzept [Ong04] [LC00]. One-Stop-Shop in der Medizin Im Krankenhaus der University of Colorado wurde 2012 ein neue Notaufnahme einge- richtet; Dr. Rich Zane wurde beauftragt diese zu leiten. Schnell wurde klar, dass der errichtete Komplex zu klein für die Menge an Patienten war. Der Bau wurde für 25.000 Patienten pro Jahr geplant, jedoch war die tatsächliche Zahl mit 60.000 wesentlich höher. Dadurch entstanden lange Wartezeiten und viele Personen mussten das Krankenhaus wieder ohne Erhalt der notwendigen Hilfe verlassen. Dies führte zu dringend erforderlichen Veränderungen, welche 2013 eingeleitet wurden [Kut13]. Die Notaufnahme wurde mit Hilfe eines neuen Konzeptes wiedereröffnet, ein 24h One- Stop-Shop. Seitdem gibt es kaum noch Wartezeiten für die Patienten und sie können mit den Ärzten oft sofort sprechen bzw. werden direkt untersucht und wenn möglich behandelt. Der One-Stop-Shop dient hier als erste Anlaufstation. Je nach Beschwerden des Patienten, wird ihm entweder sofort durch einen anwesenden Arzt geholfen, oder, bei schwereren Beschwerden, direkt ins Krankenhaus geliefert. Das Ziel ist, jedem Patienten zu helfen und zu zeigen, dass sie auch bei kleineren Beschwerden die Notaufnahme aufsuchen können und nicht zwingend eine Arztpraxis [Kut13]. Durch den Erfolg, welchen der One-Stop-Shop in der Notaufnahme hatte, folgten viele andere, vor allem amerikanische, Krankenhäuser diesem Beispiel. Dadurch wurden in vielen Studien die Effizienz und Kosten solcher Einrichtungen untersucht und festgestellt, dass das Konzept funktioniert und Services optimiert angeboten werden können. Eine maßgeblich höhere Anzahl an Patienten konnte behandelt werden, mit geringeren Kosten für das Krankenhaus selbst. Wartezeiten wurden verkürzt und die Beliebtheit für die Notaufnahme stieg bei Patienten signifikant [Kut13]. 36 2.3. One-Stop-Shops 2.3.5 Vergleich von One-Stop-Shops mit verteilten Services im Gesundheitsbereich Im Jahre 2001 wurde in Großbritannien eine neue Strategie zur Behandlung von HIV und anderer Krankheiten ausgearbeitet. Ein wichtiger Punkt bei dieser strategischen Überlegung war, wie die Services angeboten werden sollen. Bisher gab es eine Vielzahl an verteilten Servicestellen, welche alle auf ein bestimmtes Gebiet fokussiert waren. Die Überlegung war einen zentralen Kontaktpunkte einzurichten, welcher alle Services kombiniert anbietet, d.h. einen One-Stop-Shop. Das Ziel war das Gesundheitssystem möglichst einfach zu gestalten und es allgemein zu modernisieren und an die heutigen Standards anzupassen. Der Patient soll es so angenehm wie möglich haben, da solche Besuche für vielen unangenehm sein können und ungern den benötigten ersten Schritt wagen [FCG+06]. Dafür wurde, mit verschiedenen Stakeholdern und Angestellten in diesem Bereich des Gesundheitswesens, Interviews geführt und die in Abbildung 2.3 dargestellten Punkte, welche für und gegen einen One-Stop-Shop sprechen, gefunden [FCG+06]. Abbildung 2.3: Vor- und Nachteile eines One-Stop-Shop [FCG+06] 37 2. Technischer Hintergrund Im Detail sind die folgenden Punkte genannt: • Logistik: Der klare Vorteil liegt hier bei der Unterbringung aller Services unter einem Dach. Die gesamte Organisation und damit verbundene Spesen können gemeinsam abgewickelt werden. Unklar ist jedoch, wie spezifisch Services angeboten werden können bzw. wer dafür zuständig ist [FCG+06]. • Gesundheitswesen: Hier könnte eine One-Stop-Shop auch hilfreich sein. Patienten können bei zusätzlichen Problemen direkt an den jeweiligen Spezialisten weitergelei- tet werden, um dort untersucht bzw. behandelt zu werden. Viele der Krankheiten sind hier abhängig voneinander, sodass eine Zusammenarbeit sinnvoll wäre. Aller- dings kann dies auch zu höheren Wartezeiten und weniger Zugänglichkeit führen, da bspw. HIV-Patienten anders behandelt werden müssen, als Patienten mit weniger ansteckenden Krankheiten [FCG+06]. • Patienten: Viele Patienten wissen die vorher aufgezählten Vorteile sehr zu schätzen. Für sie ist es einfacher, Informationen und Behandlungen zu erhalten, und sie müssen bei weiteren Problemen nicht weitervermittelt werden. Allerdings fällt auch auf, dass weniger spezifische Informationen an die Patienten weitergegeben worden sind und der gesamte Service verallgemeinert wurde, sodass manche Patienten separate Spezialisten bevorzugen [FCG+06]. • Angestellte: Für Angestellte könnte ein One-Stop-Shop mehr Abwechslung und bessere Karrierechancen bedeuten. Sie sind nicht mehr von anderen Bereichen isoliert und können somit besser zusammenarbeiten. Allerdings könnte durch die Verallgemeinerung auch viel Expertenwissen verloren gehen bzw. zu viele Experten benötigt werden, welche alle an einen Ort angestellt sein müssen [FCG+06]. • Kosten: Hier kann vor allem bei doppelten Services eingespart werden, welche nur noch einmal angeboten werden müssen. Auch Bestellungen und andere Nebenkosten können aufgeteilt werden. Jedoch kann die Notwendigkeit zur Anstellung von Personen eines jeden Fachbereiches zu hohen Kosten führen, welche manchmal nicht dringend benötigt werden [FCG+06]. Nachdem nun die verwendeten Technologien und Konzepte erläutert wurden, wird in den nächsten Kapiteln auf das Projekt eingegangen. Es wird der Entwicklungsprozess beschrieben, die daraus entstandene Applikation ausgewertet und mögliche zukünftige Verbesserungen erläutert. 38 KAPITEL 3 Projekt-Design Einleitend wurde in Kapitel 1 bereits über die Ausgangslage des Projektes gesprochen und die neuen Workflows und Anforderungen kurz beschrieben. Diese Artefakte und deren Einwirken auf das Design des Projektes sollen nun genauer analysiert werden. 3.1 Analyse der Anforderungen Bevor auf die eigentlichen Anforderungen des Projektes eingegangen wird, werden zuerst die Prämissen des eingesetzten Softwareentwicklungsprozesses erläutert, da alle Abläufe und Design-Entscheidungen darauf basieren: • User Experience: Die Handhabung soll konsistent und nutzerfreundlich über alle TU-Services sein. • Feedback: Es soll eng mit den Benutzer/innen zusammengearbeitet werden und damit eine benutzerorientierte Entwicklung ermöglicht werden. Diese benutzerori- entierte Gestaltung (User-centered design) ermöglicht eine schnelle Reaktionszeit auf Feedback und soll so eine möglichst hohe Zufriedenheit bei den Anwendern erzeugen. • Transparenz: Stakeholder sollen laufend einen Überblick über die Aktivitäten erhalten. Zusammenfassend soll ein besonderer Augenmerk auf dem/der Benutzer/in liegen und eine transparente Entwicklung geboten werden. Dies lässt sich auch in den Anforderungen im Abschnitt 1.3 wiedererkennen, welche im Folgendem genauer analysiert werden, um anschließend das Projekt zu planen. 39 3. Projekt-Design • One-Stop-Shop: Für die Umsetzung eines One-Stop-Shops wird ein geeigneterer Kontaktpunkt und dementsprechende Ressourcen, Infrastruktur und Personal be- nötigt. Es müssen Workflows entwickelt werden, welche für das Personal möglichst intuitiv sind und fortlaufend abgearbeitet werden können. Da es sich um einen One-Stop-Shop handelt, werden auch zusätzliche Services angeboten. Diese müssen für das Personal von den üblichen Abläufen ausgehend leicht gestartet werden können, um den Kunden bestmöglich helfen zu können. • Echtzeitdruck: Der Echtzeitdruck ist für den Einstieg besonders relevant, da die TUcard für eine vollständige Benutzung der Infrastruktur an der TUWien notwendig ist. Deshalb ist es dringend erforderlich, dass neue Studenten und Mitarbeiter diese sofort erhalten. Benötigt wird dafür ein geeigneter Drucker, welcher Karten in einem angemessen Zeitraum produzieren kann, eine stabile Kommunikation mit diesem Drucker, um Fehler schnellstmöglich zu beheben und daran angepasste Workflows, welche in der Zwischenzeit andere Aufgaben erledigen lassen, um die Wartezeit optimal zu nutzen. • Aufteilung der Datenverwaltung: Durch die Rollenverteilung bei einzelnen Karten- typen soll das Personal auch nur die korrespondierenden Daten verwalten können. Dafür werden spezielle Services benötigt, welche je nach Anfrage die Berechtigungen der Person überprüfen und basierend darauf Daten und Funktionalität anbieten. • Weitere Mitarbeiter: Für die Einführung des neuen Kartentyps Weitere Mitarbeiter, muss dieser dem System bekannt gegeben, bestehende Workflows angepasst und dem Personal die Möglichkeit zur Verwendung mitgeteilt werden. Außerdem soll in diesem Zusammenhang die Architektur so gestaltet werden, dass weitere Kartentypen bei Bedarf möglichst schnell und problemlos hinzufügbar sind. Diese Skalierbarkeit soll in der gesamten Applikation gegeben sein, um zukünftige Anforderungen bestmöglich in das System einbauen zu können. • Verwaltung: Es sollen Seiten erstellt werden, welchen den Administratoren Verwal- tungstools zur Verfügung stellen. Diese Seiten müssen angesichts der angebotenen Services besonders gut abgesichert werden und die Administratoren bestmöglich unterstützen. • Usability: Alle angebotenen Services sollen auf den Nutzer ausgelegt sein und ein einheitliches Konzept aufweisen. Dafür ist eine genaue Planung und einheitliche Designrichtlinien erforderlich, welche vom bestehenden Gesamtsystem (TISS) und der neuen Applikation umgesetzt werden. • Kartenverbrauch: Die Reduktion des Kartenverbrauchs steht in direktem Zusammen- hang mit der Wahl eines möglichst zuverlässigen Druckers und der Kommunikation damit, um Fehldrucke zu minimieren. Für die Einführung der Deaktivierung bzw. Reaktivierungsfunktion einer TUcard, muss ein neuer Status im System eingeführt werden, welcher mit entsprechenden Eingaben eines Nutzers erreicht werden kann. 40 3.2. Notwendige Anpassungen 3.2 Notwendige Anpassungen In der Einleitung (siehe Abschnitt 1.1.3) wurde bereits auf den aktuellen Workflow für die Beschaffung einer neuen Studierenden- bzw. Mitarbeiter/innenkarte eingegangen. Dieser soll analysiert und mit den vorher aufgestellten Anforderungen bzw. Wünschen und Emp- fehlungen von Benutzer/innen verglichen werden, damit die notwendigen Anpassungen für den neuen Workflow aufgestellt werden können. 3.2.1 TUcard für Studierende 1. Vorerfassung: Die Vorerfassung bleibt größtenteils ident. Der zukünftige Studierende trägt die benötigten Daten in das Online-Formular ein und schickt es ab. Zusätzlich wird noch die Option für das Festlegen eines Passwortes angeboten. 2. Studienabteilung: Auch ident bleibt die Abgabe aller notwendigen Dokumente in der Studienabteilung, wo auch die Korrektheit aller Daten geprüft wird. 3. Kartendruck: Sind alle Daten korrekt, startet der neue Prozess des Echtzeitkar- tendruckes. Eine neue TUcard mit den überprüften Daten des Studierenden wird innerhalb einer Minute gedruckt und übergeben. 4. Abschließen des Aufnahmeprozesses: In der Zwischenzeit werden Infopapiere für den Studierenden gedruckt, weiterführende Informationen ausgestellt und etwaige Fragen beantwortet. 5. Validierung: Die Validierung der Person entfällt, da die TUcard persönlich ausge- geben wird. Dadurch ist die vorher notwendige Aktivierung in TISS nicht mehr erforderlich. 6. Bezahlung: Nach der erfolgreichen Anmeldung an der TU Wien muss der Studien- betrag eingezahlt werden. Wurde dies erledigt, kann mit Hilfe eines TUcard-Kiosks das aktuelle Gültigkeitsdatum auf die TUcard aufgedruckt werden. 7. Kosten: Die Erstausstellung der TUcard ist kostenlos, bei Verlust oder Diebstahl wird ein Entgelt berechnet. Für diese Umstellungen sind folgende Aufgaben zu erledigen: • Es müssen neue Drucker ausgewählt und diese dann angeschafft werden. • Die neuen Drucker müssen in das bestehende System eingebunden werden. • Die Kommunikation mit ihnen muss implementiert werden. • Der Echtzeitdruck muss in die Erstaufnahme eingebaut werden. 41 3. Projekt-Design • Die Programmierung der internen Karten-Chips muss in den Druckprozess eingebaut werden. • Verwaltungsseiten für die Studienabteilung müssen erstellt und benutzerzentriert evaluiert werden. 3.2.2 TUcard für Mitarbeiter/innen Der neue Workflow für die Mitarbeiter/innenkarten wird noch nicht auf einen One- Stop-Shop umgestellt. Durch Unstimmigkeiten zwischen verschiedenen Abteilungen, wird die TUcard daher noch nicht bei Beginn des Arbeitsverhältnisses ausgestellt. In der Zwischenzeit wird aber der bisherige Prozess optimiert, bis auch hier der Echtzeitdruck zum Einsatz kommt. Die Funktionalität dafür wird aber bereits implementiert, sodass nach der Klärung eine schnelle Umstellung möglich ist. 1. Bestellung: Die TUcard kann in TISS unter dem Menüpunkt TUcard bestellt werden. Es kann ein dezentraler Abholort ausgewählt werden, sodass auch außer- halb liegende Institute eine Karte einfacher erhalten können. Nachdem ein Foto hochgeladen wurde, wird die Karte direkt an diesem Ort gedruckt oder dorthin übermittelt, wo sie dann von dem/der Mitarbeiter/in abgeholt werden kann. 2. Aktivierung: Die Karte muss anschließend in TISS aktiviert und an einem TUcard- Kiosk jährlich verlängert werden. 3. Kosten: Für Mitarbeiter/innen treten keine Kosten auf. Zusätzlich zu den Umstellungen, welche bei der TUcard für Studierende genannt worden sind, ist hier auch die Implementierung eines Workflows erforderlich, welcher den Druck von Mitarbeiter/innenkarten ermöglicht und die Übermittlungen von und zu den Sicher- heitslogen organisiert. Dafür soll eine neue Seite erstellt werden, welche die bestellten Karten mit den hochgeladenen Bildern der Benutzer/innen anzeigt und einen Druck basierend auf dem Abholort ermöglicht. Die angezeigten Bilder werden vor dem Druck auf die Erfüllung aller Kriterien und bei Abholung zusätzlich auf die zugehörige Person überprüft. Durch die Organisation nach Abholort, können die Karten direkt vor Ort gedruckt werden, was zu einer maßgeblichen Beschleunigung des Verfahrens führt und der/die Mitarbeiter/in schneller die TUcard erhält. Parallel dazu soll eine Unterschriften- liste der gedruckten Karten erzeugt werden, welche bei Abholung unterschrieben wird und den Erhalt somit bestätigt. 3.2.3 TUcard für sogenannte "Weitere Mitarbeiter/innen" Der Workflow für weitere Mitarbeiter/innen erfolgt analog zu jenem der Mitarbeiter/innen. Bei der Bestellung ist wiederum die Auswahl eines Abholortes und das Hochladen eines passenden Bildes verpflichtend. Anschließend werden die bestellten TUcards der weiteren 42 3.2. Notwendige Anpassungen Mitarbeiter/innen auf der selben Druckseite wie auch die TUcards für Mitarbeiter/innen angezeigt und gedruckt. Für die/den Druckbeauftragte/n entsteht dadurch kein Mehr- aufwand, da die Zuordnung auf den passenden Kartendrucker automatisch erfolgt und deshalb die beiden Kartentypen gleichzeitig gedruckt werden können; dies ist aufgrund der unterschiedlichen Kartenlayouts notwendig. Auch die Unterschriftenliste wird um die weiteren Mitarbeiter/innen erweitert und ermöglicht zusätzlich die Abholung durch den für die weiteren Mitarbeiter/innen Verantwortlichen. Für den Druck der weiteren Mitarbeiter/innen sind zusätzlich folgende Aufgaben zu erledigen: • Einführung der weiteren Mitarbeiter/innen in die Applikation, sodass auch diese TUcards bestellen können. • Anpassung der Mitarbeiter/innen-Druckseite, damit auch weitere Mitarbeiter/innen angezeigt und gedruckt werden können. • Anpassung der Unterschriftenliste, sodass auch der/die weitere Mitarbeiter/in bzw. die verantwortliche Person den Erhalt bestätigen kann. 3.2.4 Allgemeine Funktionen Bei dem Design des Projektes, soll wie vorher erwähnt, die Benutzerfreundlichkeit eine große Rolle spielen. Deshalb sollen grundlegende Funktionen für alle Kartentypen ident angeboten werden und auch so funktionieren. Ein weiterer dadurch erreichter Vorteil ist die Wiederverwendung von Funktionen und Workflows. Bspw. werden TUcards für weitere Mitarbeiter/innen mit der selben Logik wie auch jene für Mitarbeiter/innen gedruckt. Der Code wird dadurch zwar etwas komplexer, aber ist dennoch einfacher zu warten und erweitern da dies nur an einer Stelle passieren muss. Weitere wichtige Funktionalitäten, welche für alle Kartentypen ident sind, werden hier kurz aufgelistet und beschrieben: • Verwaltungsfunktionen für Administratoren (Sperre, Deaktivierung, Reaktivierung und Neudruck) • Verwaltungsfunktionen für Benutzer (Deaktivierung und Reaktivierung) • Auslesen der Benutzerdaten für die Bibliothek, sodass der Barcode auf der Rückseite entfällt 43 3. Projekt-Design 3.3 Design 3.3.1 Planung Nachdem die Anforderungen und die notwendigen Anpassungen für die neue Applikation geklärt sind, muss die Realisierung geplant werden. Dafür werden die Anforderungen in Redmine1 als Tasks angelegt und in Unterprojekte organisiert; eines dieser Projekte wäre bspw. die TUcard für Studierende. Sind alle Tasks angelegt, werden diese nochmals mit den Stakeholdern besprochen, um etwaige Unklarheiten zu beseitigen. Anschließend werden zu jedem Task die jeweiligen Entwicklertickets angelegt. Diese unterscheiden sich dadurch, dass in den Entwicklertickets die konkreten zu implementierenden Artefakte beschrieben sind und in den Task lediglich die von außen sichtbare, zu erledigende Aufgabe. Eine vereinfachte Form eines Tasks könnte so aussehen: Task: Die Studierendenkarte muss in Echtzeitdruck gedruckt werden. Wobei die zugehörigen Entwicklertickets folgendermaßen aufgeteilt werden könnten: Entwicklerticket 1: Implementierung einer Schnittstelle zur Kommunikation mit dem Drucker. Entwicklerticket 2: Erzeugung einer neuen Studierendenkarte, basierend auf den Daten des Studierenden. Entwicklerticket 3: Implementierung des Frontends zur Überwachung des Druckprozesses. Für jedes dieser Tickets soll auch eine Dauer angegeben werden, um den Entwicklungs- prozess planen zu können und dem Kunden eine ungefähre Zeitabschätzung mitzuteilen. Dabei wird versucht, möglichst agil zu arbeiten, d.h. dem Kunden frühe Prototypen zum Testen zu präsentieren, um deren Feedback wieder einarbeiten zu können und das Produkt damit stetig zu verbessern. Durch die Angabe von Zeitintervallen und das zwischenzeitige Präsentieren wird dem Kunden gezeigt, dass die Entwicklung voran schreitet und seine Meinung maßgeblichen Einfluss darauf hat. 3.3.2 Wahl der Technologien Um die Implementierung zu erleichtern, wird auf Frameworks zurückgegriffen, welche viele Vorteile mit sich bringen. Unter anderem wird dem/der Entwickler/in eine große Anzahl an fertigen Funktionen angeboten, welche sich meist im Enterprise-Umfeld bereits bewährt haben und bei etwaigen Schwachstellen Aktualisierungen bieten. Auch sollen 1Ein Projektmanagement-System, https://www.redmine.org/, 02.03.2019 44 3.3. Design vor allem im Sicherheitsbereich nicht auf proprietäre Lösungen zurückgegriffen werden, da hier ein hoher Grad an Expertenwissen benötigt wird. Im Abschnitt 2.1 wurden die verwendeten Technologien bereits kurz beschrieben. Es wurden auch besonders jene Eigenschaften dargestellt, welche für das Projekt wichtig und ausschlaggebend für die Entscheidungsfindung sind. Da das Projekt zwar eine eigenständige Applikation, dennoch aber Teil eines größeren Systems (TISS) ist, werden bereits verwendete und bewährte Technologien meist beibehalten. In der Planungsphase wurde dies mit der bereits vorhandenen Erfahrung in der Installation, Verwendung und Instandhaltung argumentiert. Dies trifft vor allem auf die Verwendung von Java und des Oracle RDBMS zu. Veraltete Artefakte, welche zum Teil noch in Verwendung sind, wurden aber durch moderne Alternativen ersetzt. Bei der Serverwahl musste sich zwischen der beschriebenen Implementierung von Wildfly und Tomcat2 entschieden werden, da beide Varianten derzeit in TISS im Einsatz sind. Aufgrund der im Abschnitt 2.1.3 beschriebene Offenheit und Konfigurierbarkeit wurde Wildfly ausgewählt. Nachdem alle Anforderungen klar sind, Tasks und Entwicklertickets angelegt und die zu verwendenden Technologien beschlossen wurden, kann mit der eigentlichen Implementie- rung des Projektes begonnen werden. Diese ist im nächsten Kapitel beschrieben. 2http://tomcat.apache.org/, 02.03.2019 45 KAPITEL 4 Implementierung Die folgenden Abschnitte befassen sich mit der konkreten Implementierung des Projektes. Es werden die Hierarchie, die Aufteilung der einzelnen Module und die Kommunikation dazwischen beschrieben und die getroffenen Designentscheidungen argumentiert. Außer- dem wird das Testen des geschriebenen Programmiercodes beschrieben und erklärt, wie die Richtlinien der Datenschutzgrundverordnung umgesetzt werden. 4.1 Softwarearchitektur 4.1.1 Aufbau Der Aufbau der Applikation lässt sich als klassisches Schichtenmodell beschreiben. Hierbei wird die Applikation in drei Teile aufgespaltet: die Präsentationsschicht (front end), die Logikschicht und die Datenhaltungsschicht (back end). • Präsentationschicht. Dies ist die oberste Schicht der Applikation und verschafft dadurch dem/der Benutzer/in Zugang zum System. In dieser Schicht werden Benutzeroberflächen und die dahinterstehende Logik definiert, welche die Oberfläche interaktiv macht. Bspw. werden geladene Daten aus der Datenbank in verschiedenste Darstellungsformen konvertiert oder die an Benutzereingaben gebundenen Handler- Funktion deklariert. • Logikschicht. Diese Schicht dient der Kommunikation zwischen Präsentations- und Datenerhaltungsschicht. Sie ist dafür zuständig, von dem/der Benutzer/in angefor- derte Daten aus der Datenbank zu laden, diese falls notwendig weiter zu verarbeiten und an die Präsentationsschicht zur Darstellung zu übermitteln. Auch komplexere Berechnungen werden in diese Schicht ausgelagert, da die Präsentationschicht so we- nig Logik wie möglich enthalten soll. Die definierten Funktionen werden in Services 47 4. Implementierung zusammengefasst, welche von allen Modulen, je nach Notwendigkeit, erreichbar sind. Die eigentliche Implementierung ist je nach Anwendungsfall in eigene Klassen und Module ausgelagert, oder befindet sich direkt in der Servicedefinition. • Datenhaltungsschicht. Die Datenhaltungsschicht ist für alle Zugriffe auf die Daten- bank verantwortlich. Je nach Berechtigung und Anwendungsfall liest und schreibt sie Daten und kann auch einfache Konvertierungs- oder Sortierungsaufgaben erledigen. Abbildung 4.1: Darstellung eines Schichtenmodells [ Ba09]. Durch diese Aufteilung erreicht man eine geringe Koppelung zwischen den einzelnen Modulen. Dies ist vorteilhaft für die Wartung und das Verständnis des Systems. Fehler können somit meist auf eine Schicht zurückgeführt werden und man muss, je nach Problemstellung, nur einen gewissen Teil betrachten. Außerdem sind einzelne Schichten leichter austauschbar falls bspw. ein neue Präsentationsschicht eingeführt werden soll oder das dahinterliegende Datenbanksystem geändert wird. Abbildung 4.1 stellt eine solche Aufteilung mit Hilfe einer Beispielapplikation dar. In der Präsentationschicht werden Daten angefordert, welche anschließend von der Logikschicht verarbeitet und 48 4.1. Softwarearchitektur an die Datenhaltungsschicht weitergegeben werden. In dieser Schicht werden die Daten ausgelesen, an die Logikschicht für finale Berechnungen zurückgegeben und abschließend in der Präsentationschicht dargestellt. Die Aufteilung der Schichten wird mit Hilfe von Modulen realisiert, welche jeweils spezielle Aufgabengebiete besitzen und nicht nur aus den drei genannten Schichten bestehen. Dies ist ab einem gewissen Komplexitätslevel notwendig, da die Funktionalität mehr als nur das Darstellen von Daten aus der Datenbank beinhaltet. Dennoch bleibt das Schichtenmodell erhalten, es wird lediglich erweitert. Die konkret vorhandenen Module und ihre Zuständigkeiten werden im Folgenden aufgelistet und kurz beschrieben: • frontend. Das Modul frontend stellt die klassische Präsentationschicht dar. Hier werden mit Hilfe von Java Server Faces und Primefaces die Benutzeroberflächen definiert und in den dahinterstehenden Beans die Logik programmiert. Unter einer Bean versteht man eine Klasse, welche direkt mit der Benutzeroberfläche gekoppelt ist und einfache, dafür benötigte Funktionalitäten enthält. Sie ist auch dafür zustän- dig, angeforderte Befehle von dem/der Benutzer/in an die verantwortlichen Module weiterzuleiten. Außerdem befinden sich hier einfache Klassen, welche darzustellende Informationen enthalten, und für die Benutzeroberfläche benötigte Ressourcen (u.A. Bilder, CSS-Dateien usw.). • api. Das Modul api stellt die klassische Logikschicht dar. Hier werden die Interfaces für die Services definiert, welche meist von allen Modulen ausgehend erreichbar sind. Somit ist eine Abhängigkeit zu allen anderen Module gegeben und sie ist für die gesamte Kommunikation verantwortlich. Wie vorher erwähnt, finden sich die Implementierungen der Interfaces nur in seltenen Fällen direkt in dieser Schicht. Allerdings befindet sich die Definition der Datentransferobjekte in diesem Modul, welche zum Übermitteln der Daten vom backend in die anderen Module dienen. Die Entitätsklassen selbst, also jene, welche die Datenbanktabellen abbilden, werden nur im backend verwendet. • backend. Das Modul backend stellt die klassische Datenhaltungsschicht dar. Hier werden neue Daten entgegengenommen und in die Datenbank geschrieben. Diese- können dann zu einem späteren Zeitpunkt, abhängig der Anfrage, wieder ausgelesen und weiterverarbeitet werden. Auch befinden sich hier einige Implementierun- gen von Services, welche speziell für den Kommunikationsprozess von Lesen und Schreiben zuständig sind. Zusätzlich werden, wie vorher erwähnt, die Tabellen als Klassen (Enitätsklassen) dargestellt, welche von den auch hier implementierten Datenbankmanagern administriert werden. • rest-api. Das Modul rest-api bietet Schnittstellen nach außen an. Da sich TISS aus verschiedenen Applikationen zusammensetzt, müssen diese untereinander kommuni- zieren, um Daten und Events austauschen zu können. Dafür werden Schnittstellen implementiert, welche unter einem gewissen Pfad mit gewissen Berechtigungen bzw. einer Authentifizierung Anfragen entgegennehmen und entsprechend Daten 49 4. Implementierung zurückliefern. Eine genaue Beschreibung der Implementierung dieses Moduls folgt im Abschnitt 4.2. • printer-ws. Das Modul printer-ws ist für die Kommunikation mit dem Kartendru- cker und allen damit zusammenhängenden Funktionalitäten zuständig. Die Drucker bieten ein SOAP-Interface1 an, welches dementsprechend in der Applikation de- finiert werden muss, um Aufrufe zu ermöglichen. Die Daten müssen in für den Drucker lesbare Formate konvertiert und die anschließend gestarteten Prozesse überwacht werden, um passende Fehlermeldungen zurückzugeben (bspw. "Drucker nicht erreichbar", "fehlerhaftes Format"). Sollte sich zu einem späteren Zeitpunkt für einen anderen Druckeranbieter entschieden werden, ist das Modul durch die gegebene modulare Koppelung austauschbar, da alle Funktionen über allgemein definierte Interfaces zur Verfügung gestellt werden. • tasks. Im Modul tasks werden zeitbasierte und wiederkehrende Aufgaben definiert. Es handelt sich um sich wiederholende Prozesse, welche zu einer gewissen Zeit ausgeführt werden, um Daten zu überprüfen, Erinnerungsmails zu versenden oder die Synchronisierung mit anderen Systemen anzustoßen. In dieser Applikation dienen diese Aufgaben folgender Funktionalität: – Das Versenden einer Mail, um auf die notwendige Verlängerung der TUcard hinzuweisen. – Das Versenden täglicher Mails, um die Status der Drucker an die jeweilige, für die Wartung zuständige Abteilung, mitzuteilen. – Das automatische Deaktivieren von TUcards bei Beendigung des Dienstver- hältnisses. • security. Das Modul security stellt Funktionalitäten im Sicherheitsbereich zur Verfügung. Darunter fallen beispielsweise die korrekte Authentifizierung und Au- torisierung, die Überprüfung von Rollen und Rechten und die Beschränkung und Regelung der Schnittstellen-Zugriffe von Drittsystemen. Es wird vor allem in der Präsentationsschicht verwendet, um Funktionalitäten und Daten entsprechend der Berechtigungen von dem/der Benutzer/in anzuzeigen, aber auch in der Logikschicht, um Prozesse gemäß sicher durchzuführen. 4.1.2 Arbeitsprozesse Jeder Prozess benötigt die Zusammenarbeit mehrerer Module. Dafür müssen diese untereinander kommunizieren und Daten austauschen. Wie ein von dem/der Benutzer/in gestarteter Arbeitsprozess intern abläuft, wird nun anhand eines Beispieles erläutert. 1Simple Object Access Protocol, https://www.w3.org/TR/soap/, 03.03.2019 50 4.1. Softwarearchitektur Prozess zum Erzeugen einer Studierenden-TUcard Für die Erzeugung einer neuen TUcard für Studierende sind folgende Schritte zu erledigen: 1. Der/die Studierende wird in einer anderen Applikation des Systems zum Studium aufgenommen. 2. Im Zuge dessen wird im Modul rest-api eine Schnittstelle aufgerufen, welche eine neue Kartenbestellung entgegennimmt. 3. Der Befehl zum Erstellen einer neuen Karte wird von rest-api an api weitergegeben. 4. Das Modul api verarbeitet die Daten und gibt sie an backend weiter. 5. Das Modul backend nimmt die Daten entgegen und erzeugt daraus einen neuen Eintrag in der Datenbank. Dieser Prozess läuft bei der Aufnahme eines/r Studierenden im Hintergrund ab. Wäh- renddessen wird der/die Mitarbeiter/in auf die Kartendruck-Seite weitergeleitet. 1. Der/die Mitarbeiter/in initiiert den Druck mit einem Klick. 2. Das Modul frontend verarbeitet diesen Klick und gibt den Befehl an printer-ws weiter. 3. In printer-ws werden die Daten für den Druck konvertiert und die dementsprechende Schnittstelle, welche vom Drucker angeboten wird, aufgerufen. 4. Das Modul frontend zeigt den Status des Druckes in der Zwischenzeit für den/die Benutzer/in an. 5. Sobald der Druck abgeschlossen wurde, wir vom Drucker eine Schnittstelle in rest-api aufgerufen. 6. Das Modul rest-api gibt den Endstatus (Erfolg, Fehler) an backend weiter, welches diesen in die Datenbank einträgt. 7. Das Modul frontend zeigt den Status für den/die Benutzer/in ersichtlich an. Die beiden beschriebenen Prozesse werden in Abbilung 4.2 graphisch dargestellt. Die Spalten stellen die jeweiligen Module dar, wobei sich der Modulname im Titel befindet. Die Zeilen bilden die zeitliche Abfolge der Aufrufe ab. 51 4. Implementierung Abbildung 4.2: Darstellung des Prozesses zum Erstellen einer neuen TUcard. 52 4.1. Softwarearchitektur 4.1.3 Testen Um den Benutzer/innen ein möglichst fehlerfreies System anzubieten, welches die opti- male Abwicklung ihrer Aufgaben ermöglicht, ist das Testen ein fundamentaler Teil der Softwareentwicklung. Es gibt unterschiedlichste Ansätze, wie Tests in die Entwicklung eingebracht werden, wie deren Abläufe aussehen und wie groß die Testabdeckung sein soll. Diese Ansätze werden im Folgenden nicht diskutiert, da primär jene Testansätze dargestellt werden sollen, mit welchen dieses Projekt entwickelt und erprobt wurde. Automatisierte Tests Automatisierte Tests sind in zu jedem Lebenszyklus der Softwareentwicklung fundamental. Man versteht darunter programmierte Tests, welche gewisse Funktionalitäten einer oder mehrerer Komponenten testen. Durch die Automatisierung kann bei ersten Implementie- rungen oder bei späteren Änderungen immer sofort die Funktionalität überprüft werden [MP02]. Je nach Lebenszyklus unterscheidet sich die Herangehensweise: • Bevor mit der Implementierung begonnen wird, aber die späteren Abläufe bzw. gewünschten Funktionen definiert sind, können Tests geschrieben werden, welche diese Funktionalität testen und zu Beginn aufgrund der fehlenden Implementie- rung fehlschlagen. Wird dann mit der Programmierung begonnen, kann durch die Ausführung dieser Tests sofort die Richtigkeit und der Fortschritt überprüft werden. • Während der Implementierung können Tests zum Überprüfen von Spezialfällen verwendet werden, die ansonsten schwierig zu rekonstruieren sind. Damit kann ein aufwendiger Testfall in kurzer Zeit nachgestellt und auf Richtigkeit überprüft werden. Bei besonders komplexen Aufgaben muss auch die Richtigkeit des Tests selbst gewährleistet sein, da sonst nur vermeintliche Korrektheit besteht. • Nachdem die Implementierung fertiggestellt ist, können automatisierte Tests beim Ändern oder Hinzufügen von Funktionalität verwendet werden. Wenn Code an ver- schiedensten Stellen verändert bzw. hinzugefügt wurde, kann damit die Richtigkeit und Funktionalität schnell überprüft werden. Automatisierte Tests wurden in der Applikation vor allem mit den beiden Test-Frameworks JUnit2 und Arquillian3 durchgeführt. Beide bieten unterschiedliche Herangehensweisen an, welche im Folgenden kurz beschrieben werden: • JUnit. Mit Hilfe von JUnit kann die Funktionalität einzelner Methoden, Klassen oder Module (Komponententests) getestet werden. Es wurde daher bereits zu Beginn der Implementierung benutzt und immer wieder erweitert. 2https://junit.org/, 09.03.2019 3http://arquillian.org/, 09.03.2019 53 4. Implementierung • Arquillian. Das Framework Arquillian hingegen unterstützt das Erzeugen von Integrationstests. Dabei werden verschiedene voneinander abhängige Module auf ihre Interaktion getestet. Manuelle Tests Manuelle Tests werden vor allem für das Testen der Präsentationsschicht verwendet, da im Rahmen des Projektes noch keine automatisierten Frontend-Tests dafür eingeführt wurden. Der erste manuelle Test wird immer von dem/der Entwickler/in selbst ausgeführt. Nachdem eine neue Funktionalität implementiert oder eine sonstige Änderung getätigt wurde, wird durch das Ausführen der Applikation und des Startens des Features manuell getestet. Solche Tests sind elementar, da ein großer Teil der möglichen Fehler hiermit gefunden werden kann. Für ausführlichere Tests wird in der implementierenden Stelle auf ein Team von Testern zurückgegriffen. Auch bei dieser Applikation wurde beim Fertigstellen eines neuen Fea- tures oder sonstigen Änderungen Tester beauftragt, welche das System auf Korrektheit überprüfen und, falls möglich, Arbeitsabläufe testen. Wurde der Fehler behoben bzw. die Funktionalität korrekt implementiert, wird das Ticket geschlossen. Bei gefundenen Fehlern wird das Ticket mit einem Kommentar wieder an den/die Entwickler/in zugewie- sen. Da nicht alle Artefakte auf diese Weise getestet werden können, wird dem Testteam mitgeteilt, ob ein Test möglich ist und was genau überprüft werden soll. Probebetrieb Um die Applikation optimal testen zu können, werden Testsysteme benötigt. Auf diesen werden verschiedene Versionen der Applikation bereitgestellt und können möglichst ident zur Applikation in Produktion benutzt und getestet werden. Auf diese Testsysteme haben zu Beginn nur die Entwickler/innen selbst Zugriff, um die grundlegenden Abläufe zu testen. Anschließend wird das benötigte Testsystem auch für das Testteam freigeschaltet, welches ausführlichere Tests durchführt. Sind auch diese bestanden, kann das System für einzelne berechtigte Stakeholder freigeschaltet werden. Dies dient vor allem dem Einholen von Feedback und dem Aufzeigen des Fortschrittes. Solche Rückmeldungen sind besonders in der benutzerzentrierten Entwicklung wertvoll, da man Daten und Kritiken von realen Benutzer/innen erhält. Wurde die Applikation von den verschiedenen Stakeholdern akzeptiert, wird diese Ver- sion in Produktion gestellt. Oft wird die Applikation auch in dieser Umgebung nur für eingegrenzte Nutzer freigeschaltet, um den Produktivbetrieb zu testen, da man in Testumgebungen nie alle Faktoren beeinflussen bzw. nachstellen kann. Dies ist natürlich nur bei der Einführung von neuer Funktionalität möglich. Fehler in bereits veröffentlichten Teilen der Applikation müssen sofort behoben werden. Wurde auch der Probebetrieb erfolgreich abgeschlossen, wird die Version für alle berech- tigten Benutzer/innen freigeschaltet und kann verwendet werden. 54 4.2. Kommunikation mit anderen Systemen 4.1.4 Datenschutz-Grundverordnung Durch die Einführung der neuen Datenschutz-Grundverordnung in der EU muss in Applikationen ein besonderer Wert auf personenbezogene Daten gelegt werden. Oft war für die Benutzer/innen nicht nachvollziehbar, welche ihrer Daten gespeichert und wie diese weiterverarbeitet wurden. Die neue Regelung soll dies nun vereinfachen und striktere Normen im Bezug auf die Verarbeitung von personenbezogene Daten vorschreiben. Hier ein relevanter Auszug daraus: Der Schutz natürlicher Personen bei der Verarbeitung personenbezogener Da- ten ist ein Grundrecht. Gemäß Artikel 8 Absatz 1 der Charta der Grundrechte der Europäischen Union (im Folgenden „Charta“) sowie Artikel 16 Absatz 1 des Vertrags über die Arbeitsweise der Europäischen Union (AEUV) hat jede Person das Recht auf Schutz der sie betreffenden personenbezogenen Daten.4 Um den Benutzer/innen Einsicht zu gewähren, mussten Anpassungen im gesamten TISS implementiert werden. Es wurde eine Seite erzeugt, welche dem/der Benutzer/in ermöglicht gespeicherten Daten einzusehen und warum diese persistiert werden müssen. Außerdem gibt es die Möglichkeit, eine komplette Auflistung aller Daten via Mail zu erhalten, in welcher auch sämtliche mit der Person in Relation gespeicherte Informationen angezeigt werden. Diese Daten werden von den einzelnen Teilsystemen über Schnittstellen an eine zen- trale Stelle übertragen und dort kombiniert für den/die Benutzer/in dargestellt. Die Funktionsweise dieser Schnittstellen wird in Abschnitt 4.2 genauer beschrieben. Die Abfrage der Daten erfolgt mit Annotationen zu den Datenbankfeldern. Relevante Informationen werden dementsprechend gekennzeichnet und bei Anfragen basierend auf einer eindeutigen Personen-ID ausgelesen. Relevant sind jegliche Daten, durch welche eine Person identifiziert werden kann, z.B. Name, Geburtsdatum oder sonstige IDs, welche auf eine Person zurückgeführt werden können. 4.2 Kommunikation mit anderen Systemen Da es sich bei TISS um ein System handelt, welches aus mehreren Subsystemen besteht, müssen diese in der Lage sein, untereinander zu kommunizieren. Dies funktioniert über Schnittstellen. Jedes System hat seine eigenen Zuständigkeiten und speichert dement- sprechend andere Daten ab. Diese werden aber für verschiedenste Anwendungszwecke auch in den anderen Systemen benötigt. Einerseits um Daten nicht doppelt zu speichern, andererseits um eine klare Strukturierung zu erzeugen. 4https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32016R0679, Seite 1, 09.03.2019 55 4. Implementierung Die Applikation TISS besteht insbesondere aus folgenden Teilprojekten: • TUcard. Hierbei handelt es sich um das in dieser Arbeit beschriebene Projekt. Es regelt sämtliche, mit der von der TU Wien ausgestellten Smartcard, zusammenhän- gende Prozesse. • Lehre. Dieses Projekt ist für die Organisation der Lehre verantwortlich. Darun- ter fallen beispielsweise die gesamte Organisation der Vorlesungen und Übungen, die Raumreservierung, Mobilität (bspw. Erasmus-Programm), Bewertungen und Studienabschluss. • Forschung. Das Projekt Forschung ist für alle Bereiche verantwortlich, welche mit dem Ansuchen, Bestätigen und Organisieren von Forschungsprojekten zusammen- hängen. Es können neue Projektanträge eingereicht werden, berechtigte Personen können diese genehmigen oder ablehnen, den Fortschritt vermerken und mit anderen Forschungsportalen austauschen. • Organisation. Die grundlegenden Informationen über Personen, Infrastrukturen und sämtliche allgemeinen Daten der TU Wien werden hier verwaltet. Außerdem werden die Anstellungsverhältnisse von Personen und die Erstaufnahme von Studierenden geregelt. In den folgenden zwei Abschnitten wird die Kommunikation zwischen dem Projekt TU- card und den anderen Teilprojekten von TISS beschrieben. Es folgen Erklärungen über angebotene Schnittstellen dieses Systems und verwendete Schnittstellen von Zweitsyste- men. 4.2.1 Zur Verfügung gestellte Schnittstellen Um Informationen über die Karten mit anderen Systemen zu teilen, bietet das Projekt TUcard verschiedene Schnittstellen an. Die wichtigsten werden im Folgenden aufgelistet und kurz beschrieben: • Bestellen. Da beispielsweise die Registrierung und Aktivierung von neuen Studie- renden in einem anderen System erfolgt, wird eine Schnittstelle angeboten, welche eine neue Kartenbestellung entgegennimmt. Damit wird die Registrierung eines/r neuen Studierenden dem TUcard-System bekannt gegeben und es kann ein neuer Karteneintrag erzeugt werden. Dafür wird eine Personen-ID und der gewünschte Kartentyp benötigt. Weitere Personendaten, welche für die zu erzeugende TUcard benötigt werden, werden anschließend mit der vorhandenen Personen-ID erneut angefragt und gespeichert. • Karteninformationen. In manchen Systemen ist es notwendig, den Status der Karten einer Person anzuzeigen. Dies hat vor allem Vorteile für die Benutzerfreundlichkeit, 56 4.2. Kommunikation mit anderen Systemen da verschiedenste Informationen gemeinsam angezeigt werden können und nicht auf den jeweiligen Seiten gesucht werden müssen. Die Anfrage verlangt eine eindeutige ID (bspw. Personen-ID, Karten-ID), mit welcher die zugehörigen Karten in der Datenbank gefunden werden können. Trifft eine Anfrage auf mehrere Karten zu, werden diese als Liste zurückgegeben. In den zurückgegebenen Daten findet man, je nach Anfrage, Grundlegendes wie den derzeitigen Status oder auch eine URL zur Weiterleitung für genauere Informationen. • Antwort vom Kartendrucker. Damit der Kartendrucker nach Abschließen des Druck- vorganges die Applikation über den Ausgang benachrichtigen kann, muss eine Schnittstelle angeboten werden, welche die jeweiligen Daten entgegennimmt. Dafür werden verschiedene Daten, welche unter anderem eine eindeutige ID des Druck- vorgangs und den Ausgangsstatus enthalten, an die entsprechende Schnittstelle gesendet und dort weiterverarbeitet. Dieser Ausgangsstatus gibt an, ob der Druck der Karte erfolgreich war und sie dementsprechend verwendet werden kann. Zudem wird dem/der Benutzer/in angezeigt, ob die Karte ausgehändigt werden kann oder der Druck neu gestartet werden muss. • Verlängerungsterminal. Um Karten nach Ablauf ihrer Gültigkeit zu verlängern, müssen sie mit Hilfe eines TUcard-Terminals erneuert werden. Dieses Terminal fragt basierend auf den ausgelesenen Daten der Karte bei einer angebotenen Schnittstelle nach, ob und für welche Dauer die Karte verlängerbar ist. Anschließend wird das neue Gültigkeitsdatum aufgedruckt, oder, bei einem Misserfolg, eine Fehlermeldung angezeigt. Auf dem Chip der Karte sind verschiedene IDs kodiert, welche durch die gegebenen Berechtigungen des Terminals ausgelesen werden können. Eine dieser IDs wird als Parameter zur Schnittstelle gesendet, wo basierend auf dem Personentyp und der Anstellung bzw. dem Studium das Gültigkeitsdatum berechnet wird. Dieses Datum wir als Antwort zurückgegeben und vom Terminal erneut mit den chip-kodierten Daten auf der Karte validiert. Wird dieser Prozess erfolgreich durchgeführt, folgt ein erneuter Aufruf mit der bestätigten Verlängerung. Abschließend wird das neue Gültigkeitsdatum aufgedruckt und die Karte dem/der Benutzer/in wieder ausgegeben. • Schließsystem. Da die TUcard auch für das Schließsystem verwendet wird, müssen dementsprechende Berechtigungen ausgetauscht werden. Dazu werden Schnittstellen angeboten, welche die notwendigen Informationen entgegennehmen und weiterleiten. • Datenschutz-Grundverordnung. Für die Datenschutz-Grundverordnung (siehe auch Abschnitt 4.1.4) müssen von allen Systemen Daten zur jeweiligen Person angefragt und kombiniert angezeigt werden. Dafür wird von jedem der Teilsysteme eine Schnittstelle angeboten, wo in einem einheitlichen Format, basierend auf einer Personen-ID, alle gespeicherten Informationen zurückgegeben werden. 57 4. Implementierung 4.2.2 Verwendete Schnittstellen von anderen Systemen Da das Projekt TUcard auch Informationen von anderen Systemen benötigt, um Karten verwalten und ausstellen zu können, werden verschiedenste Schnittstellen anderer System- teile aufgerufen. Die wichtigsten werden im Folgenden aufgelistet und kurz beschrieben: • Person. Um eine neue Karte zu erstellen und bestehende Besitzer zu verwalten, ist es notwendig, Personendaten zu erhalten. Diese Informationen werden über eine sogenannte Personenschnittstelle abgerufen, welche mit verschiedenen IDs und Parametern funktioniert und dementsprechende Ergebnisse zurückliefert. Teilweise werden diese Personendaten anschließend auch im Projekt gespeichert, um einfachere Abfragen zu ermöglichen. Hierbei handelt es sich aber nur um direkt mit der Karte zusammenhängende Daten, bspw. den Namen oder das Geburtsdatum einer Person, welche auf die Karte gedruckt oder kodiert werden soll. • Personentyp. Auch das Verhältnis einer Person zur TU Wien muss mit Hilfe einer Schnittstelle bestimmt werden. Anhand einer Personen-ID kann abgefragt werden, ob es sich um eine/n aktive/n Studierenden, Mitarbeiter/in oder Sonstiges handelt. Dies ist wichtig für das Anzeigen von auf Personengruppen begrenzte Daten, das Ausstellen der TUcard und die Verlängerung der Gültigkeit. Abhängig vom Perso- nentyp können entsprechende Kartentypen ausgestellt werden. Die Anstellungsdauer bzw. der eingezahlte Studienbetrag entscheidet über die Gültigkeitsdauer. • Titel. Bestimmte Kartentypen ermöglichen das Aufdrucken des Titels des/der Besitzers/in. Die Titel werden auch über eine dafür ausgelegte Schnittstelle ab- gefragt, da sie einer gewissen Logik der Reihung und Schreibweise unterliegen, die sich verändern kann. Somit muss die Logik nur an einer Stelle implementiert und bei notwendigen Änderungen nur dort angepasst werden. Unabhängig davon werden diese Titel intern nochmals gekürzt, falls sie zu lang für die auf der Karte vorgesehene Fläche sind. • Rollen/Rechte. Jede Person hat abhängig von ihren Verhältnis zur TU Wien (Mitarbeiter/in, Studierende/r, Sonstiges) verschiedenste Rollen und Rechte. Diese werden basierend auf den zu erledigenden Aufgaben ausgestellt. Jede im System zur Verfügung gestellte Funktionalität soll auf diese Rollen und Rechte überprüfen, um unerwünschte Zugriffe zu verhindern. Um dies zu ermöglichen, werden mit Hilfe einer Personen-ID Berechtigungen abgefragt, mit denen der/die Benutzer/in das System anschließend dementsprechend verwenden kann. Da es sich hier oft um größere Datensätze handelt, welche öfters verwendet werden, werden diese zwischengespeichert. • Kartendrucker. Wie im vorherigen Abschnitt 4.2.1 bereits erwähnt, verläuft die Kommunikation mit den Kartendruckern über Schnittstellen. Diese stellen gewisse Funktionen zur Verfügung und können mit entsprechenden Parametern aufgerufen werden: 58 4.2. Kommunikation mit anderen Systemen – Start eines Kartendruckes – Abfrage der Warteschlange – Fehlerbehebung – Start einer Reinigung – Neustart Mit Hilfe dieser Befehle müssen alle Prozesse korrekt gestartet und auf ihren Status überprüft werden, um ein möglichst fehlerfreies Abwickeln der Aufträge zu ermöglichen. • Bilder. Auf Wunsch des/der Benutzers/in kann das für die TUcard hochgeladene Bild auch im allgemeinen Adressbuch von TISS verwendet werden. Wird diese Option gewählt, wird das Bild mit Hilfe einer Schnittstelle an das jeweilige System gesendet. Mit Hilfe einer Personen-ID, welche als Parameter mitgegeben wird, wird dieses Bild anschließend dort als Profilbild gesetzt. • Mensa. Gewisse Studierende haben Anrecht auf verbilligte Preise in der Mensa. Dieses Recht wird jedes Semester neu vergeben und beim Verlängern der TUcard mit aufgedruckt. Um zu Überprüfen, ob ein Studierender diese Ermäßigung erhält, wird eine Schnittstelle mit der Matrikelnummer als Parameter aufgerufen, welche anschließend das entsprechende Ergebnis zurückliefert. • Bibliothek. Da die TUcard auch als Identifikation für die Bibliothek gilt, werden auch dort notwendige Daten zu Beginn bei der Registrierung mit einer Schnittstelle übertragen. Außerdem wird bei Deaktivierung, Reaktivierung und Sperre noch ein Status mitgeschickt, damit mit einer gesperrten Karte kein Zutritt gewährt wird. • Organisationseinheiten. Die Verwaltung von einzelnen Abteilungen und Instituten unterliegt einer strengen Logik, kann sich ständig verändern und wird in einem anderen System verwaltet. Daher werden auch diese Informationen mit Hilfe einer Schnittstelle abgefragt. Sie werden in diesem Projekt zusätzlich für Anstellungs- verhältnisse verwendet, da hier die genaue Zugehörigkeit auslesbar ist. Außerdem wir bei Mitarbeiter/innenkarten die jeweilige Organisationseinheit gespeichert, um beispielsweise allgemeine Schließsystemberechtigungen zu erhalten. • Semester. Die Berechnungen des Semesterstarts und -endes befinden sich in der Teilapplikation Lehre. Notwendige Daten werden über Schnittstellen zur Verfügung gestellt. Für die Gültigkeit der Studierendenkarte wird das Enddatum des aktiven Semesters ausgelesen und auf die Karte gedruckt. Nachdem die Implementierung abgeschlossen wurde und die Applikation getestet und ausreichend in der Produktivumgebung verwendet worden ist, kann mit der Auswertung des Systems begonne werden, welche im folgenden Kapitel beschrieben wird. 59 KAPITEL 5 Ergebnisse 5.1 Abgrenzung: Mein Beitrag im gegenständlichen Projekt Da es sich bei diesem Projekt um eine Umstellung hält, war ein gewisser Teil der Infrastruktur bereits vorhanden. Diese Funktionalität wurde falls sie noch benötigt wurde weiterhin verwendet, oder andernfalls entfernt. Mein Beitrag am Projekt war vor allem die neue Kartenausgabe, Kartenverwaltung und Implementierung aller damit zusammenhängender Funktionen. Insbesondere betrifft es die Einführung des One-Stop- Shops für Studierende, die neue Kartenausgabe für Mitarbeiter/innen und die Einführung der Karten für weitere Mitarbeiter/innen, einschließlich aller dafür benötigten Funktionen. 5.2 Evaluierung der Forschungsfrage 5.2.1 Vorgehen Für die Evaluierung der Forschungsfrage wurden Experteninterviews mit verschiedenen Stakeholdern durchgeführt. Es wurde mit Leitern der jeweiligen zuständigen Abteilungen, mit Angestellten, welche direkt mit den Kunden in Kontakt sind, und mit Administratoren, welche die gesamten Prozesse überwachen und warten, gesprochen. Damit gelang ein Einblick, wie die Umstellung auf die zuständigen Abteilungen wirkte. Zusätzlich konnten die Interviewpartner über die Zufriedenheit ihrer Kunden (Studierende, Mitarbeiter/innen) berichten, da sie bestens über die Veränderungen und Unterschiede, welche durch die Umstellungen aufgetreten sind, Bescheid wissen. Mit folgenden Abteilungen wurden Experteninterviews durchgeführt: • TU.it. Die TU.it war vor der Umstellung für das Drucken und Organisieren der TUcard zuständig. Jetzt kümmert sie sich vor allem um die Wartung der Hardware 61 5. Ergebnisse und im geringen Ausmaß um die Administration. Mit dem Abteilungsleiter wurde besprochen, wie die Umstellung verlief und wie sie in der Abteilung aufgenommen wurde. Zusätzlich wurde auch mit einem Angestellten, welcher früher für den Kartendruck und Administration zuständig war und jetzt Hardwarewartung und kleinere Aufgaben in der Administrierung der TUcard durchführt, ein Interview geführt. • Studienabteilung. In der Studienabteilung wurde ein One-Stop-Shop für die Erstauf- nahme von Studierenden eingerichtet. Die größte Veränderung war die zusätzliche Verantwortung über die TUcard für Studierende. Die Auswirkungen dieser Umstel- lung wurde mit dem Abteilungsleiter und mehreren Referent/innen besprochen. Der Abteilungsleiter konnte dabei allgemein Rückmeldung geben und über aufgetretene Probleme bei der Umsetzung sprechen. Die Referent/innen konnten direkt über ihre Erfahrungen berichten, welche Prozesse sich für Studierende verändert haben und wie diese aufgenommen wurde. • Organisationseinheit Gebäude und Technik. Die Organisationseinheit Gebäude und Technik ist für die Administration und das Drucken der TUcards für Mitarbei- ter/innen und weitere Mitarbeiter/innen verantwortlich. Auch in diesem Fall wurde mit den jeweiligen Abteilungsleiter/innen gesprochen, wie sie die Umsetzung die- ser neuen Verantwortung organisiert haben und sie bis jetzt bewerten. Ebenfalls wurde mit den für den Druck beauftragten Personen gesprochen, wie sie die neue Aufgabe in ihren Arbeitsalltag eingebunden haben und wie sie die Zufriedenheit der Mitarbeiter/innen und weiteren Mitarbeiter/innen wahrnehmen. • Stabstelle CSD. Die Stabstelle CSD ist für die Umsetzung und Wartung der ge- samten Applikation verantwortlich und übernimmt zusätzlich noch administrative Aufgaben. Daher wurde mit dem Abteilungsleiter gesprochen, wie aus seiner Sicht die Umstellung verlief, da er von Anfang an bei allen Gesprächen und Entscheidun- gen eine maßgebliche Rolle spielte. Außerdem wurde ein für die Administration der TUcard verantwortlicher Mitarbeiter befragt, wie er die Veränderung wahrnahm. Mit seiner Hilfe wurde auch eine technische Auswertung des Systems durchgeführt. Auf Basis der Interviews mit den genannten Personen wurde die folgende Auswertung erstellt. Zu Beginn werden die allgemeinen Rückmeldungen ausgewertet, welche sich auf das komplette System bzw. die Umstellung der Kartenverwaltung und Kartenausgabe beziehen. Anschließend wird auf die einzelnen unterschiedlichen Kartentypen eingegangen und besprochen, inwiefern die Umstellung erfolgreich war bzw. was sich geändert hat. An dieser Stelle möchte ich mich bei Herrn Wolfgang Spreicer, Herrn Andreas Nussbaum, Herrn Philipp Kolmann, Frau Marlene Vlasek, Herrn Anton Hörmann und allen weiteren Mitarbeiter/innen der Studienabteilung, Organisation Gebäude und Technik und TU.it, welche bei den Interviews anwesend waren, für ihre Zeit und hilfreichen Informationen bedanken. 62 5.2. Evaluierung der Forschungsfrage 5.2.2 Allgemeines Eine der häufigsten Rückmeldungen und jene, wo sich alle Stakeholder einig sind, ist, dass es sich um eine große Umstellung handelte und das Projekt für alle beteiligten Abteilungen sehr arbeitsintensiv war. Umso wichtiger war es, dass die Qualität der Umsetzung optimal ist und alle Beteiligten eine möglichst reibungslose Umstellung erleben konnten. Trotz allem traten vor allem zu Beginn Probleme auf, was beim Ausmaß einer solchen Veränderung aber zu erwarten war. Komplett neue Systeme kamen erstmals zum Einsatz, neue Workflows mussten einstudiert werden und es fehlte allen Beteiligten noch an Erfahrung. Durch das erwartete Auftreten solcher Probleme wurden bei der Umsetzung folgende zwei Maßnahmen ergriffen: • Schrittweise Umstellung. Es wurde eine schrittweise Einführung des Systems gewählt. Jeder Kartentyp wurde separat voneinander veröffentlicht, um sich vollständig auf diesen konzentrieren zu können. Dies brachte aber auch Probleme mit sich, da zwei Systeme parallel geführt werden mussten. Für die betroffene Abteilung war dies aber von Vorteil, da man sich komplett auf ihre Probleme und Wünsche konzentrieren konnte. • Unterstützung in den ersten Wochen. Vor jeder Umstellung wurden alle Beteiligten geschult und in die Workflows eingeführt. Zusätzlich war bei Beginn einer jeden Umstellung immer mindestens ein zuständige/r Entwickler/in, Administrator/in oder ein/e Mitarbeiter/in vom Kundendienst des CSD in der betroffenen Abteilung anwesend, um etwaige Fragen zu beantworten, den Prozess zu beobachten und beim Lösen von Problemen zu helfen. Diese beiden Maßnahmen wurden sehr positiv aufgenommen und wurden auch bei den Interviews immer wieder als besonders gelungen hervorgehoben. Das Ziel benutzerorien- tiert zu arbeiten führte dazu, dass der Kunde sich nicht auf sich allein gestellt gefühlt hat, sondern auf Hilfe zurückgreifen konnte. Nach dieser Einführungsphase stellte sich das System meist als weitgehend stabil dar. Die Anzahl der Serviceanfragen verringerte sich immer weiter und durch die technische Auswertung konnte festgestellt werden, dass sich die Anzahl der Fehler abnahm und die Workflows funktionierten. Ein anderer Punkt, welcher vor allem von der Leitung verschiedener Abteilungen positiv bemerkt wurde, ist die nun klare Definition der Prozesse im Zusammenhang mit der TUcard und der Aufnahme von Studierenden, Mitarbeiter/innen und weiteren Mitarbei- ter/innen. Im Rahmen der Umstellung war es anfangs notwendig, alle alten Abläufe zu analysieren, wobei man bemerkte, dass es keine Dokumentation gab und dadurch niemand über den gesamten Prozess Bescheid wusste, nur über die jeweilige Zuständigkeit. Durch die Umstellung wurden nun alle Prozesse genau definiert und dokumentiert. Dadurch wurde die Wartung maßgeblich vereinfacht und neue Benutzer/innen können sich schneller ins System einarbeiten. Auch die Aufgabenverteilung ist nun klarer. Jede Abteilung weiß durch die genaue Definition, für welche Bereiche sie zuständig ist und welche Aufgaben 63 5. Ergebnisse an welche andere Abteilung weitergeleitet werden können. Somit führte die Definition der Abläufe auch zu einer genaueren Aufteilung der Zuständigkeiten, ein wichtiger Punkt in den Richtlinien der TU Wien. Einige Zeit nach der Umstellung folgte noch eine weitere positive Rückmeldung: Da das System funktionierte, wurden Wünsche und Vorschläge geäußert, welche darauf basieren. Es wurde ein Bezahlsystem eingerichtet, mit dem man unter anderem die Ersatzgebühr für Studierendenkarten bezahlen kann, das Schließsystem soll dementsprechend angepasst werden und es gab weitere Vorschläge für zukünftige Projekte, was darauf schließen lässt, dass die Kunden mit dem System zufrieden sind. 5.2.3 Studierende Die Umstellung der Aufnahme von Studierenden auf einen One-Stop-Shop war die größte und schwierigste Aufgabe des Projektes. Es musste eine große Anzahl an Prozessen umgestaltet und der Kartendruck jeweils eingeführt werden. Deshalb wurde entschieden, das neue System erstmals mit dem Anmeldebeginn im Sommersemester 2018 einzusetzen, da dort erfahrungsgemäß weniger Studierende als im Wintersemester zu erwarten sind. Die Umstellung wurde von den Mitarbeiter/innen als besonders schwierig und aufwendig bezeichnet. Dies mag einerseits an den zusätzlichen Aufgaben liegen, welche ihnen nun zugeteilt wurden, andererseits bringt eine derartige Veränderung ein gewisses Ausmaß an Problemen mit sich. Die Einführungsphase half damit, erste Probleme zu beseiti- gen und die neue Aufgabe kennenzulernen. Allerdings wurde dies nicht immer positiv aufgenommen, da der Kartendruck eine gewisse zeitliche Verzögerung bewirkt, welche vor der Umstellung noch nicht vorhanden war. Somit wurde trotz des optimierten Ein- baus in den bestehenden Workflow, der gesamte Prozess verlangsamt, was allerdings bei zusätzlichen Aufgaben selbstverständlich ist. Es wurde über zusätzliche logistische Aufgaben gesprochen, welche vorher nicht in ihrer Verantwortung lagen, aber auch über jene, welche ihnen jetzt erspart werden. Ein Beispiel war das Überprüfen der Adresse für die Zustellung der TUcard. Dabei gab es bei verschiedenen Wohnsitzen und vor allem bei Mobilitätsstudierenden immer wieder Probleme, welche nun durch die sofortige Ausgabe nicht mehr auftreten. Trotz der zusätzlichen Aufgaben und der Probleme, welche sie mit sich bringen, wurden besonders die Vorteile für Studierende hervorgehoben. Die gesamte Studienabteilung war sich einig, dass der One-Stop-Shop für Studierende sehr vorteilhaft ist und den Einstieg sichtlich vereinfacht. Besonders positiv sei die drastisch verkürzte Wartezeit für den Erhalt der TUcard. Musste früher mehrere Wochen darauf gewartet werden, wird durch den Echtzeitdruck dies auf einige Minuten reduziert und der/die Studierende verlässt die Studienabteilung bereits mit der TUcard. Dies wirke sich besonders positiv auf den Auf- nahmeprozess aus und die Studierenden erschienen sichtlich zufriedener und bewerteten dieses Konzept sehr positiv. Durch die Umstellung wurde der Studierendenausweis auch als offizieller Lichtbildausweis anerkannt; auch dies wurde öfters positiv angemerkt. 64 5.2. Evaluierung der Forschungsfrage Die Umstellung kann somit als Erleichterung für die Studierenden gesehen werden, welche das Aufnahmeverfahren maßgeblich vereinfacht und beschleunigt. Die neue Verteilung der Aufgaben wird noch kritisch gesehen, wird aber stetig optimiert, um alle Stakeholder möglichst zufrieden zu stellen. 5.2.4 Mitarbeiter/innen Die nächste Umstellung war die TUcard für Mitarbeiter/innen. Dabei mussten keine Fristen beachtet werden, da die Ausgabe der TUcard für Mitarbeiter/innen ganzjährig stattfinden kann. Zu Beginn wurden die Kartendruckbeauftragten und die Abteilungs- leiter/innen wiederum genau geschult und auch für einige Zeit nach der Einführung begleitet. Der Prozess wurde aufgrund des geringeren Zeitdruckes bei der praktischen Ausführung schnell eingelernt, weshalb auch die Schulung weniger Zeit beanspruchte. Die Umstellung wurde von den Mitarbeiter/innen und der Leitung der Abteilung als “nicht besonders problematisch“ bezeichnet. Der Prozess konnte einfach in den jeweiligen Arbeitsalltag eingebunden werden und gilt als nicht großer zusätzlicher Aufwand. Zwar gab es anfangs auch Probleme, welche aber beseitigt werden konnten. Da allerdings eine größere Anzahl an Personen für den Druck zuständig sind und diese auch gelegentlich wechseln, treten anfängliche Schwierigkeiten öfters auch, wie eine technische Auswertung ergab. Allerdings wird das Wissen nun mit schriftlicher Dokumentation und Erfahrung abteilungsintern weitergegeben, sodass es nur noch selten Anfragen an die Entwicklungs- abteilung gibt. Die klare Strukturierung und Aufteilung der Daten und Zuständigkeiten wurde auch besonders positiv vermerkt. Es sei einfach sich eine Übersicht der Daten zu verschaffen, diese zu kontrollieren und falls notwendig zu warten. Für die Mitarbeiter/innen selbst ist auch diese zwischenzeitliche Lösung ohne One- Stop-Shop von großem Vorteil. Die Karten werden von den zuständigen Personen in einem Abstand von maximal einer Woche gedruckt und können direkt am Arbeitsort abgeholt werden. Die Wartezeit wurde somit von zwei bis drei Wochen auf maximal eine Woche reduziert. Auch Mitarbeiter/innen an externen Standorten können nun dort ihre Karten beziehen, ohne einen Umweg auf sich zu nehmen bzw. einen Transport organisieren zu müssen. Außerdem wurde die Erinnerungsmail für das Erneuern der TUcard für Mitarbeiter/innen positiv bemerkt. Dies wurde in der Entwicklung als nicht besonders wichtig eingestuft, hatte aber einen großen Einfluss auf die Zufriedenheit mit der Umstellung des Systems. Die Möglichkeit dieser Funktion wurde im Rahmen des benutzerorientierten Designs öfters bemerkt und wurde dementsprechend umgesetzt. Auch in diesem Fall kann die Umstellung als erfolgreich betrachtet werden. Den Mitarbei- ter/innen wurde der Prozess der Beschaffung ihrer TUcard maßgeblich vereinfacht und die Druckbeauftragten haben diesen bereits erfolgreich in ihren Arbeitsalltag integriert. 65 5. Ergebnisse 5.2.5 Weitere Mitarbeiter/innen Aufgrund der Ähnlichkeit zum Workflow der TUcard für Mitarbeiter/innen wurde dieser Prozess relativ kurz darauf auch in Betrieb genommen. Die Veränderungen die dadurch aufgetreten sind, wie im Abschnitt 3.2.3 beschrieben, minimal. Dennoch wurden die Mitarbeiter/innen wieder neu geschult, um notwendige zusätzliche Informationen zu vermitteln und auch den Unterschied zwischen den verschiedenen Kartentypen zu erklären, damit sie den Prozess auch verstehen und nicht nur die Ausführung übernehmen. Da dieser Typ von Personen vorher noch keine eigene Karten hatte und auf Gästekarten angewiesen war, fanden die größten Umstellungen im Hintergrund statt. Ein großer Vorteil, den die Einführung dieses Kartentyp nach sich zog, war die klare Definition des Begriffes weitere Mitarbeiter/innen. Vorher war dies nicht klar definiert und wurde oft völlig falsch verwendet. Für die Einführung der Karte war eine klare Definition notwendig, welche in der gesamten Universität nun angewandt wird; auch dies verbessert wiederum die Richtlinien der TU Wien. Da vorher weitere Mitarbeiter/innen lediglich eine Gästekarte erhielten, stellten sie auch ein gewisses Sicherheitsrisiko dar, da die Angabe eines Namen optional war und Sicherheitsaspekte oft vernachlässigt wurden. Für die weiteren Mitarbeiter/innen selbst wurde ein großer Vorteil festgestellt. Die Personalisierung der Karte führte zur besseren Integration und erleichtert den Organisa- tionsprozess signifikant. Zusammenfassend konnte durch die Umstellung eine klare Definition für weitere Mitar- beiter/innen geschafft werden, die Organisation wurde maßgeblich vereinfacht und die Ausgabe lässt sich optimal in den Prozess der TUcard für Mitarbeiter/innen einbinden. 5.2.6 Administration Jene Personen, welche für die Administration der TUcards verantwortlich sind, sind größtenteils gleich geblieben, allerdings haben sich ihre Aufgabe entsprechend der neuen Applikation verändert. Sie haben somit einen guten Vergleich der Systeme, da sie mit beiden Versionen sehr intensiv gearbeitet haben und auch das notwendige technische Wissen bzw. Einblick in das System besitzen. Im Rahmen der engen Zusammenarbeit mit den Entwickler/innen, wurde mit ihnen zusammen immer wieder technische Auswertungen durchgeführt, welche auch im Rahmen der Interviews nochmals besprochen wurden. Sie waren somit aktiv an der Implementierung beteiligt. Besonders positiv wurde die schnellere Abarbeitung der notwendigen Workflows zur Behebung von Problemen beschrieben. Diese seien nun viel einfacher und intuitiver in der Bedienung. Die strikte Aufteilung von Daten auf die jeweiligen verantwortlichen Abteilungen hilft auch bei der Fehlersuche und lässt Probleme einfacher nachvollziehen. Für Administratoren werden die identischen Seiten wie auch für die Abteilungen selbst verwendet, nur mit zusätzlichen Filterparametern und Funktionalitäten. Dieses Konzept der dynamischen einzelnen Seiten ermöglicht den Administratoren schnellere Abarbeitung und vermeidet das Suchen und Wechseln der benötigten Ressourcen. Die abgeschaffte 66 5.2. Evaluierung der Forschungsfrage Synchronisierung zu Zweitsystemen erleichtert die Wartung spürbar und vermeidet Konflikte zwischen Datensätzen. Durch die technische Auswertung konnte die vorher bereits von anderen Mitarbeiter/innen bestätigte schnellere Kartenzustellung nochmals verifiziert werden, da sich der Zeitraum zwischen Bestellung und Aktivierung maßgeblich verringerte. Die Abteilung der TU.it sieht die Umstellung als positiv an, da ihre Prozesse damit sehr vereinfacht wurden. Anfangs war aber auch für sie die Umstellung sehr arbeitsintensiv, da sie für die Kodierung der TUcard und die Erneuerung der Terminals zuständig gewesen sind. Die neuen Prozesse haben aber auch für sie die Aufgaben erleichtert und sie arbeiten nun problemlos mit den neuen Applikationen. Die Umstellung lief ihres Erachtens relativ problemlos, was vor allem an der guten Kommunikation mit den zuständigen Personen in der Stabstelle CSD lag. Die Neuerung brachten für sie vor allem eine einfachere Wartung, welche intuitiver ist, und das Einführen neuer Anwendungen auf der Karte, welche nun dynamisch auf die TUcard kodiert werden können. Eine objektive und technische Auswertung des Kartenverbrauchs stellte außerdem eine große Verbesserung fest. Die auftretenden Druckfehler wurde von ca. 10 Prozent auf 3 Prozent reduziert. Für die Administratoren brachte die Umstellung viele Verbesserungen und vereinfachte ihre Arbeitsprozesse. Sie hatten einen maßgeblichen Einfluss auf den Erfolg, da viele organisatorische und technische Aufgaben von ihnen erledigt werden mussten und dafür viel Zeit investiert wurde. Diese Zeit wird aber durch die nun vereinfachten und schnelleren Prozesse gerechtfertigt. Nach Einsicht und Analyse der Daten, welche durch Experteninterviews und einer technischen Auswertung erzeugt worden sind, lässt sich die Forschungs- frage vor allem für Studierende und Mitarbeiter/innen als positiv beantworten. Die Umstellung erhöht die Kundenzufriedenheit signifikant, welches eines der zentralen Ziele des Projektes war. Bei den einzelnen Abteilungen herrscht noch Ungewissheit. Die verbesserten Workflows werden vor allem von den Administratoren als sehr positiv bezeichnet, allerdings gibt es in einzelnen Fäl- len noch einen gewissen Grad an Unzufriedenheit bei der Aufgabenverteilung, welche mit zukünftigen Optimierungen und Anpassungen möglichst beseitigt werden soll. 67 5. Ergebnisse 5.3 Probleme und weitere Verbesserungsmöglichkeiten Im Rahmen der Interviews wurde explizit auf aufgetretene Probleme eingegangen, um zu sehen, welche Schwachstellen die Umstellung hatte bzw. welche potenziell immer noch bestehen. Folgende Punkte wurden besonders häufig erwähnt bzw. sind von besonderer Wichtigkeit: • Anfangsphase. Wie vorher bereits erwähnt, gab es vor allem in der Anfangsphase der Umstellung Probleme. Das Einlernen der neuen Benutzer/innen, Unklarheiten bei gewissen Spezialfällen und anfängliche Fehler in der Applikation waren meist die Ursache dafür. Diese wurden aber durch die Mithilfe der zuständigen Abteilungen, Ausbessern der Fehler, Klärung und Implementierung der Spezialfälle und durch die gewonnenen Erfahrungen der Benutzer/innen gelöst. • Unstimmigkeiten. Bei der Planung der Zuständigkeiten und Übernahme von Pro- zessen gab es oft Unstimmigkeiten zwischen den einzelnen Abteilungen. Es mussten Lösungen gefunden werden, welche alle Stakeholder möglichst zufrieden stellen, aber dennoch eine optimale Abarbeitung der Prozesse ermöglichen, um vor allem optimale Kundenzufriedenheit zu erreichen. • Neue Aufgaben. Die Verantwortung und Übernahme neuer Aufgaben muss für die jeweilig Verantwortlichen ersichtlich sein und Sinn machen. Ansonsten führt dies zu Beschwerden und Unzufriedenheit gegen die Veränderung. Dies gelang bei dieser Umstellung nicht immer, wurde aber mit Hilfe von weiteren Erklärungen und der sichtlich vorhandenen Vorteile meist gelöst. • Drucker. Die gewählten Drucker sind auch nach der Einführungsphase noch recht anfällig für Fehler. Es besteht zwar ein großes Maß an Verbesserung im Vergleich zu den Vorgängern, dennoch treten in einigen Fällen Fehler auf, welche sich nicht auf ein Fehlverhalten der Benutzer/innen oder der Implementierung zurückführen lassen. Dies ist ab einer gewissen Häufigkeit sehr frustrierend und kann die Zufrie- denheit der Benutzer/innen sehr beeinträchtigen. Trotz vieler Serviceanfragen und Verbesserungen des zuständigen Servicepartners, bleiben Probleme vorhanden. • Netzwerk. Bei der Einrichtung der neuen Struktur mit PCs und Druckern, sind an manchen Standorten Probleme im Netzwerk aufgetreten, welche eine optimale Kommunikation verhindert haben. Die enorme Größe des bestehenden Netzwerkes an der TU Wien machte dies zu einer schwierigen Aufgabe, welche weiterhin bearbeitet werden muss. • Terminals. Die Terminals zum Verlängern der Gültigkeit einer TUcard sind teils sehr wartungsintensiv und ermöglichen nicht immer eine optimale Servicierung der Kunden. Die zuständige Abteilung der TU.it ist um eine Lösung bemüht und es wurden bereits Verbesserungen eingeführt. In Zukunft folgt ein kompletter Wechsel der internen Hardware. 68 5.3. Probleme und weitere Verbesserungsmöglichkeiten • Applikationsfehler. Vor allem zu Beginn der Umstellung sind einige Fehler in der Implementierung aufgetreten, welche eine optimale Abarbeitung der Prozesse verhindert haben; diese konnten aber durch agile Softwareentwicklung schnell behoben werden. Das Lösen dieser Probleme hat höchste Priorität. Einige mussten von den Benutzer/innen mit der Hilfe der jeweiligen Abteilung selbst überwunden werden, andere waren in der Verantwortung der Stabstelle CSD und der TU.it, welche die Applikationen zur Verfügung stellen. Wieder andere bestanden bereits und wurden durch die Einführung des neuen Systems erst klar. Vor allem für das Problem der Kartendrucker ist es notwendig, eine möglichst schnelle und optimale Lösung zu finden. Ein weiterer wichtiger Punkt waren die gewünschten Verbesserungen. Es wurde bespro- chen, welche zusätzlichen Funktionen bzw. Änderungen im bestehenden System die Abläufe optimieren und somit ein besseres Benutzererlebnis ermöglichen würden. • Infomails. Wie bereits vorher erwähnt, ist die Erinnerung zum Ablauf der Gültigkeit der TUcard besonders positiv aufgefallen. Daraus sind neue Ideen entstanden, für welche Zwecke man ähnliche E-Mail Benachrichtigungen noch verwenden könnte. Besonders oft erwähnt wurde eine Erinnerung zum Abholen bzw. Aktivieren der TUcard für Mitarbeiter/innen und weitere Mitarbeiter/innen. Diese werden zwar einmalig über das Eintreffen am Abholort informiert, jedoch wird eine große Anzahl erst nach erneuter manueller Benachrichtigung abgeholt. Diesen Prozess zu automatisieren würde den jeweiligen Verantwortlichen sehr helfen. • Weitere administrative Funktionen. Ein Wunsch der Administratoren und der Service-Mitarbeiter/innen ist, besonders häufig auftretende Probleme automatisch zu lösen. Die bereits vorhandene Seite zum Starten solcher Prozesse, soll um gewissen Funktionen erweitert werden, welche nochmals genauer vereinbart werden. Dies würde auch dem Helpdesk die Möglichkeit geben, solche Aufgaben zu erledigen, um somit die Administratoren zu entlasten. Die Wünsche der jeweiligen Abteilungen werden intern nochmals besprochen und priori- siert. Die Benutzer/innen werden anschließend über die Entscheidungen und den Fort- schritt informiert. 69 5. Ergebnisse 5.4 Vergleich mit anderen Umstellungen Vergleicht man nun die hier durchgeführte Umstellung, mit anderen in Abschnitt 2.3.4 beschriebenen Umsetzungen sind einige Ähnlichkeiten festzustellen. Einerseits sind die klaren Vorteile und Vereinfachungen für den Kunden nochmals zu erwähnen. Wie auch bei den beschriebenen Umstellungen, optimiert die Einführung dieses Systems den Ablauf zum Erhalt der TUcard für Studierenden, Mitarbeiter/innen und weiteren Mitarbeiter/innen. Andererseits sind auch die aufgetretenen Probleme ähnlich. Wie auch bei den anderen Umstellungen, gab es Differenzen zwischen den einzelnen Abteilungen über die neuen Zuständigkeiten und Aufgabenbereiche. Die Zuteilung von neuen Prozessen führte in einzelnen Fällen zu Beschwerden und es musste in der Diskussion eine Lösung dafür gefunden werden. Unterschiedlich war die schrittweise Umstellung, welche als durchaus positiv gewertet wurde. Durch die im Vergleich langsamere Einführung konnten sich die jeweiligen Stake- holder an die Umstellung gewöhnen und wurden auch mit voller Aufmerksamkeit von den anderen Abteilungen unterstützt. Abschließend konnten aber keine wesentlichen Abweichungen bzw. Überraschungen im Vergleich zu anderen Umstellungen festgestellt werden, welche durch die dementsprechende Vorbereitung bereits eingeplant wurden. 70 KAPITEL 6 Zusammenfassung und Ausblick Zusammenfassend lässt sich die Forschungsfrage nach den Auswirkungen auf die Sta- keholder durchaus positiv beantworten. Vor allem die Studierenden, Mitarbeiter/innen und weitere Mitarbeiter/innen, welche die TUcard erhalten, profitieren sehr davon. Auch für die TU.it, für welche es zwar eine sehr arbeitsintensive Veränderung war, und ihre Mitarbeiter/innen, welche viele Anpassungen implementieren mussten, sind die daraus hervorgegangenen Vorteile nun signifikant. Die einfachere Wartung ihrer Systeme und Organisation wird sich in Zukunft rentieren. Für die anderen Stakeholder, insbesondere die Studienabteilung und die Abteilung für Gebäude und Technik, welche nun zusätzliche Aufgaben zugeteilt bekommen haben, wird die Zukunft zeigen, ob die Prozesse an ihre Wünsche angepasst werden können bzw. ob sie sich an sie gewöhnen und die Aufteilung nach der jeweiligen Zuständigkeit (bspw. Ausgabe und Druck der TUcard für Studierende in der Studienabteilung) akzeptieren oder eine andere Lösung gefunden werden muss. Um den Erfolg des Projektes auch in Zukunft fortführen zu können, ist es allerdings dringend notwendig die Probleme, welche im Abschnitt 5.3 beschreiben worden sind, zu beheben bzw. nicht wieder auftreten zu lassen. Auch wird es mit zukünftigen Wünschen oder Änderungen immer wieder neue Herausforderungen geben, welche allesamt mit der bewährten benutzerzentrierten Entwicklung gelöst werden müssen. Das Projekt kann - wie meist in der Softwareentwicklung - auch nicht als abgeschlossen betrachtet werden. Es folgt noch die Einführung von weiteren Kartentypen, welche den Umgang mit dem System noch erweitern und den Benutzer/innen helfen soll. Auch darf die Wartung nach der Einführungsphase nicht vernachlässigt werden und es müssen immer Analysen und technische Auswertungen angefertigt und an die Stakeholder kommuniziert werden. Die Erfahrungen, welche mit der Umstellung gemacht worden sind, können helfen, ähnliche Projekte in Zukunft umzusetzen, und durch die verbesserte Verbindung, welche nun zwischen den einzelnen Abteilungen herrscht, kann dies schneller und effizienter geschehen. 71 Literaturverzeichnis [ Ba09] Bartledan, Wikimedia Commons. Overview of a three-tier application, 2009. [Zuletzt überprüft 01.04.2019]. [ So13] Someone’s Moving Castle, Wikimedia Commons. Illustration of iso/iec 7810 sizes in millimetres, 2013. [Zuletzt überprüft 22.2.2019]. [20110] OECD Reviews of Regulatory Reform OECD Reviews of Regulatory Reform: Italy 2009 Better Regulation to Strengthen Market Dynamics: Better Regula- tion to Strengthen Market Dynamics. OECD Reviews of Regulatory Reform. OECD Publishing, 2010. [Chi14] U. Chirico. Smart Card Programming. Lulu.com, 2014. [Chra] P. Christensson. Eeprom definition. https://techterms.com/ definition/flashmemory. Geprüft: 02.12.2018. [Chrb] P. Christensson. Ram definition. https://techterms.com/ definition/ram. Geprüft: 02.12.2018. [Chrc] P. Christensson. Rom definition. https://techterms.com/ definition/rom. Geprüft: 02.12.2018. [EBF+13] J. Eberspächer, M. Bossert, N. Fliege, H.J. Vögel, and C. Bettstetter. GSM Global System for Mobile Communication: Vermittlung, Dienste und Protokolle in digitalen Mobilfunknetzen. Informationstechnik. Vieweg+Teubner Verlag, 2013. [FCG+06] R. S. French, C. M. Coope, A. Graham, M. Gerressu, C. Salisbury, J. M. Stephenson, and One-Stop Shop Evaluation Team. One stop shop versus collaborative integration: what is the best way of delivering sexual health services? Sex Transm Infect, 82(3):202–206, Jun 2006. 16731668[pmid]. [GJS+14] James Gosling, Bill Joy, Guy L. Steele, Gilad Bracha, and Alex Buckley. The Java Language Specification, Java SE 8 Edition. Addison-Wesley Professional, 1st edition, 2014. 73 [Hei] Yoni Heisler. A visual history of netscape navigator. https: //www.networkworld.com/article/2833526/software/ a-visual-history-of-netscape-navigator.html. Geprüft: 16.11.2018. [Hen07] Mike Hendry. Multi-application Smart Cards: Technology and Applications. Cambridge University Press, 2007. [How] David Howard. Eeprom definition. Whatisanelectricalcontact? Ge- prüft: 02.12.2018. [HS99] Michael Hammer and Steven Stanton. How process enterprises really work. Harvard business review, 77:108–18, 216, 11 1999. [HYC+11] Min-Huei Hsu, Ju-Chuan Yen, Wen-Ta Chiu, Shu-Ling Tsai, Chien-Tsai Liu, and Yu-Chuan Li. Using health smart cards to check drug allergy history: The perspective from taiwan’s experiences. Journal of Medical Systems, 35(4):555–558, Aug 2011. [JBo] JBoss. Getting started with wildfly 8. https://docs.jboss. org/author/display/WFLY8/Getting+Started+Guide. Geprüft: 16.11.2018. [JED] JEDEC. integrated circuit (ic). https://www. jedec.org/standards-documents/dictionary/terms/ integrated-circuit-ic. Geprüft: 02.12.2018. [KEN] WILL KENTON. One-stop shop. https://www.investopedia.com/ terms/o/onestopshop.asp. Geprüft: 13.01.2019. [KMN15] Josef Kittler, John C. Mitchell, and Moni Naor. Smart card research and advanced applications. In Lecture Notes in Computer Science, 2015. [Kut13] Beth Kutscher. One-stop shop for care. Modern healthcare, 43(21):6–7, May 27 2013. [LC00] Giovanni Valotti Laura Caccia. Lo sportello unico per le imprese. Una guida in sei mosse. 2000. [Mar] Gary Martin. One stop shop. https://www.phrases.org.uk/ meanings/one-stop-shop.html. Geprüft: 13.01.2019. [McM] Robert McMillan. Is java loosing its mojo? https://www.wired.com/ 2013/01/java-no-longer-a-favorite. Geprüft: 11.11.2018. [MM07] K. Mayes and K. Markantonakis. Smart Cards, Tokens, Security and Appli- cations. Springer US, 2007. 74 [MP02] D.J. Mosley and B.A. Posey. Just Enough Software Test Automation. Just enough series. Prentice Hall PTR, 2002. [MT98] D. Mcelroy and E. Turban. Using smart cards in electronic commerce. Inter- national Journal of Information Management, 18(1):61 – 72, 1998. [oEB] The Editors of Encyclopaedia Britannica. Microprocessor. https://www. britannica.com/technology/microprocessor. Geprüft: 02.12.2018. [Ong04] Edoardo Ongaro. Process management in the public sector: The experience of one-stop shops in italy. International Journal of Public Sector Management, 17(1):81–107, 2004. [Oraa] Oracle. The history of java technology. https:// www.oracle.com/technetwork/java/javase/overview/ javahistory-index-198355.html. Geprüft: 11.11.2018. [Orab] Oracle. JavaTM ee at a glance. https://www.oracle.com/ technetwork/java/javaee/overview/index.html. Geprüft: 16.11.2018. [Orac] Oracle. The java language environment. https://www.oracle.com/ technetwork/java/intro-141325.html. Geprüft: 11.11.2018. [Orad] Oracle. Java platform, enterprise edition (java ee) 8. your first cup: An introduction to the java ee platform. https://javaee.github.io/ firstcup/java-ee001.html. Geprüft: 16.11.2018. [Orae] Oracle. Java virtual machine technology over- view. https://docs.oracle.com/javase/10/vm/ java-virtual-machine-technology-overview.htm# JSJVM-GUID-982B244A-9B01-479A-8651-CB6475019281. Geprüft: 11.11.2018. [Oraf] Oracle. Javaserver(tm) faces specification. https://javaee.github.io/ javaserverfaces-spec/. Geprüft: 16.11.2018. [Orag] Oracle. Oracle java se support roadmap. https://www.oracle.com/ technetwork/java/javase/eol-135779.html. Geprüft: 11.11.2018. [Pri] PrimeTek. Why primefaces. https://www.primefaces.org/ whyprimefaces/. Geprüft: 16.11.2018. [PTM11] Marie-Pier Pelletier, Martin Trépanier, and Catherine Morency. Smart card data use in public transit: A literature review. Transportation Research Part C: Emerging Technologies, 19(4):557 – 568, 2011. 75 [Ran] Brian Randell. Is wildfly right for you? https://www.c2b2.co. uk/middleware-blog/is-wildfly-right-for-you.php. Geprüft: 16.11.2018. [RE10] Wolfgang Rankl andWolfgang Effing. Smart Card Handbook. Wiley Publishing, 4th edition, 2010. [RJ11] G. Radić and S. Jakovljević. Identity management of high education student mobility. In 2011 IEEE 9th International Symposium on Intelligent Systems and Informatics, pages 507–509, Sept 2011. [SP16] Brett St Pierre. Upgrading to a smart öne cardßtudent id. Security Technology Executive, 26(1):28–30, Feb 2016. Copyright - Copyright SouthComm Business Media LLC Feb/Mar 2016; Dokumentbestandteil - Photographs; Zuletzt aktualisiert - 2016-03-31. [Sun] Sun. What is java technology and why do i need it? https: //web.archive.org/web/20100925204716/https://java.com/ en/download/faq/whatis_java.xml. Archiviert: 25.09.2010, geprüft: 11.11.2018. [SWF01] Stefan Stremersch, Stefan Wuyts, and Ruud T Frambach. The purchasing of full-service contracts:: An exploratory study within the industrial maintenance market. Industrial Marketing Management, 30(1):1 – 12, 2001. [Teca] Techopedia. Antenna. https://www.techopedia.com/definition/ 5041/antenna. Geprüft: 02.12.2018. [Tecb] Techopedia. Oracle database (oracle db). https://www.techopedia. com/definition/8711/oracle-database. Geprüft: 16.11.2018. [The] TheIdioms. One stop shop. https://www.theidioms.com/ one-stop-shop/. Geprüft: 13.01.2019. [Tut] Tutorialspoint. Javaserver faces (jsf) tutorial. https://www. tutorialspoint.com/jsf. Geprüft: 16.11.2018. [Tysa] Matthew Tyson. What is the jdk? introduction to the java development kit. https://www.javaworld.com/article/3296360/core-java/ what-is-the-jdk-introduction-to-the-java-development-kit. html. Geprüft: 11.11.2018. [Tysb] Matthew Tyson. What is the jre? introduction to the java runtime environment. https://www.javaworld.com/article/3304858/learn-java/ what-is-the-jre-introduction-to-the-java-runtime-environment. html. Geprüft: 23.11.2018. 76 [Tysc] Matthew Tyson. What is the jvm? introducing the java virtual machine. https://www.javaworld.com/article/3272244/core-java/ what-is-the-jvm-introducing-the-java-virtual-machine. html. Geprüft: 11.11.2018. [VR88] Sandra Vandermerwe and Juan Rada. Servitization of business: Adding value by adding services. European Management Journal, 6(4):314 – 324, 1988. [Wal03] Evon Washington Walters. Editor’s choice: Becoming student centered via the one-stop shop initiative: A case study of onondaga community college. Community College Review, 31(3):40–54, 2003. [WM10] H. Wollmann and G. Marcou. The Provision of Public Services in Europe: Between State, Local Government and Market. Edward Elgar Publishing, Incorporated, 2010. [ZKG13] S.B. Zakhour, S. Kannan, and R. Gallardo. The Java Tutorial: A Short Course on the Basics. Java Series. Pearson Education, 2013. 77