DIPLOMSKA NALOGA · 2020-01-30 · diplomska naloga z naslovom Uporaba sistema za upravljanje z učnimi vsebinami v velikih skupinah, pri mentorju doc. dr. Marjanu Krašni in somentorju

UNIVERZA V MARIBORU

FAKULTETA ZA NARAVOSLOVJE IN MATEMATIKO

ODDELEK ZA MATEMATIKO IN RAČUNALNIŠTVO

DIPLOMSKA NALOGA

Bojan Bedrač

Maribor, 2008

UNIVERZA V MARIBORU


ODDELEK ZA MATEMATIKO IN RAČUNALNIŠTVO

Diplomska naloga

UPORABA SISTEMA ZA UPRAVLJANJE Z UČNIMI

VSEBINAMI V VELIKIH SKUPINAH

Mentor:

doc. dr. Marjan Krašna

Somentor:

izr. prof. dr. Ivan Gerlič

Kandidat:

Bojan Bedrač

Maribor, 2008

Zahvala

Ob koncu tega dela bi se rad iskreno zahvalil svojim bližnjim za podporo med

študijem in med nastajanjem tega dela. Zahvalil bi se tudi ostalim, ki so mi v tem

času stali ob strani, ter študijskim kolegom za čas in pomoč, ki so mi ju namenili

v času študija. Hvala mentorju doc. dr. Marjanu Krašni in somentorju izr. prof. dr.

Ivanu Gerliču za strokovno vodenje in pomoč pri nastajanju dela.

UNIVERZA V MARIBORU


IZJAVA

Podpisani Bojan Bedrač, roj. 19.07.1982, študent Fakultete za naravoslovje in

matematiko Univerze v Mariboru, smer Računalništvo in tehnika, izjavljam, da je

diplomska naloga z naslovom Uporaba sistema za upravljanje z učnimi vsebinami

v velikih skupinah, pri mentorju doc. dr. Marjanu Krašni in somentorju izr. prof.

dr. Ivanu Gerliču, avtorsko delo. V diplomski nalogi so uporabljeni viri in

literatura korektno navedeni; teksti niso prepisani brez navedbe avtorjev.

_____________________

(podpis študenta)

Maribor, 10.3.2008

Program diplomskega dela

V diplomskem delu preverite možnosti, ki jih ponuja LMS Moodle v primeru

velikih skupin udeležencev. Kako ga je mogoče nadgraditi s svojimi

programskimi moduli, če nam osnovna postavitev ne ustreza (za primer

pedagoške prakse) in kje so njegove meje ob različnih scenarijih uporabe. Prav

tako preverite na katerem sistemu se Moodle bolje obnaša (WAMP ali LAMP) in

sestavite priporočila za postavitev sistema v izobraževalnih ustanovah.

Osnovni viri:

• Rohan, Rebecca Frances, Building better Web pages, 1998.

• Hanke, Johann-Christian ;Šuler, Aleš, Spletne strani in HTML : [naj

ostane preprosto!] , 2001

• Sharp, John ;Jagger, Jon, Microsoft Visual C # .NET, 2002

Mentor: doc. dr. Marjan Krašna

Maribor, 10. 1. 2008

Uporaba sistema za upravljanje z učnimi vsebinami v velikih skupinah

Povzetek

Uporaba sistemov za upravljanje z učnimi vsebinami je v porastu, predvsem pri

izvajanju e-izobraževanja v prvi osebi ali na daljavo. V diplomski nalogi sem

predstavil razvoj razširitve sistema Moodle, za potrebe spremljanja pedagoške

prakse študentov. Tehnične zahteve strojne opreme za podporo delovanja sistema

so običajno okvirne in grobo zastavljene. Namen te diplomske naloge je bil tudi

praktično preizkusiti delovanje odprtokodnega sistema za upravljanje z učnimi

vsebinami, Moodle, v velikih skupinah. Obremeniti sistem z več sto uporabniki in

izmeriti odzivnost sistema, kot bi se odzival v resničnih situacijah.

Ključne besede

Sistemi za upravljanje z e-učnimi vsebinami, Moodle, Ergonomija odzivnih

časov, E-izobraževanje, Izobraževanje na daljavo, Razvoj razširitve za Moodle

Application of Learning Management System for large groups

Abstract

Two main topics I am covering in my thesis are engineering additional

functionality in Moodle E-learning system without affecting the existing structure

of the application and stress testing of the Moodle E-learning system, to asses the

capacity of existing Moodle installations and to produce basic guidelines for

planning and evaluation of future Moodle installations. In order to asses the

capacity of existing Moodle installations a program called »Moodle stress test

tool« was created to aid in the process of evaluating and monitoring response

times under heavy use of the system.

Keywords

E-learning systems, Moodle, Response times, Distance learning, Engineering

Moodle modules

Kazalo vsebine

1 UVOD .................................................................................................................. 1

2 VELIKE SKUPINE IN SISTEMI ZA UPRAVLJANJE Z UČNIMI

VSEBINAMI ....................................................................................................... 4

2.1 Definicija velike skupine ................................................................................. 4

2.2 Problemi velikih skupin .................................................................................. 5

2.2.1 Komunikacijski in organizacijski problemi velikih skupin ..................... 5

2.2.2 Odzivni čas .............................................................................................. 6

2.2.2.1 Komponente odzivnega časa ........................................................... 6

2.2.3 Hkratni dostopi ...................................................................................... 13

2.2.4 Ergonomija odzivnega časa ................................................................... 14

2.2.5 Spremenljiva psihologija uporabnikov .................................................. 17

2.3 Sistemi za upravljanje z e-učnimi vsebinami .............................................. 18

2.3.1 Komercialni sistemi ............................................................................... 20

2.3.1.1 Blackboard ..................................................................................... 20

2.3.1.2 Apex learning ................................................................................ 20

2.3.1.3 Desire2Learn ................................................................................. 21

2.3.2 Odprtokodni sistemi .............................................................................. 21

2.3.2.1 Manhattan Virtual Classroom ....................................................... 23

2.3.2.2 Dokeos ........................................................................................... 24

2.3.2.3 Moodle ........................................................................................... 25

3 RAZISKOVALNI CILJI ................................................................................. 26

4 RAZISKOVALNA IZHODIŠČA ................................................................... 28

5 METODOLOGIJA .......................................................................................... 28

6 PRAKTIČNI DEL ............................................................................................ 29

6.1 Razvoj lastnega modula v sistemih za upravljanje z e-učnimi

vsebinami ....................................................................................................... 29

6.1.1 Vsebina in namen e-gradiva .................................................................. 29

6.2 Razvoj lastnega modula za sistem za upravljanje z e-učnimi vsebinami

Moodle ............................................................................................................ 32

6.2.1 Podatkovna struktura ............................................................................. 33

6.2.2 Programska koda ................................................................................... 35

6.2.3 Oblikovanje ........................................................................................... 37

6.2.4 Aktivnosti udeležencev v procesu ......................................................... 38

6.2.4.1 Študent ........................................................................................... 38

6.2.4.2 Mentor ........................................................................................... 42

6.2.4.3 Predmetni didaktik ........................................................................ 44

6.2.5 Zaključek ............................................................................................... 44

6.3 Obremenitev sistema za upravljanje z e-učnimi vsebinami Moodle ........ 45

6.3.1 Spremenljivke ........................................................................................ 46

6.3.2 Testno okolje ......................................................................................... 46

6.3.3 Priprava sistema za upravljanje z e-učnimi vsebinami Moodle ............ 47

6.3.4 Program Moodle stress test tool ............................................................ 48

6.3.4.1 Delovanje programa ...................................................................... 52

6.3.5 Primerjava postavitev sistema Moodle v okolju Windows in Linux .... 55

6.3.5.1 Testno okolje ................................................................................. 56

6.3.5.2 Izvedba testiranja in zaključki ....................................................... 57

6.3.6 Obremenitev sistema Moodle na fakultetnem strežniku ....................... 61

6.3.6.1 Izvedba testiranja in zaključki ....................................................... 62

7 SKLEP ............................................................................................................... 69

8 LITERATURA ................................................................................................. 72

1

1 Uvod

Izobraževanje je že pred časom prešlo iz klasičnih načinov izobraževanja na

moderne načine. V izobraževanje so se začeli vpeljevati multimedijski gradniki,

kot so zvok, slika in video, s katerimi se dosegajo različni nivoji interaktivnosti

[3]. Učitelja v določeni meri nadomestijo multimedijski gradniki, učenec pa lahko

izobraževanje izvaja tudi samostojno takrat, ko mu to ustreza. Dodaten korak

naprej predstavlja tudi vse bolj razširjeno e-izobraževanje oz. izobraževanje na

daljavo z uporabo interneta. V ta namen se uporabljajo sistemi za upravljanje z

učnimi vsebinami [4] (v nadaljevanju sistemi za upravljanje z e-učnimi

vsebinami). Takšen način izobraževanja v primerjavi s klasičnim izobraževanjem

pridobi nekaj dobrih lastnosti, pridobi pa tudi nekaj slabih lastnosti, ki so

povezane s tehnično izvedbo in organizacijo takšnega izobraževanja. Prednosti, ki

jih takšno izobraževanje prinaša so v prvi vrsti širši krog ljudi, ki jih lahko takšno

izobraževanje doseže in cenovna ugodnost, ter prilagodljivost. Slabosti so vezane

pretežno na tehnično izvedbo takšnega izobraževanja, s tem mislim predvsem na

stroške, ki so povezani z vzpostavitvijo sistemov za izobraževanje na daljavo.

Dodatne slabosti so v izgubi stika med učiteljem in učencem, kar deloma

nadomesti komunikacija preko spletnih medijev, prinaša pa dodatno slabost, da

učitelj nima več natančno definiranega delovnega časa, saj mu to prinaša dodatno

delo.

V okviru projekta Partnerstvo fakultet in šol 21, smo za potrebe spremljanja

študentov na opazovalni pedagoški praksi potrebovali sistem, s katerim bi

omogočili komunikacijo med vsemi vpletenimi v proces. Razvoj takšnega sistema

bi zahteval preveč časa, zato smo se odločili, da uporabimo že obstoječi sistem, ki

se uporablja za upravljanje z e-učnimi vsebinami na fakulteti [6]. Napisal sem

modul, ki ga je bilo mogoče vključiti v sistem in je uporabljal osnovno

podatkovno strukturo sistema, omogočal pa je dodatno funkcionalnost, ki smo jo

potrebovali. Delovanje modula smo preizkusili v praksi na 24 študentih, 13

mentorjih in 6 predmetnih didaktikih in sodelavcih. Izvedba projekta in uporaba

1 Več informacij na http://www.pfmb.uni-mb.si:8080/partnerstvo/default.aspx

2

modula je tekla po pričakovanjih in za uporabnike ni zahtevala dodatnega učenja,

saj je modul uporabljal obstoječo arhitekturo in delovne poti. Vsi udeleženi v

procesu so pozdravili takšen način spremljanja dela in komunikacije, zato bo v

prihodnje preko tega sistema sodelovalo še več uporabnikov. S predvidenim

porastom uporabnikov, smo začeli razmišljati tudi o maksimalni količini oz.

maksimalnem številu uporabnikov, katerim bi sistem še omogočal nemoteno delo.

Pri vzpostavitvi sistemov za upravljanje z e-učnimi vsebinami, se ljudje večinoma

opirajo na tehnične specifikacije strojne opreme, le malokrat pa na dejanske

zahteve aplikacije, preko katere se izvaja e-izobraževanje. Za delovanje sistema za

upravljanje z e-učnimi vsebinami potrebujemo s tehničnega vidika tri ključne

komponente. Strežnik, ki je lahko tudi močnejši osebni računalnik, v

profesionalnih okoliščinah pa mora biti samo temu posvečen strežniški

računalnik. Na strežniškem računalniku morata biti nameščena spletni in

podatkovni strežnik. Tretja, bistvena komponenta pa je aplikacija oz. program, ki

omogoča izvajanje izobraževanja na daljavo in upravljanje z e-učnimi vsebinami.

Izbira je vedno v rokah izvajalca, tako na področju izbire strežnikov, kot na

področju izbire aplikacije. Pri izbiri komponent je potrebno upoštevati več

dejavnikov oz. zahtev. Ocenitev teh dejavnikov pa je tisti korak, ki ga izvajalci

večkrat izpustijo in le grobo ocenijo, saj nimajo pravega orodja za ocenjevanje

zahtev in to nemalokrat vodi do predimenzioniranja ali še hujše do preslabo

zastavljenega sistema, ki ne zadosti zahtevam. Tako se v obeh primerih soočamo s

težavo. Če smo sistem predimenzionirali, smo brez razloga porabili preveliko

denarja, če pa smo ga zastavili preslabo, potem ne bo zadostil zahtevam, kar

vsekakor ni naš namen in lahko v nadaljevanju pomeni celo dražjo rešitev, kot

predimenzioniranje.

Forum enega od proizvajalcev sistemov za upravljanje z e-učnimi vsebinami je

poln objav udeležencev (uporabnikov), ki se sprašujejo kako oceniti zahteve in

temu ustrezno določiti zmogljivosti komponent, ki naj jih kupijo. Na tržišču je kar

nekaj programov, ki so namenjeni testiranju strežnikov. Običajno takšni programi

obremenijo sam strežnik, kar pa ni pravi pokazatelj, kako bi se naša aplikacija

obnašala v resničnih situacijah. Sam strežnik recimo lahko v konici zahtev

3

sprejme sto hkratnih zahtev, vse nadaljnje pa začne zavračati, vendar to ne

pomeni, da je zgornja meja sto hkratnih uporabnikov. Zelo mala verjetnost je, da

bi vseh sto uporabnikov poslalo strežniku zahtevo v istem trenutku. Torej se te

zahteve bolj porazdelijo in četudi sistem uporablja več sto uporabnikov hkrati, bi

število hkratnih zahtev mogoče nikoli ne preseglo nekaj deset zahtev. To so

seveda le ugibanja in ocene, ki jih nameravam v sklopu te diplomske naloge

preizkusiti in dokazati. Obremenitve strežnika so različne tudi glede na vsebine, ki

jih ponujamo v sistemu za izobraževanje na daljavo, zato število uporabnikov ni

glavni dejavnik prepustnosti takšne aplikacije.

4

2 Velike skupine in sistemi za upravljanje z učnimi

vsebinami

2.1 Definicija velike skupine

Pri definiranju velikosti skupine se srečamo s prvo težavo, kako pravilno oceniti

velikost skupine. Ugotovimo, da je definicija velikosti skupine odvisna od

okoliščin, v katerih je ta skupina definirana. Za analogni primer uporabimo

skupino turistov, ki jih vodi en sam turistični vodič. Za enega vodiča je že skupina

petdesetih turistov lahko obravnavana kot velika skupina. V svetu interneta, kjer

so relacije med udeleženci skupine nekoliko drugačne, pa skupina petdesetih

uporabnikov nekega spletnega mesta velja za manjšo skupino. Razlika izhaja

ravno iz specifičnosti relacije med udeleženci, ki v tem primeru ni konstantna med

tistim, ki vodi in tistimi, ki sledijo. Relacija med udeleženci se vzpostavi po

potrebi, zato je skupina, čeprav po velikosti večja od skupine turistov, po številu

hkrati vzpostavljenih relacij med udeleženci, manjša. Ta učinek se doseže z

načinom dela, ki mu pravimo objavljanje oz. oddajanje. Tisti, ki vodi skupino

objavi informacijo, ki je pomembna za udeležence, bodisi za vse, bodisi za

posameznike. Udeleženci potem neodvisno od vodje skupine to informacijo

obdelajo in na osnovi te informacije ustrezno reagirajo. Neposredne relacije med

udeleženci se vzpostavljajo le po potrebi, zato takšne skupine niso neposredno

obremenjene s številom udeležencev.

V svetu interneta je definicija velike skupine prepuščena več dejavnikom. Eden od

dejavnikov je ustrezna zmogljivost strojne opreme, da vzdržuje stik med

udeleženci skupine. Pomemben dejavnik je tudi sistem, ki te udeležence združuje,

saj mora zagotavljati ustrezno strukturo in funkcionalnost, da se relacije med

udeleženci na enostaven način beležijo in shranjujejo, da jih lahko udeleženci

zaznajo in na njih ustrezno reagirajo. Velike skupine so v svetu interneta različno

velike, od nekaj sto uporabnikov do več tisoč uporabnikov. Najpomembnejši

dejavnik, ki definira velikost takšnih skupin pa je njihova aktivnost. V primeru, da

imamo več tisoč uporabnikov, ki so zelo neaktivni, lahko takšno skupino brez

slabe vesti definiramo kot majhno. Za potrditev te trditve, poglejmo enostaven

5

izmišljen primer »velike« skupine s sto tisoč uporabniki. Od teh sto tisoč

uporabnikov je le petsto uporabnikov stalno aktivnih. Za definiranje takšne

skupine lahko potem vzamemo, da ima skupina le petsto članov. Preostali člani, ki

niso aktivni, ne prinašajo obremenitev skupini in so zato v definiciji takšne

skupine nepomembni ter jih lahko zanemarimo.

Iz tega sledi, da so za definiranje velikosti skupine pomembni le aktivni

udeleženci. V nadaljevanju bom, ko bom govoril o velikosti določene skupine, s

tem mislil na število njenih aktivnih članov. Aktivnost teh članov predstavlja

obremenitev sistema in strojne opreme.

2.2 Problemi velikih skupin

Pri obvladovanju velike skupine naletimo na podobne težave, kot turistični vodič,

ki obvladuje skupino turistov. Zaradi velikosti skupine, ki je neprimerno večja od

skupine turistov, pa se začnejo kazati tudi druge težave, ki jih pri manjših

skupinah ni. Organizacija takšne skupine zahteva več nivojsko hierarhijo

udeležencev. Običajno imamo vsaj dva nivoja, s čimer zagotavljamo dovolj

visoko stopnjo kontrole in koordiniranja med udeleženci. Kar hočemo doseči je

objavljanje oz. oddajanje sporočil tistih članov, ki so višje na lestvici in

odgovarjanje oz. dialog tistih, ki so na lestvici nižje. S tem dosežemo, da je

celotna skupina informirana o temah, ki so za njih pomembne in hkrati

dopuščamo dialog med udeleženci o temah, ki se jim zdijo pomembne, brez

vpliva na tiste člane, ki jih ta dialog ne zanima.

2.2.1 Komunikacijski in organizacijski problemi velikih skupin

Težave v komunikaciji izvirajo iz številčnosti članov in so deloma rešene že v

organizaciji skupine. V sistemu želimo količino komunikacij čim bolj zmanjšati.

Število hkratnih komunikacijskih sej določa eno največjih obremenitev sistema za

izobraževanje na daljavo. Komunikacija med člani skupine ni rešena z uporabo e-

pošte, saj bi to pomenilo, da bi bilo vsako sporočilo člana skupine pomnoženo s

številom članov skupine in bi v primeru velike aktivnosti članov pomenilo

ogromne količine podatkov, ki bi se morali prenašati po omrežju oz. se shranjevati

6

v sistemu in ga nepotrebno obremenjevati. Težava je rešena z uporabo objav oz.

oddaj, kar pomeni, da je vsako sporočilo le objavljeno, člani skupine pa o tem ne

prejmejo nobenega obvestila. Preverjanje novosti v sistemu je tako prepuščeno

samim članom, kar lahko včasih vodi do neobveščenosti. S tehničnega stališča je

ta rešitev boljša, saj pomeni za vsako sporočilo člana le eno objavo takšnega

sporočila. Odpade torej nepotrebna komunikacija med sistemom in člani, s tem pa

tudi obremenitev omrežja in sistema.

2.2.2 Odzivni čas

Spletne aplikacije delujejo po principu zahteva/odziv [9]. Uporabnik z uporabo

brskalnika poda zahtevo strežniku. Strežnik zahtevo sprejme in začne na osnovi te

zahteve izvajati programsko kodo, ki se običajno v celoti izvede na strežniku. Ko

se ta koda izvede, strežnik uporabniku vrne rezultat – odziv v obliki, ki jo lahko

prikaže uporabnikov brskalnik. Čas, ki preteče med zahtevo uporabnika in

odzivom strežnika, imenujemo odzivni čas. To je dejansko čas med klikom

uporabnika, do prikaza celotnega rezultata zahteve. Odzivni čas je sestavljen iz

več delov oz. komponent.

2.2.2.1 Komponente odzivnega časa

Na odzivni čas, ki ga doživlja uporabnik ob uporabi spletne strani oz. spletne

aplikacije, vpliva veliko dejavnikov. V grobem jih lahko razdelimo v šest

osnovnih spremenljivih dejavnikov [14], ki skupaj določajo skupni odzivni čas, ki

ga doživlja uporabnik. Ti dejavniki so:

• velikost strani,

• najmanjša pasovna širina (prenos),

• čas krožne poti,

• število ciklov,

• čas strežniškega in uporabnikovega procesiranja.

7

Velikost strani

Velikost strani je bila včasih ključnega pomena za odzivni čas. S porastom hitrih

povezav, pa je ta komponenta odzivnega časa izgubila svoj površinski pomen.

Velikost strani sestavljajo poleg HTML kode, tudi velikosti vseh ostalih objektov,

ki so vključeni v stran. Vsekakor je velikost strani še vedno premo sorazmerno

povezana z odzivnim časom, torej večja kot je stran, daljši je odzivni čas. Velikost

strani merimo v bajtih oz. večji enoti kilobajtih. Za določanje velikosti strani z

vsemi vključenimi objekti, lahko uporabimo brezplačno orodje »Web Page

Analyzer«2 ali kakšno drugo orodje, ki je dosegljivo na spletu. Z uporabo tega

orodja, dobimo vse podatke o dejavnikih, ki jih bom opisal v nadaljevanju.

Čeprav namen te naloge ni optimizacija spletne strani oz. spletne aplikacije, mi je

to orodje prikazalo kar nekaj zanimivih rezultatov pri analizi velikosti strani v

sistemu za izobraževanje na daljavo preko spleta [14].

Najmanjša pasovna širina (hitrost prenosa)

Uporabnikova izkušnja je pri normalnem delovanju strežnika, spletne aplikacije in

vmesnih povezav, omejena s pasovno širino (hitrostjo prenosa) na strani

uporabnika. Vendar lahko težave nastopijo tudi v vmesnih povezavah med

uporabnikom in strežnikom. Hitrost prenosa je takšna, kot je hitrost v najožjem

grlu vseh povezav med uporabnikom in strežnikom. Hitrost prenosa merimo v

količini prenesenih podatkov v enoti časa. Običajno se hitrost navaja v številu

prenesenih bitov v eni sekundi. Podatek, ki je bolj uporaben in reprezentativen za

uporabnika pa je hitrost prenesenih bajtov v eni sekundi. Današnje hitre povezave

dosegajo več megabitov na sekundo, pa vendar je potrebno biti pri oblikovanju

spletnih strani oz. pri urejanju strani v sistemu za izobraževanje na daljavo,

previden. Za izračun odzivnega časa, bomo vpeljali enostavno formulo, ki jo

lahko uporabimo, če imamo podatek o velikosti strani in najmanjši pasovni širini

oz. hitrosti prenosa. Surovi čas prenosa lahko izračunamo po naslednji enačbi (1)

[14]:

2 Dosegljivo na naslovu http://www.websiteoptimization.com/services/analyze/

8

�� (1)

�� š�� š��ž�� !"�

Na primeru strani z uporabljeno grafiko in kakšnim objektom za povečanje

interaktivnosti, lahko izračunamo surovi čas za prenos takšne strani iz strežnika k

uporabniku. Predpostavimo, da je velikost strani 800 kilobajtov in da ima

uporabnik povezavo s hitrostjo 1 Mbps. Najprej pretvorimo hitrost povezave iz

bitov v bajte in tako dobimo hitrost 128 kilobajtov v sekundi.

�� #$$� !%&#� !"� � '()�

(2)

Izračun po enačbi (2) nam pokaže, da bi za prenos takšne spletne strani

potrebovali 6,5 sekund. Pri prenosu podatkov se preko omrežja ne prenašajo zgolj

podatki, pač pa se prenašajo tudi kontrolne informacije, ki jih med transportom

doda vsaka izmed plasti, kot je razvidno iz referenčnega modela OSI na sliki 1

[19].

Slika 1: Podatki pri prenosu skupaj z glavami in repi posameznih plasti

9

Legenda oznak:

• LH – glava povezavne plasti • NH – glava omrežne plasti • TH – glava transportne plasti • SH – glava plasti seje • PH – glava predstavitvene plasti • AH – glava aplikacijske plasti • TH – glava repa

Paketi informacij, ki se prenašajo po omrežju so enake velikosti. Pri počasnejši

povezavi, bi prenos takšne spletne strani trajal še dlje. Recimo pri uporabi starejše

modemske povezave (56 K) preko telefonske linije, ki dosega povprečno hitrost

okrog 4 KB/s, bi za prenos takšne strani potrebovali dobre tri minute. S porastom

dostopov do strani preko mobilnih telefonov so nižje hitrosti tudi dejavnik, na

katerega moramo računati. Čeprav je hitrost takšnega prenosa pri zgoraj

uporabljenem izračunu sprejemljiva, bo uporabnik doživel malo daljši čas zaradi

prenosa vsakega objekta posebej.

Čas krožne poti

Čas krožne poti nam določa zakasnitev, ki se pojavi med zahtevo in odzivom

zaradi dejavnikov, ki so prisotni v delovanju omrežja in podomrežij, po katerih

potuje naša zahteva in v končni fazi odziv. To je čas, ki ga merimo od trenutka, ko

se pošlje uporabnikova zahteva strežniku, do trenutka, ko se vrnejo prvi biti

odziva. Na čas, ki preteče vmes, močno vpliva stanje omrežij med uporabnikom

in strežnikom, po katerem podatki potujejo. Za spremljanje časa ene krožne poti,

lahko uporabimo program ping, ki je bil ustvarjen ravno v ta namen. Deluje kot

neke vrste sonar, tako da pošlje po omrežju paketke strežniku in meri čas do

prejema odziva strežnika. Glede na pot teh paketkov po omrežju, je ta čas lahko

različen. Odvisen je tudi od obremenjenosti omrežja po katerem potujejo paketki.

Obremenjenost svetovnega omrežja lahko spremljamo tudi na spletni strani

»Internet Health Report«3, kjer lahko v realnem času spremljamo zastoje na

omrežju. Čeprav čas krožne poti merimo v milisekundah, se lahko ta čas glede na

3 Dosegljiv na naslovu http://www.internetpulse.com

10

obremenjenost omrežja močno spreminja in dosega tudi nesprejemljivo visoke

vrednosti.

Primer izpisa programa ping (v »lokalnem« omrežju)

Slika 2: Izmerjen čas krožne poti v lokalnem omrežju s programom ping

Na primeru, ki ga kaže slika 2 vidimo, da je bil povprečen čas, potreben za krožno

pot poslanega paketka v »lokalnem« omrežju, 0.225 ms. Čas krožne poti je v tem

primeru zanemarljiv. Na drugem, bolj skrajnem primeru, ki ga kaže slika 3 pa

lahko vidimo, da je čas krožne poti že tako visok, da igra pomembno vlogo pri

uporabnikovi izkušnji v interakciji s spletno stranjo. Za primer vzemimo spletno

stran na kitajskem strežniku (www.ctn.com.cn).

Slika 3: Izmerjen čas krožne poti v svetovnem omrežju s programom ping

Če grobo zaokrožimo čas krožne poti, na 500 milisekund za vsak paketek, potem

vidimo, da bi sama zakasnitev pri prenašanju paketkov preko omrežja znašala pol

sekunde za vsak par zahteva/odziv.

Cikli

Običajna spletna stran je sestavljena iz HTML kode in objektov, kot so slike, zvok

in video. Nekateri načrtovalci spletnih strani uporabijo majhne sličice za

oblikovanje strani. Majhne sličice uporabijo zato, da bi uporabnik čim hitreje

dobil informacijo, da se stran prenaša in se med tem, ko čaka na prenos ostalih

sličic in objektov, zamotil s tistimi, ki so se že prenesle. Razlog, zaradi katerega je

11

čas krožne poti pomemben, pa je ravno v velikem številu uporabljenih objektov

na strani. Prej omenjeni čas krožne poti velja za vsak objekt, naj si bo še tako

majhna datoteka. Torej ena sličica pomeni čas krožne poti, kateremu prištejemo še

čas za prenos sličice, glede na njeno velikost. Komunikacija, ki teče med

uporabnikovim računalnikom in strežnikom pri prenosu spletne strani in vsakega

izmed objektov je sestavljena iz štirih krožnih poti (ciklov). V prvem ciklu se

izvede preslikava DNS naslova v IP naslov. V preostalih treh ciklih pa se prenese

vsebina. Moderni brskalniki so zato narejeni tako, da omogočajo izvedbo več

ciklov hkrati, z uporabo več povezav med uporabnikovim računalnikom in

strežnikom. Brskalniki tako omogočajo v povprečju štiri hkratne povezave s

strežnikom in hkratno izvedbo štirih ciklov. Število ciklov lahko enostavno

izračunamo z uporabo enačbe (3) za izračun z uporabo števila objektov [14]. Prvi

štirje cikli so namenjeni preslikavi DNS naslova in prenosu besedilnega dela

spletne strani. Za vsak naslednji objekt so potrebni (brez DNS preslikave) trije

cikli, moderni brskalniki pa zmorejo štiri hkratne povezave, zato število ciklov

delimo s številom štiri.

�*�+,�� - ./ 0 ��123+��

- (3)

Ko smo izračunali število ciklov, ki so potrebni za prenos spletne strani z vsemi

objekti, lahko izračunamo še zakasnitve, ki so posledica delovanja omrežja. Za

primer vzemimo spletno stran s 40 objekti in čas krožne poti iz zgornjega

preizkusa, 432 milisekund.

�4�+��3� � $5-/& 0 6- . / 0 -$- 7 � %-5'##�� (4)

Iz izračuna (4) je razvidno, da je samo zaradi zakasnitev in števila uporabljenih

objektov, čas prenosa spletne strani s strežnika na uporabnikov računalnik, ne

glede na hitrost uporabnikove povezave, dosegel zelo visoko vrednost.

Čas procesiranja

Delo procesorja in njegova moč se merita v frekvenci, s katero procesor deluje, ta

pa določa število operacij, ki jih lahko procesor izvede v eni sekundi. Procesor

12

praviloma vedno deluje pri svoji maksimalni moči, spreminja se le koristna izraba

procesorske moči. Neizkoriščena procesorska moč se izgubi in ne pomeni

zmanjšanja porabe električne energije, razen v posebnih izvedbah procesorjev, ki

podpirajo novejše tehnologije, ki znajo v času neizkoriščenosti oz. slabe

izkoriščenosti procesorske moči znižati frekvenco procesorja in s tem dejansko

zmanjšati njegovo porabo, ob tem pa še vedno zadostiti potrebam po procesorski

moči.

Zadnja dva dejavnika, ki nastopita pri izračunu potrebnega časa za prenos strani

po uporabnikovi zahtevi, sta čas procesiranja zahteve na strežniku in čas

procesiranja odziva v uporabnikovem računalniku. Na strežniški strani je ta čas

odvisen od tipa strani, ki jo uporabnik zahteva. V primeru, ko gre za statično

stran, ki se ne spreminja, je že v uporabnikovi zahtevi podano vse, kar potrebuje

strežnik za serviranje strani. Postopek je potem zelo enostaven in enolično

določen. Strežnik pošlje uporabniku odziv v obliki spletne strani, ki jo je ta

zahteval. Čas procesiranja je v tem primeru minimalen in odvisen od karakteristik

trdega diska v strežniku. V primeru zahteve dinamičnih strani, pa se lahko čas

procesiranja drastično poveča. Čas je lahko potem odvisen od veliko spremenljivk

in procedur, ki se izvedejo pri obdelavi zahteve. Te zahtevajo procesorsko moč in

uporabo spomina. Iz tega sledi, da več kot je takšnih zahtev, več procesorske moči

in spomina je uporabljeno. Zahteve, ki sledijo, so zato lahko včasih v podrejenem

položaju glede na prejšnje zahteve, ki so porabile vsa razpoložljiva sredstva

strežnika in so zato prisiljene počakati v vrsti, kar prinese še dodatne zakasnitve.

Odzivni čas je premo sorazmeren z obremenitvijo strežnika.

Na uporabnikovi strani je tudi tip strani tisti, ki vpliva na čas procesiranja. Z

naraščanjem števila objektov in njihovo kompleksnostjo, narašča tudi čas, ki je

potreben za obdelavo odziva. Na primer uporaba slik, Java apletov in Flash

vsebin, močno poveča čas procesiranja. Tako, kot na strani strežnika, je priklic

statične besedilne vsebine zanemarljivo kratek, medtem, ko je priklic vsebin, ki

vključujejo dinamične komponente spletnih strani, običajno daljši. Razlog tiči v

dejstvu, da večina dinamičnih vsebin potrebuje dodatne programe, ki poleg

brskalnika obdelujejo prejeto vsebino. To so razni predvajalniki za interaktivne

13

oz. multimedijske vsebine, kot na primer Flash, Windows media player, Real

player, Quicktime, Java in ostali. Vsi objekti teh tipov zahtevajo zagon dodatnega

programa, ki pripomore k povišanju časa procesiranja.

Tabela 1: Odzivni čas glede na obremenjenost strežnika [14]

Obremenjenost strežnika

Neobremenjen strežnik

1000 uporabnikov/

uro

2000 uporabnikov/

uro

3000 uporabnikov/

uro

Tip strani

Domača stran 0.1 s 0.3 s 0.9 s 2.4 s

Informacije o izdelku 0.4 s 0.5 s 1.6 s 5.5 s

Stanje računa 3.4 s 5.6 s 8.4 s 16.1 s

Overitev kreditne kartice 15.5 s 18.5 s 22.4 s 37.7 s

2.2.3 Hkratni dostopi

Vsak strežnik ima fizično pogojeno število hkratnih dostopov, ki jih lahko obdela.

To število je pogojeno s strojno opremo, saj vsaka zahteva oz. dostop zahteva svoj

del procesorske moči, ki zahtevo obdela in svoj del spomina, ki je namenjen

shranjevanju zahteve, ter vmesnih podatkov pri obdelavi. Dodatna omejitev, ki

običajno v profesionalnih postavitvah ni prisotna, je lahko tudi prepustnost

omrežja. Število hkratnih zahtev oz. dostopov, ki jih lahko strežnik obdela je v

veliki meri odvisno tudi od zahtevnosti obdelave zahtev. Bolj kot je zapletena

zahteva, več sredstev zavzame na strežniku in s tem podaljša čas obdelave, s tem

pa poveča tudi interval, v katerem se lahko zvrstijo hkratne zahteve. Na primer

kompleksna matematična zahteva, ki vzame strežniku za obdelavo kar nekaj časa,

pomeni, da je v tem času strežnik obremenjen. Vse zahteve, ki pridejo na strežnik

v času obdelave, so hkratne zahteve in pomenijo dodatno obremenitev. Strežnik

ima omejitev, ki jo je moč spreminjati v nastavitvah spletnega strežnika in že v

osnovi določa najvišje število hkratnih dostopov oz. zahtev, ki jih strežnik sploh

sprejme. To število je običajno nastavljeno precej visoko, da uporabniki ne dobijo

14

občutka, da strežnik ne deluje. Vprašanje pa je, ali lahko strežnik v sprejemljivem

času obdela število vseh zahtev, ki jih lahko sprejme.

Kot primer lahko uporabimo odprtokodni spletni strežnik Apache, ki ima ob

namestitvi nastavljeno to mejo na sto petdeset hkratnih dostopov oz. zahtev.

Predpostavimo, da so zahteve kompleksne in da potrebuje strežnik za njihovo

obdelavo več sekund. Strežnik bi seveda te zahteve sprejel, bi se pa čas, ki je

potreben za njihovo obdelavo zaradi hkratnih zahtev povečal, morda celo preko

meje, ki je še sprejemljiva za uporabnika. Pri nastavljanju največjega števila

uporabnikov, ki lahko hkrati pošiljajo zahteve strežniku, je zato potrebno biti sila

pazljiv. Če nastavimo to število prenizko, potem ne izrabimo zmogljivosti

strežnika v celoti, obenem pa dobijo uporabniki občutek, da strežnik ne deluje.

Kadar presežemo to število, začne strežnik na vse nadaljnje zahteve uporabnikov

odgovarjati z odgovorom, da je maksimalno število hkratnih zahtev doseženo in

da je strežnik trenutno nedosegljiv. Če nastavimo število hkratnih dostopov

previsoko, pa strežnik sprejema zahteve preko svojih zmogljivosti. To vodi do

preobremenitve strežnika, saj pomeni sprejemanje večjega števila zahtev

uporabnikov, kot jih lahko obdela v nekem sprejemljivem času. Uporabniki

začnejo zaradi tega dobivati od strežnika odgovor, da je čas za obdelavo njihove

zahteve potekel oz. da je pretekel čas, namenjen čakanju na odziv poslane

zahteve.

2.2.4 Ergonomija odzivnega časa

»Online sites lose billions of dollars every year due to sluggish

performance speed and user bailouts.« [14]

Podjetja, ki se ukvarjajo s pridobitno dejavnostjo in jim spletne strani

predstavljajo velik vir dohodka, bodisi zaradi marketinga, bodisi zaradi uporabe

spletnih strani, zaradi nedosegljivosti oz. podaljšanega odzivnega časa, izgubljajo

ogromne količine prihodkov iz tega naslova. Pri takšnih podjetjih je nemoteno

delovanje spletnih strani ključnega pomena. Po raziskavah [15] o vedenju

uporabnikov, glede na odzivni čas, lahko ugotovimo, da je stanje enako pri

nekomercialnih in izobraževalnih straneh. Ljudje niso pripravljeni čakati in tako

15

kot postanejo nestrpni v čakalni vrsti v vsakdanjem življenju, postanejo nestrpni,

ko morajo čakati na odziv spletnega strežnika. Različne raziskave so prišle do

različnih zaključkov in zato je težko odgovoriti na vprašanji:

• »Kako hitro je dovolj hitro?« in

• »Kako počasi je prepočasi?«.

Območje zadovoljstva

V ta namen so v letu 1968 pri podjetju IBM izvajali študijo, ki je pokazala, da je

uporabnik zbran in ciljno usmerjen le dokler je odzivni čas aplikacije tako nizek,

da ga uporabnik skoraj ne zazna. Ta čas so izmerili in ugotovili, da je ciljni

odzivni čas pod eno sekundo. Tako nizek odzivni čas je postal cilj pri razvoju

aplikacij za poslovno rabo pri IBM. Raziskovalci so odkrili tudi, da ko odzivni čas

preseže mejo desetih sekund, uporabnik izgubi zbranost in ciljno usmerjenost na

aktivnost, ki jo izvaja z računalnikom. Ob presežku te meje, uporabnik zazna, da

računalnik za odziv potrebuje dlje kot običajno in se odloči, da bo računalnik

potreboval še nekaj časa in začne razmišljati o drugih stvareh. Vmesni odzivni čas

je še sprejemljiv, zbuja pa pri uporabnikih različne občutke [15].

Druga raziskava [12], ki je vključevala kupce računalniške opreme, se je

osredotočala na njihovo zbranost pri izvedbi nakupa opreme preko spleta.

Ugotovitve so bile podobne; pri odzivnih časih, višjih od deset sekund, so

uporabniki strani doživljali negativne občutke. Zanimiva ugotovitev, do katere so

prišli, pa je bila, da bolj, ko so se uporabniki bližali zaključku nakupa

računalniške opreme, bolj so bili nestrpni in pričakovali nižje odzivne čase. Na

začetku nakupovanja so bili tako zadovoljni z odzivnimi časi pod desetimi

sekundami, medtem, ko so bili proti koncu nakupovanja nezadovoljni že z

odzivnimi časi, ki so presegali štiri sekunde.

Raziskovalci Zona research so v svoji študiji [22] ugotovili in vzpostavili pravilo

osmih sekund. Uporabniki naj bi bili zadovoljni z odzivnimi časi pod osmimi

sekundami. Odzivni časi, ki presegajo osem sekund, pa naj bi pri uporabnikih

spodbujali negativno zaznavanje strani, ki jo uporabljajo.

16

Odgovor na različna zaznavanja odzivnih časov, je razložila raziskava [18]

podjetja User interface engineering, ki je prinesla rezultate, ki so bili v nasprotju z

vsemi ostalimi. Ugotovili so, da skupni odzivni čas ne igra tako močne vloge, kot

število elementov na strani, ki pritegnejo uporabnikovo pozornost. V raziskavi so

zajeli deset različnih spletnih strani, ki so jih morali uporabniki razvrstiti po

hitrostih odzivnosti, ki so jih dojemali. Proti pričakovanjem so uporabniki eno od

najhitrejših strani okarakterizirali kot najpočasnejšo, medtem, ko so drugo, ki je

bila ena izmed počasnejših, okronali za najhitrejšo [15].

Raziskovalci [18] so odkrili povezavo med številom elementov, ki so zanimivi za

uporabnika in skupnim odzivnim časom strani. Ti elementi so za vsakega

uporabnika drugačni in so običajno delčki besedila oz. pomembna števila, ki

pritegnejo uporabnikovo pozornost oz. imajo za uporabnika določeno vrednost.

Ugotovili so tudi, da so uporabniki pripravljeni čakati vsega štiri sekunde za

posamezni element, ki jih zanima. Ob primerjavi prej omenjenih strani so

ugotovili, da je stran, ki je bila sicer skupno hitrejša, vsebovala manj za

uporabnike zanimivih elementov in čeprav se je njena vsebina v povprečju

naložila pod osmimi sekundami, so jo uporabniki zaznavali kot počasno, saj je

običajno vsebovala samo en element, ki je bil zanimiv za uporabnike. Medtem so

počasnejšo spletno stran, ki je vsebovala več zanimivih elementov in se je v

povprečju naložila v šestintridesetih sekundah, dojemali kot hitrejšo, saj je število

elementov, ki so bili za uporabnike zanimivi, dosegalo višje število. Ugotovili so,

da glede na število zanimivih elementov, lahko skupni odzivni čas preseže osem

sekund in ga uporabniki ne bodo dojemali kot negativnega. Vzpostavili so tudi

povezavo med ciljem, ki ga uporabniki poskušajo doseči in njihovo

pripravljenostjo na podaljšano čakanje na odziv.

Tolerančno območje

Raziskovalci so ugotovili, da po preteku sprejemljivega odzivnega časa, ki znaša

med osem do deset sekund, uporabniki preidejo v svoje tolerančno območje. To je

območje, v katerem so še pripravljeni počakati na odziv strežnika, občutijo pa že

nelagodje ob podaljšanem odzivnem času. Ta čas je odvisen od vsakega

17

posameznika in njegovega trenutnega razpoloženja, ocenjujejo pa ga na okrog

štirikratnik [15] sprejemljivega odzivnega časa, torej nekje okrog štirideset

sekund.

Po preteku tolerančnega časa, uporabnik preide v območje frustracije in v večini

primerov prekine interakcijo s spletno stranjo. Reakcija izhaja iz vsakdanjega

življenja, kjer so uporabniki navajeni, da njihovemu dejanju sledi nekakšen odziv.

Kot primer lahko uporabimo vžig osebnega avtomobila. Če bi vžig osebnega

avtomobila trajal štirideset sekund, bi uporabnik najbrž logično sklepal, da z

avtomobilom nekaj ni v redu. Po enakem principu ob uporabi spletne strani, pri

daljšem odzivnem času sklepa, da je s strežnikom nekaj narobe in prekine

nadaljnjo interakcijo.

2.2.5 Spremenljiva psihologija uporabnikov

Z enakim tempom, kot napreduje razvoj tehnologije, ki je pomembna za

elektronsko interakcijo, napreduje tudi razvoj pričakovanj in zahtev uporabnikov

[22]. Z dvigom hitrosti dostopa do interneta, se je toleranca do odzivnega časa

zmanjšala. Uporabniki živijo hitrejše življenje, zato je njihov čas bolj dragocen.

Toleranca uporabnikov do odzivnega časa, je različna od strani do strani,

načeloma pa za večino strani in obnašanje uporabnikov veljajo naslednji zakoni

[14]:

1. Zakon vztrajnosti

Uporabniki so predvidoma vztrajni, niso pa lojalni, kar pomeni, da bodo

načeloma vztrajali pri uporabi določene strani, dokler ta streže njihovim

zahtevam. V trenutku, ko stran ne bo več zadovoljevala njihovih zahtev,

bodo izbrali konkurenčno stran in vztrajali z njo, dokler bo služila

njihovim zahtevam.

2. Zakon uporabniškega dojemanja

Zmogljivost aplikacije je potrebno meriti s stališča uporabnika. Zavedati

se je potrebno, da uporabniki ne dostopajo do strani, z istimi

18

zmogljivostmi, kot mi. Tako postane lepa animacija, ki jo lahko v okviru

lokalnega omrežja občudujemo za uporabnike s počasnejšimi povezavami

nepotreben zamudni dejavnik, ki močno vpliva na dojemanje strani.

3. Zakon odgovornosti

Odzivni čas je odvisen od različnih dejavnikov, ki se nahajajo na strani

strežnika, na strani uporabnika in vmes. Zapomniti pa si je potrebno, da ne

glede na to, kje tiči vzrok za počasno delovanje spletnih strani, bodo

uporabniki vedno krivili avtorja oz. lastnika spletnih strani.

4. Zakon pričakovanja

Uporabnikovo dojemanje zmogljivosti spletnih strani je odvisno od

njegovih pričakovanj. Uporabnikova pričakovanja izvirajo iz prejšnjih

interakcij s temi stranmi, oz. iz uporabe podobnih konkurenčnih strani. Če

so uporabniki navajeni, da se konkurenčne spletne strani prikazujejo z

odzivnim časom dveh sekund, potem bo šest sekund za te uporabnike že

pomenilo počasno delovanje.

2.3 Sistemi za upravljanje z e-učnimi vsebinami

Z razvojem e-izobraževanja je nastala potreba po upravljanju vse večjih količin e-

učnih vsebin. V ta namen so pričeli nastajati sistemi za upravljanje z e-učnimi

vsebinami [21]. Z namenom, da bi kar najbolj ustrezala uporabi kjerkoli in

kadarkoli, je upravljanje z e-učnimi vsebinami izvedeno preko interneta.

Posebnost, ki sisteme za upravljanje z e-učnimi vsebinami ločijo od navadnih

spletnih strani, je njihova dodatna funkcionalnost. Ta zajema manipulacijo z

uporabniki, vlogami uporabnikov, predmeti, vsebinami, poročili, ocenjevanjem in

več. Med najpogostejše osnovne funkcije, ki jih ponujajo sistemi za upravljanje z

e-učnimi vsebinami lahko štejemo[2][11]:

• Upravljanje

o z uporabniki

19

o z vlogami uporabnikov

o s predmeti

o s prostorsko razdelitvijo

o s poročili

• Preverjanje in ocenjevanje uporabnikov

• Pregled lastnih dosežkov

• Obveščanje in komuniciranje z uporabniki

• Koledar posameznega predmeta oz. sistema

Trg, ki podpira sisteme za upravljanje z e-učnimi vsebinami je v porastu in dosega

vrtoglave vrednosti [20]. Vse več podjetij in izobraževalnih ustanov se odloča za

vzpostavitev enega od sistemov. Glavni razlogi za odločitev za uporabo sistema

za upravljanje z e-učnimi vsebinami je preglednost nad izvajanjem izobraževanj

in s tem povezanim strateškim planiranjem (predvsem v primeru podjetij).

Različni sistemi ponujajo osnovno funkcionalnost, ki sem jo opisal zgoraj,

ponujajo pa tudi dodatno funkcionalnost in od tega je običajno odvisna tudi cena.

Izbira primernega sistema je težka, saj najverjetneje noben od sistemov ne bo v

celoti ustrezal vsaki postavitvi. V končni fazi prinaša izbira sistema preveč ali

premalo funkcionalnosti, zato je večina sistemov izvedena modularno, kar

pomeni, da izberemo le funkcije, ki jih potrebujemo, ostalih funkcij pa zaradi

prijaznosti do uporabnikov ne namestimo, saj bi to lahko pomenilo le več zmede

med uporabniki. Ena od raziskav [8] je pokazala tudi, da je bilo v letu 2006 veliko

uporabnikov takšnih sistemov nezadovoljnih s svojo izbiro in so v prihodnosti

načrtovali menjavo sistema oz. nadgradnjo z dodatno funkcionalnostjo. Glede na

lastne potrebe in možnosti, se organizacije in ustanove pri izbiri odločajo med

uporabo komercialne ali brezplačne odprtokodne rešitve. Poglejmo si nekaj

najpogosteje uporabljanih komercialnih in odprtokodnih rešitev ter prednosti, ki

jih ponujajo.

20

2.3.1 Komercialni sistemi

Komercialni sistemi so večinoma zaprti sistemi, ki omogočajo združljivost z

ostalimi sistemi in so plačljivi. Uporabljajo se predvsem v industriji, saj so cene

takšnih sistemov razmeroma visoke. V izobraževanju se zaradi njihove cene

uporabljajo v primerih, ko druge cenejše alternative ne dosegajo zahtev, ki jih

imajo posamezne ustanove.

2.3.1.1 Blackboard4

Sistem, ki je razdeljen na več opcijskih podsistemov, združuje v različici

Blackboard Academic Suite orodja za upravljanje z e-učnimi vsebinami (LMS),

upravljanje s skupnostjo uporabnikov (Community) in upravljanje s spletnimi

vsebinami (CMS). V drugem podsistemu, imenovanem Blackboard Commerce

Suite, združuje plačilne transakcije in e-trženje ter prodajo znotraj skupnosti

uporabnikov (na primer: študentski kampus), ter mrežo podjetij, ki uporabljajo

možnost plačevanja z Blackboard debitnimi karticami znotraj kampusa.

Blackboard je v letu 2006 odkupil tudi eno prvih komercialnih in najbolj

uporabljanih spletnih učilnic WebCT5. Čeprav je sistem načeloma zaprto koden,

omogoča razširitev funkcionalnosti in prilagajanje potrebam z uporabo odprte

arhitekture, ki se imenuje Building Blocks. Za razširitev WebCT sistemov, je na

voljo tehnologija PowerLinks. Sisteme Blackboard trenutno uporablja več

milijonov uporabnikov po vsem svetu. Velikosti sistemov, ki so v uporabi so

različne in merijo od preproste uporabe sistema za upravljanje z e-učnimi

vsebinami, do celotnega upravljanja študentskih kampusov preko sistema

Blackboard.

2.3.1.2 Apex learning6

Podjetje je ustanovil soustanovitelj Microsofta, Paul Allen, ki je verjel, da je

mogoče uporabiti enak pristop k izobraževanju preko interneta, kot se uporablja v

4 Dosegljiv na naslovu http://www.blackboard.com 5 Za izvajanje e-izobraževanja, ga uporablja DOBA (http://www.doba.si) 6 Dosegljiv na naslovu http://www.apexlearning.com

21

visokem šolstvu, tudi v osnovnih šolah. Izdelek je namenjen predvsem

ameriškemu trgu, saj je usmerjen v njihovo osnovno šolstvo (K-12) in za razliko

od ostalih sistemov za upravljanje z e-učnimi vsebinami vsebuje vnaprej

pripravljene celovite predmete, ki sledijo učnim načrtom in so namenjene

uspešnemu doseganju ciljev, zastavljenih v učnih načrtih. Sistem je namenjen tudi

komunikaciji med vsemi udeleženci v izobraževalnem procesu, tako imajo dostop

do sistema in možnost medsebojne komunikacije učenci, starši, učitelji in

strokovni delavci šole. Na ta način je zaznavanje težav v učenju in napredku lažje,

odpravljanje težav pa hitrejše, saj so vse strani udeležene v izobraževanju bolj

obveščene. V svoji zgodovini je sistem Apex learning uporabljalo več kot milijon

uporabnikov na štiri tisoč šolah.

2.3.1.3 Desire2Learn7

Sistem je namenjen tako izobraževanju v izobraževalnih ustanovah, kot

izobraževanju znotraj podjetja. Zelo prilagodljiva arhitektura omogoča izbiro

funkcionalnosti in velikosti, ki jo uporabnik potrebuje. Sistem je primeren za

uporabo nekaj sto uporabnikov do nekaj sto tisoč uporabnikov, kar mu daje

posebno vrednost. Namenjen je upravljanju tako z e-učnimi vsebinami (LMS), kot

spletnimi vsebinami (CMS), vse skupaj pa je uporabniku prijazno in zelo

intuitivno. Vmesniki so zelo dodelani in usmerjeni predvsem v prihranek

dragocenega časa pri izvajanju aktivnosti, ki jih izvajajo uporabniki. Na primer

ocenjevanje več uporabnikov hkrati in izdelava poročil iz samodejno zbranih

podatkov. Dodatni moduli vključujejo tudi orodja za sodelovanje v realnem času

in orodja za shranjevanje in ponovno uporabo e-učnih vsebin, z uporabo meta

podatkov, preko več različnih, ločenih predmetov. Sistem Desire2Learn uporablja

več kot štiri milijone uporabnikov po vsem svetu.

2.3.2 Odprtokodni sistemi

Pri vzpostavitvi spletnih učilnic oz. sistemov za upravljanje z e-učnimi vsebinami,

je običajno poglavitnega pomena cena. To predvsem drži za izobraževalne

7 Dosegljiv na naslovu http://www.desire2learn.com

22

ustanove, katerim glavni cilj ni ustvarjanje dobička oz. je ta dobiček nižji in ne

predstavlja realnih možnosti financiranja plačljivih sistemov. Dodatni razlog za

uporabo odprtokodne rešitve, je potreba po dodatni funkcionalnosti. Rešitve v

večini plačljivih in zaprto kodnih sistemih, so omejene na ponudbo proizvajalca

oz. je včasih njihova izvedba celo nemogoča. Pri uporabi odprtokodne rešitve,

dobimo poleg izdelka tudi vso izvorno kodo sistema, tako je z nekaj

programerskega znanja in poznavanja sistema mogoče funkcionalnost prilagoditi

lastnim potrebam in željam, pri tem pa običajno ni potrebno dokupiti dodatne

programske opreme od proizvajalca sistema. Odprtokodne rešitve so običajno

nastale na lokalnih šolah oz. univerzah za lastne potrebe, z uporabo in porastom

zahtev pa so nekatere prerasle svoj okvir in se razvile v prave sisteme za

upravljanje z e-učnimi vsebinami, ki se lahko merijo z industrijskimi

komercialnimi sistemi, ki so plačljivi. Pri uporabi odprtokodnih rešitev obstaja

ena velika pomanjkljivost, ki jo v večini primerov nadomesti razlika v ceni in

odprte možnosti dodatnega razvoja in prilagodljivosti, ki se skriva v samem bistvu

pomena besede odprte kode. Takšne rešitve nimajo pravega proizvajalca, saj

nastanejo kot plod več razvijalcev programske opreme, ki so lahko locirani tudi

po vsem svetu in sodelujejo izključno preko spleta. Zaradi tega je pridobivanje

profesionalne podpore uporabnikom večinoma nemogoče, razen v redkih

primerih, kjer so bila ustanovljena posebna podjetja8, ki nudijo podporo

uporabnikom svojih odprtokodnih aplikacij. Določena podjetja poleg plačljive

različice svojega sistema s podporo, ponujajo tudi brezplačno odprtokodno

različico brez podpore.

Večino pomoči, ki jo uporabniki lahko pričakujejo o uporabi sistema oz.

morebitni nadgradnji, uporabniki iščejo po spletnih forumih, ki združujejo

skupnost uporabnikov sistema. Tukaj prihaja do izmenjave mnenj, podajanja želja

razvijalcem, objavljanja lastnih rešitev in zgodb o uspehu pri uporabi. Pri tem je

potrebno poudariti, da je pomoč pridobljena na ta način lahko netočna, zamudna

in celo nepravilna, saj jo lahko nudi vsak uporabnik, ki ni nujno kvalificiran oz.

dovolj izkušen za nudenje te vrste pomoči.

8 Kot v primeru Moodle – podjetje na naslovu http://www.moodle.com

23

Prednost takšnih sistemov pa se kaže tudi v varnosti, saj je zaradi odprtosti kode

lažje zaznati varnostne luknje po sistemu »več glav več ve«. Nabor razvijalcev, ki

imajo opravka z uporabo te kode, lahko presega več tisoč uporabnikov, kar je

absolutno več, kot v katerikoli industrijski razvojni hiši. Odpravljanje varnostnih

pomanjkljivosti je hitrejše, saj je kateremukoli od razvijalcev, ki ima dovolj

znanja, omogočeno, da napako odpravi in objavi popravek, ki ga lahko ostali

uporabniki uporabijo pri svojih namestitvah.

2.3.2.1 Manhattan Virtual Classroom9

Namestitev je namenjena za uporabo na Linux oz. Unix strežnikih, izvedena je v

celoti v programskem jeziku C in brez uporabe podatkovne baze. Delovanje je

hitro, zahteve sistema pa niso visoke, zato je uporaba mogoča na različni strojni

opremi, tudi starejši. Sistem namesto podatkovne baze uporablja kar datotečni

sistem z uporabo map in datotek za shranjevanje podatkov, s tem pa odpade

dodatna administracija podatkovne baze in dodatna zahtevnost aplikacije. Sistem

je namenjen izvajanju izobraževanja preko interneta in omogoča upravljanje z e-

učnimi vsebinami, preverjanja znanja, več vrst komunikacije med uporabniki in

dostopa do dnevnika uporabe sistema. Nekaj posebnosti, ki zaradi unikatne

zasnove sistem ločijo od drugih:

• označevanje novih vsebin, tako da jih udeleženci takoj zaznajo,

• enostavnost uporabe, ki uporabnike spodbuja k pogostejši uporabi,

• dobra dokumentacija uporabe sistema za uporabnike in administratorje,

• enostavno izdelovanje varnostnih kopij podatkov (preprosto kopiranje).

Manhattan virtualne učilnice uporablja več tisoč uporabnikov po vsem svetu,

največ v njegovem rojstnem kraju, na univerzi Western New England College.

9 Dosegljiv na naslovu http://manhattan.sourceforge.net

24

2.3.2.2 Dokeos10

Uporabniku prijazen sistem za upravljanje z e-učnimi vsebinami, ki v sebi

združuje vse pomembne gradnike te vrste sistemov. K njegovemu razvoju so

pristopile mednarodne univerze, šole in posamezniki ter organizacije, zato je v

pravem pomenu besede odprtokoden. Vsebuje tudi prevod vmesnika v

slovenščino. Omogoča uvoz SCORM paketov in spremljanje uspešnosti

uporabnikov preko SCORM arhitekture. Na uporabniku prijazen način je mogoče

uvoziti predstavitve v formatu MS Powerpoint in iz njih ustvariti spletne

predstavitve. Z uporabo Flash tehnologije in dodatnega strežnika, omogoča tudi

možnost izvedbe video konferenc med uporabniki. Poleg osnovnih načinov

preverjanja znanja, so na voljo tudi nekatere bolj napredne možnosti, kot je

uporaba vročih točk, kot prikazuje slika 4, in odprtih odgovorov.

Slika 4: Uporaba vprašanj tipa vročih točk [2]

10 Dosegljiv na naslovu http://www.dokeos.com

25

Vsebuje tudi avtorska orodja s predlogami, s katerimi lahko v zelo kratkem času

izdelamo učne vsebine in preverjanja. Med drugim nudi tudi pisanje blogov,

uporabo forumov, klepetalnice, anketiranje in je lahko po želji oz. potrebi tudi

sistem za upravljanje z vsebinami (CMS).

Vodilna ideja pri razvoju sistema je, da sistem ostane uporabniku prijazen in

enostaven, da bodo uporabniki čim manj časa namenjali uporabi in čim več časa

izobraževalnim vsebinam.

2.3.2.3 Moodle11

Ime Moodle je kratica, ki pomeni Modular Object Oriented Dynamic Learning

Environment in ima več pomenov, med drugim ga lahko razumemo tudi kot

besedo, ki spodbuja improvizacijo in odprtost, dve ključni načeli, ki so jima sledili

njegovi razvijalci.

Moodle je zaradi svoje odprtokodne licence (GNU/GPL) in modularne zasnove

idealen za razvoj dodatnih funkcionalnosti. Razvoj osrednjega sistema je

prepuščen razvijalcem, ki prihajajo iz komercialne in nekomercialne sfere.

Moodle dopušča odprte možnosti pri izdelavi e-učnih vsebin in ponuja redko

možnost, da udeleženci (po želji tudi učenci) soustvarjajo vsebine znotraj enega

predmeta. Omogoča različne metode in pristope k poučevanju in administraciji

sistema.

Pomembnejša opravila, ki jih podpira so:

• uporaba forumov znotraj sistema za komunikacijo med uporabniki,

• upravljanje z vsebinami (CMS),

• izdelava kvizov z uporabo različnih tipov vprašanj,

• pisanje blogov,

• izvajanje anket,

11 Dosegljiv na naslovu http://moodle.org

26

• izdelava slovarjev,

• možnost preverjanje znanja,

• povezljivost z ostalimi načini overovitve (LDAP, IMAP, …),

• aktivnosti (delavnice, …),

• različne vrste vpisovanja v predmete,

• filtriranje vsebin,

• prilagajanje videza.

Moodle je eden izmed najbolj razširjenih sistemov za upravljanje z e-učnimi

vsebinami in ima preko 38 tisoč registriranih namestitev po vsem svetu, preko 16

milijonov uporabnikov in 1,6 milijona predmetov. Preveden je v več kot 70

jezikov, tako lahko uporabniki brez težave uporabljajo pri delu svoj materni jezik.

Največ predmetov v namestitvi ponuja češka univerza v Brnu, ki ima v svoji E-

learning virtualni učilnici, na voljo kar 19.223 različnih predmetov [11]. Moodle

je zelo razširjen tudi v slovenskem šolstvu, saj ga uporablja Univerza v Mariboru,

Univerza na Primorskem in večje število slovenskih osnovnih in srednjih šol.

3 Raziskovalni cilji

Uporaba sistema za upravljanje z e-učnimi vsebinami zahteva od uporabnika oz.

upravitelja izbiro sistema in s tem povezane funkcionalnosti. Večina sistemov

omogoča razširljivost, vendar običajno le v okviru uporabe dodatnih modulov, ki

jih ponuja podjetje, ki je lastnik sistema oz. njegovi razvijalci v primeru

odprtokodnega zastonjskega sistema. Uporaba zaprtih modulov pomeni

kompromis med funkcionalnostjo, ki jo želimo in funkcionalnostjo, ki je na voljo.

Večkrat se zgodi, da bi radi imeli funkcionalnost po meri, saj točno takšne

funkcionalnosti, kot si je želimo, ne najdemo v obstoječih modulih. V takšnem

primeru nam ne preostane nič drugega, kot da dodatno funkcionalnost razvijemo

sami [7]. Natanko to smo tudi storili v okviru projekta Partnerstvo fakultet in šol

27

2, kjer smo potrebovali možnost spremljanja študentov na opazovalni pedagoški

praksi in izvedbo komunikacije med udeleženimi v procesu. Za osnovo smo

uporabili sistem za upravljanje z e-učnimi vsebinami Moodle, ki se uporablja na

naši fakulteti in je eden izmed najbolj razširjenih po svetu [1]. Namen

diplomskega dela je prikazati, čim bolj neodvisno od sistema, kako se lotiti

takšnega projekta in kako ga uspešno izvesti ter ustvariti dodatno funkcionalnost,

brez vplivanja na delovanje osnovnega sistema. Besedilo predvideva zadostno

znanje programiranja v programskem jeziku, v katerem je napisan sistem in

osnovno poznavanje relacij in dela s podatkovnimi bazami. Pridobivanje znanja o

programskih jezikih in podatkovnih bazah ni namen tega dela in v nadaljevanju ni

opisano.

Za dodajanje funkcionalnosti potrebujemo osnovni sistem, ki je namenjen

upravljanju z e-učnimi vsebinami. Vzpostavitev takšnega sistema je kompleksen

proces in ga je potrebno skrbno načrtovati. V primeru, da ta korak preskočimo oz.

ga zanemarimo, se v večini primerov soočamo z eno izmed dveh težav:

1. Sistem je predimenzioniran

2. Sistem je preslabo zastavljen

V obeh primerih to ni cilj, ki smo ga poskušali doseči in namen tega diplomskega

dela je tudi izdelava programske opreme, s pomočjo katere lahko preizkusimo

delovanje enega od sistemov in na osnovi rezultatov izpeljemo okvirne zahteve

za dimenzioniranje in vzpostavitve nadaljnjih sistemov. Pri ustvarjanju programa,

sem se omejil na sistem, ki je v uporabi na naši fakulteti, to je Moodle. Vendar je

ideja preizkusa dovolj široka in program napisan dovolj odprto, da bi z malo

spremembami lahko podpirala testiranje in izpeljavo podobnih zaključkov, za

katerikoli sistem za upravljanje z e-učnimi vsebinami. Na osnovi zbranih

podatkov, bom ocenil trenutno obremenitev sistema in maksimalno, za

uporabnike še sprejemljivo obremenitev. Namen dela je spremljati umetno

ustvarjeno obremenitev, ki simulira delo več sto uporabnikov, kot bi sami

delovali, po vnaprej določenih scenarijih, ki so najpogosteje izpeljani v

uporabniških sejah. V teoretičnem delu sem predstavil dejavnike, ki vplivajo na

28

uporabniško izkušnjo pri delu s spletnimi sistemi, v praktičnem delu bom glede

na ta vodila meril odzivnost sistema. Iz podatkov bom poskušal izpeljati vodila,

ki jim moramo slediti pri vzpostavljanju takšnega sistema in izbiri potrebne

strojne opreme, glede na predvideno število uporabnikov sistema, da bo njihovo

delo vedno nemoteno in primerno hitro.

4 Raziskovalna izhodišča

Splošna raziskovalna izhodišča pri nastajanju dela se navezujejo na:

• Odzivne čase pri dostopu do spletnih gradiv in psihološko ergonomijo

povezano s tem,

• sisteme za upravljanje z e-učnimi vsebinami in njihovo izbiro,

• izdelavo razširitev za povečanje funkcionalnosti sistemov za upravljanje z

e-učnimi vsebinami,

• dimenzioniranje sistemov za upravljanje z e-učnimi vsebinami, glede na

potrebe v šolskih ustanovah,

• za večino sistemov je možno razviti lastne razširitvene module,

• izdelavo napotkov za razvoj razširitvenih modulov in pravilno

dimenzioniranje sistemov za upravljanje z e-učnimi vsebinami.

5 Metodologija

Pri študiju in interpretaciji virov sem uporabljal deskriptivno metodo, pri

primerjavah sistemov za upravljanje z e-učnimi vsebinami sem uporabljal

eksperimentalno-komparativno metodo. Testiranja sem izvajal na vnaprej

pripravljenem vzorcu umetno ustvarjenih uporabnikov, ki so naključno izvajali

vnaprej določene uporabniške scenarije. Med zbiranjem podatkov za izpeljavo

zaključkov, sem uporabljal kvantitativno raziskovanje in deskriptivno statistiko za

obdelavo podatkov ter prikaz rezultatov.

29

6 Praktični del

Za delovanje sistema za dinamično prikazovanje spletnih strani oz. gradiv, kot je

to izvedeno v sistemih za upravljanje z e-učnimi vsebinami, je struktura podobna

vzorčni, ki jo prikazuje slika 5.

Slika 5: Relacija med uporabnikom in sistemom

Pri razvoju razširitve sistema je naš cilj čim manj vplivati na strukturo samega

sistema in dodatno strukturo za naše potrebe graditi okrog osnovne strukture. Pri

tem je smiselno uporabiti že obstoječe podatkovne strukture in programske

funkcije, saj tako poskrbimo, da bo naša dodatna koda funkcionalna tudi po

morebitnih posodobitvah sistema in podatkovne strukture.

6.1 Razvoj lastnega modula v sistemih za upravljanje z e-učnimi

vsebinami

6.1.1 Vsebina in namen e-gradiva

Gradivo je sestavni del portfelja – mape praktičnih pedagoških dosežkov študenta.

Vezano je na praktično pedagoško usposabljanje študentov v skupnem

pedagoško-didaktično-psihološkem sklopu ter v predmetnem sklopu. Elektronska

Uporabnik

Strežnik

Aplikacija

Podatkovna baza

Shramba podatkov

Zahteva

Zahteva Odziv

30

spremljava in evalvacija dela študentov pri praktičnem pedagoškem usposabljanju

je sestavljena iz odprtega in zaprtega dela. Odprti del elektronskega gradiva (A

del) je javno dostopen vsem vključenim v praktično pedagoško usposabljanje

študentov na Filozofski fakulteti in Fakulteti za naravoslovje in matematiko

Univerze v Mariboru. Zaprti del elektronskega gradiva (B in C del) je namenjen

samo konkretnemu študijskemu timu: študentu, učitelju-mentorju in nosilcu

predmeta v skupnem pedagoško-didaktično-psihološkem sklopu, kjer bo študent

opravljal opazovalno prakso (B del) oz. predmetnemu didaktiku (C del).

V A delu so predstavljene temeljne značilnosti praktičnega pedagoškega

usposabljanja. A del nudi možnost aktivne komunikacije na temo praktičnega

pedagoškega usposabljanja študentov v obliki e-foruma oz. elektronske oglasne

deske. V B in C delu so rubrike, namenjene konkretnemu spremljanju aktivnosti

študentov pri praktičnem pedagoškem usposabljanju. B del je vezan na

opazovalno prakso pri predmetih skupnega pedagoško-didaktično-psihološkega

sklopa. Izpolnjujejo ga učitelj mentor, nosilec izbranega predmeta in študent. C

del je vezan na predmetno prakso, vključno s skupinskimi hospitacijami in

vzorčnimi učnimi nastopi. Izpolnjujejo ga učitelj mentor, predmetni didaktik in

študent.

Namen uporabe e-gradiva

• Dvig učinkovitosti in kakovosti praktičnega pedagoškega usposabljanja

študentov in ciljno usmerjanje le-tega v doseganje predvidene

kompetentnosti študentov;

• izboljšava dokumentarno-informacijske infrastrukture za načrtovanje,

spremljavo in evalvacijo praktičnega pedagoškega usposabljanja

študentov;

• posodobitev dosedanjih dnevnikov pedagoške prakse in njihova vključitev

v portfelj - mapo praktičnih pedagoških dosežkov študentov;

31

• izboljšava modela usposabljanja študentov pedagoškega dodiplomskega

študija za učno prakso v prenovljenih bolonjskih študijskih programih s

podporno pedagoško dokumentacijo;

• povečanje učinkovitosti komunikacije med študenti, predmetnimi didaktiki

in učitelji mentorji (strokovni sodelavci fakultet) na področju praktičnega

pedagoškega usposabljanja študentov;

• širitev nabora kakovostnih elektronskih vsebin za izobraževalno

implementacijo in dvig ravni informacijske (digitalne, računalniške)

pismenosti delavcev v vzgoji in izobraževanju.

Moj del pri izdelavi dodatnega modula je bil povezan z opazovalno pedagoško

prakso (B del). Namenjen je bil spremljanju študentov in njihovega dela v šoli, v

sklopu opazovalne pedagoške prakse, ki se izvaja v tretjem letniku študija

sociologije in je namenjena spoznavanju delovanja šole in šolskih strokovnih

služb.

Cilji opazovalne pedagoške prakse

Cilji opazovalne pedagoške prakse za študente so:

• usposobiti študente za sistematično opazovanje pouka učiteljev ter

študentov kolegov;

• seznaniti študente z življenjem in delom šole;

• usposobiti študente za sistematično opazovanje drugih aktivnosti na šoli

(interesne dejavnosti……);

• seznaniti študente z načinom in oblikami sodelovanja z različnimi (pod)

sistemi šole (šolska svetovalna služba, starši, vodstvo šole, širše okolje

….);

32

• razviti zavest študentov o nujnosti stalne refleksije lastne prakse,

sodelovanja z drugimi učitelji ter stalnega strokovnega izpopolnjevanja in

s tem profesionalne rasti;

• seznaniti študente s šolsko dokumentacijo.

Naloge študenta v sklopu opazovalne pedagoške prakse

Študent mora v času opravljanja opazovalne pedagoške prakse opravljati

naslednje naloge:

• študent opravi uvajalne in evalvacijske razgovore z učiteljem mentorjem

na opazovalni praksi;

• opazuje delo šolske svetovalne službe;

• spoznava delo in različne vloge učitelja (razrednik, mentor učencem, vodja

aktiva…), drugih pedagoških delavcev, ravnatelja;

• sodeluje v eni izmed dejavnosti, ki potekajo na šoli (npr. ekskurzija,

projektni dan, športni dan, organizacija npr. tekmovanja…);

• opazuje in po pripravljenih kriterijih analizira pouk na različnih stopnjah

in pri različnih predmetih;

• vodi in izpolnjuje obrazec opazovalne prakse.

6.2 Razvoj lastnega modula za sistem za upravljanje z e-učnimi

vsebinami Moodle

Moodle je odprtokodni sistem, tako je njegova koda transparentna in jo je mogoče

ustrezno nadgraditi, brez negativnih posledic za sistem in podatke. S tem, ko ne

vplivamo na podatkovno strukturo sistema in ne spreminjamo programske kode,

poskrbimo za nemoteno delovanje sistema tudi po morebitnih nadgradnjah. Pri

snovanju razširitve sem najprej pregledal podatkovno bazo in strukturo

shranjevanja podatkov.

33

6.2.1 Podatkovna struktura

Sistemi za upravljanje z e-učnimi vsebinami večinoma12 shranjujejo svoje podatke

v podatkovno bazo. Podatki so urejeni v tabelah in med seboj povezani s

primarnimi in drugimi ključi, ki enolično določajo vsak element v podatkovni

bazi. Takšno shranjevanje je v uporabi ne glede na podatkovno bazo, ki se

uporablja. V podatkovno bazo se shranjujejo vsi podatki, ki se spreminjajo in jih

želimo shraniti za kasnejši priklic. Med podatki so najosnovnejše tabele podatkov,

ki so povezane z delovanjem sistema in ostali podatki, ki so povezani s

funkcionalnostjo in dodatki.

Podatki o uporabnikih

V tabeli o uporabnikih (tabela user) se nahajajo podatki, ki jih potrebujemo vedno,

kadar hočemo prikazovati vsebino glede na prijavljenega uporabnika. Za nas

pomembni podatki v tabeli so id (številka – »EMŠO«) uporabnika, ki enolično

določa uporabnika v sistemu. Id je v tabeli z uporabniki primarni ključ, kar

pomeni, da je za vsakega uporabnika drugačen. Na to številko se bomo sklicevali

vedno, ko bomo hoteli nek podatek shraniti v povezavi z nekim uporabnikom.

Nekaj za nas pomembnih podatkov je v tabeli na sliki 6. To so username

(uporabniško ime), password (geslo), firstname (ime), lastname (priimek),

lastlogin (zadnja prijava). V tabeli ne spreminjamo ničesar, saj hočemo ohraniti

konsistentnost podatkov v sistemu. Za vse dodatne podatke o uporabniku, ki jih

želimo shraniti, ustvarimo dodatno tabelo (dodatni_podatki) in jo povežemo s

tabelo user preko polja id, kot kaže slika 6.

Slika 6: Dodatna tabela s podatki o uporabnikih

12 Z izjemo Manhattan Virtual Classroom, ki uporablja datoteke.

34

Na enak način lahko v katerokoli tabelo s podatki dodamo lastne podatke brez, da

bi vplivali na originalno strukturo. Pri ustvarjanju tabel moramo paziti na

normalizacijo tabel, da preprečimo podvajanje podatkov. Z normalizacijo

preprečimo tudi nekonsistentnost podatkov ob morebitnih spremembah.

Podatki, povezani s spremljanjem procesa opazovalne pedagoške

prakse

Za potrebe spremljanja študentov na opazovalni pedagoški praksi, sem kreiral še

20 dodatnih tabel, v katerih so shranjeni ostali podatki, ki so vezani na pedagoški

proces. Tako sem torej izkoristil uporabnike, ki so že v sistemu, s čimer sem

preprečil podvajanje uporabnikov in jim omogočil prijavo z uporabniškim

imenom in geslom, ki ga že uporabljajo za dostop do sistema za upravljanje z e-

učnimi vsebinami. Dosegel sem tudi to, da ostanejo podatki v primeru sprememb

v sistemu še vedno konsistentni tudi v dodatnem modulu. Sprememba imena

uporabnika na enem mestu, povzroči spremembo na vseh (normalizacija).

Uporabil sem tudi obstoječo arhitekturo prijavljanja v sistem in shranjevanja

prijavnih podatkov, podatkov o zadnjem dostopu in zadnjih spremembah

podatkov, kar je pomembno pri prikazovanju časovno odvisnih vsebin. Nekaj

primerov dejanskih tabel, ki sem jih uporabil za shranjevanje dodatnih podatkov

je na sliki 7.

Uporabniške datoteke, ki jih uporabniki nalagajo na strežnik za uporabo pri

predstavitvi predmetov (razna gradiva, slike, …), se ne shranjujejo v podatkovno

bazo, pač pa se shranjujejo kot datoteke v sistem map, ki je organiziran in ločen

po predmetih. V podatkovno bazo se shranjujejo le podatki, ki so povezani s temi

datotekami, to so poljubna poimenovanja datotek oz. virov. Večkratna ponovna

uporaba iste datoteke v sistemu pomeni le dodaten zapis v podatkovno bazo in ne

predstavlja podvajanja datotek.

35

Tabela: user (dodatna) Tabela: izvajanje dejavnosti

Tabela: potrdilo o praksi

Slika 7: Dodajanje lastnih polj v ločeno podatkovno strukturo

6.2.2 Programska koda

Del programske kode, ki skrbi za delovanje modula za spremljanje študentov na

opazovalni pedagoški praksi, sem napisal ločeno od vse ostale programske kode

sistema Moodle. Tako je ostala originalna programska koda nedotaknjena in v

primeru nadgradnje oz. posodobitve sistema, predvidoma ne bo težav. Datoteke,

ki vsebujejo dodatno programsko kodo sem shranil v ločene mape, da jih že na

prvi pogled ločimo od osnovnih. Glavna naloga pri snovanju programske kode je

ugotovitev prijavnega postopka osnovnega sistema, saj so sistemi za upravljanje z

e-učnimi vsebinami praviloma zaprti sistemi, ki od uporabnika zahtevajo prijavo,

to je vnos uporabniškega imena in gesla za dostop do vsebin. V mojem primeru

sem imel na voljo dokumentacijo, saj je sistem odprtokoden in razmeroma dobro

dokumentiran. V primeru, ko nimamo dostopa do dokumentacije ali še hujše, do

programske kode, je ugibanje prijavnega postopka lahko zelo težavno ali celo

nemogoče.

Prijavni postopek

Vsak uporabnik se v sistem prijavi z vnosom uporabniškega imena in gesla. V

sistemu praviloma ne moreta obstajati dve enaki uporabniški imeni, lahko pa

36

obstaja neomejeno število enakih gesel. Z vnosom prijavnega para uporabniškega

imena in gesla, preverimo, da je oseba, ki deluje v sistemu res tista, za katero se

izdaja.

Slika 8: Prijava uporabnika v sistem Moodle

Prijava uporabnika in shranjevanje uporabniških podatkov v sistemu je izvedena

na enega od naslednjih načinov:

• Z uporabo piškotkov (cookie):

o podatki o prijavi in času trajanja prijave se shranijo na uporabnikov

računalnik,

o precej varen način, saj bi morali nepridipravi za vdor uporabiti

piškotek, ki je shranjen na uporabnikovem računalniku oz. uganiti

njegovo vsebino.

• Z uporabo sej:

o podatki o prijavi in času trajanja prijave se shranijo na strežnik,

o možnost shranjevanja podatkov o seji v datotečni sistem ali v

podatkovno bazo,

o shranjevanje podatkov o prijavi in seji v piškotek (cookie) ali URL

za preverjanje istovetnosti,

37

o z dodatno zaščito podatkov v seji lahko preprečimo odtekanje

podatkov zaradi vdora v uporabniško sejo.

Moodle zapisuje podatke o sejah v datoteke oz. v podatkovno bazo, odvisno od

nastavitve, ki jo izberemo.

V sistemu za upravljanje z e-učnimi vsebinami Moodle, je dostop do podatkov o

prijavi in vseh njegovih objektov mogoč že z vključitvijo osnovne nastavitvene

datoteke »config.php«, ki se nahaja v korenski mapi namestitve sistema. S tem

lahko dostopamo tudi do objekta USER, ki vsebuje vse podatke o prijavljenem

uporabniku. Na ta način lahko pregledujemo podatke, kot so uporabniško ime,

ime, priimek, id uporabnika in druge. S pridobitvijo id prijavljenega uporabnika,

pa lahko nadalje upravljamo z ostalimi podatki, ki so, kot smo videli prej, vezani

na uporabnika ravno preko njegovega id.

Za prijavo in odjavo iz sistema sem uporabil že obstoječo strukturo, v lastni kodi

pa sem omejil dostop z uporabo iste strukture, ki omogoča dostop do zasebnih

vsebin, ki so prilagojene uporabniku.

6.2.3 Oblikovanje

Oblikovanje vsebin, povezanih z opisom in vstopom v modul, smo izvedli kar z

Moodlovim vgrajenim sistemom za upravljanje z vsebinami (CMS) in ustvarili

predmet »Praktično pedagoško usposabljanje študentov«, kot je razvidno iz slike

9. S tem smo dosegli tesno integracijo dodatne funkcionalnosti v obstoječi sistem,

saj uporabnik niti ne opazi, da uporablja v bistvu fizično ločen sistem, ki ni del

sistema za upravljanje z e-učnimi vsebinami in izkorišča le njegovo strukturo in

osnovne funkcije za delo z uporabniki. S tem smo pridobili močne možnosti

oblikovanja vsebin in si prihranili kar nekaj dela z uporabniškim vmesnikom in

upravljanjem z vsebinami.

38

Slika 9: Oblikovni izgled predmeta za podporo praktičnemu pedagoškemu usposabljanju

študentov

6.2.4 Aktivnosti udeležencev v procesu

V procesu opravljanje pedagoške prakse sodelujejo predmetni didaktik, mentor in

študent. Dodatni modul preko sistema Moodle omogoča vsakemu od njih vpogled

in možnost spreminjanja področij, ki so v procesu za njih relevantna. Glede na

vlogo v procesu, ima vsak udeleženec pravice dostopanja do različnih delov

podatkov. Tako sem ločil dostope glede na vloge in aktivnosti.

6.2.4.1 Študent

Študent v času opravljanja opazovalne pedagoške prakse izvaja aktivnosti, ki mu

jih skupaj predpišeta didaktik in mentor. Študent mora voditi dnevnik o svojem

delu, kar opravi kar preko sistema Moodle.

Aktivnosti

V tem času študent najprej opravi uvajalni razgovor z učiteljem mentorjem,

ravnateljem, pomočnikom ravnatelja, spoznava delo šole in šolsko dokumentacijo.

V nadaljevanju prakse izvede več hospitacij pri pouku, med drugim tudi pri

39

razredni uri, in spoznava delo šolske svetovalne službe ter zaključi s

sodelovanjem pri izvedbi ene izmed šolskih aktivnosti. Z mentorjem skupaj

pregledata gradivo (dnevnik) in v primeru, da je študent izvedel vse svoje

aktivnosti uspešno, je izpolnil svoje obveznosti.

Pravice

Študent z uporabo dodatnega modula izpolnjuje obrazce, ki so bili prej na papirju,

kar v elektronski obliki. Navodila za izpolnjevanje in dostop do obrazcev sta

oblikovana v sistemu Moodle, v okviru predmeta Praktično pedagoško

usposabljanje študentov, kot je prikazano na sliki 10. Ko študent odda obrazec, ga

nima več možnosti spreminjati, saj bi tako lahko prišlo do nekonsistentnosti

podatkov. Študent ima prav tako možnost pregledovanja svojega napredka in

lahko tako spremlja, katere obrazce je že izpolnil in oddal in katerih še ni, kot

kaže slika 11.

Slika 10: Dostop do obrazcev za izpolnjevanje in pregled ter tiskanje vnesenih podatkov

40

Najprej vpiše za vsako od smeri šolo, na kateri bo opravljal prakso, izbere

didaktika in mentorja ter določi datum trajanja pedagoške prakse, kot prikazuje

slika 11.

Slika 11: Izpolnjevanje splošnih podatkov o opazovalni pedagoški praksi

Študent nadaljuje z izpolnjevanjem obrazcev po seznamu. Študent med drugim

izpolnjuje tudi obrazec za hospitiranje pri učnih urah, ki je predpisan s strani

fakultete oz. predmetnega didaktika in je prikazan na sliki 14. Študent ima

možnost vse svoje vnose kadarkoli pregledati in natisniti in sicer vse naenkrat ali

vsakega posebej oz. samo izbrane obrazce, kot kaže slika 13. Ima tudi vpogled v

oceno mentorja in didaktika in njune opombe.

Slika 12: Hitri pregled izpolnjenih obveznosti študenta

41

Slika 13: Pregled in tiskanje vnesenih podatkov

V obrazcu za pregled in tiskanje vnesenih podatkov lahko kadarkoli pregleduje in

natisne kateregakoli od obrazcev, ki jih je vnesel. Za svoj osebni portfelj mora

natisniti poročila o aktivnostih, kot je navedeno v navodilih.

42

Slika 14: Izpolnjevanje podatkov o hospitaciji učne ure

Komunikacija z ostalimi študenti, mentorji in predmetnim didaktikom poteka

preko oglasne deske oz. e-foruma. Odprti e-forum je namenjen komunikaciji med

sodelujočimi partnerji pri praktičnem pedagoškem izobraževanju. Študentje lahko

zastavijo vprašanja, katerih odgovori bodo zanimivi širši skupini sodelujočih.

Objavljajo se lahko novosti s področja literature, strokovnih srečanj in

izobraževanj, zanimivih za praktično usposabljanje študentov, zanimivosti z

mentorskih šol oz. vabila na predstavitve njihove ustvarjalnosti ipd.

6.2.4.2 Mentor

Mentor usklajuje izvedbo opazovalne pedagoške prakse s predmetnim

didaktikom. Njegova odgovornost je uspešno izpeljati prakso in študentu nuditi

ustrezno vodenje in strokovno pomoč pri njegovem izobraževanju v tem času.

43

Aktivnosti

Mentor v času izvajanja prakse študentu nudi čim več možnosti za njegovo

izobraževanje v obliki aktivnosti, ki jih zahteva program praktičnega

izobraževanja, ki ga poda predmetni didaktik. Sproti pregleduje študentove

opravljene obveznosti in mu svetuje ter ob koncu praktičnega izobraževanja poda

predmetnemu didaktiku kratko opisno oceno študenta.

Pravice

V sistemu in dodatnem modulu ima mentor nekaj več pravic in drugačne naloge,

kot študent. Tako ima mentor možnost pregleda nad vnesenimi podatki študentov,

ki so mu dodeljeni, kar je izvedeno samodejno, glede na vnos študenta pri

izpolnjevanju splošnih podatkov o opazovalni pedagoški praksi. Mentor ima v

vsakem trenutku pravico in možnost vpogleda v vnesene podatke vseh svojih

študentov in možnost tiskanja teh podatkov. Na koncu mentor izpolni oceno s

komentarji, ki služi didaktiku v pomoč pri ocenjevanju študenta in izdaji potrdila

o opravljeni opazovalni praksi, kot prikazuje slika 15.

Slika 15: Mentor izpolni ob koncu oceno študenta na praksi

44

Mentor po vpisu ocene študenta nima več možnosti spreminjanja ocene, tako kot

je ni imel v papirnati obliki. Mentor lahko natisne potrdilo o opravljeni praksi in

ga podpiše, vendar le v primeru, ko je didaktik že vnesel svojo oceno, sicer je

potrdilo neveljavno. Tudi mentor lahko komunicira s študenti, ostalimi mentorji

oz. didaktiki o poljubnih temah z uporabo e-foruma, ki je del sistema Moodle.

6.2.4.3 Predmetni didaktik

Aktivnosti

Predmetni didaktik najprej pregleda ali je študent izpolnil vse obveznosti, nato

pregleda študentov dnevnik in mentorjevo oceno. Na koncu poda tudi svojo

oceno. Didaktikova ocena je končna ocena. Didaktik tudi natisne potrdilo o praksi

in ga potrjenega vrne študentu, ki ga odda v referatu.

Pravice

Predmetni didaktik ima možnost pregleda napredka za vse svoje študente. Študent

se dodeli didaktiku, ko izpolni splošne podatke o praksi. Didaktik lahko v vsakem

trenutku pogleda vsakega od vnosov, ki ga je študent zapisal v svoj dnevnik.

Predmetni didaktik vidi tudi opombe pri mentorjevi oceni in na podlagi tega poda

svojo oceno. Didaktik lahko končno oceno tudi spremeni, ravno tako kot je lahko

spreminjal oceno v papirni obliki, dokler ne natisne potrdila o opravljeni praksi.

6.2.5 Zaključek

Študenti, mentorji in didaktiki so sprejeli takšen način izmenjave informacij v

povezavi z opravljanjem pedagoške prakse. S tem so prihranili veliko časa, saj so

bili podatki zbrani na enem mestu in vsi, ki so imeli pravice vpogleda v podatke,

so lahko kadarkoli dostopali do teh podatkov. Prihranek v času je nastopil tudi pri

izdaji potrdila, saj je študent lahko že predhodno natisnil potrdilo in ga mentorju

in didaktiku dal le še v podpis. Prav tako so dobili udeleženci na vsa svoja

vprašanja hitreje odgovore, ostali udeleženci pa so lahko videli odgovore na

pogosta vprašanja, brez da bi po nepotrebnem ponovno obremenjevali mentorja

ali didaktika. Zaradi uspeha pilotskega projekta, se bo takšen način spremljanja

45

študentov na pedagoški praksi uporabljal tudi v prihodnje, predvsem za področja

in smeri, ki sem jih navedel v uvodu. Ena od prednosti takšnega načina dela je

tudi arhiviranje podatkov, saj podatki ostajajo v sistemu tudi kasneje, da lahko vse

strani pregledujejo vnesene podatke, brez potrebe po ponovnem srečanju. Prav

tako ostajajo v sistemu vprašanja in odgovori, ki so se porajala med izvajanjem

pedagoške prakse in tako služijo naslednikom, ki bodo izvajali pedagoško prakso.

Večjih slabosti, ki bi bile povezane s prehodom na elektronsko vodenje dnevnika

in izvedbo pedagoške prakse študentov, ni, saj je bil projekt namenjen ravno

izboljšanju procesa. Edina slaba lastnost, ki so jo uporabniki izpostavili je, da je ta

način časovno zahtevnejši od papirnega in zahteva razpoložljivo računalniško

opremo, ki je nekateri nimajo.

6.3 Obremenitev sistema za upravljanje z e-učnimi vsebinami

Moodle

Zmogljivost sistema za upravljanje z e-učnimi vsebinami je odvisna od strojne

opreme. Forum za uporabnike in administratorje postavitev sistema Moodle ima

posebej razdelek [10] namenjen razpravam o strojnih zahtevah sistema, ki vsebuje

različne informacije. Nekateri trdijo, da je ključnega pomena povečanje

procesorske moči, drugi, da je najpomembnejša količina spomina, vendar le redki

svoje trditve utemeljijo, kar pomeni, da so najverjetneje le ugibanja, ki niso

preverjena. Moj namen v sklopu diplomskega dela je bil preveriti kakšne so

dejanske zahteve glede na število uporabnikov in njihovo aktivnost. Odločil sem

se izvesti niz različnih testiranj in s tem preveriti:

• Koliko uporabnikov zadovoljivo sprejme osebni računalnik kot strežnik,

• kakšna je razlika med postavitvijo Moodla glede na operacijski sistem,

• kdaj postane odzivnost sistema za uporabnika nesprejemljiva,

• katera operacija je najbolj kompleksna in skriva potencial za optimizacijo,

• kako zmogljiv je fakultetni sistem za upravljanje z e-učnimi vsebinami.

46

Za potrebe testiranj sem napisal program, ki simulira dejansko aktivnost

uporabnikov po vnaprej pripravljenih scenarijih. Program sem nato poganjal na

računalnikih, ki so simulirali delo uporabnikov (v nadaljevanju uporabniški

računalniki) in tako obremenjeval strežnik in sistem, ki je tekel na njem. Iz

rezultatov testiranj sem potegnil lastne zaključke, katere lastnosti so pomembne

pri načrtovanju vzpostavitve takšnega sistema in priporočila za sestavo strojne

opreme glede na obseg sistema. Za potrebe testiranja sem hotel vzpostaviti čim

bolj nevtralno testno okolje, v katerem bi lahko dobil čim bolj točne odgovore na

moja vprašanja.

6.3.1 Spremenljivke

V testiranjih sistema sem se odločil spremljati odzivni čas, saj iz tega izhaja

uporabnost sistema in posledično njegova prihodnost, ki je odvisna od

zadovoljstva uporabnikov. Izhajajoč iz raziskav o zadovoljstvu uporabnikov in

njihovi psihologiji [22], sem kot ciljni odzivni čas vzel osem sekund. Torej

sprejemljiv odzivni čas, pri katerem bo uporabnik še zadovoljno uporabljal sistem,

je osem sekund. Pri povečanju odzivnega časa bo uporabnik začel doživljati

neprijetne občutke, povezane z uporabo sistema in v končni fazi opustil uporabo

sistema, saj si bo o sistemu razvil negativno mnenje. Odzivni čas je odvisen od

obremenitve sistema, kar pomeni, da s porastom števila uporabnikov raste. Druga

spremenljivka v testiranjih je število uporabnikov. Testiranja sem izvajal z

različnim številom uporabnikov. Tretja spremenljivka, ki vpliva na odzivni čas, je

aktivnost uporabnikov, ki sem jo določil s časovnim razmikom med posameznimi

akcijami uporabnika.

6.3.2 Testno okolje

Pri izvedbi testiranj, sem meril čas od uporabnikovega klika (zahteve) do

strežnikovega celotnega odgovora (odziva). Pri merjenju časa sem izpustil čas

procesiranja odziva na uporabnikovi strani, saj dejansko nisem prikazoval

rezultata zahteve. To sem storil zaradi specifičnosti testiranj, ki so zajemala

praviloma enostavnejše spletne strani, kjer je čas procesiranja na uporabnikovi

strani zanemarljivo kratek. Testiranja sem izvajal v nadzorovanem okolju, kjer

47

sem poskušal zmanjšati moteče dejavnike, ki bi utegnili vplivati na točnost

rezultatov. Vsa testiranja sem tako izvajal v lokalnem omrežju, kjer je

uporabniške računalnike in strežnik, na katerem je tekel sistem ločil le en

usmerjevalnik, tako da je bila pasovna širina povezave 100 Mb/s. S tem sem

preprečil vpliv hitrosti mrežne povezave na odzivni čas oz. ga znižal na

zanemarljiv nivo. Pri pripravi uporabniških računalnikov, sem upošteval njihovo

omejeno zmogljivost in število uporabnikov, ki jih je simuliral posamezni

računalnik priredil tako, da uporabniški računalnik ni bil nikoli obremenjen preko

svojih zmogljivosti, kar bi pomenilo dodatne zakasnitve zaradi nezmožnosti

pravočasne obdelave rezultatov. Pri pripravi predmetov, v katerih so bili aktivni

simulirani uporabniki, sem uporabljal praviloma manjše datoteke, da čas prenosa

ne bi vplival na odzivni čas, saj bi bili odzivni časi v tem primeru odvisni tudi od

velikosti datotek, kar ni bil namen. Odzivni čas je odvisen od zmogljivosti

strežnika, medtem ko je čas prenosa datotek odvisen od hitrosti povezave med

uporabniškim računalnikom in strežnikom in praviloma v večji meri odvisen od

hitrosti povezave uporabnika v internet. S temi ukrepi sem zmanjšal vpliv motečih

dejavnikov na zanemarljiv nivo in pri izvedbi testiranj dobil le dejanski odzivni

čas, ki bi ga uporabnik doživljal ob uporabi sistema v idealnih pogojih.

6.3.3 Priprava sistema za upravljanje z e-učnimi vsebinami

Moodle

Za potrebe testiranj sem ustvaril poseben predmet v sistemu in v njega vpisal

večje število testnih študentov (uporabnikov), ki sem jih ustvaril v ta namen.

Predmet sem vzorčno oblikoval in napolnil z vsebinami ter ostalimi aktivnostmi.

V predmet sem dodal nekaj datotek, ki so simulirale dejanske objave gradiv

izvajalcev predmeta. Dodal sem forum in objave, katere so lahko testni uporabniki

pregledovali. Izdelal sem klepetalnico in dodal tudi raznovrstni slikovni material

in multimedijske vsebine (Flash), ki so običajno prisotne v predmetih v sistemu.

Končna oblika predmeta je prikazana na sliki 16.

48

Slika 16: Testni predmet Moodle stress test

6.3.4 Program Moodle stress test tool

Program Moodle stress test tool je nastal kot nujni stranski produkt diplomskega

dela, saj na tržišču ni orodja, s katerim bi lahko preverili oz. testirali delovanje

sistema za upravljanje z e-učnimi vsebinami. Obstajajo programi za testiranje

zmogljivosti strežnika, kar pa ni bil namen tega dela. Zmogljivost strežnika in

zmogljivost sistema, ki teče na tem strežniku, sta dve ločeni stvari. Prav lahko se

zgodi, da je strežnik izjemno učinkovit, sistem, ki teče na njem pa ne dosega tako

bleščečih rezultatov. Namen programa je bil preizkusiti sam sistem in ne

strežnika. Program je simuliral dejansko aktivnost uporabnikov in ne zgolj

vzpostavljanje povezav s strežnikom, kot je to v navadi pri programih, ki testirajo

obremenitve samega strežnika. Program je za vhodne parametre prejel le dve

besedilni datoteki, in sicer datoteko z uporabniki in datoteko s scenariji. Program

je prirejen za testiranje sistema Moodle verzije 1.8.4+, vendar ga je mogoče z

malo sprememb prilagoditi za uporabo s starejšimi verzijami (pred 1.7.x), ki so

uporabljale drugačen način odjave iz sistema.

Razvojna platforma

Program sem napisal v programskem jeziku Visual C# .NET. Za izbiro

programskega jezika sem se odločil zaradi enostavnosti in preglednosti izdelave

rešitev. Uporabljal sem Visual C# 2008 Express Edition, ki je ena izmed

okrnjenih različic razvojnih okolij, ki jih ponuja Microsoft. Prednost uporabe te

49

različice je, da je njena uporaba brezplačna. Vse kar moramo storiti je, da uporabo

izdelka registriramo na Microsoftovi spletni strani. Vseeno pa dobimo močno

orodje, s katerim lahko izdelamo kompleksne programe, kot je ta. Uporaba

razvojnega okolja je mogoča le v operacijskem sistemu Microsoft Windows. Iz

tega izhaja tudi dejstvo, da je uporaba programa Moodle stress test tool mogoča le

na Windows uporabniških računalnikih. Operacijski sistem, na katerem teče

sistem za upravljanje z e-učnimi vsebinami ni pomemben, saj program testira le

sistem za upravljanje z e-učnimi vsebinami, ki ga je mogoče namestiti na večino

znanih operacijskih sistemov.

Podatki o uporabnikih

Vsak uporabnik v sistemih za upravljanje z e-učnimi vsebinami prejme ob vpisu v

sistem prijavne podatke, s katerimi se prijavlja v sistem. Ti prijavni podatki so

sestavljeni iz uporabniškega imena, gesla in enolično določene številke

uporabnika (id). Moj program je kot enega izmed vhodnih parametrov prejel

besedilno datoteko s seznamom prijavnih podatkov uporabnikov, ki jih je nato

simuliral. Podatki so bili shranjeni v obliki besedila ločenega z vejicami oz.

podpičji (CSV oblika). Razlog za to odločitev je bila lažja manipulacija s temi

podatki, saj delo s CSV oblikovanimi datotekami zelo dobro obvlada tudi program

Microsoft Excel. Z uporabo Excela je bilo mogoče enostavno izdelati prijavne

sezname uporabnikov za vsak uporabniški računalnik. Primer uporabniške

datoteke je viden na sliki 17.

S takšnim načinom izbire uporabnikov je bilo možno ob vsakem testiranju

spreminjati nabor uporabnikov, ki so sodelovali v testiranju.

50

Slika 17: Primer besedilne uporabniške datoteke in njena manipulacija v programu

Microsoft Excel

Scenariji uporabniške aktivnosti

Uporabniško sejo med uporabo sistema lahko razdelimo na tri dele, in sicer

prijavo v sistem, vmesno aktivnost in odjavo iz sistema. Scenarije uporabniške

aktivnosti sem tako razdelil v fiksne in variabilne scenarije. Med fiksne scenarije

sem uvrstil prijavo in odjavo, saj se ti dve aktivnosti zgodita vedno, v vsaki

uporabniški seji. Ostali scenariji, ki pomenijo uporabniško vmesno aktivnost, torej

med prijavo in odjavo, so lahko poljubni, zato sem jih uvrstil med variabilne

scenarije. Simulirano uporabniško aktivnost si lahko predstavljamo takole:

• Prijava v sistem,

• izvajanje določenih akcij:

o ogled foruma,

o pregled gradiva,

o klepet s soudeleženci v sistemu,

o ogled video gradiva,

51

o ogled obvestila,

o …

• odjava iz sistema.

Podatki, ki se nanašajo na opis posameznega scenarija in datoteke s scenariji v

celoti, so bolj strukturirani kot sami prijavni podatki uporabnikov. Iz tega razloga

sem namesto CSV oblike uporabil datoteke v obliki XML. Tako sem izdelal svoje

značke, s katerimi sem izdelal strukturo, ki sem jo potreboval. Pri vsakem

scenariju sem označil ali gre za fiksni ali za variabilni scenarij, dodal opis

scenarija, ime skripte, ki se izvede na strežniku in morebitne podatke, ki naj se

pošljejo strežniku z uporabnikove strani. Scenarije, ki so bili odvisni od

uporabniških podatkov, kot je recimo prijava, sem dodatno opremil s

spremenljivimi polji, katera so pri izvedbi nadomestile prave vrednosti.

Spremenljiva polja sem označil z znakoma »%«, tako je na primer prostor za

uporabniško ime rezervirala oznaka »%username%«. Pri izvedbi takšnega

scenarija pa se je namesto »%username%« na strežnik poslalo dejansko

uporabniško ime uporabnika.

Skozi XML datoteko s scenariji sem omogočil tudi nastavitev nekaterih drugih

nastavitev testiranja, kot sta čas13 med akcijami uporabnikov in naslov strežnika

oz. sistema za upravljanje z e-učnimi vsebinami, ki sem ga testiral. Primer XML

datoteke za enostavno aktivnost uporabnika je prikazan na sliki 18.

Uporaba besedilnih datotek pomeni transparentnost nastavitev in enostavno

spreminjanje nastavitev.

13 Čas se izbira naključno glede na nastavljeno spodnjo in zgornjo mejo.

52

Slika 18: Primer XML datoteke s scenariji uporabniške aktivnosti

6.3.4.1 Delovanje programa

Uporaba programa je s stališča uporabnika, ko ima enkrat pripravljeni obe

datoteki, dokaj enostavna. Vse kar mora storiti je, da pokaže na obe datoteki in

program se lahko začne izvajati. Najprej program preveri obe datoteki in že na

začetku javi napako, če s pripravljenimi podatki ni vse v redu. Za obdelavo

datoteke, ki vsebuje besedilo ločeno z vejico, program uporablja splošne razrede

in metode za delo z besedilnimi datotekami. Za obdelavo XML datoteke, pa

uporablja knjižnico MSXML, s katero strukturirano prebere podatke iz datoteke.

Shranjevanje uporabniških podatkov in podatkov o scenarijih se izvede v posebej

pripravljene podatkovne strukture, ki ohranijo strukturirano obliko. Ostale

nastavitve se shranijo v globalne spremenljivke zaradi posebne oblike kasnejše

uporabe, ki izhaja iz specifičnosti programa. Primer uporabe programa je prikazan

na sliki 19.

53

Slika 19: Uporaba programa Moodle stress test tool

Izvajanje

Ko program prebere vse potrebne podatke in zgradi potrebne strukture, se lahko

začne izvajati. Izvedbo sprožimo s klikom na gumb »Test moodle«. Program za

vsakega izmed uporabnikov ustvari ločeno nit, v kateri se izvaja aktivnost

uporabnika. Program tako ustvari toliko niti, kot je število uporabnikov v

uporabniški datoteki. Zaradi tega postane izvajanje programa kompleksno in težje

razumljivo, prav tako pa postane iskanje napak zahtevnejše. Zaradi specifičnosti

takšnega načina programiranja, sem moral v program uvesti nekaj načinov

izvajanja kontrole nad delovanjem posamezne niti. Zaradi kompleksnejšega

načina prenašanja podatkov med nitmi in skrbi zaradi dostopa vsake niti do

posodobljenih podatkov, sem v izvedbi uporabljal zaklepanje struktur in globalne

spremenljivke. Za vsakega od uporabnikov program izvede prijavo v sistem,

izvede nekaj naključnih aktivnosti, ki so označene kot variabilne aktivnosti (v

časovnem razmiku kot je nastavljen v XML datoteki) in so med seboj neodvisne,

nato pa se odjavi iz sistema.

Beleženje aktivnosti

Program med svojim delovanjem vse pomembne podatke zapisuje v besedilno

datoteko. Zaradi lažje kasnejše obdelave podatkov podatke zapisuje v obliki

besedila, ločenega z vejico oz. podpičjem (CSV). Takšne podatke lahko kasneje

enostavno odpremo s programom Microsoft Excel in z njimi poljubno

manipuliramo in izdelujemo grafične prikaze podatkov. Beleženje se izvaja v

54

vsaki niti posebej, zato se uporablja zaklepanje datoteke med pisanjem, da ne bi

prihajalo do zmešnjave in nekonsistentnosti podatkov. Vsaka akcija vsakega

izmed uporabnikov, ki se je izvedla, je zabeležena v datoteki. V datoteki je

shranjenih tudi nekaj kontrolnih podatkov, ki sem jih uporabljal med nastajanjem

programa in služijo za ugotavljanje, v kateri niti se je zgodil zapis. V datoteki so

med drugimi kontrolnimi podatki shranjeni najpomembnejši podatki:

• Oznaka niti, v kateri je bil izveden zapis in s tem id uporabnika,

• Tip akcije

o Login – prijava uporabnika,

o Random – izvedba enega od naključnih variabilnih scenarijev,

o Logout – odjava iz sistema,

o Error – v primeru, da zahteva ne uspe, se vpiše napaka, ki jo javi

strežnik

• Čas izvedbe akcije – (točen datum in čas izvedbe akcije (zahteve)),

• Odzivni čas – merjen v milisekundah in primerno oblikovan,

• Velikost prejetega rezultata (odziva) na zahtevo (velikost strani,

datoteke…),

• Opis akcije – za lažje ločevanje v kopici podatkov

• Čas razmika med akcijami – naključni čas, ki je pretekel med izvedbo

prejšnje in trenutne akcije.

Primer besedilne datoteke, ki je nastala kot rezultat beleženja aktivnosti med

delovanjem programa, je na sliki 20, in sicer v besedilni obliki ter kasneje odprti v

programu Microsoft Excel.

55

Slika 20: Primer zabeleženih podatkov med izvedbo programa

6.3.5 Primerjava postavitev sistema Moodle v okolju Windows in

Linux

Prvo od testiranj je bila primerjava zmogljivosti, ki izhaja iz operacijskega

sistema, ki poganja sistem za upravljanje z e-učnimi vsebinami. V testne namene

sem na isti računalnik namestil operacijski sistem Microsoft Windows Server

2003 in Debian Linux. Na obeh sem vzpostavil tudi sistem za upravljanje z e-

učnimi vsebinami Moodle in znotraj tega identični predmet. Testiranja sem izvajal

z istim številom uporabnikov. Hotel sem preizkusiti kakšen del strežniške moči

odpade glede na izbiro operacijskega sistema in kako smotrno oba operacijska

sistema razpolagata s sistemskimi sredstvi pri določeni obremenitvi, ter kako se to

odraža na uporabniško dojemanje delovanja sistema.

56

6.3.5.1 Testno okolje

Glede na izbiro operacijskega sistema, sem izbiral tudi strežniške programe, ki so

ključni za poganjanje sistema Moodle. Strežnika sem vzpostavil na osebnem

računalniku, ki ni ravno primerljiv s strežniškimi računalniki, je pa vseeno dovolj

zmogljiv, da poganja sistem Moodle in omogoča primerjavo med sistemoma,

čeprav pri nižjem številu uporabnikov. Ustvaril sem dva razdelka (particiji), na

katera sem namestil oba sistema, tako, da sem lahko potem kadarkoli preklopil iz

enega v drugega in izvedel dodatna testiranja, s katerimi sem potrjeval svoje

domneve. Vsa testiranja sem izvajal s privzetimi nastavitvami sistemov, kar ni

nujno najbolj optimalna rešitev, saj je na forumih veliko zapisov o izboljšanju

zmogljivosti z naprednejšimi nastavitvami strežnika.

Zmogljivost strežnika

Računalnik, ki sem ga izbral za testiranja je imel naslednje tehnične specifikacije:

• procesor Intel Pentium 4 (1400 MHz),

• 512 MB RAM DDR

• ATA trdi disk

• 100 Mb ethernet vmesnik

Microsoft Windows Server 2003

Namestil sem osnovno različico sistema (Standard edition) in vzpostavil vse

potrebne strežniške programe. Za spletni strežnik sem uporabil IIS 6.0, ki je del

sistema Windows Server 2003. Za prevajanje skript PHP, iz katerih je sestavljen

Moodle, je skrbel PHP 5.2.5, ki je bil nameščen kot ISAPI modul znotraj IIS.

Podatkovni strežnik je predstavljal MySQL 5.0.45 z uporabo vrste shranjevanja

MyISAM. Sistem za upravljanje z e-učnimi vsebinami je predstavljal Moodle

različica 1.8.4+, ki je bila v tistem času zadnja stabilna različica. Za spremljanje

obremenitev strežnika med testiranjem sem omogočil oddaljeno namizje, preko

57

katerega sem spremljal trenutno obremenitev procesorja in izrabo spomina, ter

pasovne širine omrežne povezave. Vse ostale informacije, povezane z izvedbo

testiranja, je beležil program Moodle stress test tool, ki se je izvajal na

uporabniških računalnikih in ni predstavljal dodatne obremenitve strežnika.

Debian Linux

Pri vzpostavitvi strežnika v okolju Linux, sem izbral distribucijo Debian, ki je ena

izmed najbolj uporabljanih med Linux uporabniki. Za spletni strežnik sem

uporabil odprtokodni strežnik Apache2, za prevajanje skript PHP, pa je skrbel

modul PHP 5.2.0. Podatkovni strežnik je predstavljal MySQL 5.0.20 z uporabo

vrste shranjevanja MyISAM. Sistem za upravljanje z e-učnimi vsebinami je

poganjal Moodle različica 1.8.4+, tako da ni bilo bistvenih razlik med obema

postavitvama. Na sistemu Linux sem vzpostavil tudi SSH lupinski dostop, ki mi je

omogočal spremljanje obremenitev med izvajanjem testiranja. Vse ostale

informacije o testiranju je beležil program Moodle stress test tool, ki se je izvajal

na uporabniških računalnikih in tako ni dodatno obremenjeval strežnika.

6.3.5.2 Izvedba testiranja in zaključki

Testiranje sem izvajal z uporabo petih uporabniških računalnikov, na katerih sem

simuliral skupaj sto dvajset uporabnikov. Uporabil sem kar računalnike v eni

izmed računalniških učilnic in na vseh omogočil oddaljeno namizje, preko

katerega sem jih upravljal ter tako dosegel, da sem lahko skoraj istočasno pognal

program na vseh računalnikih. Število uporabnikov sem priredil zmogljivosti

uporabniških računalnikov, saj bi presežek zmogljivosti uporabniških

računalnikov pomenil dodatno zakasnitev, ki bi iz tega izhajala in rezultati ne bi

bili več točni. Tehnična specifikacija uporabniških računalnikov je bila naslednja:

• Procesor Intel Pentium 4 2.40 GHz,

• Spomin 512 MB DDR

• ATA trdi disk

58

Obe testiranji sem izvedel večkrat, na identični postavitvi sistema Moodle, z

istimi uporabniki in istim scenarijem uporabniške aktivnosti.

Microsoft Windows Server 2003

Pri izvajanju testiranja sem uporabil sto dvajset simuliranih uporabnikov in

izvedel testiranje s časovnim razmikom deset do petnajst sekund med vsako

akcijo posameznega uporabnika. Pred pričetkom obremenitve je sistem za svoje

delovanje in delovanje strežnikov porabljal 308 MB spomina in okrog 0%

procesorske moči. Med izvedbo testiranja sem spremljal porabo spomina in

procesorske moči ter pasovne širine. Procesor je bil med testiranjem vseskozi

izrabljen stoodstotno, kar je normalno, saj je ves čas moral obdelovati zahteve

uporabnikov. Izraba pasovne širine omrežne povezave med enim izmed testiranj

je vidna na sliki 21.

Slika 21: Izraba pasovne širine omrežne povezave

Iz grafa na sliki 22 je razvidno, da je sicer večji del odzivnih časov ustrezal

ciljnemu odzivnemu času pod osmimi sekundami. Nekaj odzivnih časov pa je bilo

izjemoma podaljšanih, tudi do nesprejemljivih razsežnosti, saj strežnik pri tako

velikem številu hkratnih zahtev ni uspel zadovoljiti potreb simuliranih

uporabnikov. Najbolj kompleksni sta bili v tem scenariju prijava in odjava

uporabnika, saj sta, kot je razvidno iz tabele 2, ti dve aktivnosti porabili največ

časa za obdelavo.

59

Tabela 2: Odzivni časi glede na vrsto aktivnosti uporabnika

Odzivni čas Datum in čas zahteve

Velikost odziva v bajtih Opis aktivnosti

00:01,1 7.2.2008 15:52 4464 Prenos datoteke 6

00:01,7 7.2.2008 15:52 4785 Prenos datoteke 11

00:03,7 7.2.2008 15:53 4639 Prenos datoteke 2

02:30,5 7.2.2008 15:53 8250 Odjava iz sistema

00:26,7 7.2.2008 15:53 8464 Prijava v sistem

00:04,3 7.2.2008 15:53 23740 Vstop v predmet

MST


00:02,3 7.2.2008 15:53 4639 Prenos datoteke 2

Slika 22: Odzivni čas vsake izmed zahtev simuliranih uporabnikov (Windows)

Debian Linux

Izvedba simulacije in testiranja postavitve sistema Moodle v operacijskem

sistemu Linux je potekala enako kot prejšnja v operacijskem sistemu Microsoft

Windows. Pred pričetkom testiranja je sam operacijski sistem s strežniki porabljal

115 MB spomina in izkoriščal okrog 0% procesorske moči Simuliral sem sto

dvajset uporabnikov, za simulacijo pa sem uporabil pet uporabniških

00:00,0

00:17,3

00:34,6

00:51,8

01:09,1

01:26,4

01:43,7

02:01,0

02:18,2

02:35,5

02:52,8

1

11

21

31

41

51

61

71

81

91

10

1

11

1

12

1

13

1

14

1

15

1

16

1

17

1

18

1

19

1

20

1

21

1

22

1

23

1

Od

zivn

i čas

Zahteve

Odzivni časi (Windows)

60

računalnikov, ki so glede na svoje zmogljivosti simulirali med 20 in 40

uporabnikov. Vsak izmed simuliranih uporabnikov je izvajal aktivnosti v

časovnem razmiku deset do petnajst sekund med vsako akcijo. Testiranje sem

izvajal na identičnem predmetu, kot v primeru Microsoft Windows. Izraba

procesorske moči je bila ves čas okrog sto odstotna, saj je strežnik obdeloval

zahteve uporabnikov skoraj v vsaki sekundi. Odzivni časi so bili slabši kot pri

istem testiranju v operacijskem sistemu Microsoft Windows. Prikazani so v grafu

na sliki 23.

Slika 23: Odzivni čas vsake izmed zahtev simuliranih uporabnikov (Linux)

Zaključki

Kot sem predvideval, se je izkazalo, da je računalnik prešibak zato, da bi opravljal

naloge strežnika, na katerem bi tekel sistem za upravljanje z e-učnimi vsebinami

Moodle. Zanimiva je razlika med sistemoma, saj praviloma med uporabniki velja

Linux za bolj optimalen in manj zahteven sistem. Slednje se je izkazalo kot

resnično, saj je v mirujočem stanju pred obremenitvijo Linux porabljal manj

sistemskih sredstev. Med obremenitvijo pa se je pokazalo zanimivo nasprotje, saj

je Microsoft Windows navkljub bolj zahtevnemu operacijskemu sistemu, dosegel

boljše rezultate. Tukaj moram še enkrat omeniti, da sem testiranja izvajal v obeh

sistemih s privzetimi nastavitvami, zato ne morem trditi, kateri sistem bi z

00:00,0

00:43,2

01:26,4

02:09,6

02:52,8

03:36,0

04:19,2

1

16

31

46

61

76

91

10

6

12

1

13

6

15

1

16

6

18

1

19

6

21

1

22

6

24

1

25

6

27

1

28

6

30

1

31

6

33

1

34

6

36

1

Od

zivn

i čas

Zahteve

Odzivni časi (Linux)

61

optimalnimi nastavitvami dosegal boljše rezultate oz. katerega od sistemov je

mogoče pripraviti do boljše prepustnosti.

Dodatna zanimivost, ki sem jo zasledil med testiranjem je tudi podatek, da

največja prepustnost omrežnega vmesnika v času testiranja ni presegla 80%,

čeprav so zahteve terjale višjo prepustnost. Procesorska moč je bila v obeh

primerih izrabljena 100% ves čas, kar pomeni, da je to ena od ključnih

pomanjkljivosti strojne opreme pri teh dveh postavitvah.

Nepričakovan rezultat se je pokazal tudi pri spremljanju porabe pomnilnika, ki je

kazal na to, da je poraba pomnilnika narasla le za manjši delež tudi pri več kot sto

uporabnikih, ki so hkrati uporabljali sistem.

Priporočila za izboljšanje zmogljivosti

V primeru tega strežnika bi priporočal nadgradnjo procesorja in povečanje

količine pomnilnika. Za dodatno izboljšanje prepustnosti bi priporočal tudi

menjavo omrežnega vmesnika, saj trenutni ni zagotavljal niti izkoristka pasovne

širine, ki jo navaja proizvajalec. Za resnejšo uporabo strežnik ni primeren, v ta

namen bi priporočil pravi strežniški računalnik.

6.3.6 Obremenitev sistema Moodle na fakultetnem strežniku

Fakultetni strežnik za izvajanje izobraževanja na daljavo deluje že več kot eno

leto in si je v tem času pridobil nekaj več kot 2000 uporabnikov. Ob povečanju

števila e-gradiv v sistemu me je zanimalo, ali je strežnik, ki poganja sistem

Moodle dovolj zmogljiv, da bo tudi v prihodnje uspel zadovoljivo opravljati svoje

naloge. V ta namen sem pripravil testni predmet in kreiral dodatnih 2000

uporabnikov, ki so služili za simulacijo obremenitve strežnika in sistema Moodle.

Za potrebe testiranja sem uporabil celotno računalniško učilnico, to je 10

uporabniških računalnikov, ker sem pričakoval boljšo odzivnost, kot v prejšnjih

testiranjih, saj gre za močan strežniški računalnik. Tudi tukaj moram opozoriti, da

operacijski sistem teče skoraj s privzetimi nastavitvami in obstaja še nekaj rezerv

pri optimizaciji delovanja, če bi bilo to kdaj potrebno.

62

Zmogljivost strežnika

Strežnik, ki poganja sistem Moodle v praksi, ima naslednje tehnične specifikacije:

• Dvojedrni procesor Intel Pentium D 3,2 GHz,

• 2 GB RAM DDR2

• 1 Gb ethernet vmesnik

• SATA trdi diski

• Apache (1.3.33) spletni strežnik

• MySQL podatkovni strežnik 4.1.21

• PHP prevajalnik 4.3.11

• Moodle 1.6.1+

V enoletnem delovanju še ni bilo pripomb na delovanje strežnika, zato sem

pričakoval visoko odzivnost strežnika in pripravil več simuliranih uporabnikov in

povečal njihovo aktivnost. Pred začetkom testiranja je bil strežnik neobremenjen

in porabljal okrog 500 MB pomnilnika in običajno okrog 0% procesorske moči.

Vse morebitne zahteve je obdelal tako hitro, da je bil čas obremenitve procesorja

ob trenutnem številu uporabnikov zanemarljiv.

6.3.6.1 Izvedba testiranja in zaključki

Za potrebe testiranja sem uporabil 600 simuliranih uporabnikov, ki so izvajali

svoje aktivnosti po scenarijih s časovnim razmikom med 1 in 2 sekundama. Za ta

korak sem se odločil, po prvih testiranjih, ko sem sistem obremenil s sto dvajset

uporabniki in običajnim časovnim razmikom med 10 in 15 sekundami. Odzivnost

sistema se v tem primeru ni spremenila in je bila enaka kot če bi sistem uporabljal

en sam uporabnik oz. sistem sploh ne bi bil uporabljan. Razlaga sledi iz rezultatov

tega testiranja, saj se je izkazalo, da je povprečen odzivni čas med zahtevo in

odzivom trajal okrog 0,3 sekunde. To pomeni, da je navkljub takšnemu številu

63

hkratnih uporabnikov (120) sistem uspel obdelati vse zahteve preden so prišle

naslednje. Moj cilj sem zato priredil in nastavil čas razmika tako, da skrajšam

interval med zahtevami, hkrati pa sem povečal število simuliranih uporabnikov in

s tem število zahtev.

Prikaz rezultatov sem razdelil v tri dele:

• Začetek obremenitve,

• polna obremenitev,

• ponehanje obremenitve.

Med izvajanjem obremenitve sem spremljal še število hkratnih dostopov do

sistema, obremenitev strežnika (procesor, omrežni vmesnik, pomnilnik) in

obremenitev uporabniškega računalnika.

Začetek obremenitve

Tabela 3: Odzivni časi glede na vrsto aktivnosti uporabnikov

Odzivni čas Datum in čas zahteve Velikost odziva Opis akcije

00:02,0 19.2.2008 1:20 3514 Vstop v predmet MST

00:01,8 19.2.2008 1:20 3526 Prenos datoteke 3

00:02,4 19.2.2008 1:20 3526 Prenos datoteke 8



00:01,7 19.2.2008 1:20 3526 Prenos datoteke 5

00:04,0 19.2.2008 1:20 3526 Prenos datoteke 1

00:02,9 19.2.2008 1:20 3526 Flash video test


00:03,5 19.2.2008 1:20 3520 Ogled foruma 2

00:02,3 19.2.2008 1:20 3526 Prenos datoteke 6

00:01,6 19.2.2008 1:20 3526 Prenos datoteke 6



00:03,8 19.2.2008 1:20 3520 Ogled foruma

00:02,3 19.2.2008 1:20 3526 Prenos datoteke 7



64

Iz grafa na sliki 24 je lepo razvidno, kako se je večal odzivni čas, ko so simulirani

uporabniki pričeli z uporabo sistema. Več kot je bilo uporabnikov in več kot je

bilo zahtev, višji je bil odzivni čas. V času testiranja se je izvedlo več kot 17 tisoč

zahtev simuliranih uporabnikov. Večino časa so se zahteve izvajale istočasno, kar

je razvidno iz grafa na sliki 25.

Slika 24: Odzivni časi v začetku testiranja

Število hkratnih zahtev je bilo v začetku testiranja nekoliko nižje, saj simulirani

uporabniki še niso bili ustvarjeni v celoti.

Delovanje sistema je bilo med tem sicer obremenjeno, vendar ni bilo upočasnjeno

do mere neuporabnosti. Obremenitve procesorja in pomnilnika je razvidna iz slike

26.

00:00,0

00:00,9

00:01,7

00:02,6

00:03,5

00:04,3

00:05,2

00:06,0

00:06,9

1 101 201 301 401

Od

zivn

i čas

i

Zahteve

Odzivni časi (distance)

Slika 25: Število

Slika 26: Obremenitev procesorja in izraba pomnilnika v začetku testiranja

Iz obremenitve procesorja je razvidno, da je

postopoma dosegla

pomnilnika se je dvignila za vsega 100 MB, kar pomeni, da

porastu števila uporabnikov, ne narašča tako strmo, kot obremenitev procesorja.

0

2

4

6

8

10

12

14

16

1 3 5

Zah

teve

Število hkratnih zahtev v začetku testiranja (<600 uporabnikov)

: Obremenitev procesorja in izraba pomnilnika v začetku testiranja

Iz obremenitve procesorja je razvidno, da je v začetku simulacije obremenitev

postopoma dosegla 100% in takšna je ostala do konca simulacije.

pomnilnika se je dvignila za vsega 100 MB, kar pomeni, da poraba pomnilnika ob

števila uporabnikov, ne narašča tako strmo, kot obremenitev procesorja.

5 7 9 11 13 15 17 19 21 23 25 27

Čas v sekundah

Število hkratnih zahtev

65

600 uporabnikov)

: Obremenitev procesorja in izraba pomnilnika v začetku testiranja

v začetku simulacije obremenitev

100% in takšna je ostala do konca simulacije. Poraba

poraba pomnilnika ob

števila uporabnikov, ne narašča tako strmo, kot obremenitev procesorja.

27 29 31

66

Polna obremenitev

V času, ko so se ustvarili vsi simulirani uporabniki in dobesedno zasipali sistem z

zahtevami, je bila obremenitev procesorja venomer 100 %, narasla pa je tudi

poraba pomnilnika, kot je razvidno iz slike 29. Obremenitev se je poznala tudi na

omrežnem vmesniku, kar prikazuje slika 28.

Slika 27: Odzivni časi med polno obremenitvijo sistema

Slika 28: Obremenitev omrežnega vmesnika med polno obremenitvijo sistema

Slika 29: Obremenitev procesorja in

Odzivni časi so pričeli dosegati najvišje vrednosti v test

najvišje vrednosti dosegle

prikazuje slika 30.

Slika 30: Število hkratnih zahtev med polno obremenitvijo sistema (600 uporabnikov)

0

2

4

6

8

10

12

14

16

18

20

1 2 3 4

Zah

teve

: Obremenitev procesorja in pomnilnika med polno obremenitvijo sistema

Odzivni časi so pričeli dosegati najvišje vrednosti v testiranju, prav tako pa so

dosegle tudi hkratne zahteve simuliranih uporabnikov

Število hkratnih zahtev med polno obremenitvijo sistema (600 uporabnikov)

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Čas v sekundah


67

pomnilnika med polno obremenitvijo sistema

iranju, prav tako pa so

hkratne zahteve simuliranih uporabnikov, kot

Število hkratnih zahtev med polno obremenitvijo sistema (600 uporabnikov)

21 22 23 24 25

Ponehanje obremenitve

Proti koncu obremenitve se je število hkratnih zahtev zmanjšalo, zmanjšala se je

tudi obremenitev sistem

Slika 31: Število hkratnih zahtev med ponehanjem obremenitve sistema

Odzivni časi so se proti koncu obremenitve znižali in

raven, kot je prikazano na sliki 32.

Slika

0

2

4

6

8

10

12

14

1 2 3 4

Zah

teve

00:00,0

00:17,3

00:34,6

00:51,8

01:09,1

01:26,4

01:43,7

02:01,0

02:18,2

1

Od

zivn

i čas

i

Ponehanje obremenitve


tudi obremenitev sistema, odzivnost pa se je zaradi tega dvignila.

Število hkratnih zahtev med ponehanjem obremenitve sistema

Odzivni časi so se proti koncu obremenitve znižali in spet dosegli

, kot je prikazano na sliki 32.

Slika 32: Odzivni časi med ponehanjem obremenitve

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Čas v sekundah


1001 2001 3001 4001 5001

Zahteve

Odzivni časi

68


Število hkratnih zahtev med ponehanjem obremenitve sistema

spet dosegli normalno

21 22 23 24

5001 6001

69

Zaključek

Strežniški računalnik se je po mojih predvidevanjih odzival tudi ob povečanem

številu simuliranih uporabnikov. Čeprav je iz grafov razvidno, da so nekateri

odzivni časi presegli mejo osmih sekund, pa jih je večina tudi ob polni

obremenitvi strežnika ostalo pod to mejo. Povprečni odzivni čas med testiranjem

je tako znašal z vsemi izrednimi odzivnimi časi, 4,8 sekunde. Najvišji odzivni čas

je znašal tudi dve minuti, vendar je šlo v tem primeru za kompleksnejšo akcijo, to

je odjavo. Iz stališča uporabnika to niti ne bi bilo moteče, saj veliko uporabnikov

med odjavo oz. namesto odjave kar zapre brskalnik.

V mojih testiranjih sta bili najkompleksnejši aktivnosti prijava v sistem in odjava

iz sistema, pri čemur je bila slednja najzahtevnejša in je zahtevala najvišji odzivni

čas. V času izvedbe testiranja sem tudi sam uporabljal sistem Moodle, ki se je

odzival kot običajno in ni bilo zaznati vidnejših zakasnitev v odzivnosti. Iz teh

rezultatov lahko sklepam, da bi sistem, ki je v uporabi na fakulteti lahko prenesel

več tisoč uporabnikov, ki bi opravljali svoje delo. Aktivnosti pravih uporabnikov

bi si sledile z večjim časovnim razmikom, kar pomeni, da bi jih strežnik lažje

obdelal in bi lahko prenesel skupno več hkratnih uporabnikov. Potrdim lahko tudi,

da je sistem ustrezno dimenzioniran za število študentov, ki so potencialni

uporabniki sistema, čeprav sem med testiranjem nekajkrat dobil tudi napako pri

povezovanju s sistemom, ki je sporočala, da je število simultanih uporabnikov

preseženo. Iz odzivnosti, ki jo je sistem v tem trenutku kazal, pa sklepam, da bi se

takšnim sporočilom bilo mogoče izogniti z nastavitvijo več dovoljenih simultanih

povezav uporabnikov v nastavitvah spletnega strežnika Apache.

7 Sklep

V sklopu izdelave diplomskega dela sem izdelal razširitev za sistem za

upravljanje z e-učnimi vsebinami. Ta razširitev je omogočila dodatno

funkcionalnost, ki smo jo potrebovali. Lahko trdim, da je izdelava dodatnih

razširitev mogoča za vsak odprtokodni sistem, če imamo dovolj programerskega

znanja in še lažja, če imamo na voljo dokumentacijo. Odprtokodni sistemi so

70

običajno lažje razširljivi in dokumentacija za njih je lažje dosegljiva. Pomembno

je, da vedno, ko se lotimo izdelave aplikacije z določeno funkcionalnostjo,

pregledamo naše obstoječe aplikacije in preverimo, ali bi lahko uporabili že

obstoječe strukture in izdelali le dodatno funkcionalnost. V mojem primeru sem

uporabil večji del uporabnih lastnosti sistema Moodle, dodal pa sem nekaj

dodatnih funkcionalnosti, ki jih Moodle ne ponuja zaradi specifičnosti teh

funkcionalnosti. Pri tem sem izrabil že obstoječe module, kot so delo z

uporabniki, forum, delo z vsebinami, objava gradiv, več nivojska uporabniška

hierarhija, koledar, pošiljanje sporočil med uporabniki in klepet. Seveda bi za

vzpostavitev funkcionalnosti, ki smo jo potrebovali, moral razviti le uporabniško

prijavo, bi bilo delo s takšno aplikacijo zahtevnejše, poleg tega, pa ne bi ponujalo

vseh ostalih funkcij, kot jih ponuja sedaj.

Iz tega sledi, da je vedno lažje razviti dodatno funkcionalnost za že obstoječi

sistem, kot razviti celoten sistem znova. Najbolje lahko ta sklep pojasnim z

vprašanjem: »Zakaj bi ponovno izumljali kolo, če želimo dodati le zvonec?«

Pri vzpostavitvi kateregakoli sistema, do katerega dostopa več uporabnikov je

vedno v prvi vrsti izdelava ocene, koliko uporabnikov bo takšen sistem

uporabljalo. Pri tem je poleg obstoječih potencialnih uporabnikov potrebno misliti

tudi na prihodnje potencialne uporabnike. Na primer fakulteta z nekaj tisoč

študenti, ne potrebuje sistema, ki bi zdržal sto tisoč uporabnikov. Prav tako si ne

more privoščiti vzpostavitve sistema, ki ne bi podpiral normalnega dela vsaj toliko

uporabnikov, kot je vpisanih študentov, ki so potencialni uporabniki sistema.

Predvsem v času, ko je izobraževanje z uporabo sistemov za upravljanje z e-

učnimi vsebinami, kot primarno ali sekundarno obliko izobraževanja v porastu.

Pri vzpostavitvi sistema je dobro imeti kakšno orodje, s katerim lahko glede na

potrebe določimo obseg sistema. Moj program ne določa obsega sistemov, ampak

le izmeri odzivnost določenega sistema ob simulirani uporabi. Iz teh rezultatov pa

lahko potem sklepamo o predvidenem obsegu za druge sisteme. V vseh mojih

testiranjih je bila ozko grlo moč procesorja. Moja priporočila pri vzpostavitvi

sistema, so zaradi tega predvsem izbira močnejšega procesorja glede na število

potencialnih uporabnikov. Iz testiranj izhaja tudi ugotovitev, da je količina

71

pomnilnika druga najpomembnejša stvar, čeprav je v mojih testiranjih uporaba

pomnilnika narasla le za 15 do 20%, bi pri večji obremenitvi in drugačnih

scenarijih količina uporabljenega pomnilnika še narasla. Le ugibam lahko, če

postavim glede potrebnega pomnilnika grobo zahtevo za 100 MB pomnilnika za

vsakih 100 uporabnikov. Vendar kot sem že omenil, pomnilnik ni ključni dejavnik

pri zmogljivosti sistema in 20 GB pomnilnika ne pomeni zmožnosti dela 20 tisoč

hkratnih uporabnikov, saj bi že veliko prej številnim zahtevam podlegel procesor.

Testiranja so le potrdila dejstvo, da je načrtovanje obsega sistema za upravljanje z

e-učnimi vsebinami kompleksna naloga. Za določanje zmogljivosti sistema ne

obstaja enostavna formula, v katero bi vstavili spremenljivke in dobili magični

rezultat. Pri načrtovanju je potrebno upoštevati več dejavnikov, med njimi

najpomembnejše:

• Število potencialnih uporabnikov,

o načrtovanje prostorske zahtevnosti,

• število hkratnih uporabnikov

o načrtovanje procesorske moči,

• narava njihovega dela,


o načrtovanje količine pomnilnika,

• vrste in oblike e-učnih vsebin,


o načrtovanje količine pomnilnika,

o načrtovanje prepustnosti omrežnega vmesnika.

72

Pri načrtovanju obsega sistema moramo torej, glede na glavne dejavnike, posebno

pozornost posvetiti procesorski moči, količini pomnilnika in prepustnosti

omrežnega vmesnika.

8 Literatura

[1] Alexa. (12. februar 2008). Traffic Details from Alexa. Prevzeto 12. februar

2008 iz moodle.org:

http://www.alexa.com/data/details/traffic_details/moodle.org?site0=moodl

e.org&site1=blackboard.com&site2=dokeos.com&site3=apexlearning.co

m&site4=desire2learn.com&y=r&z=3&h=300&w=610&range=6m&size=

Medium

[2] Dokeos. (marec 2007). dokeos Open Source e-Learning. Prevzeto 11.

februar 2008 iz Features - Test authoring:

http://www.dokeos.com/features.php#tests

[3] Gerlič, I. (November/December 2007). Organizacija. Distance education

models and new communication trends in education , str. 273-278.

[4] Gerlič, I. (2000). Sodobna informacijska tehnologija v izobraževanju.

Ljubljana: DZS.

[5] Hanke, J.-C. (2001). Spletne strani in HTML : [naj ostane preprosto!]. (A.

Šuler, Prev.) Šempeter pri Gorici: Flamingo.

[6] Krašna, M., & Bratina, T. (2007). MIPRO 2007 : 30th Jubilee

International Convention. E-portfolio of teacher training (str. 146-149).

Rijeka: MIPRO.

[7] Krašna, M., & Kaučič, B. (2007). Computer science and technology /

proceedings of the 11th WSEAS international conference on computers.

Designing e-portfolio module for open source LMS (str. 305-310). Crete:

WSEAS.

73

[8] Learning Circuits. (avgust 2006). Learning Circuits -- ASTD's Online

Magazine Covering E-Learning. Prevzeto 09. februar 2008 iz 2006 Survey

of Learning Management Systems:

http://www.learningcircuits.org/2006/August/2006LMSresults.htm

[9] MomentumSI. (2006). Service Oriented Enterprise. Prevzeto 18. februar

2008 iz Request-Response: http://www.serviceoriented.org/request-

response.html

[10] Moodle forum. (1. avgust 2006). Moodle. Prevzeto 19. januar 2008 iz

Capacity: http://moodle.org/mod/forum/discuss.php?d=50934

[11] Moodle. (12. februar 2008). Moodle. Prevzeto 12. februar 2008 iz Moodle

Statistics: http://moodle.org/stats/

[12] Nina, B., Anna, B., & Allan, K. (2000). Integrating User-Perceived

Quality into Web Server Design. 9th International World Wide Web

Conference.

[13] Rohan, R. F. (1998). Building better Web pages. San Diego: AP

Professional.

[14] Savoia, A. (julij 2001). Better Software magazine. Prevzeto 19. januar

2008 iz Web Page Response Time 101:

http://www.stickyminds.com/sitewide.asp?ObjectId=5030&Function=edet

ail

[15] Sevcik, P. J. (julij 2002). NetForecast Articles. Prevzeto 19. januar 2008 iz

Understanding How Users View Application Performance:

http://netforecast.com/Articles/BCR%20C22%20Performance%20Zones.p

df

[16] Sevcik, P. J. (januar 2003). NetForecast Articles. Prevzeto 19. januar 2008

iz Web Performance - Not a Simple Number:

http://netforecast.com/Articles/BCR%20C25%20Web%20Performance%2

0-%20Not%20A%20Simple%20Number.pdf

74

[17] Sevcik, P. J., & Bartlett, J. (oktober 2001). NetForecast Articles. Prevzeto

19. januar 2008 iz Understanding Web Performance:

http://netforecast.com/Articles/BCR%20Article%20Web%20Performance

%20FNL.pdf

[18] Spool, J. M. (Julij 2001). WebWord. (J. S. Rhodes, Izpraševalec)

WebWord.

[19] Vehovec, A., & Azarov Domajnko, M. (09. januar 2006). Poglavja iz

komunikacij. Prevzeto 18. februar 2008 iz Referenčni model OSI:

http://ro.zrsss.si/maja/mreze/ZgradDelov/osi.htm

[20] Whitney, K. (januar 2006). Chief Learning Officer magazine. Prevzeto 09.

februar 2008 iz Report Shows LMS Market Growing Apace:

http://www.clomedia.com/newsletters/2006/January/1267/index.php

[21] Wikipedia. (07. februar 2008). Wikipedia, the free encyclopedia. Prevzeto

08. februar 2008 iz Learning management system:

http://en.wikipedia.org/wiki/Learning_Management_System

[22] Zona research. (April 2001). Keynote Systems. Prevzeto 03. Februar 2008

iz Resource Library: White Papers:

http://www.keynote.com/docs/whitepapers/zona_need_for_speed.pdf

Documents

DIPLOMSKA NALOGA · 2020-01-30 · diplomska naloga z naslovom Uporaba sistema za upravljanje z učnimi vsebinami v velikih skupinah, pri mentorju doc. dr. Marjanu Krašni in somentorju