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.

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.

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.

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.

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.

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.

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.

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:

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.

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

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:

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:

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.

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.

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:

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 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: