User Story: Besuchernachweis im Covid-19-Kontext

Die Corona-Pandemie führte in Bibliotheken nicht nur zu massiven Umstellungen hinsichtlich digitaler Angebote, auch der Publikumsverkehr ist im Zuge der Wiedereröffnung durch Regelungen neugestaltet. In diesem Zusammenhang müssen einerseits ministerielle Vorgaben zur Nachverfolgung von potentiellen Kontakten beachtet werden und andererseits datenschutzrechtliche Belange. Auch die unkomplizierte Nutzung und zugleich schnelle Erfassung spielen eine hohe Priorität im Kontext eines kontaktarmen, aber durchsatzstarken Betriebes. An der Universitätsbibliothek Magdeburg wurde hier eine Lösung entwickelt, die viele Anforderungen ohne zusätzlichen Ressourceneinsatz abdeckt und zugleich zur Nachnutzung in anderen Einrichtungen zur Verfügung steht. Im vorliegenden Beitrag werden die Anforderungen kurz dargestellt, die im agilen Projektmanagement entwickelte Software beschrieben und Potentiale für eine Nach- und Weiternutzung aufgrund der ersten Betriebserfahrungen aufgezeigt.

1. Ausgangslage

Mit der Corona-Pandemie wurde der Publikumsbetrieb an der Universitätsbibliothek der Otto-von-Guericke-Universität Magdeburg (UB Magdeburg) am 16. März 2020 eingestellt. Damit die Nutzer*innen auch weiterhin Zugang zu den Angeboten der Bibliothek erhalten, wurden unterschiedliche Dienste wie die kontaktlose Ausleihe, digitale Lieferdienste, Chat und – insbesondere für die Lehre – digitale Semesterapparate ausgebaut. Obwohl diese Angebote sehr stark nachgefragt wurden und für das Sommersemester die Lehre vorwiegend von digitalen Formaten bestimmt wird, wurde eine zeitnahe Wiedereröffnung zum frühestmöglichen Zeitpunkt Anfang Mai anvisiert. Insbesondere Studierende, die sich in der Phase ihrer Abschlussarbeit befanden, ersehnten dies. Zugleich wurden von staatlichen Stellen Regeln definiert, um Personenbeschränkungen sowie eine Nachverfolgung von Kontakten im Publikumsbetrieb zu ermöglichen.

Das Bibliothekssystem Magdeburg ist Teil des Gemeinsamen Bibliothekverbundes (GBV) und nutzt im lokalen Bibliothekssystem Barcodes zur eindeutigen Identifikation im Kontext der Nutzerverwaltung, welche auch aus den Nutzerausweisen auslesbar sind. Im Bibliothekssystem sind zudem Adressen und Kontaktinformationen hinterlegt. Mit der Anforderung, dass Bibliotheksbesuche in einem Verzeichnis vier Wochen festgehalten werden müssen und die entsprechenden Kontaktinformationen hinterlegt sind, um eine Wiedereröffnung zu ermöglichen, wurde mit Methoden der agilen Softwareentwicklung ein Tool zur Nutzerdatenerfassung durch die Abteilung IT-Anwendungen entwickelt, das im Folgenden vorgestellt wird.

Die Abteilung IT-Anwendungen der UB Magdeburg ist für den Betrieb des lokalen Bibliotheksystems, für die Infrastruktur und die technischen Belange im Haus sowie für den Zugang zu elektronischen Medien verantwortlich. Dabei kann die Abteilung durch ein heterogen aufgestelltes Team eine breite Anforderungspalette abdecken. Drei Mitarbeiter verfügen u.a. über Java-Programmiererfahrungen.

2. Anforderungen an den Besuchernachweis

Basisanforderung an die zu entwickelnde Lösung ist die Umsetzung der gesetzlichen Regelungen im Kontext der Corona-Pandemie, d.h.

• die Ermittlung der derzeitigen Personenzahl im Gebäude im Verhältnis zur zulässigen Gesamtzahl,
• die Möglichkeit, auf Aufforderung des Gesundheitsamts eine Liste von möglichen Kontaktpersonen sowie deren Kontaktdaten im Falle einer Corona-Infektion eines*r Nutzer*in zu erstellen sowie
• ein möglichst kontaktarmer Betrieb unter Gewährleistung des Sicherheitsabstandes.

Zusätzlich zu diesen funktionalen Anforderungen müssen jedoch auch andere Aspekte berücksichtigt werden, um einen reibungslosen Betrieb zu gewährleisten. Diese betreffen insbesondere die Aspekte des Datenschutzes, der Benutzbarkeit sowie der Zuverlässigkeit.

Auch in pandemischen Zeiten sollten die Grundsätze der Datensparsamkeit und des Datenschutzes nicht ignoriert werden,1 insbesondere wenn es sich um Kontaktdaten wie Post- und Mailadressen handelt, welche missbraucht werden könnten.2 Daher wurde die Anforderung gestellt, die Sichtbarkeit dieser Informationen für besuchende Personen und das Sicherheitspersonal einzuschränken, idealerweise durch die Nutzung von Pseudonymen. Eine Liste von Kontaktdaten sollte im Idealfall nur nach Aufforderung durch das Gesundheitsamt erstellt werden und nach Abgabe bzw. gemäß den rechtlichen Regeln gelöscht werden.

Als wichtige Anforderung an die Benutzbarkeit wurde identifiziert, dass die Lösung von Sicherheitspersonal ohne IT-Erfahrungen und ohne besondere Schulung intuitiv bedient werden kann. Damit soll zugleich eine möglichst hohe Qualität der erfassten Daten sichergestellt werden. In diesem Kontext stellt auch die Aufrechterhaltung des Betriebes im Falle von technischen Störungen, fehlerhafter Bedienung oder anderen Fehlerquellen eine wichtige Anforderung dar.

Weiterhin musste eine Lösung in kurzer Zeit entwickelt werden und, da Lieferzeiten möglicherweise notwendiger Hardware infolge der Pandemie stark gestiegen sind, mit den vorhandenen Ressourcen umsetzbar sein. Um auf neue Entwicklungen im gesetzlichen Kontext und auf Anwenderfeedback reagieren zu können, mussten Änderungen zeitnah von allen beteiligten Entwicklern umsetzbar sein. Daher wurde eine agile Vorgehensweise für das Entwicklungsprojekt angewandt3 und als Framework Java4 gewählt.

3. Lösungsalternativen

Nachdem die Anforderungen an eine Lösung zur Einlasskontrolle aufgestellt waren, wurden zunächst verschiedene Lösungen anderer Bibliotheken gesucht. Aufgrund der sehr frühen Wiedereröffnung und der Kurzfristigkeit konnte jedoch keine einsetzbare Lösung identifiziert werden. Teilweise wurde der Zutritt durch Voranmeldung (per eMail oder Telefon) ermöglicht, was in der UB Magdeburg bereits während des kontaktarmen Basisbetriebs für die kontaktlose Ausleihe angewandt wurde. Dieses Vorgehen ist zur Erfüllung der Anforderungen aber nicht ausreichend. Daher mussten Lösungsalternativen eigenständig erarbeitet werden. Diese unterscheiden sich vor allem im Ausmaß der technischen Integration in das bestehende Bibliothekssystem.

Als erste Alternative wurde ein Buch mit handschriftlichen Kontaktdaten identifiziert. Diese Lösung erfordert keine technische Umsetzung und wäre daher sofort einsatzbereit unter Nutzung minimaler Ressourcen. Großer Nachteil dieser Lösung ist jedoch die Qualität der angegebenen Daten: Um hier Falschangaben zu vermeiden, müsste das Sicherheitspersonal die Kontaktdaten, z.B. auf Basis des Personalausweises, kontrollieren. Im Sinne des kontaktarmen Betriebes stellt dies daher keine wirkliche Alternative dar. Da alle Kontaktdaten im Klartext sichtbar sind, kann ein Missbrauch durch andere Nutzer*innen nicht ausgeschlossen werden. Im Sinne der Zuverlässigkeit müsste die Liste regelmäßig kopiert werden, damit die Informationen nicht verloren gehen.

Als weitere Alternative wurde ein Einsatz einer Kamera zum Fotografieren der Nutzerausweise kurz diskutiert, da hierbei Fehler durch zusätzliche Informationen (Name und Matrikelnummer) reduziert werden können. Jedoch ist einerseits keine Hardware im Sinne des kontaktarmen Betriebes momentan vorhanden und andererseits werden bei diesem Vorgehen mehr Daten als unbedingt notwendig erhoben und gespeichert. Eine reine Zählung durch eine Kamera hingegen führt nicht zur Identifikation der Nutzer*innen, auch wenn hierbei kein Personaleinsatz notwendig wäre. Weiterhin wurde ein vollständig in das Bibliothekssystem integrierter Funktionsschirm in Betracht gezogen, ähnlich des Betriebes an den Ausleihtheken. Dies hätte den Vorteil, dass Barcodes der Nutzerkarten zur Identifikation genutzt werden können und der (echtzeit-aktuelle) Adressdatensatz im System sichtbar wird. Aufgrund des professionellen Betriebs des Bibliothekssystems wäre auch die Zuverlässigkeit garantiert. Als Hauptnachteil sei hier jedoch die Komplexität der Entwicklung genannt, da hier eine Änderung des Datenmodells zur Erfassung der Nutzungszeiten für jede*n Nutzer*in erforderlich wäre sowie eine Schulung des Sicherheitspersonals. Gegenüber der handschriftlichen Lösung wären Kontaktdaten nicht für die Nutzer*innen sichtbar, jedoch für das Sicherheitspersonal. Als technische Grundvoraussetzung muss dabei ein Netzwerkanschluss für das Zielsystem eingerichtet werden, was sich in der UB Magdeburg aus baulichen Gründen schwierig gestaltet.

Aufgrund dieser Komplexität, welche nicht in der kurzen Zeit bewältigt werden konnte, wurde eine Lösung angestrebt, welche die Vorteile der obigen Alternativen möglichst ohne deren Nachteile verbindet. Im Bibliotheksmanagementsystem liegen die Kontaktdaten im System vor, die über die Barcodes der Benutzungskarten identifiziert werden können. Die Benutzungsordnung der UB legt dabei fest, dass man als Nutzer*in angemeldet sein muss. Somit spricht in diesem Fall nichts gegen eine vollständige Trennung von Identifikationsschlüsseln (Barcodes) und Kontaktdaten, welche nur im Bedarfsfall aufgelöst wird. Zur Erfassung der Ein- und Ausgänge kann daher eine einfache Tabelle, z.B. in MS Excel, genutzt werden.

Eine direkte Verbuchung der Ein- und Ausgänge in einer Excel-Tabelle hat jedoch den Nachteil, dass das Sicherheitspersonal in dieser Tabelle arbeiten muss und Fehleingaben oder unbeabsichtigte Löschung nicht ausgeschlossen werden können. Die Fehleranfälligkeit wird in diesem Zusammenhang als sehr hoch eingeschätzt. Auch weitere wichtige Angaben wie die Zeit oder die Unterscheidung auf Ein- oder Ausgang müssen händisch in der Tabelle pro Buchung festgehalten werden.

Daher wurde die Entscheidung für ein Stand-Alone-Tool getroffen, welches mit möglichst geringer Komplexität das Personal nicht überfordert und flexibel erweiterbar ist, um zugleich gesammelte Erfahrungen aus dem Betrieb in die Weiterentwicklung einfließen zu lassen. Durch die Loslösung vom Bibliothekssystem kann kein Echtzeit-Abgleich mit dem Datenbestand durchgeführt werden, jedoch ermöglicht die geringe Komplexität sowie die freie Technologiewahl eine schnelle Umsetzung und Einführung der Lösung.

4. Konzept und Umsetzung

Als Hardware für den Einsatz des Programms standen in der UB Magdeburg Windows-10-Rechner zur Verfügung. Als Haupteingabegerät wurde ein Touchscreen angeschlossen, um eine möglichst intuitive Bedienung zu ermöglichen. Für den kontaktarmen Betrieb konnte ein Barcode-Scanner im „Hands-Free-Modus“ genutzt werden. Wegen der oben erwähnten baulichen Einschränkungen befindet sich der Rechner nicht im Netzwerk der UB Magdeburg.

Zur näheren Erläuterung soll an dieser Stelle zunächst das entwickelte Konzept für den Einsatz der Lösung anhand der Abbildung 1 vorgestellt werden, bevor auf die Umsetzung der einzelnen Anforderungen eingegangen wird.

Abb. 1: Setup der Anwendung

Nutzer*innen werden zunächst nur einzeln eingelassen. Daraufhin scannen sie ihren Nutzerausweis, dessen Barcode dann durch das Programm erfasst wird, und die Bibliotheksbenutzung ist nach Klick des Sicherheitspersonals auf „Rein“ registriert (vgl. Abbildung 2). Sollte der Ausweis nicht vorliegen, ungültig sein oder ist die maximale Nutzeranzahl erreicht, so wird das Sicherheitspersonal durch die Anwendung entsprechend textuell informiert. Beim Verlassen der Bibliothek ist der Vorgang analog. Ein Scannen des Barcodes erfolgt durch die Nutzer*innen und das Verlassen wird in der Anwendung registriert (Klick auf „Raus“).

Abb. 2: Screenshot des Programms

Die Ein- und Ausgänge der Nutzer*innen werden dabei in einer Tabellenstruktur dokumentiert. In Tabelle 1 ist das Format dieser Tabelle beispielhaft illustriert. Bei jeder Interaktion wird dabei der Zeitstempel sowie (abhängig vom Klick des Sicherheitspersonals) Ein- und Ausgang eines Barcodes dokumentiert. So repräsentiert jede Zeile eine Nutzerinteraktion (entweder Ein- oder Ausgang)

Tabelle 1: Ausgabeformat der gespeicherten Barcodes für jeden Tag

Zeitstempel	Eingang	Ausgang
20.05.2020 08:03:01	Barcode1
20.05.2020 08:05:32	Barcode2
20.05.2020 08:17:57		Barcode1
TT.MM.JJJJ HH:MM:SS	Barcode [entweder hier]	[oder hier]

Im Kontext der agilen Softwareentwicklung wurden zunächst etappenweise Ziele definiert, umgesetzt und getestet (Entwicklungsiteration), um eine erste Version zur Wiedereröffnung einsatzfähig zu haben.5 Für jede Erweiterung bzw. Korrektur des Programms wird eine neue, komplette Entwicklungsiteration durchgeführt, bevor diese in den Einsatz überführt wird (Spiralmodell6). Weiterhin wurden etablierte Design-Prinzipien des Software-Engineerings, neben Objektorientierung insbesondere Separation of Concerns mit Hilfe des MVC-Architekturmusters,7 eingesetzt, um die Wartbarkeit, Wiederverwendbarkeit und Erweiterbarkeit der Lösung durch alle beteiligten Entwickler sicherzustellen. Zur Erhöhung der Robustheit wurde festgelegt, erfasste Informationen nicht ausschließlich im Speicher zu halten, sondern direkt physisch mit einer CSV-Ausgabe-Datei für jeden Tag zu synchronisieren. Somit werden die erfassten Daten persistent auf der Festplatte gespeichert und sind vor Verlust durch System- oder Anwendungsabstürze geschützt. Weiterhin werden diese Daten, sofern vorhanden, beim erneuten Start der Anwendung wieder in den Speicher geladen, was eine unterbrechungsfreie und konsistente Fortsetzung der Erfassung ermöglicht.

Dies ermöglicht es darüber hinaus, Änderungen während des Betriebes direkt umzusetzen. Dafür wurde die Parametrisierung des Programms, soweit sinnvoll, in eine Konfigurationsdatei ausgelagert, die bei Neustart des Programms eingelesen wird. Dort wurden Parameter gekapselt, wie die maximal zulässige Personenzahl. Bei größeren Änderungen wird die ausführbare JAR-Datei einfach ersetzt, idealerweise außerhalb der Öffnungszeiten.

Um eine Freigabe des entwickelten Tools hinsichtlich der Nutzung durch die beauftragte Person für den Datenschutz zu erhalten, wurde diese frühzeitig mit einbezogen. Hier wurde ein Dokument erstellt, das das Programm beschreibt und die wichtigen erfassten Daten benennt. Eine Freigabe der Nutzung durch den Datenschutzmanager konnte dadurch in kurzer Zeit erfolgen.

In Tabelle 2 ist eine Übersicht der wichtigsten Anforderungen und ihrer technischen Umsetzung dargestellt.

Tabelle 2: Anforderungen und ihre Umsetzung

Anforderung	Umsetzung
Anzahl Nutzer*innen im Haus	Zählmatrix getrennt nach Eingang und Ausgang
Kontaktliste	Nach Aufforderung per Bibliothekssystemabfrage
Kontaktarmer Betrieb	Hands-Free-Scanner, Abstandsregeln
Benutzbarkeit	Minimale Interaktion, intuitive Benutzung
Datenschutz	Trennung Daten und Pseudonyme (Barcodes), keine Netzwerkverbindung
Zuverlässigkeit	Datenpersistenz auf Dateisystemebene (Speichern) und minimale Logik
Schnelle Umsetzung	Nutzung vorhandener Hardware und Java, Konfigurationsdatei

5. Weiterentwicklung im agilen Kontext

Durch den Einsatz der Lösung, insbesondere in Zusammenarbeit mit dem Personal, das die Software nutzt, konnten Erfahrungen und Herausforderungen für die Weiterentwicklung gesammelt und priorisiert werden. In unserem Fall zeigte sich zunächst die Herausforderung, dass nicht alle Nutzer*innen eine Karte mit Barcode (insbesondere externe Personen) besitzen, da die Bibliothek nur als Arbeitsplatz genutzt wurde. Hier musste ein Prozess etabliert werden, dass sich diese Personen zunächst als Nutzer*innen an der Ausleihtheke registrieren müssen und erst danach durch Einscannen der erworbenen Karte erfasst wurden.

Aufgrund datenschutzrechtlicher Vorgaben werden die Daten der Nutzer*innen nach bestimmten Kriterien der Inaktivität aus dem Bibliothekssystem gelöscht (z.B. abgelaufene Mitgliedschaft oder keine Ausleihen). Dies führte jedoch im Kontext der im vorigen Absatz erwähnten Nutzung zu Personen, hier insbesondere Studierende, welche einen Barcode auf der Studierendenkarte besitzen, deren Kontaktdaten im Bibliotheksmanagement jedoch gelöscht wurden. Hier musste das Tool um eine Prüfung des Barcodes im Vergleich zum Datenbestand aller registrierten Barcodes erweitert werden. Dieses Feature wurde in einer weiteren Entwicklungsiteration umgesetzt, getestet und eingeführt. Dabei wird vor Öffnung der Bibliothek jeden Tag eine Liste aller „bekannten“ Barcodes im Bibliotheksmanagementsystem erstellt. Beim Scannen erfolgt dann ein Abgleich mit dem Barcodebestand und gegebenenfalls ein Hinweis auf unbekannte Barcodes. Auch hier werden die Nutzer*innen zunächst an die Ausleihtheke gebeten, um ihre Daten zu vervollständigen.

Eine weitere Herausforderung ist die Ausstellung neuer Karten mit neuen Barcodes durch Verlustmeldung der Nutzenden. Bisher wurden die alten Barcodes im System einfach ersetzt. Dies musste im Zuge der Erfassung ebenfalls geändert werden, nun werden die bisherigen Barcodes im lokalen Datenfeld „Alte Benutzernummer“ gepflegt, um die Rückverfolgbarkeit auch bei Kartenwechsel zu gewährleisten.

Nach den ersten Erfahrungsberichten des Sicherheitspersonals wurde vor allem darauf hingewiesen, dass eine Diagnosemöglichkeit durch den*die Anwender*in zunächst nicht bestand. Gemeint ist hier die Information, ob ein bestimmter Barcode bereits im Haus registriert ist, um doppelt gezählte Ein- und Ausgangvorgänge zu vermeiden. Die Anzeige dieser Information konnte in einer weiteren Entwicklungsiteration umgesetzt, getestet und eingeführt werden.

Eine andere Idee für die Weiterentwicklung des Tools besteht in der automatischen Erfassung, ob ein Ein- oder Ausgang vorliegt. Während dies das Sicherheitspersonal bei der Bedienung entlasten würde, wurden jedoch auch Nachteile festgestellt, insbesondere in der Fehlerbehandlung. Trotz gewissenhafter Prüfung ist es an einigen Tagen nicht gelungen, alle Ein- und Ausgangvorgänge konsistent zu erfassen. Daher wurde die Entwicklung dieses Features zunächst nicht weiterverfolgt.

6. Nachnutzung

Mittlerweile wurden wir bereits von weiteren Bibliotheken angesprochen, ob eine Nutzung des Tools möglich ist. Die modulare Gestaltung sowie die hohe Parametrisierbarkeit der Lösung erleichtern die Weitergabe der Lösung im gleichen Kontext ungemein. In diesem Zusammenhang wurde eine weitere Entwicklungsiteration durchgeführt, um beliebige Barcodes durch einen parametrisierbaren regulären Ausdruck zu unterstützen.

Zudem können die Daten statistisch analysiert werden, um eine Entscheidungsbasis für flexible Entscheidungen z.B. für die Vermeidung von Warteschlangen o.Ä. zu bieten. Im Sinne des Datenschutzes werden dabei solche Analysen nur auf einer anonymisierten Datenbasis durchgeführt. Die Anonymisierung wird für jeden Tag separat durchgeführt, sodass sich die Interaktionen beliebiger Nutzer*innen zwar über einen Tag, aber nicht über mehrere Tage verfolgen lässt (um eine Personenbeziehbarkeit zu erschweren).

Um die Bibliotheksleitung täglich über das Nutzungsverhalten zu informieren, werden in der UB Magdeburg folgende Werte täglich berichtet:

• Zahl der Ein- und Ausgänge: diese ist vor allem Indikator für die Belastung des Sicherheitspersonals, da diese bei jeder Interaktion reagieren müssen.
• Maximale Anzahl der Personen im Haus: diese Metrik lässt zunächst nachvollziehen, dass die gesetzlichen Vorgaben in Pandemiezeiten erfüllt werden, weiterhin kann die Obergrenze bei Bedarf angepasst werden. Im Falle der UB Magdeburg wurde diese Obergrenze zunächst auf 100 Personen gesetzt und im Laufe der ersten zwei Wochen auf 200 Personen erhöht, um Warteschlangen zu vermeiden.
• Anzahl der unterschiedlichen Nutzer*innen eines Tages: diese Information dient der Ermittlung des eigentlichen Service-Bedarfs.
• Zahl der Personen im Haus eine Stunde vor Schließung: diese Metrik wird genutzt, um den Bedarf von längeren Öffnungszeiten abzuschätzen (bisher reduziert von 8-17 Uhr).

7. Fazit

Die Corona-Pandemie hat unsere gesamte Gesellschaft in tiefgreifende Veränderungen gestürzt, die auch Bibliotheken vor Herausforderungen gestellt haben. Nach der vorübergehenden Schließung der UB Magdeburg konnte eine Wiedereröffnung nur unter strengen Auflagen erfolgen, welche die Zählung der Nutzer*innen genauso beinhalten wie die Erstellung von Kontaktlisten für den Infek­tionsfall. In diesem Beitrag wird die Auswahl und Entwicklung einer IT-Lösung beschrieben, die diese Auflagen ohne größeren Ressourceneinsatz umsetzt.

Hierbei stellte vor allem die kurze Entwicklungszeit eine große Herausforderung dar. So musste eine Lösung geplant, konzipiert, umgesetzt und getestet werden, welche im Betrieb zuverlässig und auch durch nicht IT-affines Personal bedienbar ist sowie den Datenschutz beachtet.

Daher wurde in einem agilen Entwicklungsprozess eine Java-Anwendung implementiert, welche in der kurzen Zeit umsetzbar war und dabei viele Vorteile gegenüber einer nicht-technischen Lösung vorweist, wie z.B. die eingeschränkte Sichtbarkeit von Kontaktdaten sowie die Vermeidung von Oberflächenberührungen. Die agile Methode erlaubte es, die Lösung nicht als final zu betrachten, sondern aus den Erfahrungen der ersten Betriebstage zu lernen und das Programm dementsprechend weiterzuentwickeln, ohne dass die Stabilität des Betriebs verletzt wurde. Weiterhin konnte auf der vorliegenden Datenbasis parallel eine Adaptivität für das Besuchermanagement erfolgen, z.B. durch bedarfsorientierten Personaleinsatz.

Als Erfolgsfaktoren für die Lösung können insbesondere die frühzeitige Einbindung aller berührten Interessensgruppen (Bibliotheksleitung, Entwickler, Sicherheitspersonal, Datenschutzbeauftragte, Thekenpersonal, Nutzer*innen) sowie das agile Vorgehensmodell, welches große Flexibilität in der Entwicklung und einen stabilen Betrieb verbindet, benannt werden.

Sollten Sie Interesse an der entwickelten Lösung haben, wenden Sie sich gerne an die Autoren. Die Software wurde unter Open Source gesetzt8 und kann daher von anderen Einrichtungen flexibel eingesetzt und weiterentwickelt werden, siehe hierzu auch GitHub9.

Literaturverzeichnis

–Balzert, Helmut: Lehrbuch der Software-Technik, Heidelberg u.a. 1998 (Lehrbücher der Informatik 2).

–Gamma, Erich: Design patterns. Elements of reusable object-oriented software, Boston 2002²⁵ (Addison-Wesley professional computing series).

–Kim, Gene; Humble, Jez; Debois, Patrick u.a.: The DevOps handbook. How to create world-class agility, reliability, & security in technology organizations, Portland, OR 2016.

–Meyer, Albin: Softwareentwicklung. Ein Kompass für die Praxis, Berlin 2018.

–Stiftung Datenschutz: Dateneigentum und Datenhandel, Berlin 2019 (DatenDebatten).

–Verordnung (EU) 2016/679 des europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung), 2016.

Veit Köppen, Universitätsbibliothek Magdeburg

Sascha Bosse, Universitätsbibliothek Magdeburg

Christian Schulz, Universitätsbibliothek Magdeburg

Zitierfähiger Link (DOI): https://doi.org/10.5282/o-bib/5609

Dieses Werk steht unter der Lizenz Creative Commons Namensnennung 4.0 International.