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.

2 Kommentare:

Thomas Hapke hat gesagt…

Danke, Adrian, für Deine beiden letzten Blogbeiträge, die für mich gerade passend kamen, da ich zur Zeit versuche, die bisherige Arbeit einer AG Metadaten im Rahmen der HOOU für mich zusammenzufassen.

Durch Deinen Kommentar zu Axel Dürkops Beitrag im HOOU-Blog sind mir nochmal zwei Aspekte der Diskussion um Metadaten für OERs deutlich geworden, die auch im Rahmen der HOOU immer wieder diskutiert werden:

Der erste Aspekt bezieht sich auf Aktivitäten, ein Repository zu konzeptionieren und dabei die enthaltenen OERs mit Metadaten zu beschreiben, damit sie in einem denkbaren Portal gefunden werden können, gleichzeitig aber die Daten so zu kodieren und offen anzubieten, dass die von Dir benannte Metadaten-Austausch-Infrastruktur für OERs oder OER-Informationsinfrastruktur, in der Studie MDAS genannt, diese nutzen kann.

Der zweite Aspekt umfasst die Publikation von OERs innerhalb vorhandener Repositories (z.B. Zenodo), auf YouTube und anderswo, oder etwa wie bei Axel via Gitlab, wobei die Metadaten als Angebot für die OER-Informationsinfrastruktur den jeweiligen OERs als Beschreibungsdatei beizugeben sind bzw. diese direkt in die OERs zu integrieren.

Für diesen zweiten Aspekt habe ich kaum Vorstellungen über die konkrete Praxis. Ich stecke leider überhaupt nicht in der Praxis des Themas Linked Data drin und auch in der Theorie dazu nur am Rande. Kannst Du Beispiel für OERs nennen, wo dies aus Deiner Sicht optimal umgesetzt wurde?

BTW: Das von Dir in Deiner Antwort auf den Kommentar von Boris Bockelmann zum ersten Blogpost von Dir zum Thema sehr schön illustrierte grundlegende Problem der Ergänzung und Anpassung durch Dritte, bei OER ja auch auf die Inhalte bezogen, erfährt aus meiner Sicht noch eine weitere Komplexitätssteigerung.

OERs sind unter Umständen nicht nur irgendwelche Objekte (Dateien, Webseiten usw.), sondern können ja durchaus auch "Gemenge" von Objekten sein. Was ich im Rahmen der Diskussionen innerhalb der HOOU ziemlich früh gelernt habe, OERs nicht nur objektorientiert, als Bibliothekar auch gerne publikationsorientiert 8-) , sondern diese auch prozessorientiert zu denken. Siehe auch den schönen Text von Iver Jackewitz zum Lebenszyklus einer OER im HOOU-Blog. Open Educational Practices (OEPs) sind als Prozesse wichtige Komponenten der didaktischen Diskussion zu OERs, wie z.B. Kerstin Mayrberger zeigt.

Auch ein ganzes Lernarrangement kann als OER gesehen werden. Dieses kann z. B.aus einem didaktischen Konzept zu einem Lernthema, eines Seminars usw. bestehen, z.B. in Form einer Textdatei. Dazu kann eine Materialliste sowie eine Materialsammlung kommen. Die Materialliste kann Literatur, Links u.a. enthalten, die teilweise als Objekte Teil des Lernarrangements, genauer der Materialsammlung sein können, teilweise sind dies sicher aber auch Hinweise auf externe Objekte. Die Materialsammlung umfasst zum didaktischen Konzept des Lernarrangements gehörende Materialien, die in einem bestimmten Sinnzusammenhang stehen.

Hier kommen also noch viel mehr Fragen der Vererbung von Metadaten in die Diskussion. Metadaten zu OERs "leben" quasi wie die OERs selbst und können "wachsen". Aber ob man immer alle Metadaten der verwendeten Materialien als Metadaten mitschleppen muss, also auch die Frage, wie feingranular konzipiert man einzelne OERs, ist für mich offen.

vali hat gesagt…
Der Kommentar wurde von einem Blog-Administrator entfernt.

Kommentar veröffentlichen

Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.