2016-06-02

Infrastrukturanforderungsbestimmung

Meinen letzten Blogbeitrag habe ich on- wie offline mit zwei Jans und mit Boris Bockelmann diskutiert (Besten Dank!).

Unter anderem ging es in den Gesprächen (wie auch im Austausch mit Boris in den Kommentaren zum Beitrag) um die Frage, ob für die dezentrale Erstellung und Synchronisierung von Metadaten ein zentraler Service nötig sei oder ob das auch dezentral funktionieren kann. Dabei ist mir eine wichtige und grundsätzliche Problematik mit Blick auf die DIPF-Infrastrukturstudie bewusst geworden: Wie so oft wird eine mehr oder weniger konkrete technische Lösung geliefert (hier: ein zentraler "Metadaten-Austausch-Service"), bevor überhaupt eine hinreichende Sammlung der Anforderungen an die OER-Infrastruktur stattgefunden hat. Zwar gibt es in der Studie einen gesonderten Abschnitt zu den Anforderungen (S.46-53), allerdings bleiben diese an der Oberfläche.

Bevor die tatsächliche Entwicklung der Infrastruktur oder die Konkretisierung ihrer Architektur beginnt, sollten die Anforderungen konkretisiert werden. Dies lässt sich z. B. anhand von User Stories tun wie im folgenden skizziert wird.

Nutzergruppen

Letztlich sind es die Anforderungen und Bedürfnisse der Nutzerinnen und Nutzer einer Infrastruktur (und nicht jene der Auftrag- oder Geldgeber, der Betreiber oder irgendwelcher anderer Akteure), die für die Ausgestaltung der Infrastruktur maßgeblich sein sollten. Somit sollten als erstes die verschiedenen Typen von Nutzern der Infrastruktur gesammelt werden. Im Falle von OER sind dies:

  • Menschen, die neue OER erschaffen und dabei unter Umständen bestehende OER überarbeiten und/oder kombinieren
  • Menschen, die nach OER suchen zum Einsatz in ihrer oder anderer Leute Bildung

Dies sind zwei sehr große und sehr heterogene Nutzergruppen. Von Grundschul- oder Förderpädagogen, bis zum Universitätsprofessor, von der an einem Thema nur beiläufig interessierten Person, über Schüler der Primär- und Sekundarstufe bis zur Doktorandin ist hier alles vertreten. Eine genauere Betrachtung der verschiedenen Untergruppen wäre sicherlich angebracht.

Erst User Stories formulieren, dann entscheiden

Zur Bestimmung der Anforderungen an eine zu entwickelnde Technologie haben sich in der agilen Softwareentwicklung User Stories etabliert. Es ist sinnvoll, zunächst eine ganze Menge User Stories aus Perspektive der verschiedenen Nutzergruppen zu sammeln, bevor man sich für oder gegen eine bestimmte Herangehensweise oder für eine bestimmte Technolologie entscheidet. Hier sind ein paar Beispiele:

Als Förderlehrerin in Deutsch möchte ich eine große Menge von Aufgaben und Übungen zum Buchstaben "A" finden, damit ich meinen Schülerinnen und Schülern über den recht langen Lernprozess abwechslungsreiche Lernmaterialien anbieten kann.

Als Lehrer möchte ich durch einen Klick auf ein "Edit"-Knopf die Ressource direkt im Browser anpassen können (Rechtschreibfehler, kleinere Anpassungen etc.), so dass ich schnell die von mir gewünschte Ressource zur Hand hab.

Als Lehrer möchte ich in einer komfortablen Webanwendung neue Arbeitsblätter erstellen, indem ich Übungen und Aufgaben aus verschiedenen Quellen kombiniere.

Als Lehrerin möchte ich von mir online erstellte Arbeitsblätter im Klassensatz ausdrucken.

Als Lehrer, der Arbeitsmaterialien zu einem bestimtmen Thema sucht, möchte ich an einer bestimmten Ressource auf andere Versionen derselben Ressource auf anderen OER-Plattformen hingewiesen werden.

Als Ersteller von OER möchte ich übersichtliche, intuitiv nutzbare webbasierte Autorenwerkzeuge, damit ich auf einfache Weise neue OER erzeugen und publizieren kann.

Als Ersteller von OER möchte ich Anforderungen an eine OER-Infrastruktur auf einfache Weise bestehende OER plus Metadaten von verschiedenen Plattformen übernehmen können, um eine angepasste Version der Ressource zu erstellen.

Als ehemalige Lehrerin möchte ich die Sammlung der von mir selbst erstellten Arbeitsblätter einscannen und unter einer offenen Lizenz für andere zur Nachnutzung publizieren.

Und so weiter. Dies sind nur ein paar Beispiele. Man sieht schnell, dass am Ende einer Sammlung von User Stories, die möglichst alle Nutzergruppen und alle Formen von OER berücksichtigt, eine sehr große Menge an User Stories zusammenkommen sollte. Diese können dann sortiert und priorisiert werden, zum einen für die Entwicklung von konkreter OER-Software, zum anderen für Entscheidungen hinsichtlich der Architektur (zentral vs. dezentral) der Gesamtinfrastruktur. Anforderungen ändern sich mit der Zeit, weshalb im Laufe der Entwicklung von Software und der OER-Infrastruktur die User Stories regelmäßig angepasst, ergänzt und neu priorisiert werden sollten.