Systémová implementace elektronické podpory výuky (případová studie)

Abstrakt: Při nasazování rozmanitých systémů pro elektronickou podporu výuky se můžeme setkat s různým pojetím jejich technické implementace. Použitá architektura však má obvykle zásadní vliv na dostupnost a škálovatelnost systému v produkčním provozu, a proto se může stát její vhodný výběr kritický pro následnou životaschopnost celého výukového prostředí. Tato spíše technicky orientovaná případová studie má za cíl prakticky předvést některé základní myšlenky na příkladu Informačního systému Masarykovy univerzity a diskutovat možné výhody a úskalí na modelových ukázkách.

I. Úvod

Problematika výběru vhodného systému pro elektronickou podporu výuky (LMS) je pro mnohé zájemce o využití informačních technologií ve výuce stále aktuálním tématem. Přirozeným kritériem výběru pro takový systém je obvykle množství, rozmanitost a propracovanost jednotlivých možností a nástrojů usnadňujících výuku, které dané prostředí poskytuje. Vedle toho však existují další kritéria, která nemusí být pro základní určení vhodnosti produktu podstatná, ale mohou výrazně ovlivnit jeho produkční nasazení a rutinní provoz. Tento článek má za cíl diskutovat právě takové charakteristiky LMS, které se mohou projevit teprve v případě masivního nasazení. Na rozdíl od čistě aplikačního pohledu (hodnocení funkcí poskytovaných systémem) se jedná spíše o systémovou či implementační charakteristiku. Ukazuje se však, že i toto hledisko je pro nasazení nástrojů elektronické podpory výuky důležité (mnohdy dokonce kritické), a proto má smysl je zohlednit již při samotném výběru systému.

Přestože se nyní zaměříme spíše na implementační část, není cílem tohoto příspěvku detailně hodnotit konkrétní technické postupy, které mohou být při tvorbě a nasazení systému použity. Namísto těchto detailů se spíše zaměříme na obecnější charakteristiku systémů, která má na konkrétní implementaci vliv.

Základem pro naše uvažování budou některé vlastnosti LMS, které jsou pro provoz systému a jeho další rozvoj v organizaci důležité. Při výběru jednotlivých řešení nám tyto vlastnosti pomohou odlišit konkrétní technické implementace, které dodavatel či autor řešení nabízí. Vedle obecné charakteristiky se zaměříme na konkrétním příkladu Informačního systému Masarykovy univerzity v Brně (IS MU) na možnosti, jak lze v praxi takových vlastností dosáhnout. Praktické zkušenosti z téměř sedmiletého vývoje a provozu v masivním prostředí mohou případně pomoci předejít problémům, které mohou v souvislosti s nevhodně zvolenou architekturou systému vyvstat.

Důležitým faktorem při našem uvažování je rozdíl v pojetí nástrojů e-learningu. Pokud jsou funkce pro elektronickou podporu výuky užitečným avšak pouze volitelným doplňkem povinných kurzů případně povinnou součástí volitelných kurzů, nejsou nároky kladené na LMS tak velké, jako v případě, kdy je jeho využití vnímáno jako součást běžné univerzitní výuky napříč všemi obory.

II. Vymezení problematiky

1. Rozšiřitelnost

V případě tvorby elektronických kurzů zaměřených na jeden obor (oblast) je modifikace požadavků snadnější. Často lze totiž upravit možnosti samotných kurzů tak, aby kopírovaly možnosti příslušného LMS. V případě využití pro širokou škálu specifických výukových oborů však dříve či později narazíme na požadavky, které daný LMS neumožňuje a bez kterých nejenže je práce málo efektivní, ale vůbec se bez nich neobejdeme.

V takovém případě je nutné, aby byl LMS otevřený změnám. Toho lze docílit příslušnou smlouvou s dodavatelem případně využitím některého z LMS distribuovaných formou open-source software. Pak změnám nic nebrání a lze s výhodou upravit funkcionalitu tak, aby přesně vyhovovala potřebám organizace.

Open-source software však může mít vzhledem k rozšiřitelnosti i nevýhody. V případě, že změny, které pro svoje potřeby organizace provede, nejsou akceptovány původním autorem, je nutné provozovat a zejména udržovat vlastní verzi LMS, která bude jednak obsahovat vlastní úpravy a jednak umožní zohlednit změny, které byly promítnuty do původního software. Některé open-source projekty (například jádro operačního systému Linux) lze tímto způsobem poměrně dobře udržovat v několika rozných klonech. Ne vždy je to však takto možné. V případě velkého množství požadavků, které jsou v rámci nasazení implementovány samostatně (nejsou součástí původního projektu) tak může být provoz méně efektivní, než údržba vlastního LMS.

Vývoj vlastního LMS však není možný vždy. Zejména menší organizace bez dostatečného zázemí jsou proto odkázány na kompromis mezi vlastními požadavky, cenou za jejich implementaci a možnostmi, které existující implementace LMS nabízí. Minimálně tento kompromis je nutné uvažovat při nasazení LMS s ohledem na jeho funkční rozšiřitelnost.

2. Škálovatelnost

Pokud uvažujeme o nasazení LMS pro účely v rámci výuky jednoho oboru - například omezeného množství kurzů, které vyučuje jedna katedra či jedno školící centrum, lze potřebnou kapacitu pro dosažení požadovaného výkonu poměrně snadno odhadnout. Pokud však je cílem vybudování integrovaného prostředí pro celou organizaci (univerzitu, společnost s mnoha pobočkami) kde je elektronická podpora výuky považována za jeden ze strategických cílů, musí tomu být přizpůsobena i technická infrastruktura zvoleného LMS.

Skutečnost, že konsolidace výpočetních prostředků v rámci integrace organizace není jednoduchou otázkou, dokazuje dnešní vývoj i v dalších oblastech jako například oblast podnikových informačních systémů a na ně navázaných aplikací. Z technického hlediska jsou požadavky kladené na LMS podobného charakteru a proto implementace LMS může řešit stejné problémy. Efektivní dosažení požadovaného výkonu, který v mnoha případech navíc není dopředu odhadnutelný, je proto další důležitou otázkou, kterou si musí provozovatel LMS klást, aby jeho systém byl v praxi použitelný.

3. Schopnost integrace

Pokud tedy elektronické nástroje nejsou pouhým doplňkem běžné výuky, ale naším cílem je jejich nasazení do rutinního výukového procesu, je nutné, aby systém, který tyto nástroje zpřístupňuje, byl schopen transparentní spolupráce s ostatními procesy uvnitř organizace. Základem pro takovou integraci je jistě schopnost automatického přenosu dat mezi jednotlivými systémy a jejich promítnutí do provozu všech komponent. Přestože ani tyto mechanismy nemusí dnes být vždy běžnou součástí všech LMS, jejich implementace není hlavním problémem, neboť obvykle předpokládají, že primárním zdrojem dat je vždy jeden ze systémů. Naopak náročnější překážky je nutné překonat ve chvíli, kdy stejné údaje mohou být generovány různými systémy rovnocenně a jejich zpracování není prováděno dávkově. Pak je nutné implementovat synchronizaci takovýchto údajů na obou stranách vzájemné komunikace, což nemusí být vždy jednoduché a v některých případech vůbec možné. Uvažujeme-li o efektivním nasazení LMS do již existující výpočetní infrastruktury, může hrát volba LMS s ohledem na jeho integraci v rámci organizace rovněž podstatnou roli při jeho výběru.

4. Dostupnost

Problém schopnosti systému izolovat chybu od běžného provozu totiž velice úzce souvisí se schopnosti systému škálovat vlastní výkon. V případě tzv. on-line transakčního zpracování dat, ke kterému uvnitř LMS ve skutečnosti dochází, je nutné zajistit konzistenci uchovaných dat i v případě, kdy přístup k nim je distribuován na jednotlivé nezávislé komponenty. Distribuovaná správa souběžného přístupu k datům je však v masivním nasazení neefektivní a proto ji není možné jednoduše použít bez ohledu na výkon celého systému.

III. Praktický příklad

Nyní se zaměříme na konkrétní zkušenosti, které byly získány v souvislosti s vývojem a následným provozem Informačního systému Masarykovy univerzity v Brně (IS MU). Ačkoliv původním posláním IS MU, který začal v současné podobě vznikat v roce 1998, bylo zajistit administrativu spojenou s běžnou univerzitní výukou, rozsah problému, který systém řeší je podobný tomu, který řeší LMS. Zkusme proto nyní ve stručnosti shrnout některé důvody, které vedly k rozhodnutí implementovat strategické prvky LMS přímo v rámci IS MU, namísto využití některého z již existujících řešení.

První z námi diskutovaných vlastností byla rozšiřitelnost LMS. Ačkoliv některé z dostupných řešení LMS jsou distribuovány formou open-source software, ukázalo se, že uživatelské požadavky napříč univerzitou hluboce přesahují možnosti, které tyto systémy umožňují. Naskýtá se tedy otázka, zda je efektivní tyto potřeby implementovat do již existujícího systému, neboť takové zásahy do kódu nejsou dlouhodobě udržitelné. Správce systému tak je na jedné straně limitován možnostmi, které mu dávají autoři a na straně druhé požadavky, které mu klade samotná organizace. Limity, které tento přístup umožňuje tak jsou ve velkém měřítku poměrně snadno dosažitelné, čímž se stává výhodnější varianta integrace nových nástrojů přímo jako součást již existujících možností pro efektivnější běh kurzů.

I přes tyto zkušenosti není cesta vlastního vývoje LMS jistě jedinou možností, pokud se jedná pouze o možnost rozšíření systému. Nasazení vlastních analytiků, vývojářů a techniků pro úpravu, správu a provoz vlastní verze původně open-source projektu je také možné. Přestoupíme-li však k druhému požadavku - škálovatelnosti - získává možnost integrace do již existujícího systému, v případě Masarykovy univerzity, na mnohem vyšší důležitosti. Souběžné zpracování požadavků velkého množství paralelně přistupujících uživatelů totiž vyžaduje netriviální infrastrukturu, jejíž náklady na provoz a pořízení jsou výrazně závislé na počtu operací, které systém nejen běžně zpracovává, ale dokáže obsloužit i v případě dočasných zátěži (nemluvě o schopnosti efektivně obsloužit výrazné zátěžové Špičky a přetížení). Udržování takovéto infrastruktury pro dva paralelní systémy je méně efektivní, než částečné navýšení z důvodu obsluhy nových funkcí elektronické podpory výuky pro stávající infrastrukturu.

Pokud tedy organizace, jako tomu bylo v případě Masarykovy univerzity, disponuje dostatečně škálovatelnou infrastrukturou, bylo výhodnější využít ji i pro realizaci nástrojů elektronické podpory výuky. V případě, že organizace žádnou takovou integrační infrastrukturou nedisponuje a je nutné ji vytvořit přímo pro potřeby příslušného LMS, je potřeba zvážit, zda architektura a technologie použitá v návrhu zvažovaného LMS dokáže nejen pojmout velké množství uživatelů (celkový počet aktivních uživatelů se za celou dobu provozu IS MU od běhu na dvouprocesorovém serveru až po systém s výkonem několika desítek procesorů řádově nezměnil), ale i jejich souběžnou aktivní práci.

V případě nasazení nástrojů elektronické podpory výuky jako součást běžného života Masarykovy univerzity bylo nutné také zajistit jejich integraci se stávající infrastrukturou. Tam, kde je administrativa spojená se studiem řízena stále klasickými prostředky a výhod informačních technologií ještě není plně využito, je problém integrace spíše okrajový. Pokud však chceme nové nástroje efektivně spojit s existujícími možnostmi (například automatické navržení hodnocení na zakládá bodů v písemném testu může být snadno doplněno o podobnou funkci pracující nad elektronickými testy a pod.), je jejich integrace naprosto klíčová. Připustíme-li navíc, že žádný z dostupných LMS není přímo určen pro prostředí českých vysokých škol, je skutečná integrace do vysokoškolského prostředí ještě náročnější, než je tomu například při využití LMS pro potřeby lokální pobočky nadnárodní organizace, která se řídí svými globálními interními pravidly.

Posledním zmiňovaným úkolem provozovatelů LMS je zajištění dostupnosti systému i v případě chyby v hardwarové nebo softwarové realizaci. Udržení systému větší velikosti reálně v nepřetržitém chodu vyžaduje velké investice. Pokud navíc vyžadujeme, aby žádná chyba způsobená uvnitř jedné komponenty neovlivnila ostatní části, je nutné využít pro běh systému dosud méně rozšířené technologie. Ne každý LMS dostupný na trhu je ale pro takové prostředí vhodný. Budujeme-li spíše systém lokálního charakteru, který napomáhá studentům ve výuce, nemusí být striktní důraz na nepřetržitou dostupnost vzhledem k neúměrně vysokým nákladům nutný. Pokud se však elektronické nástroje stávají běžnou povinností studenta, musí infrastruktura zajistit, že student je bude moci využít stejně tak, jako může využít volných lavic v posluchárně v případě klasické výuky. Přístup musí být zajištěn například bez ohledu na to, v jakém časovém pásmu se vyučující nebo student na své stále rozšířenější zahraniční stáži vyskytuje. V případě Masarykovy univerzity bylo tedy výrazně vhodnější využít stávající infrastrukturu pro nepřetržitý chod systému také pro běh prvků elektronické výuky přímo v rámci IS MU.

IV. Závěr

Cílem tohoto příspěvku bylo upozornit na pouze některé možné problémy, které se mohou při konkrétní implementaci LMS objevit. Příslušné technické detaily, jak jednotlivé vlastnosti konkrétně zajistit jsou však již nad rámec jeho původního určení. Konference SCO 2005 je však jistě vhodnou platformou pro jejich hlubší diskusi a to nejen mezi odborníky na elektronickou podpory výuky navzájem, ale i v rámci příslušné organizace, která se pro masivní nasazení těchto technologií rozhoduje nebo je v nějaké míře již provozuje a na zmíněné problémy sama narazila.