Welches LMS ist das Richtige? Kriterien und Auswahlstrategien - Manfred Postel, 05.03.2008
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Welches LMS ist das Richtige?
Kriterien und Auswahlstrategien
Manfred Postel, 05.03.2008
CampusSource Mission statement Die Landesinitiative CampusSource hilft Bildungsein- richtungen, u.a. Infrastrukturen für das computer- und netzbasierte Lehren und Lernen sowie den Einsatz neuer Medien zu schaffen. Sie vermittelt Ihnen kosten- frei von Hochschulen entwickelte Open Source Software. Die Software wird über die CampusSource- Börse http://www.campussource.de angeboten, unterliegt den Lizenzbedingungen der General Public License (GPL) und muss einem definierten Qualitäts- standard entsprechen, um aufgenommen zu werden
Die Initiative Im Rahmen der Initiative CampusSource werden Zahlreiche, u.a. an Hochschulen entwickelte Lern- plattformen (LMS) und Werkzeuge für das Lernen und Lehren im Netz allen Interessierten kostenlos unter der GPL Lizenz angeboten. Das Angebot der CampusSource Landesinitiative in den primären Bereichen e-Learning, Open Source und Open Content richtet sich an nationale und internationale Anwender in allen Bildungsein- richtungen, Institutionen und Unternehmen.
Die Open Source Börse Derzeit werden 18 Systeme, darunter 10 komplette elektronische Lehrplattformen (LMS) und 8 Module (Werkzeuge) unter der GNU General Public License angeboten. Mit über 5800 registrierten Anwendern ist CampusSource weltweit z.Z. die größte Open Source Börse für e-Learning Werkzeuge.
Definition: Lernplattform
„Unter einer webbasierten Lernplattform ist eine
serverseitig installierte Software zu verstehen,
die beliebige Lerninhalte über das Internet zu
vermitteln hilft und die Organisation der dabei
notwendigen Lernprozesse unterstützt.“
(Baumgartner et al., 2002)Typische Funktionalitäten Administration von Lernenenden/Teilnehmern Verwaltung von Inhalten Unterstützung der Lehrenden Organisation der Kommunikation und der Betreuung Erstellung von Inhalten Übungen und Tests Literaturverwaltung Raumverwaltungssysteme etc.
Zusammenfassung: Merkmale, Entscheidungskritrien
Empfehlungsmatrix Quelle: bildung.at – Evaluation von Lernplattformen www.bildung.at/filedatabase/downloader.php?file_code=c27699e03fe6614ecd2b0cec7fff5254
Beispiel–Anforderungskatalog
- Basics -
NEED 2have NICE 2have
1. Gewährleistung von Datenschutz- und -sicherheit, Verfügbarkeit, Zukunftssicherheit X
2. Abbildung mehrere Schulen mit gemeinsamer und differenzierter Darstellung (Schule, X
Abteilung, Klasse, Gruppe)
3. Begleitung bei Entwurf und Umsetzung der Plattformstruktur X
4. Übernahme von administrativen Aufgaben während der Einführungsphase (Hilfe bei X
ersten Admin-Tätigkeiten) und während des Betriebs (Backup, Einspielen von Patches)
5. Hosting / ASP beim Anbieter X
6. Erweiterbarkeit der Plattform um zusätzliche Bausteine jederzeit möglich X
(Verwaltungssoftware, Managementtools, Stunden-, Raumplanung u. a.)
7. geringe Systemanforderungen auf der Benutzerseite (Browser-basiert, keine spezielle X
Hard- und Software)
8. Benutzersystemcheck (evtl. reicht Browser-Plug-In-Check) mit entsprechender X
Download-Möglichkeit
9. Teilnehmerzahl z. Zt. ca. 3000, X
Erweiterbarkeit notwendig (voraussichtl. max. 10000)
10. Schulung / Einführung X
11. Support X
12. Hotline XBeispiel–Anforderungskatalog
- Funktionen -
NEED 2have NICE 2have
13. Mailfunktion: Anbindung eines
a. jeder Benutzer erhält eine eigene Mailadresse, die auch außerhalb des Systems X freien Mailservers
genutzt werden kann
b. Möglichkeit der Weiterleitung
c. Passwortabfrage (bei Vergessen) per Mail X
d. SMS-Benachrichtigungsmöglichkeit X
Serverfunktionalität Hosting >> X
14. Dateiablage:
a. alle Dateiformate X
b. Dateibeschreibungen / Metainformationen X
c. freie hierarchische Verzeichnisstruktur mit unbegrenzter Tiefe Verschieben, Löschen, X
Kopieren, Umbenennen von Dateien und Ordnern für jeden Benutzer, jede Gruppe,
jeden Content
d. Versionskontrolle X
15. Darstellung von Nutzern (Steckbriefe) mit Bild X
16. Diskussionsforum X
17. News / Whiteboard X
18. vom Lehrer freizugebendes Chat XBeispiel–Anforderungskatalog:
- Funktionen -
NEED 2have NICE 2have
19. Übersicht und Ansprechmöglichkeit von im System aktiven Nutzern X
20. Speicherplatz für alle Teilnehmer (Schüler mind. 20 MB, X
Lehrer mind. 100 MB)
21. Terminkalender X
22. Suchfunktion für Benutzer (mind. für Admin) X
23. Hilfefunktion X
24. Application-Sharing (z. B. für die Erstellung eines Mindmaps, Einbindung des gewünschten Tools >> X
Programm zur Stundenplan-Entwicklung etc.) (webfähig)
25. Video- / Tonübertragung Einbindung des gewünschten Tools >> X
(z.B. Audio: Skype)Beispiel–Anforderungskatalog:
-Administration-
NEED 2have NICE 2have
26. Anlegen von Benutzern im System einmalig für alle Funktionen X
27. Automatische Generierung von Login und Passwort X
28. Passwortverwaltung (Benutzer kann Passwort ändern, bei Vergessen eines Passwortes X
wird per Aufforderung ein evtl. neu generiertes an Teilnehmer gemailt)
29. Klassenweises Anlegen von Teilnehmern über Skripte (z.B. über csv-Datei aus der X Anbindung an Ihre
Schulverwaltungssoftware); Löschen von Gruppen Schulverwaltungs-
software
30. Rollenkonzept (Administrator, Lehrer, Schüler, Projektgruppenleiter) X
31. individuelle Rechtevergabe für Teilnehmer, Gruppen und Untergruppen X
durch Lehrer, Admin, Projektgruppenleiter
32. offene Gruppenräume / Gastaccount XBeispiel–Anforderungskatalog:
- Content -
NEED 2have NICE 2have
33. Materialbibliotheksfunktion (Mehrfachnutzung von Inhalten, Zuordnung von Inhalten zu X
Benutzergruppen)
34. Stichwort – Suchfunktion X
35. Einbindung von Fremdcontent X
36. Offenheit der Dateiformate X
37. Autorentool X
38. Prüfungsmodul (Klassenarbeit etc.) X
39. gruppenbezogene und individuelle statistische Auswertbarkeit von Schüler-Aktivitäten X
(welche Module wurden wann wie lange und in welcher Art und Weise bearbeitet?)
Datenschutzrichtlinien der BUW
40. Bereitstellung / Vermittlung von Content (Tauschbörse) X
41. Versionsmanagement XSituation Heute Viele kommerzielle und Open Source Systeme - ca. 250 LMS/LCMS Hohe Anzahl von implementierten Funktionalitäten Systeme überwiegend nicht kompatibel Anwender wünschen verschiedene Funktionalitäten von einzelnen Systemen sowie individuell anpassbare, passgenaue Lösungen Funktionalitäten zwischen Systemen nicht austauschbar oder einzeln auswählbar Mehrere Systeme z.B. in einzelnen Hochschulen im Einsatz (z.B. für Geisteswissenschaften, für Ingenieurwissenschaften,...) Viele kleine Entwicklergemeinschaften (um einzelne Systeme) Noch keine Konvergenz der Systeme erkennbar
LMS/LCMS/Plattform-Strategien Eigene Entwicklung Application Service Provider (ASP) Kommerzielle Lösung Open Source Lösung
Eigene Entwicklung + Maßgeschneiderte Lösung + Geschäftsmodell lässt sich exakt abbilden + Integration in bestehende Infrastruktur “einfach“ + Hohe Flexibilität + Keine Herstellerabhängigkeit - Teuer und aufwändig - Oft Mangel an Wissen und Entwicklungspersonal
ASP Lösung + Konzentration auf Inhalte möglich + Kein technisches Personal und Hardware erforderlich + Kostengünstig bzgl. “total cost of ownership“ – Starke Abhängigkeit vom Anbieter – Starke Einschränkung bzgl. Geschäftsmodell – Inflexibel bzgl. Funktionalitäten
Kommerzielle Lösung + Zur Zeit relativ kostengünstig in der Anschaffung + Hoher Funktionsumfang - Geschäftsmodell wird durch Software vorgegeben - Individuelle Funktionalitäten fehlen - Inflexibel bzgl. Erweiterbarkeit (Quellcodes nicht verfügbar) - Herstellerabhängigkeit (Lizenzen, Inkompatibilität, ....) - Risiko durch Marktbereinigung (Herstellerfirmen verschwinden)
Open Source Lösung + Kostengünstigste Alternative in Anschaffung und Betrieb + Flexibel bzgl. Erweiterbarkeit (Verfügbarkeit von Quellcodes) + Keine Herstellerabhängigkeit + Verwendung offener Standards – Teilweise “unausgereifte“ Implementierungen – Häufig fehlender kommerzieller Support
Produktunabhängige Prüfkriterien
Kommerzielle Systeme / Open Source Systeme
Hersteller/Entwickler/Vertrieb:
Langfristige Bindung
Abhängigkeiten
Kosten:
Lizenz- und Erwerbskosten
Updates, Anpassungen, Erweiterungen
Support u. Supportkosten
Folgekosten
Qualität u. Qualitätsmanagement
Systemsicherheit
Investitionssicherheit
TCO (Total Cost of Ownership)Rechtliche, ökonomische und technologische
Grundlagen von Open Source-Software
• Zentrale komparative Konkurrenzvorteile von Open Source
versus Closed Source
– Sicherheit durch transparente Entwicklung
– Modulare Architekturen fördern Wiederverwendung
– Keine Lock-In-Effekte durch offene Standards
– Tendenziell niedrigere Total Costs of Ownership (TCO)
• Potenzielle Problembereiche
– Koordinationsmängel bei der langfristigen
Systemplanung
– Qualitätsdefizite in der Software-Wertschöpfungskette
• Support
• Fehlermanagement
• ...Wirtschaftlichkeitsbetrachtung
- Kosteneffekte -
Entwicklungskosten Betriebskosten
Planungskosten Lfd. Kosten für Server
+ -
Anschaffungskosten -- Total Cost Lfd. Kosten für
-
Software of Arbeitsplatzrechner
- Ownership --
Anschaffungskosten Kosten für Wartung
Hardware
(TCO) und Administration
+ +
Kosten der Schulungs- und
Systemeinführung Supportkosten
Legende
+ Steigerung der TCO
- Senkung der TCOStrategischer Bezugsrahmen
Technologische Erfolgsfaktoren Organisatorische Erfolgsfaktoren
- Erweiterbarkeit
- Wiederverwendbarkeit - Kompetenzen zur
- Interoperabilität kollaborativen Entwicklung
- Herstellerunabhängigkeit - Lernfähigkeit
- Skalierbarkeit - Organisatorischer Fit
Open Source
Systeme
Wirtschaftliche Erfolgsfaktoren
- Senkung der Anschaffungskosten
- Senkung der Wartungskosten
- Senkung der
AdministrationskostenProzessfaktoren
CampusSource-Kontakt Internet: www.campussource.de E-Mail: campussource@campussource.de Tel.: 02331 / 987 - 4258/4257 Fax: 02331 / 987 - 4384 CampusSource Geschäftsstelle bei der FernUniversität in Hagen Universitätsstraße 11, D - 58097 Hagen Kontakt: manfred.postel@campussource.de
Sie können auch lesen
