Skip to content. | Skip to navigation

Citation and Metadata
Document Actions
Full Text

1. State of the Art

Nahezu alle Hochschulen in Deutschland besitzen bereits erste pilothafte Eigenentwicklungen von Studierenden-Apps. Tatsächlich zeigt der regelmäßige Vergleich mit anderen Hochschulen gerade im Arbeitskreis Web in der ZKI, in dem die Webverantwortlichen von ca. 50-60 Hochschulen regelmäßig aktuelle Entwicklungen an ihren Einrichtungen diskutieren, dass die teilweise sehr unsystematische Herangehensweise an diesen neuen Kommunikationskanal zu den Studierenden (und gegebenenfalls auch zu den Mitarbeitern) erhebliche Unsicherheiten und einen gewissen Wildwuchs nach sich ziehen. Zum einen gibt es gerade an größeren Universitäten mit tendenziell technischer (MINT) Orientierung oft eine Vielzahl paralleler App-Entwicklungen, die allerdings zumeist jeweils nur eine bestimmte Serviceleistung der Hochschule oder des mit dieser verknüpften Studentenwerks abbilden. Uns sind Hochschulen bekannt, die 8 bis 10 proprietäre App-Parallelentwicklungen bereitstellen. Es gibt da dezidierte Apps für den Hochschulsport, für das Studienmanagement, für die Mensa, Apps vom AStA der jeweiligen Universität, Bibliotheken-Apps usw. All diese Apps weisen unterschiedliche Entwicklungsgrade auf und werden unterschiedlich intensiv gepflegt und weiterentwickelt. Gerade für Studienanfänger an diesen Hochschulen ist es dabei schwer, die für sie jeweils richtige App aus dem Hochschulangebot zu finden.

Es zeigt sich gerade angesichts dieser bisweilen wuchernden und unsystematisch koordinierten Entwicklungen, dass viele Universitäten nach einer Struktur oder einem Verbund suchen, mit dem zusammen sie eine zentrale App – herausgegeben vom jeweiligen Rechenzentrum oder Medienzentrum mit zentraler Koordination und Pflege der Daten – entwickeln können. Konzepten zur Übertragbarkeit von Daten, zur Standardisierung von Diensten und daran geknüpften Datenströmen und für ein individuelles Studierenden-Portfolio, das ein Studierender von einer App in die App einer anderen Universität übernehmen kann, wird eine hohe Aufmerksamkeit zu Teil. Gerade vor diesem Hintergrund stellt das hier beschriebene Projekt „Generisches Framework Studi-App“ ein wichtiges und zukunftssicheres Konzept und Vorhaben für die deutsche Hochschullandschaft dar.

2. Situation und Idee

Das Studium an deutschen Hochschulen erfordert vom Studierenden ein Höchstmaß an Disziplin und Selbstorganisation, um neben dem eigentlichen Wissensaufnahmeprozess die vielfältigen Studien-Management-Aufgaben optimal ausfüllen zu können.

Es gilt daher, den Studierenden Software-Werkzeuge für ein möglichst einfaches und effizientes Management des Studiums an die Hand zu geben. Apps stellen hierbei zeitgemäße Mensch-Maschine-Schnittstellen für die „Digital Natives“, die moderne, mobile Studierendengeneration des beginnenden 21. Jahrhunderts dar.

Für die Hochschulen steht im Mittelpunkt des Interesses, dass es eine zentrale Einrichtung gibt, die für Konzeption, Projektierung und Produktion der App-SW sowie für die Kanalisierung der über die App weitergereichten Informationen zuständig ist. Häufig fällt dabei die Wahl auf die Rechen- und Medienzentren der Hochschulen. Hierbei ist eine gewisse Eile geboten. Aufgrund des hohen Bedarfes an mobilen Werkzeugen zum persönlichen Studienmanagement zeigen sich an zahlreichen Hochschulen bereits Tendenzen, dass eine Vielzahl proprietärer App-Entwicklungen von Einrichtungen, Lehrstühlen und selbstberufenen Unistrategen produziert und mit in der Regel schlecht abgestimmter Gesamtkonzeption an mannigfaltige Zielgruppen und Interessenten der Hochschule adressiert werden. Das hinterlässt beim Außenstehenden oftmals ein zerrissenes, inhomogenes Bild der entsprechenden Organisation.

Weiterhin zeigt sich im Vergleich einiger exemplarisch analysierter Einzelapp-Entwicklungen von Hochschulen aus dem unten skizzierten Verbund, dass die Möglichkeiten der mobilen Endgeräte an einzelnen Einrichtungen zum Aufbau neuer Lern- und Verwaltungsprozesse einschließlich einer komplexen, mehrdimensionalen Kommunikationskultur geführt haben – hier kann ein nachhaltiger Wissenstransfer zwischen den im hier skizzierten Verbundprojekt organisierten Hochschulen zu gänzlich neuen Wissensvermittlungsszenarien und zu optimierten Kommunikations- und Ausbildungsstrategien führen.

Mit der Vision eines gemeinsamen Entwicklungsprojektes zur Planung, Projektierung, Entwicklung und zur langfristigen Betreuung und Pflege eines generischen Frameworks mit standardisierenden Konzepten und Verfahren als Middleware und darauf aufbauendem App-Baukasten und exemplarischen App-Prototypen organisiert und konzipiert seit Oktober 2012 eine stetig wachsende, heute ca. 30 Hochschulen in ganz Deutschland umfassende Arbeitsgruppe im Arbeitskreis Web der ZKI (Zentren für Kommunikation und Information, der Zusammenschluss der Rechen- und Medienzentren aller Hochschulen und außeruniversitärer Forschungseinrichtungen in Deutschland) ein großes, überregionales Studienmanagement-App-Projekt.

Geplant als dezentrales, über viele Hochschulstandorte in Deutschland verteiltes Communityprojekt mit Schnittstellen-zentrierten, spezialisierten Entwicklungszentren können damit vielfältige Synergien einer modular-verteilten Entwicklungsstrategie genutzt, Wissenstransferprozesse koordiniert und gefördert sowie redundanzvermeidende Anpassungsprozesse bei der Erstellung einer Kombination aus generischem Framework und spezialisierten Apps mit vielfältigen Schnittstellen zu Campus-Management-Systemen und wissenschaftlichen Infrastrukturen etabliert werden.

2.1 Zielgruppen

Zentrale Zielgruppe sind die Studierenden der jeweiligen Universität, denen mit einer App für mobile Endgeräte (Smartphones, Tablets) ein Studien-Verwaltungs-Werkzeug an die Hand gegeben wird, das nicht nur als zentrale Informations- und Kommunikationsplattform für den Unialltag fungiert, sondern daneben auch mit Funktionalitäten wie einem persönlichen Studien-Portfolio und mit Werkzeugen für das mobile Lernen ausgestattet ist. Es steht zu erwarten - erste Erfahrungen an beteiligten Hochschulen, die schon Apps für Studierende eingeführt haben, belegen dies auch - dass die entsprechenden Apps nicht nur von Studierenden sondern auch von Mitarbeitern und - ein gutes Rollenmanagement vorausgesetzt - von Gästen und Besuchern der jeweiligen Hochschulen genutzt werden wird. Die schon heute abschätzbaren Auswirkungen auf Lehre, Forschung und Verwaltung sind bedeutend. Durch konzipierte „Feedback-Funktionen“ aus den Apps in zentrale Komponenten der Middleware hinein können beispielsweise Raumänderungen oder Technikprobleme viel schneller und unmittelbarer von den Nutzern der Apps an die entsprechenden Ansprechpartner und Mittler in der jeweiligen Einrichtung kommuniziert werden. Durch den mobilen Zugriff auf zentrale Studierendenwerkzeuge (wie beispielsweise Funktionalitäten zur Prüfungsanmeldung) können Wartezeiten in zentralen Studierenden-Betreuungseinrichtungen (Helpdesk, Imma-Amt, IB, …) reduziert werden. Und mit gänzlich neuen mobilen Lernszenarien wie dem an der Uni Hohenheim bereits realisierten Modell der „Lernorte“ können innovative, die Hochschullehre verbessernde Methoden in den Hochschulalltag eingebaut werden.

3 Projektziele

Kerngedanke des hier vorgestellten Projektes ist es, eine umfassende Sammlung typischer Funktionalitäten, die Studierende in ihrem individuellen Studienverlauf an ihrer jeweiligen Hochschule benötigen und nutzen zusammenzutragen, die dahinterliegenden Dienste zu systematisieren und zu formalisieren, ein einheitliches Daten- und Zugriffsmodell für Dienste, Kommunikationskanäle, Inhalte und Datenströme zu entwickeln und Richtlinien für entsprechende Endbenutzerwerkzeuge (browserbasierter Zugriff, eigenständige Programme für typische PC-Systeme, insbesondere Apps für den mobilen Zugriff) zu veröffentlichen und unispezifische Apps für den mobilen Zugriff der Studierenden auf eine breite Palette von Studienmanagementfunktionen zu gewährleisten..

Damit ist sichergestellt, dass...

... Studierende auch an anderen Hochschulstandorten Zugriff auf die Services der entsprechenden Uni sowie auf die Angebote ihrer Heimatuni haben (generische, standardisierte Services)

... Hochschulen vom Ideenpool anderer Hochschulen angesichts vielfältiger Einsatzszenarien mobiler Anwendungen profitieren (Synergie)

... die Entwicklungskosten für die einzelne Hochschule überschaubar bleiben (Shared Development, Costsharing)

... bestimmte personalisierte Studienverlaufsinformationen, Noten, Lernunterlagen und persönliche Notizen in einem standardisierten Ablageverfahren realisiert werden können (E-Portfolio), das einerseits optimale Datensicherheit und den Datenschutz des Individuums garantiert, andererseits dem Studierenden auch einen Studienortwechsel unter Beibehaltung und Weiterpflege seines persönlichen Datensatzes garantiert.

3.1 generische, standardisierte Angebote

Ein zentrales Projektziel stellt die Standardisierung von Angeboten und Dienstleistungen an einer möglichst großen Zahl von Hochschulen dar. Durch die Konzeption und präzise Planung einer Middleware - bestehend aus einem leicht programmier- und erweiterbaren CMS (z.B. Drupal) und vielfältigen Schnittstellen zu Hochschul-Standard-Software (wie Campus-Management-Systemen, elektronischen Katalogen usw.) zusammen mit einem einheitlichen Daten-/Metadatenmodells für unterschiedliche Angebote der verschiedenen Hochschulen (z.B. könnte festgelegt werden, dass Mensen ihre Speisepläne immer in einem aus Excel heraus exportierbaren, einheitlichen XML-Format bereitstellen) kann gewährleistet werden, dass unterschiedliche Apps verschiedener Hochschulen auf einen in weiten Teilen einheitlichen Datensatz auch an anderen Einrichtungen des Verbundes zurückgreifen können. Damit besteht die Möglichkeit für den Studierenden, mit der ihm vertrauten App seiner Heimathochschule in anderer Rolle (z.B. Studi-Gast) auch auf Angebote und Informationsdienste anderer Hochschulen zugreifen zu können, sobald er mit seinem mobilen Endgerät auf das WLAN-Netz dieser Institutionen zugreift.

Diese generische Architektur der Middleware, die die vielfältigen Studierenden-Management-Daten typischer Hochschul-Software aufbereitet und zusammen mit Informations- und gegebenenfalls Kommunikationsströmen in ein standardisiertes Ausgabeformat überführt, ist u.a. auch Grundlage für das weiter unten beschrieben E-Portfolio in den Apps für die Studierenden. Durch standardisierte Daten-/Metadaten-Ströme kann ein Studierender ein E-Portfolio in seiner persönlichen App-Umgebung pflegen und von einer Hochschule zu einer anderen (siehe weiter unten, Abschnitt ShowCase) migrieren.

3.2 Synergie

Der zweite zentrale Aspekt des hier skizzierten Projektes ist der Wissenstransfer zwischen den im Projekt organisierten Hochschulen. Mobile Plattformen (Smartphones und Tablets) in Verbindung mit mobilen Studienmanagement-Apps sind eine relativ neue Methode der Studienverwaltung für Wissensanbieter (die Hochschulen) wie auch für Lernende, die zahlreiche, bisher nur in Ansätzen konzipierte und erprobte Lerntechniken und Studienoptimierungsmöglichkeiten erlaubt. Zwei Beispiele mögen dies erläutern.

In der Uni Hohenheim-App, deren Konzepte neben anderen Einzelprojekten als Best-Practice-Szenario in das hier vorgestellte Verbundprojekt einfließen wird (siehe Kapitel 5.4 Nutzung von Pilotvorhaben), wurden Werkzeuge zur Navigation innerhalb der Universität (Hörsaalfinder, Einblenden von Navigationspfeilen in das von der Smartphone-Kamera aufgenommene Bild unter Nutzung der GPS-Technik des Gerätes) von findigen Hochschullehrern als neue Form eines navigierenden E-Learnings eingesetzt. Ein Professor kann damit Objekte auf dem weitläufigen Uni-Campus (bestimmte Gattungen von Bäumen, Sträuchern, Tieren etc.) markieren und seine Studierenden anhand der GPS Koordinaten auf eine Entdeckungsreise zu den besprochenen Lernzielen schicken.

Das an der TU-Berlin entwickelte, Browser-basierte Studierenden-Portal myDESK nutzt seine Anbindung an HIS-LSF dahingehend, dass Studierende nicht nur ihre persönlichen Stundenpläne automatisiert um Vorlesungszeiten ergänzen können, sondern auch, um Informationen über Veranstaltungsort-Änderungen oder defekte Geräte etc. an die zentrale Middleware zurückzumelden und damit für eine viel schnellere und effizientere Benachrichtigung von Mitstudenten zu sorgen (Feedback-Kanal). Auch die TU Berlin hat das Interesse erklärt, die in myDESK entwickelten Konzepte zu Strukturen, Programmen, Methoden und Schnittstellenimplementierungen in das hier vorgestellte Großprojekt "Generisches Framework Studi-App" geeignet einzubringen.

Die Beispiele zeigen, wie der große Verbund von Hochschulen, die in dem hier vorgestellten Projektverbund eine gemeinsame Entwicklung für eine generische Middleware und darauf aufsetzende Studierenden-Apps voranbringen wollen, von den Erfahrungen anderer Einrichtungen lernen und Konzepte mit nutzen und gegebenenfalls für ihre individuellen Ausbildungsschwerpunkte weiterentwickeln können.

3.3 Shared Development, Costsharing

So vielfältig einerseits die Anforderungen und Studienregularien an verschiedenen Hochschulen sind, so zahlreich sind andererseits auch Gemeinsamkeiten bei vergleichbaren Verwaltungs- und Kommunikationsstrukturen im Verhältnis zwischen den Hochschulen und ihren Studierenden. Nahezu jede Hochschule besitzt heute ein Campus-Management-System, das alle Verwaltungs- und Informationsströme bündelt und - zentral administriert – das Studierendenmanagement-Rückgrat der Einrichtung darstellt. Abgesehen von einigen wenigen Ausnahmen, bei denen selbst entwickelte Campus-Management-Systeme zum Einsatz kommen wird dieser Softwarebereich dominiert von deutschlandweit vier großen Anbietern. Hieraus resultiert, dass jedwede App-Entwicklung für das Studierenden-Management grundsätzlich von einem überregionalen, viele Hochschulen einbindenden Verbund profitiert, in dem arbeitsteilig Schnittstellen der Middleware an wichtige Informations-, Kommunikations-, Infrastruktur- und Campus-Management-Systeme programmiert und mit anderen Hochschulen im Verbund geteilt und abgestimmt werden.

In Zeiten knapper Kassen gibt es eigentlich keine Rechtfertigung dafür, dass immer wieder gleiche Schnittstellen und Technologien an einer Vielzahl von Hochschulstandorten unkoordiniert und mit immer wieder ähnlicher Funktionalität programmiert und weiterentwickelt werden. Das hier skizzierte Verbundprojekt vermeidet redundante Einzelentwicklungen durch eine präzise koordinierte und abgestimmte Spezialisierung von Entwicklerteams auf einzelne Arbeitspakete. Nachfolgende Grafik verdeutlicht die Struktur der dezentralen, auf jeweils einzelne Anpassungen und Datenverarbeitungsprozesse hin optimierten Arbeitsteams an den verschiedenen Hochschulen.

3.4 E-Portfolio

Eine ganz zentrale Funktionalität in der Konzeption von generischem Framework und darauf aufbauender Studien-Management-App (Studi-App) stellt das persönliche E-Portfolio dar. Hierzu müssen umfangreiche Individualinformationen verschlüsselt und lokal in der App auf dem Smartphone abgelegt sein (oder als verschlüsselter Clouddienst), damit der/die Studierende mit ein und demselben Portfolio über seinen gesamten Studienverlauf - gegebenenfalls an verschiedenen Studienorten - arbeiten kann. Es steht zu prüfen, ob Hochschulen die E-Portfolios neuer Studierender, die zuvor an anderen Einrichtungen studiert haben, unter Klärung aller DS-rechtlicher Fragestellung auslesen und automatisiert um neue Inhalte erweitern dürfen.

3.5 Showcase

Studierende an Hochschulen und Hochschulen in Deutschland nutzen zur Verwaltung und Organisation ihrer Studien sowie für einzelne Lernprozesse (z.B. E-Learning, …) in zunehmendem Umfang mobile Endgeräte (Smartphones oder Tablets). Ziel des Projektes "Generisches Framework Studi-App" ist es daher, die Service- und Informationsangebote an möglichst vielen Hochschulen in Deutschland in einem einheitlichen, standardisierten Format aufzubereiten, so dass die ebenfalls im Projekt entwickelten, mobilen Applikationen (Apps) immer am jeweils gerade aktuellen Hochschul-Standort des Studierenden mit aktuellen Hochschulinformationen gespeist werden können. Nachfolgendes Szenario aus Nutzersicht möge zur Verdeutlichung der Idee eines Generischen Framework Studi-App dienen:

Die Studierende A beginnt ein Masterstudium "European Studies" an der Europa Universität Viadrina in Frankfurt (Oder). Zuvor hat sie an der Technischen Universität Berlin einen Bachelor in "Wirtschaftsinformatik" gemacht. Dort an der TU Berlin hat sie bereits die Mobile App "TUB-App" (Arbeitstitel) kennen und nutzen gelernt. Das App-Nutzungsverhalten von A umfasst folgende Vorgänge:

Einmal am System anmelden und dann...

... persönlichen Stundenplan zusammenstellen

... Kurse belegen

... Hörsäle finden

... Vertretungen, geänderte Raumplanungen und Ausfälle erkennen

... Öffnungszeiten verschiedener Einrichtungen einsehen (UB, IT-Service, ...)

... HS-Sport Angebot durchsehen und Veranstaltungen buchen

... Abstimmen mit Kommilitonen

... zu Prüfungen/Klausuren anmelden

... Notenspiegel zusammenstellen/überwachen

... Was gibt es heute in welcher Mensa/Cafeteria

... Ein Buch bestellen und Zugang zu Katalogen der Unibibliothek nutzen

... Profilnachrichten schreiben, mit Freunden kommunizieren

... Hilfe erbitten bei Betreuern, Dozenten und Verwaltungsmitarbeitern (Support)

... Fährt die Bahn pünktlich

... im LMS nach E-Kursen suchen

... E-Portfolio (Lerninhalte, persönlichen Studienfortschritt, erreichte Leistungen und Credits, Stundenpläne) verbessern und nutzen

... wichtige News zu ihrem Studium empfangen

Alle diese und möglicherweise noch eine Reihe weiterer, für den Studienerfolg von A relevanten Dienste, werden - entsprechend der Idee dieses Projektes - sowohl von der TU-Berlin als auch von der Europa-Universität Viadrina (EUV) in Form standardisierter Schnittstellen und Protokolle bereitgestellt. Darüber hinaus bieten die beiden Hochschulen jeweils noch eine Reihe spezifischer Dienste für ihre Studierenden an.

Wenn A nun von der TU Berlin, wo sie ihren Bachelor in "Wirtschaftsinformatik" gemacht hat, an die Europa- Universität Viadrina wechselt, dann wechselt sie an der TU Berlin aus der Rolle "Aktive Studierende" in die Rolle "Alumni". Weiterhin übernimmt sie ihr persönliches E-Portfolio von der TU-Berlin und dieses wird automatisch an der EUV erkannt, (datenschutzrechtlich anonymisiert) prozessiert und weiter ausgebaut mit den Services und Diensten der Europa-Universität. Dienste, die von der Europa Uni nicht angeboten werden, bleiben unangetastet, dafür wird die Diensteübersicht um Europa-Uni spezifische Dienste erweitert.

A kann also mit der gleichen App auf ihrem mobilen Endgerät (voraussichtlich mit einem an das Corporate Design der TU-Berlin angepassten Layout) wie zuvor an der TU-Berlin auch an der Europa-Universität alle Studierendenangebote, Informationsdienstleistungen, Studienmanagementfunktionen etc. mit einer einmaligen Anmeldung nutzen. Zugleich bleibt sie mit einer anderen Rolle auch in den Strukturen der TU-Berlin verankert und kann dort eine Reihe von Services weiternutzen. Eine zeitaufwendige Umstellung und Erarbeitung neuer Studienverwaltungsvorgänge bleibt ihr weitgehend erspart. Sie kann sich, Dank des hier beschriebenen "Generischen Framework Studi-App" vom ersten Augenblick an der neuen Hochschule sofort voll und umfänglich ihren Studien widmen.

Denkbar wäre zum Beispiel auch, dass A neben der Rolle "Alumni" an der TU-Berlin und der Rolle "Aktive Studierende" an der Europa-Universität noch zweimal die Rolle "Gast" an der Uni Leipzig und an der Uni Hohenheim besitzt, weil sie an den dortigen Hochschulen im Rahmen wissenschaftlicher Projekte in Forschungsgruppen mitarbeitet. Die Rolle "Gast" liefert nur Hörsäle, Vorlesungen, Öffnungszeiten, einen interaktiven Wegweiser durch die Uni, Mensapläne, Hinweise zu zentralen Einrichtungen usw.. Die Navigationsstruktur in gleichen Rollen an verschiedenen Einrichtungen ist standardisiert, die vertraute App kann zur Darstellung aller Angebote aller beteiligten Hochschulen verwendet werden.

Weiteres Beispiel: Ein Studierender ist an der Uni Leipzig immatrikuliert und nutzt eine „Uni-Leipzig-App“, innerhalb derer er als Studierender alle für seinen Studienverlauf relevanten Informationen (persönlicher Stundenplan, Wegweiser durch die Uni, Mensapläne, Zugverbindungen, Räume und Raumverlegungen, einen persönlichen Notenspiegel, E-Learning-Inhalte usw.) sieht und nutzt. Kommt er jetzt beispielsweise als Gast an die Uni Hohenheim „sucht“ sich seine „Uni-Leipzig-App“ automatisch das von der dortigen Uni für die Nutzerrolle „Studi-Gast“ bereitgestellte Serviceangebot und er kann sich an dieser Uni beinahe so sicher bewegen und Dienste nutzen, wie an seiner Heimatuni.

4 Technik und Funktionalitäten

Finales Ziel ist ein Framework (Middleware) mit vielfältigen Funktionen und Schnittstellen zu typischen Informationsinfrastrukturen an Hochschulen, mit dessen Hilfe Studierendenportale nach dem Baukastenprinzip an die jeweiligen Hochschullandschaften angepasst und in Apps für mobile Endgeräte mit unterschiedlichen Betriebssystemen implementiert werden können.

Das zentrale Repository könnte aus dem Bereich der Content Management Systems (CMS) oder der Content Management Frameworks (CMF) stammen. Der Fokus liegt hier auf quelloffenen und modularen Systemen. Dabei sollten die folgenden Kriterien erfüllt sein:

  • Große und aktive Entwicklercommunity

  • Wartungsarm durch häufige Updates

  • Modularität, Anpassungsfähigkeit, Erweiterbarkeit

  • Erweiterbare Theming- und Rendering Engine

  • Nutzer- und Rollenmanagement

  • Unterstützung gängiger Autorisierungs- und Authentifizierungsverfahren (LDAP)

  • Integrierbarkeit von Schnittstellen

  • Indizierung und Suche

  • Content Management

  • erweiterbarer Administrationsbereich

Hierfür geeignete Systeme könnten beispielsweise im CMF Drupal oder in der Portalsoftware Liferay realisiert werden. Dabei ist Drupal vor allem für die Informationsvernetzung hervorragend geeignet. In das Framework fließen die Erfahrungen, Technologien, Module, Workflows und Zugangsstrategien all derjenigen Hochschulen mit ein, die bereits eigene Lösungen entwickelt und aufgesetzt haben. Im Ergebnis entsteht damit ein von allen Hochschulen, Fachhochschulen und außeruniversitären Forschungseinrichtungen nutzbarer Pool an:

  • Software

  • Dokumentation

  • Experten in einer gut strukturierten Community (der Betreiberseite)

  • Empfehlungen zu Workflows

Die Daten- und Metadatenmodelle typischer Software-Werkzeuge im Unialltag (Campus-Management-Systeme, LMS, Forschungsinfrastrukturen, Publikationsplattformen usw.) und uniinterner Dienstanbieter (Rechenzentren, Mensen, HS-Sporteinrichtungen, Bibliotheken usw.) werden an allen beteiligten Einrichtungen systematisiert und standardisiert und in einem einheitlichen Daten-/Metadatensatz (Viadrina-Core), vergleichbar mit dem Dublin-Core im Bereich der elektronischen Lehre beschrieben. Dabei sind immer einzelne Entwicklungszentren an jeweils einer der beteiligten Hochschulen für die präzise Schnittstellenentwicklung und für die langfristige Pflege dieser Schnittstelle verantwortlich. Zu beachten ist hierbei, dass das Projekt keinesfalls ein neues Campus-Management-System zu entwickeln beabsichtigt. Es geht ausschließlich darum, ein generisches Framework für unterschiedliche mobile Apps zu entwickeln und mit standardisierten Daten aus typischen Hochschul-Software-Systemen zu speisen (Schnittstellenspezifikation). Die so gesammelten Daten werden über ein leicht erweiterbares und programmierbares CMS (siehe oben) um die Designs der jeweiligen App – respektive um das Corporate Design der die App anbietenden Hochschule erweitert - gegebenenfalls auch um typische Funktionen einer sozialen Software – und können dann an mobile Endgeräte in Verbindung mit Apps (aber auch in anderen Formaten – beispielsweise als browserbasierte Portalumgebung) ausgeliefert werden.

4.1 Daten-/Metadatenmodell

Ziel dieses Arbeitspaketes ist die systematische Gliederung hochschultypischer Dienste, Kommunikationsstrukturen und Daten in ein umfassendes, generisch-erweiterbares Daten-/Metadatenmodell. (Viadrina-Core) Dies kann ähnlich aufgebaut sein wie der Dublin Core Metadatensatz im E-Learning Bereich. Das Metadatenmodell beschreibt eine formalisierte, eindeutige Darstellung von Daten und Metadaten sowie eine exakte Spezifikation der Schnittstellen zwischen Systemen und Daten. Hochschulen, die sich auch zu einem späteren Zeitpunkt in dieses System einbringen wollen übernehmen das Daten-/Metadatenmodell. Damit sind alle auf dieses Daten-/Metadatenmodell aufsetzenden Werkzeuge (stationäre Programme, Apps, webbasierte Studierendenportale) in der Lage, die Dienste, Kommunikationsstrukturen und Daten aller im System befindlicher Hochschulen zu prozessieren und dem Studierenden anzubieten.

Hierzu müssen umfangreiche Recherchen, Bestandsaufnahmen und Vergleiche der an den beteiligten Hochschulen notwendigen Angebote für Studierende und Mitarbeiter sowie zu den dort jeweils genutzten Informationsinfrastrukturen, HS-Managementsystemen und Kommunikationsinfrastrukturen vorgenommen werden.

In einem zweiten Schritt einigen sich die Partner des hier aufgezeigten Verbundes auf ein entsprechend abgestimmtes, einheitliches Daten-/Metadatenmodell.

Dieser Projektteil ist der innovative Nukleus des gesamten Projektes. In das Daten-/Metadatenmodell fließen viel Forschung und Hintergrundrecherche sowie alle strukturellen Überlegungen zu den Bedarfen der Studierenden und den Werkzeugen, Prozessen und Kommunikations-/Datenstrukturen an den entsprechenden Einrichtungen, die diese Bedarfe abdecken sowie zur Standardentwicklung für ein im Hochschulbereich in späteren Zeiten möglicherweise nicht mehr wegzudenkendes Serviceframework.

4.2 Mögliche Dienste

Nachfolgende Sammlung von Funktionen erhebt keinen Anspruch auf Vollständigkeit. Sie wurde von Richard Huber (Europa Uni), Andreas Lehmann (TU-Berlin) und Daniel Fehrle (Uni Hohenheim) aufgrund unispezifischer Erfahrungen zusammengetragen:

  • Single Sign On

  • Integration von Lernraumsystemen wie Moodle, Ilias, Blackboard

  • Übernahme von Studienablaufsdaten (Persönlicher Stundenplan, Hörsäle, Vorlesungen, Öffnungszeiten usw.) aus Campus MM-Systemen wie HIS LFS, Datenlotsen

  • Nutzung für mobile Lehre: Lernorte ermöglichen es Dozenten und Studierenden vor Ort an definierten Punkten zu lernen

  • Funktionalitäten sozialer Software (persönliche Profile, Freundschaften, interne Nachrichten, ...)

  • E-Portfolio Funktionalitäten (der Studierende kann seinen persönlichen Studienfortschritt, erreichte Leistungen und Credits, Stundenpläne, Arbeitsmaterialien usw. in einem individuellen Profil anlegen, organisieren und gegebenenfalls mit anderen teilen.

  • Studierendentools wie Kleinanzeigenmarkt, Newsletter, Kontakt zu Profs & Uni-Mitarbeitern...

  • Interaktive Navigationssysteme unter Nutzung der Smartphone-Kamera innerhalb der Unis

  • Mensapläne, Veranstaltungskalender, Campus-Einrichtungen...

  • Integration von Mail-Diensten z.B. Horde

  • Zugang zu Services der Unibibliotheken

  • Augmented Reality Guide

  • Rechtemanagement

  • Foren

  • Kalender mit eigenen (des Studenten) und Fremdterminen (der Uni)

  • Wissensdatenbank in Form einer Wikipedia (Uni-Pedia)

  • Kollaborative Gruppen zum Erstellen gemeinsamer Dokumente (für Hausaufgaben)

  • Ortung per WLAN und GPS und einhergehende Erweiterung von ortspezifischen Informationen

    • Bspw. In einer Map gibt der Student per Smartphone und Ortung an: „Hier steht ein Kaffeeautomat“, „hier ist der Haupteingang zu diesem Gebäude“

  • Möglichkeit der Ergänzung fehlerhafter Informationen der Universitätsverwaltung durch das Wissen des Studenten

    • Bspw. die VL findet nie in diesem Raum statt, da der Dozent nicht so weit laufen möchte und demnach in seinem Besprechungsraum die VL hält

  • Buchungsmöglichkeiten von der Frameworkapplikation auf diverse externe Webseiten

    • Hochschulsport, Klausuranmeldung, …

5 Partner & Finanzierung

Es gibt in Deutschland derzeit 142 Hochschulen und gleichgestellte Hochschulen und 215 Fachhochschulen. Ergänzt werden diese durch zahlreiche private Hochschulen, Fachakademien und Business Schools, die ebenfalls Hochschul-ähnliche Studienangebote an ihre lernenden Zielgruppen vermitteln.

Aufgrund der föderalen Bildungshoheit der Länder ist es schwierig, einen überregionalen Fördertopf für das hier skizzierte Vorhaben zu finden. Prinzipiell könnten die beteiligten Hochschulen individuell bei ihren jeweiligen Landesministerien vorstellig werden und um eine entsprechende Projekt-/Entwicklungsförderung bitten. Im Sinne eines gut organisierten, in allen beteiligten Bundesländern ausgewogenen finanzierten Bundesprojektes ist dieses Vorgehen allerdings nur bedingt zielführend.

Aufgrund derzeit nicht erkennbarer Förderquellen hat das Projektplanungsteam ein zweistufiges Entwicklungskonzept mit einer Prototyp-Entwicklungsphase und einer Haupt-Projektphase entwickelt, das eine Finanzierung aus Eigenmitteln der beteiligten Hochschulen vorsieht.

Nachstehende Grafik zeigt die Verteilung der derzeit beteiligten Hochschulen und benennt das jeweils unterschiedliche Engagement der Hochschulen:

Die nachstehenden Unterkapitel beschreiben die verschiedenen, am Projekt beteiligten oder das Projekt steuernden Akteursgruppen im Detail:

5.1 AG-Studi-App

In der innerhalb des Arbeitskreis Web der ZKI angesiedelten Arbeitsgruppe Studi-App haben sich Webverantwortliche von derzeit 29 Hochschulen aus ganz Deutschland zusammengeschlossen, um gemeinsam eine entsprechende Entwicklung voranzubringen. Das Projekt hat mittlerweile bereits so hohe Ausstrahlungskraft entwickelt, dass sich auch bisher nicht beteiligte Interessenten bei der derzeitigen kommissarischen Projektleitung melden und um Beteiligung am Verbund ersuchen.

5.2 Projektleitung

Die Projektleitung wird derzeit - bis zu einer Entscheidung über eine Finanzierung einer zentralen Projektleitung gegebenenfalls durch den Vorstand der ZKI-Arbeitsgruppe Studi App im AK Web der ZKI, derzeit kommissarische Leitung der AG und des Studi-App-Projektes durch Richard Huber, CIO der Europa Universität Viadrina, Frankfurt (Oder) zusammen mit der Steuergruppe Studi-App (siehe unten) wahrgenommen.

Projektverantwortlicher

Dipl. Ing. Richard Huber
Europa Universität Viadrina
Tel.: 0335-5534-2558
Fax.: 0335-5534-72558
Email: huber@europa-uni.de

Steuergruppe für das Studi-App Projekt

Name

Uni

Mailadresse

Patrick Holz

Uni Köln

patrick.holz@uni-koeln.de

Andreas Lehmann

TU-Berlin

andreas.lehmann@tu-berlin.de

Daniel Fehrle

Uni Hohenheim

daniel.fehrle@uni-hohenheim.de

Bert Zulauf

Uni Wuppertal

zulauf@uni-wuppertal.de

Martin Mai

Uni Bamberg

martin.mai@uni-bamberg.de

Martin Schuhmann

Uni Würzburg

martin.schuhmann@uni-wuerzburg.de

Marc Schönberg

TUHH

schoenberg@tuhh.de

5.3 Pilotvorhaben an Europa-Universität und TU-Berlin

Nachdem – entsprechend unserer bisherigen Erfahrungen - die langfristige Realisierung eines an vielen Hochschulen in Deutschland verankerten App-Entwicklungsprojektes mit hohen Abstimmungs- und Planungsverzögerungen einhergeht, haben sich die Entwicklungsverantwortlichen der Technischen Universität Berlin und der Europa-Universität Viadrina dahingehend verständigt, zunächst bis Jahresende 2014 eigene Entwicklungskapazitäten für das App-Entwicklungsprojekt bereit zu stellen. Im Rahmen dieses bilateralen Entwicklungsprojektes werden folgende Ziele verfolgt und erstellt:

  1. Eine prototypische, generische, vielfältig erweiterbare Middleware für die Datenaufbereitung typischer, exemplarischer Hochschul-Services für unterschiedliche Ausgabeformate (App, Webinterface, …)

  2. Eine prototypische App mit einem reduzierten Funktionalitätenumfang in einem App-Entwicklungsframework, das ein „Umschalten“ zwischen den Corporate Designs verschiedener Hochschulen erlaubt

  3. Den Aufbau eines Daten- und Metadatenstandards für Datenströme zwischen typischen Hochschulservices und der generischen Middleware (Viadrina-Core)

  4. Eine Roadmap der zukünftig zu integrierenden Funktionalitäten basierend auf Nutzer-Szenarien, Komplexität des Moduls und Popularität der Funktionalitäten aus dem Sichtwinkel der Hauptzielgruppen (Studierende).

  5. Ein ordnendes Projekt-Management mit klaren, transparenten Strukturen für eine langfristige Arbeitsverteilung zur Anbindung neuer Services und Funktionalitäten an zukünftig vielen, dezentral agierenden Entwicklungshotspots an beteiligten Hochschulen in Deutschland

  6. Eine modulare, transparente und für neue Universitäten leicht aufzusetzende Entwicklungs-Technologie aus Open Source Bibliotheken, Entwicklungsumgebungen und Programmier-Frameworks sowie ein zentrales Studi-App-Repositry für zukünftige große, dezentral entwickelnde Programmierergruppen an vielen Hochschulen in Deutschland

  7. Eine umfangreiche Dokumentation der Entwicklungs-Umgebung, der organisatorischen Strukturen an neu partizipierenden Einrichtungen (zur Förderung des reibungslosen Zusammenspiels zwischen Entwicklungs-/IKT-Bereichen und den Hochschuleinrichtungen, die die entsprechenden Daten bereitstellen müssen), basierend auf den bisherigen Projekterfahrungen, des Datenstandards (Viadrina-Core) sowie der mittel- und langfristigen Entwicklungsroadmap.

  8. Den Aufbau und die Betreuung einer Entwickler-Community

  9. Erste Definitionen und Restriktionen für einen konsequenten Datenschutz in der zukünftigen Studi-App.

5.4 Nutzung von Pilotvorhaben

Drei Hochschulen aus dem Verbund haben sich bereit erklärt, bereits fertig gestellte und in Betrieb befindliche Eigenentwicklungen (Apps oder Middleware) in das hier skizzierte Verbundprojekt konzeptionell einzubringen. Es sind dies die Technische Universität Berlin mit dem Studierenden Framework myDESK, die Universität Hohenheim mit der "Hohenheim-App" sowie die Universität Duisburg/Essen mit der dort entwickelten und genutzten App "myUDE".

Die in diesen Anwendungen genutzten und realisierten Methoden, Technologien und Prozesse können als Best Practice Beispiele vom Projekt genutzt und - entsprechend erweitert und angepasst - dem gesamten Projektverbund zur Verfügung gestellt werden.

Die einzelnen Hochschulen und ihre ins Projekt eingebrachten Module im Detail:

5.4.1 myDESK

Das durch innoCampus an der TU Berlin entwickelte Studierendenportal myDESK ist seit dem Sommersemester 2011 im Produktiveinsatz. Die derzeitige Benutzerzahl beläuft sich auf etwa 12.000 Studierende, die myDESK aktiv nutzen.

Die Technische Universität Berlin setzt zur Informationsdarstellung, für die Organisation und Verwaltung unterschiedliche computergestützte Dienste und Systeme ein. Neben den Beschäftigten sind v.a. die Studierenden eine große Zielgruppe dieser Dienste und Systeme. Zu diesen gehören unter anderem:

  • Internetportal der TU Berlin als Informationsmedium auf Basis von Typo 3

  • HIS-LSF mit dem zugehörigen Veranstaltungsverzeichnis

  • E-Learning Plattform ISIS auf Basis von Moodle

  • MosesKonto als Verwaltungs-, Organisations- und Optimierungswerkzeug zur Tutorien-, Termin- und Klausurplanung

  • HIS-POS- bzw. QIS-POS als Dienst zur elektronischen Prüfungsanmeldung und

  • Buchungssystem für den Hochschulsport zur Anmeldung zu Sportkursen

Neben diesen gibt es auch noch weitere Dienste und Portale, die zeitlich und verwaltungsbedingt, meist getrennt voneinander entstanden sind und bis heute betrieben werden.

Die große Anzahl an Diensten und Portalen führt bei den Studierenden zu einem großen Mehraufwand hinsichtlich der selbstständigen Organisation, Informationsbeschaffung, Kommunikationsstreuung und Verteilung zeitlicher Ressourcen. Das Studierendenportal myDESK nimmt sich der besagten Probleme an und löst diese, indem es für den Studierenden einen zentralen Anlaufpunkt für unterschiedliche Dienste und Portale generiert und dabei durch Integration auch auf Datenebene weitere Mehrwerte schafft. Bereits existierende Dienste und Portale werden dabei nicht ersetzt, sondern innerhalb von myDESK integriert oder mit myDESK vernetzt.

5.4.2 Uni-Hohenheim-App

Um den Rahmen dieser Skizze nicht zu sprengen übergeben wir an dieser Stelle den Link auf die entsprechende Website der Uni-Hohenheim:

https://www.uni-hohenheim.de/app

5.4.3 myUDE

Um den Rahmen dieser Skizze nicht zu sprengen übergeben wir an dieser Stelle den Link auf die entsprechende Website der Uni-Duisburg-Essen:

https://www.uni-due.de/myude/

Beide vorgenannten Universitäten unterstützen das Projekt „Generisches Framework Studi-App“ aktiv und sind bereit, die an den Einrichtungen bereits im Regelbetrieb mit umfangreichen Studierendenzahlen (Uni Hohenheim Nutzungsgrad unter Studis mit Smartphone ca. 98%) erprobten Konzepte und App-Entwicklung vollumfänglich in das Verbundprojekt einzubringen.

5.5 SW-Firma

Basierend auf den beim Planungstreffen in Magdeburg im September 2013 mit dem Plenum der Arbeitsgruppe Studi-App festgelegten Eckparametern für das weitere Vorgehen im Verbundprojekt wurde beschlossen, eine auf App-Programmierung spezialisierte Software-Firma für die Realisierung eines Prototypen an einer ausgewählten Zahl von Hochschulen (ca. 10 Einrichtungen) zu beauftragen.

Die Wahl fiel hierbei nach umfänglicher Recherche auf ein Softwarehaus, das bereits die App der Uni Hohenheim in bisher drei Versionen produziert hat und dementsprechend zum einen Expertise in der Programmierung einer Studienmanagement-App für studentische Zielgruppen - andererseits Erfahrung in der Zusammenarbeit mit universitären Auftraggebern besitzt. Die Firma kann dabei auf das "Skelett der Hohenheim-App" zurückgreifen und dies in Anpassung an Corporate-Design-Festlegung der am Prototyp-Projekt beteiligten Hochschulen für die ca. 10 prototypischen Implementierungen mit eingeschränktem Funktionsumfang bei geringerem Aufwand an die universitären Bedarfsprofile anpassen.

5.6 Wirtschaft

Ein stetig wachsender Verbund von derzeit 29 Hochschulen, die gemeinsam ein Framework-/App-Projekt aus ihren Rechen- und Medienzentren heraus entwickeln und vorantreiben wollen, bildet ein großes wirtschaftliches und politisches Potential ab. Dementsprechend groß ist das Interesse von Unternehmen wie Peripheriegeräte-Herstellern oder Herstellern von typischer Hochschulsoftware, ihre Produkte und Softwaremodule integrieren zu können. Voranfragen z.B. beim Druckerhersteller Kyocera liefern hier ein erwartungsvolles und positives Feedback. Es steht zu erwarten, dass das verschiedene wirtschaftlich agierende Unternehmen Anbindungen an eigene Software und Hardware in Eigenregie vornehmen werden und damit den nachhaltigen Erfolg des Projektes Generisches Framework Studi-App zusätzlich absichern werden.

5.7 Förderquellen

Erste Anfragen an potentielle Förderorganisationen wurden gestellt. Eine direkte Fördervoranfrage wurde an das Referat Wissenschaftliche Literaturversorgungs- und Informationssysteme (LIS) der DFG gerichtet. Die DFG darf allerdings gemäß ihrem Grundauftrag nur Forschungsvorhaben und keine Maßnahmen zur Verbesserung der Lehre fördern. Evtl. ist der Aspekt der Standardisierung im hier skizzierten Vorhaben für die DFG ein förderungsfähiges Forschungsthema.

Weitere mögliche Förderquellen:

  • BMBF (Referat Hochschulen/Hochschulinnovation)

  • DLR

  • Volkswagen-Stiftung

  • Bosch-Stiftung

6 Projektgliederung

Das Projekt wird durch die Arbeitsfelder

  • Konzeption, Recherche und Datenerhebung

  • Umsetzung

  • Einführungsprozesse

  • Dokumentation, Roll Out

beschrieben.

Weite Teile der konzeptionellen Projektplanung erfolgen bereits im Vorfeld, um eine vergleichsweise exakte Abschätzung von Projektaufwand zu Projektnutzen und eine verlässliche Ressourcenabschätzung abgeben zu können.

Die konkrete Umsetzung des hier skizzierten Projektes kann gegliedert werden in vier große, klar voneinander unterscheidbare Entwicklungsfelder

  • Einem generischen, an allen beteiligten Hochschulen einheitlichen Daten-/Metadatenmodell ähnlich dem Dublin Core Metadatensatz im E-Learning Bereich. Hierzu müssen umfangreiche Recherchen, Bestandsaufnahmen und Vergleiche der an allen beteiligten Hochschulen notwendigen Angebote für Studierende und Mitarbeiter sowie zu den dort jeweils genutzten Informationsinfrastrukturen, HS-Managementsystemen und Kommunikationsstrukturen durchgeführt werden.

  • Einer alle Datenquellen zusammenführenden, Information strukturierend und aufbereitenden Middleware in der alle benötigten und bereitgestellten Daten entsprechend obigem Metadatenmodell in ein einheitliches Ausgabeformat überführt werden.

  • Der Erstellung generischer Schnittstellen zu Standardsoftware und typischen Uni-Applikationen

  • Der eigentlichen, prototypischen App-Programmierung für verschiedene Betriebssysteme

6.1 Projektphasen

Um angesichts des sich an vielen Hochschulen derzeit schnell entwickelnden App-Marktes das Ziel einer zentralen HS-App initiiert von den Rechenzentren etablieren zu können wird eine abgestufte Lösung mit überschaubaren Projektphasen konzipiert.

In einem ersten Schritt werden, zusammen mit einem auf App-Herstellung spezialisierten SW-Haus, Prototypen einer Studi-App für ca. 10 Hochschulen erstellt. Diese Prototypen orientieren sich methodisch an der „Hohenheim App“, berücksichtigen allerdings schon individuelle Corporate Designs (CDs) der einzelnen Hochschulen und enthalten jeweils nur ein kleineres Set leicht zu implementierender Funktionen einer späteren umfangreichen App/Studierendenverwaltungssoftware.

Dieser Prototyp dient drei Hauptzielen:

1.) Einerseits wird mit dem Prototypen die Machbarkeit des Projektes und der Willen zur Zusammenarbeit des Hochschulverbundes unter Beweis gestellt

2.) Weiterhin besteht die Idee, dass die an der Prototypentwicklung beteiligten Hochschulen den Prototyp ihren Hochschulleitungen präsentieren und versuchen, für das jeweilige Projekt im Rechenzentrum/ Webbereich eine Stelle eines Webentwicklers/Koordinators zu gewinnen. Diese Stellen bilden dann - unter einer zentralen Projektleitung - das Rückgrat des auf viele Hochschulen verteilten, dezentralen Entwicklungsprojektes (den Kern des in dieser Skizze beschriebenen Projektes) dar.

3.) Schließlich fördert der Prototyp die breitenwirksamen Streuung der Idee eines bundesweiten Verbundprojektes unter aktiver Mitwirkung der ZKI zur Projektierung und Erstellung einer generischen Studien-Management-Middleware und darauf aufsetzender Apps für mobile Endgeräte, um weitere Partner (Hochschulen) in den Verbund zu bekommen und um die Industrie (Hersteller typischer Hochschul-Soft- und Hardware-Systeme) zu einer Mitwirkung anzuregen.

Parallel dazu erfolgt politische Begleitarbeit durch den ZKI Vorstand und durch direkte Adressierung überregionaler Gremien (Treffen der Kanzler der Hochschulen in Deutschland, DGI, DFN etc.) durch Multiplikatoren im Verbund.

Organisatorisch wurde eine Steuerungsgruppe für die spätere enge Zusammenarbeit mit einer externen Softwarefirma, die für die konkrete App-Programmierung zuständig sein wird eingerichtet.

Mit den durch die Überzeugungsarbeit des Prototypen bewirkten zusätzlichen Stellen an den beteiligten Hochschulen kann in einem zweiten Schritt ein größeres Gesamtprojekt mit vielfältigen Datenschnittstellen und Nutzerwerkzeugen projektiert und umgesetzt werden.

Strukturell wird das Projekt im ersten Schritt betreut durch die Zusammenarbeit von Steuergruppe und Agentur.

In einem folgenden größeren Projekt steht im Zentrum die von allen Projektbeteiligten verabschiedete Entwicklungsroadmap für die umfangreichen Programmier- und Anpassungsarbeiten am Framework.

Dieser umfangreiche Projektplan, beschreibt alle vielfach nutzbaren Module und Schnittstellen sowie eine Übersicht aller „Spezialprobleme“ bzw. „spezieller Wünsche und Bedarfe“ einzelner Beteiligter. Alle Entwicklungspakete und Schnittstellenspezifikationen werden - auf verschiedene gestufte Release-Versionen aufgeteilt - in Arbeitspakete gegliedert, die von den jeweiligen Entwicklern an den Einzelhochschulen erstellt und in das Gesamtpaket eingebracht werden können.

Wichtig erscheint, dass in einem größeren Entwicklungsvorhaben…

  • Die zentrale inhaltliche Steuerung bei der Steuergruppe - respektive der AG-App verbleibt

  • Die erzeugte Middleware unter einer CCL veröffentlicht wird

  • Zusätzliche Partner als Technologiepartner in das Vorhaben geholt werden können.

  • Der Gesamtprozess Middleware-Schnittstellen-App als Community Model betrieben wird

  • Gegebenenfalls kleinere Einzelprojekte im Rahmen von Bachelor-/Masterarbeiten mit wissenschaftlich-forschendem Charakter vergeben werden können.

6.2 Historie

Die Planungen für das hier skizzierte Projekt begannen im Frühjahr 2012. Unten stehende Tabelle liefert einen Überblick über bisherige Treffen und zugehörige Ergebnisse:

7 Chancen, Risiken, Nachhaltigkeit

Mit dem hier skizzierten Projekt "Generisches Framework Studi-App" bietet sich die Möglichkeit, Studierenden an voraussichtlich mehr als 30 Hochschulen in Deutschland unter Nutzung mobiler Endgeräte in Verbindung mit Apps einen erheblichen Vorsprung in den Bereichen Studien-Management und Informationsversorgung zu bieten. Durch die angestrebte Kooperation kann dies zu überschaubaren Kosten für die einzelnen Hochschulen bei gleichzeitiger dauerhafter Sicherung der Nachhaltigkeit geschehen. Damit werden insbesondere auch kleinere Hochschulen, für die eine App-Eigenentwicklung in diesem Umfang nicht finanzierbar wäre, in die Lage versetzt, die Bedarfe ihrer Studierenden nach innovativen und zeitgemäßen Studienmanagementwerkzeugen zu bedienen.

Wir erkennen die Gefahr, in ein vergleichbares Dilemma zu geraten wie die Hersteller der großen Campus-Management-Systeme wie HIS oder Datenlotsen, wenn wir versuchen wollten, uns auf der Anwendungsschicht an reale Studienmanagementprozesse und Verwaltungsprozesse heranzuwagen. Hier ziehen wir schon heute die klare Grenze dahingehend, dass wir uns auf die Standardisierung der von den Systemen exportierbaren Daten, das Klassifizieren dieser Daten in geeigneten Metadatenmodellen und auf das Kanalisieren und Aufbereiten der so extrahierten Daten konzentrieren werden.

Die prominenten politische Aufhängung des Projektes (alle Beteiligungserklärungen zur Prototypbeteiligung wurden von Präsidiumsmitgliedern, Kanzlern, CIOs oder RZ-Leitern der hier engagierten Hochschulen schriftlich erklärt) garantiert die langfristige Pflege und Weiterentwicklung des Projektes. Schon jetzt sorgt die reine Mund zu Mund Werbung für eine große Zahl von Anfragen zur Beteiligung von weiteren, bisher im Verbund nicht engagierten Einrichtungen.

Die aus dem Bedarf der Hochschulleitungen nach Zentralisierung der App-Entwicklungen an ihren Hochschulen in den Rechen- und Medienzentren resultierende, einmalige Chance, die Ressourcen der derzeit an so vielen Hochschulen geplanten oder bereits begonnenen Vorhaben zu bündeln und zugleich vom Know-How der im Projekt engagierten erfahrenen App-Projektleiter zu profitieren, sollte unbedingt genutzt werden.

Weitere Materialien

Videovortrag und PowerPoint zum Thema „Generisches Framework Studi App“ im Rahmen der CampusSource Tagung am 10.04.2014 an der FernUniversität in Hagen.

Fulltext