categorieën

kalender

november 2011
m D w d v Z Z
« okt   jan »
 123456
78910111213
14151617181920
21222324252627
282930  

Digitaal toetsen (deel 4a): Security

Wanneer we ‘digitaal toetsen’ introduceren wordt al gauw kritisch gekeken naar veiligheid en fraudegevoeligheid. Terecht! We vergeten echter, om ook eens naar het traditionele toetsproces te kijken. Ook dat proces is voor verbetering vatbaar in het kader van security. Ik onderscheid zes fasen (globaal) in het toetsproces. Bij elke fase wil ik kijken naar overeenkomsten en verschillen tussen papieren toetsen en digitale toetsen. Uiteraard gericht op security.

  1. De docent ontwikkelt toetsvragen.
  2. Het proefwerk of de toets wordt naar het toetsbureau gestuurd.
  3. Het toetsbureau plant de toets (tijd, plek en (aantal) studenten).
  4. Fysieke en/of digitale voorbereiding.
  5. De toets wordt afgenomen.
  6. Het resultaat wordt verwerkt.

Opmerking: Ik ga er vanuit dat een zichzelf respecterend toetssysteem de beveiliging goed regelt. Dat zo’n beveiliging kan worden gekraakt of omzeild is nooit uit te sluiten. Ook websites van banken worden wel eens door hackers belaagd. Daarmee wil ik niet zeggen dat we onze ogen daar maar voor moeten sluiten. Nee, we moeten er uitermate verdacht op zijn en nadenken hoe we onvolkomenheden op het gebied van security in de software kunnen ondervangen, bijvoorbeeld in de manier waarop we de software gebruiken. Ook moeten we, vooral als het gaat om security, hoge eisen blijven stellen aan leverancier en programmeur.

a) Reacties en aanvullingen zijn uiteraard welkom.
b) Om te voorkomen dat de berichten te lang worden, zal ik dit onderwerp over meerdere berichten verdelen.

Wellicht is mijn beschrijving van de fasen hier en daar wat overtrokken, maar zoeken we niet altijd naar de meest onwaarschijnlijke manieren om de veiligheid van digitaal toetsen ter discussie te stellen? Natuurlijk moeten we proberen om ons in te dekken tegen zo veel mogelijk risico’s, maar als we die risico’s overdrijven dan mogen we nooit meer toetsen, ook niet op papier. In de omschrijving van de zes fasen wil ik de risico’s van papieren toetsen vergelijken met die van digitale toetsen.

Fase 1: Dat een docent zijn toetsen nog met een pen op papier maakt sluit ik bij deze gemakshalve maar even uit (zo’n leraar bestaat toch zeker niet meer?). Laten we eens kijken naar de docent die het examen thuis op zijn eigen pc of laptop maakt. De vragen voor een papieren toets zullen over het algemeen gewoon met een tekstverwerker worden uitgewerkt. Is die pc wel voldoende beveiligd en hoe zit dat met zijn draadloos netwerk? Laat nou net een van zijn ICT-studenten bij hem in de buurt wonen en zijn draadloze router kunnen ontvangen. De student kan zomaar op het onbeveiligde draadloze netwerk van de docent en is binnen een paar minuten aan het grasduinen in zijn Word documenten. De grote vraag is eigenlijk of de onderwijsinstelling weet hoe haar medewerker die examens voorbereidt en zijn computer en netwerk heeft beveiligd. Moeten we iets verzinnen om daar goede afspraken over te kunnen maken? En hoe kunnen we dat dan vervolgens controleren? Helpen we die docent dan ook, krijgt hij support van onze ICT-dienst op zijn thuiswerkplek?

Als de vragen op kantoor worden gemaakt, dan is bovenstaande natuurlijk niet van toepassing. Computer en netwerk zijn goed beveiligd :-). Maar hebben we wel zicht op die keuze, thuis of kantoor, van de docent? Leggen we die afspraak, om toetsen vanaf de werkplek binnen de instelling te ontwikkelen, vast? En controleren we dat dan ook (als dat al mogelijk is)?

Vergelijken we nu met het ontwikkelen van een digitale toets, dan moeten we twee verschillende scenario’s bekijken. a) De vragen worden gemaakt in de toetssoftware die lokaal op een computer van de docent is geïnstalleerd. Gebeurt dat thuis, dan lopen we vergelijkbare risico’s als hiervoor genoemd. Toch is er een verschil in het voordeel van de digitale toets. De vragen staan in een formaat op de harde schijf dat in elk geval minder eenvoudig terug te lezen is dan de vragen in een Word document. Het maken van de vragen op een computer binnen de instelling heeft ook hier de voorkeur. Scenario b) De vragen worden online in het toetssysteem ingevoerd. Hierbij wordt in principe geen data op de harde schijf geschreven. De vragen zijn uitsluitend nog in het beveiligde toetssysteem aanwezig. De meest veilige optie, lijkt me. In dit geval kan de docent, mits zijn netwerk goed beveiligd is, de toetsvragen ook thuis ontwikkelen.

Conclusie? Gebruik voor de ontwikkeling van toetsen en toetsvragen een beveiligd online toetssysteem waarin de vragen direct geschreven en bewerkt kunnen worden. Dat systeem beschikt bij voorkeur over versiebeheer.

In het volgende bericht Fase 2. Wordt vervolgd…

3 comments to Digitaal toetsen (deel 4a): Security

  • Dit belooft een mooie serie berichten te worden Jack! Ik kijk uit naar het vervolg.

    Je opening is ook erg herkenbaar. Sommige docenten reageren erg ‘schuw’ op digitale toetsing omdat ze allerlei beren op de weg zien qua beveiliging. Als je dan verder praat, blijkt dat ze zich over de veiligheidsaspecten van gewone papieren toetsen eigenlijk nooit echt druk hebben gemaakt. Ten onrechte, want veiligheidsrisico’s spelen natuurlijk zowel bij digitale als bij papieren toetsafname.

  • Hoi Jacques en Sander,

    Inderdaad een interessant onderwerp waar veel mensen, naar mijn mening niet helemaal terecht, mee worstelen.

    Als vertegenwoordiger van een digitaal toetspakket (Maple T.A.) komen we vaak bij de mensen (onderwijsinstellingen) langs, en komt de veiligheid en de angst voor fraude vaak aan bod.

    Allereerst is een vergelijking met schriftelijke toetsen een hele goede omdat veel aspecten hetzelfde zijn. Er moet bijv. bij beide een goede controle zijn door surveillanten bijv. dat de juiste persoon achter het papier of achter de laptop zit. En ook is het bij beide belangrijk dat de student geen spiekbriefjes (kan ook in digitale vorm zoals op smartphone of op internet) mag gebruiken. En bij betrappen hierop strenge sancties opleggen zoals uitsluiting.

    Waar ik het eigenlijk over wilde hebben is de angst voor openbaar worden van toetsvragen, of dat toetsvragen mogelijk “gestolen” worden. Ik denk juist door het tijdperk van digitale toetsen dit eigenlijk allemaal veel rooskleuriger wordt.

    In mijn eigen studietijd (Werktuigbouwkunde, TUE) kon je bij het secretariaat voor veel vakken oude examenbundels kopen, zodat je extra oefenmateriaal had, en wellicht was dit al een vorm van toetsgestuurd leren! En heel soms had je geluk dat exact dezelfde opgave op een tentamen verscheen. Echter probleem was dan ook weer voor de student dat je zoveel opgaven had gemaakt als oefening dat de herinnering aan die ene vraag niet meer 100% was.

    Bij Digitaal toetsen heb je het voordeel dat vragen “hevig” gerandomiseerd kunnen worden. En in dat geval kun je de studenten gewoon de vragen geven en ermee laten oefenen voor een examen. Tijdens het echte examen moeten ze of alle opgaven uit hun hoofd leren (wellicht onmogelijk als er 100.000 varianten zijn) of eenvoudigweg de stof snappen om de vragen te kunnen beantwoorden. In beide gevallen is het doel wellicht bereikt.

    Een eenvoudig voorbeeld is deze gerandomiseerde vraag:

    1/$a + 1/$b ==

    $a en $b zijn hier beide variabelen, en lopen bijv. van 2 tot 10. Je krijgt dus in totaal 81 verschillende vragen bijv.:

    1/3 + 1/7 =
    1/4 + 1/2 =
    1/8 + 1/5 =

    En de teller kun je overigens ook nog randomiseren en dan kom je in de orde van duizenden verschillende vragen in een vraag.

    De student mag dan best weten dat deze vraag gesteld kan/zal worden op het examen, maar hij moet toch echt snappen hoe je het dient aan te pakken. Mooi bijkomend voordeel is dat de student een extra “studietool” heeft doordat hij voor het examen eindeloos de examenvragen kan oefenen, totdat hij of zij het begrijpt.

    Dit is een rekenkundig voorbeeld, maar je kunt randomisatie ook toepassen in teksten, figuren, links etc. en uit het hoofd leren van toetsvragen is dan quasi onmogelijk.

    Dus (echte) randomisatie als beveiligingsmiddel is op dit punt een zeer krachtig wapen, en toetsvragen hoeven dan niet meer op een geheime plaats te worden bewaard.

    Nog een voordeel is dat je toetsvragen niet eeuwig geheim kunt houden. Elk jaar is er een tentamen en hertentamen, en de vragen die daar gesteld worden kunnen door studenten “mee naar buiten genomen worden” (voor mijn part door onthouden), net zoals met schriftelijke toetsen overigens. Met gerandomiseerde toetsen is dit dus een probleem dat tot het verleden behoort.

    Praktisch (huidig) nadeel van digitaal toetsen is dat examenruimtes meestal nog beperkt zijn (bijv. een examen ruimte met 100 laptops), terwijl je bij schriftelijk toetsen een grote zaal met 500 studenten kunt plaatsen. Oplossing is dat je “shifts” krijgt van bijvoorbeeld 5 * 100 studenten. Gevaar is dan dat studenten die het examen gemaakt hebben informatie doorspelen naar studenten die in een latere shift aan de beurt komen.

    Echter door de randomisatie maakt het allemaal niks uit en blijft het geheel toch veilig.

    Groeten,
    Gose

  • Jack Pleumeekers

    Dank voor jullie reacties. En… inderdaad Gose, die examenbundels daar heb ik vroeger ook nog gebruik van gemaakt. Het verschil is alleen dat het dan om een landelijke organisatie gaat, die jaarlijks slechts één examen hoeft te ontwikkelen. Dat examen bestaat dan toch over het algemeen uit allemaal nieuwe vragen. Een docent die regelmatig wil toetsen, heeft naast het ontwikkelen van al die vragen ook nog iets anders te doen. Dat maakt het ontwikkelen van een grote itembank vaak een te grote investering. Anders wordt het als je gebruik kunt maken van randomisatie. Dat biedt inderdaad voordelen. Goed dat je zo uitgebreid hebt gereageerd Gose, dat levert nieuwe input voor het vervolg van deze reeks over security. Je loopt daarmee wel wat vooruit op mijn berichten, maar dat is prima. 😉

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>