Ontwikkelen van COO-modules

Vormen van e-Learning modules

Er zijn een aantal mogelijkheden:

1. Oefeningen die in BlackBoard worden gemaakt en afgenomen. Dit kan de docent in principe zelf, maar kan ook samen met het CPIO worden ontwikkeld.
   • Voordelen:
     1. Direct te koppelen aan BlackBoard, met statistieken, release-data en overzicht cijfers
     2. Eenvoudig door docent te onderhouden
     3. Extra mogelijkheden in BlackBoard zoals randomiseren
   • Nadelen:
     1. Niet alle vraagtypen zijn mogelijk: geen open vragen, korte invul-vragen of aanklikken in een afbeelding
     2. Alleen beschikbaar voor de studenten van deze cursus
2. Formatieve toetsen van het elektronische toetsprogramma TestVision die als oefentoets kunnen worden aangeboden. Ook dit kan de docent in principe zelf.
   • Voordelen:
     1. Redelijk eenvoudig door docent te onderhouden
     2. Uitgebreide analyse van de resultaten
     3. Meer vraagtypen mogelijk dan in BlackBoard
   • Nadelen:
     1. Niet alle vraagtypen zijn mogelijk (maar wel veel)
     2. Open vragen moeten door de docent met de hand worden nagekeken
     3. Geen koppeling naar BlackBoard
     4. Studenten moeten per module worden toegewezen
3. Ontwikkeling in eigen omgeving van CPIO (was Authorware, wordt LiveCode)
   • Voordelen:
     1. Alles kan
     2. Voor iedereen beschikbaar
   • Nadelen:
     1. Docent kan dit niet zelf
     2. Gegevens worden wel opgeslagen, maar zijn lastiger te evalueren
     3. Het nadeel van de plug-in is met het bgebruik van de LiveCode-omgeving niet meer van toepassing: alle vormen kunnen op alle platforms gedaan worden

Ontwikkeling door CPIO

Bij het CPIO worden de COO-modules op maat geproduceerd in overleg met de docent.
De modules zijn meestal in de vorm van oefentoetsen, die het werkcollege kunnen vervangen, maar andere vormen zijn ook mogelijk. Er kunnen ook video's of animaties gemaakt worden.
Hierna zal voornamelijk gesproken worden over het ontwikkelen in de eigen omgeving, hoewel het hele ontwikkelproces ook gebruikt kan worden voor ontwikkeling met de andere platforms (BlackBoard en TestVision).

Kosten / tijdsinvestering

Een gemiddelde oefentoets heeft een ontwikkeltijd van ongeveer 120 uur, en heeft de volgende kenmerken:

• ongeveer 40 vragen, inclusief subvragen zijn dat 50-60 vragen
• een student is er ongeveer 90 min mee bezig
• heeft hooguit 3 korte animaties
• de lay-out is standaard
• de ruwe vragen worden door de docent aangeleverd
• alle inhoud is terug te vinden in een boek
• er is één docent bij betrokken

Alles waarin afgeweken wordt van de bovenstaande punten zal extra ontwikkeltijd opleveren.
Deze 120 uur is uitsluitend tijd van het CPIO; de docent zal daarnaast ook zelf tijd kwijt zijn voor het aanleveren van de vragen en het controleren van het script.

Andersoortige COO's zijn ook mogelijk, zoals simulaties.

Werkwijze

Er zijn een aantal stappen:

1. Intake
2. Scripten
3. Programmeren
4. Testen
5. Gebruiken
6. Evalueren

Scripten vergt de grootste tijdsinvestering: zo'n 80% van de ontwikkeltijd. Hierin worden bijvoorbeeld bij elke (sub)vraag voor alle mogelijke antwoorden feedbacks geformuleerd, en beeldmateriaal gezocht.

1 Intake

Eerst wordt een inventarisatie uitgevoerd, waarin wordt besproken:

• wat is de reden dat er voor een COO wordt gekozen?
• welk probleem wordt hiermee hopelijk opgelost, en wordt bepaald of dat zo is?
• hoeveel tijd heeft de docent om hieraan te werken?
• welk materiaal is er al beschikbaar?
• wanneer moet het gebruikt worden?

2 Scripten

Aan de hand van het aangeleverde materiaal wordt een script gemaakt waarin deze vragen helemaal zijn uitgewerkt. Bij een standaard lay-out is dit script vrij simpel. Over korte perioden van bijvoorbeeld een week wordt het laatste deel van het script goedgekeurd en kan dat worden geprogrammeerd. Omdat tijdens het programmeren vaak blijkt dat een andere vorm beter werkt, kan het voorkomen dat een vraag tijdens het uitwerken al wordt geprogrammeerd, en de docent direct de geprogrammeerde vraag moet beoordelen.

3 Programmeren

Wat nog niet tijdens het scripten is gebeurd wordt in het laatste stadium gedaan, evenals het toevoegen van paginaverwijzingen, score etc.

4 Testen

• eerste test door programmeur
• tweede test door docent
• derde test door student-assistenten

Deze laatste stap wordt wegens tijdgebrek vaak overgeslagen. Voordeel van deze laatste stap is dat de studentassistenten die straks de studenten begeleiden al weten waar de COO over gaat.

5 Gebruiken

1. Het meeste effect hebben deze modules als ze worden ingeroosterd, en de studenten er aan koppels aan moeten werken. Studenten die dit alleen thuis doen, hebben veelal de neiging om gewoon 'door te klikken' en de juiste antwoorden te noteren. Het leereffect is dan nihil.
2. Van elke sessie worden de gegevens opgeslagen. Ook kunnen meerdere studenten inloggen in één module bij het maken ervan. Deze gegevens kunnen worden gebruikt om:
   • de vragen zelf te evalueren
   • te controleren of iedereen de modules heeft gemaakt
3. De modules staan op het internet, vrij toegankelijk voor de hele wereld. Alleen van gebruikers die inloggen met een SolisID worden de gegevens bewaard.
4. Aan het einde komt vaak een korte enquête over de module (1 min). In de nieuwe omgeving is er een knop om commentaar te geven op elk gewenst moment, over bugs of inhoudelijke problemen. Deze kunnen ook verzameld worden.

6 Evaluatie

1. Uit de enquete kan de tevredenheid van de studenten afgelezen worden
2. Uit de opgeslagen gegevens kan de kwaliteit van de vragen afgelezen worden
3. Uit de opmerkingen kunnen eventuele bugs naar voren komen
4. Tevens is er altijd een enquete van de gehele cursus, waar een vraag over de COO in kan staan.