VGTogether. samenwerken in voortgangstoetsing. Programma Toetsing en Toetsgestuurd Leren

VGTogether samen werken in voortgangstoetsing

Programma Toetsing en Toetsgestuurd Leren PIJLER 1: Het verminderen van studie-uitval en werkdruk in het hoger onderwijs

Deliverable 1.1: Requirementsanalyse ICB

Datum: Auteur:

14-10-2011 Annemarie Camp, Floor Mulder, Jeroen Donkers, Frank van de Kamp

Deliverable 1.1 versie 14-10-2011

Inhoudsopgave

1.

Inleiding .................................................................................. 3

2.

Doel project en mission statement ICB ........................................ 3

3.

Organisatiestructuur en procesanalyse van de iVTG ....................... 5 3.1

Organisatiestructuur ............................................................................... 5

3.2 Toetsconstructie, toetsafname en toetsverwerking ........................................ 7 3.2.1

Toetsconstructie.................................................................................. 7

3.2.2

Toetsafname ...................................................................................... 8

3.2.3

Toetsverwerking ................................................................................. 9

4.

Analyse stakeholders ............................................................... 13

5.

Het item-constructie en -beoordelingsproces .............................. 15

5.1

State-diagram itemconstructie en -beoordelingsproces .................................15

5.2

Proces voor toetsafname ...........................................................................17

5.3

Proces na toetsafname ..............................................................................19

6. Beschrijving van rollen en bijbehorende taken in itemconstructie en beoordelingsproces ......................................................................... 20 7.

Identificatie knelpunten in itemconstructie en -beoordelingsproces 26

8.

Identificatie mogelijke oplossingen ............................................ 29

9.

Functionele requirements ......................................................... 32

9.1

Use-cases................................................................................................32

9.2

Functionele requirements ..........................................................................39

10.

Niet-functionele requirements ................................................... 42

11.

Specifieke eisen m.b.t. voortgangstoetsing en het VOSYS systeem 44

1


Lijst met afkortingen AMFON CiC DB

Alliantie Medische Faculteiten Oost-Nederland Centrale iVTG Coordinator Dagelijks Bestuur

ICB iVTG UM UMCG LiC LUMC

Itemconstructie en –beoordeling Interuniversitaire Voortgangstoets Geneeskunde Universiteit Maastricht Universitair Medisch Centrum Groningen Lokale iVTG Coordinator Leids Universitair Medisch Centrum

PROF UMCN VBC VOSYS VT WiV

Progress Test Feedback System Universitair Medisch Centrum Nijmegen Voortgangstoets Beoordelings-Commissie Voortgangstoets Service Systeem Voortgangstoets Werkgroep interuniversitaire Voortgangstoetsing

2


1.

Inleiding

Het resultaat van deze deliverable is een requirement-analyse, waarin zal worden vastgesteld aan welke criteria het “te kiezen” ICB (ItemConstructie en -Beoordeling) system dient te voldoen. Voor deze analyse zijn gesprekken gevoerd met meerdere stakeholders binnen de interuniversitaire VoortgangsToets Geneeskunde (iVTG) (zie hoofdstuk 4 voor een beschrijving van de stakeholders en bijlage 1 voor een lijst met gesprekspartners). De gesprekken zijn ingezet als instrument om de requirements te achterhalen en te verifiëren. Daarnaast zijn ze ook gebruikt om de huidige rollen en de taken van alle betrokkenen in het itemconstructie en –beoordelingsproces in kaart te brengen, de daarbij op dit moment spelende knelpunten te identificeren en om mogelijkheden voor efficiëntievergroting te ontdekken. In dit document wordt eerst de missie van het toekomstige ICB-systeem gepresenteerd. Daarna wordt in hoofdstuk 3 de huidige organisatiestructuur van de iVTG toegelicht en de processen en bijbehorende activiteiten die ten uitvoer worden gebracht in de iVTGorganisatie. In hoofdstuk 4 wordt er een weergave gegeven van alle stakeholders van de iVTG. Het itemconstructie en –beoordelingsproces wordt uitgelegd in hoofdstuk 5. Omdat dit proces erg toegespitst is op de life-cycle van een item, wordt op deze life-cycle nader ingegaan. De rollen en taken in het huidige itemconstructie en –beoordelingsproces worden uitgelicht in hoofdstuk 6. In hoofdstuk 7 wordt er ingegaan op de huidige knelpunten in het itemconstructie- en beoordelingsproces. Daarna wordt in hoofdstuk 8 toegelicht hoe het ICB-systeem een oplossing kan geven aan deze knelpunten. In hoofdstuk 9 en 10 worden de beschreven oplossingen omgezet in gedetailleerde usecase beschrijvingen en verder uitgewerkt in een lijst met requirements. De requirements die in dit document zijn opgesteld vallen uiteen in functionele en nietfunctionele requirements. Functionele requirements zijn de eisen die de stakeholders aan de werking van het ICB-systeem stellen. Het gaat hier om functionaliteiten die de gebruiker in staat stelt haar werk te doen. De niet-functional requirements beschrijven hoe het systeem moet werken en aan welke kwaliteitseisen het moet voldoen. Voorbeelden hiervan zijn veiligheid, betrouwbaarheid, beheerbaarheid en gebruikersvriendelijkheid. Tenslotte komt in hoofdstuk 11 de specifieke eisen m.b.t. voortgangstoetsing en het Voortgangstoets Service Systeem (VOSYS) aan bod.

2.

Doel project en mission statement ICB

Het hoofddoel van het VGTogether project luidt als volgt: Het faciliteren van een verhoogde itemproductie en het bereiken van een bestendiger beheersituatie middels een centrale ICT infrastructuur ten behoeve van het gehele logistieke traject rond voortgangstoetsing, op een zodanig wijze dat niet alleen de in de interuniversitaire VoortgangsToets Geneeskunde (iVTG) samenwerkende geneeskundeopleidingen daarvan gebruik kunnen maken, maar ook andere samenwerkingsverbanden rond voortgangstoetsing mogelijk worden. Om bovenstaande doelstelling te bereiken wordt er een ICB (ItemConstructie en Beoordeling) -systeem geïntroduceerd die een oplossing moet bieden voor de huidige knelpunten rondom itemconstructie en -beoordeling. De missie van het ICB-systeem is ontleend aan de doelstelling van het VGTogether project en kan als volgt worden gedefinieerd: Het ICB-systeem ondersteunt de iVTG-organisatie bij het construeren van items, het beoordelen van items, het genereren van feedback over items voor auteurs en bij het beheer van items. Deze ondersteuning verlaagt het administratieve proces rondom het

3


item constructie- en beoordelingsproces voor alle belanghebbenden die hierbij betrokken zijn .

4


3.

Organisatiestructuur en procesanalyse van de iVTG

Dit hoofdstuk beschrijft de organisatiestructuur van de iVTG. Alle voorkomende commissies of functies en hun relaties worden weergegeven. Hierna wordt uitgelegd hoe het proces van toetsconstructie, van toetsafname en van toetsverwerking verloopt. De benodigde tijd voor alle taken en activiteiten om dit te bewerkstelligen wordt uiteengezet in een tweetal tijdslijnen. 3.1

Organisatiestructuur

De interuniversitaire VoortgangsToets Geneeskunde (iVTG) is een meetinstrument om de kennisprogressie van studenten Geneeskunde gedurende hun studie te meten. Dit meetinstrument bestaat uit vier voortgangstoetsen per studiejaar. De toetsen zijn het resultaat van een interfacultaire samenwerking tussen de Universiteit Maastricht (UM), Universitair Medisch Centrum Groningen (UMCG), Leids Universitair Medisch Centrum (LUMC) en Universitair Medisch Centrum Nijmegen (UMCN). We noemen het samenwerkingsverband binnen dit project ook de iVTG, omdat aan dit verband geen formele naam is gegeven. De hieronder beschreven informatie is voor een deel afkomstig uit het contract „Samenwerkingsovereenkomst iVTG‟ (2009). De voortgangstoets (VT) wordt wel bij alle instellingen op dezelfde tijd afgenomen. In elke iVTG-instelling is er een Voortgangstoets Beoordelings-Commissie (VBC), bestaande uit een voorzitter en op dit moment vijf tot 7 leden die afkomstig uit drie cluster disciplines: de Basis-, Klinische en Gedragswetenschappelijke vakken. De voorzitter van de VBC is door de examencommissie van de opleiding als examinator aangewezen. De VBC-leden zijn verantwoordelijk voor de itemproductie en hebben daarom direct contact met de itemauteurs. De itemauteurs zijn docenten werkzaam binnen één van de drie cluster disciplines. De auteurs schrijven nieuwe items waarbij de inhoud van het item gerelateerd is aan zijn of haar eigen specialisme. Naast het schrijven van nieuwe items, worden ook de items die gebruikt zijn voor de toets opnieuw bekeken en herschreven door de itemauteurs. De VBC-leden beoordelen de kwaliteit van alle nieuwe en herschreven items aangeleverd door de auteurs van de eigen instelling. Hierbij wordt onder andere gekeken naar relevantie, inhoudelijke correctheid en de formulering van het item. In de praktijk komt het voor dat ook nieuwe items door de VBC-leden zelf geschreven worden, waarna deze met de andere plaatselijke VBC-leden beoordeeld worden. Alle items die door de VBC‟s worden goedgekeurd, worden opgenomen in de gezamenlijke itembank. Elke vraag die in deze itembank is opgenomen is daardoor eerst beoordeeld door tenminste één van de vier facultaire VBC‟s. Elke VBC wordt ondersteund door een Lokale iVTG Coordinator (LiC). De LiC verzorgt de logistieke afhandeling en alle communicatie en administratie rondom de iVTG binnen de eigen organisatie. Ook verzorgt deze coördinator de communicatie tussen de VBC‟s en de centrale organisatie van de iVTG. De centrale organisatie van de iVTG wordt ten uitvoer gebracht door de Centrale iVTG Coördinator, de Result Admins en de Psychometricus. De Result Admins zijn verantwoordelijk voor toetsverwerking, itemanalyse en berekening van de resultaten. Voordat de resultaten berekend worden, stelt de Psychometricus eerst de definitieve normen vast. De Centrale iVTG Coördinator (CiC) verzorgt de communicatie tussen de partners en is verantwoordelijk voor het beheer van de itembank in het VOSYS systeem en het opstellen van het toetsboekje. De CiC krijgt op dit moment ondersteuning van een assistent bij het invoeren van de items in de databank. De partners komen samen in de Werkgroep interuniversitaire Voortgangstoetsing (WiV). De partners worden in deze werkgroep vertegenwoordigd door de voorzitters van de VBC‟s, de lokale iVTG-coördinatoren (LiC) en betrokken onderwijsdeskundigen per 5


instelling. De WiV wordt voorgezeten door één landelijke voorzitter afkomstig uit één van de partnerinstellingen die het penvoerderschap heeft. De WiV heeft tot taak het landelijke beleid aangaande de voortgangstoets vorm te geven, waaronder procedures rond uitvoering en kwaliteit van de toets/vragen, analyse, normering en feedback en beslissingen omtrent gebruik van toetsen door derden. De WiV is eindverantwoordelijk voor de productie en analyse van de iVTG. Het Dagelijks Bestuur (DB) is een subcommissie van de WiV en is belast met de uitvoering van de taken van de WiV. Het DB bestaat uit de voorzitter van de WiV en de voorzitters van de VBC‟s. Het DB bespreekt de individuele toetsen na en neemt beslissingen over vervallen vragen en sleutelwijzigingen. Naast het DB, heeft de WiV een Wetenschappelijk Orgaan (WO) die het wetenschappelijk onderzoek coördineert met betrekking tot de voortgangstoets. Het WO stelt het meerjarenplan op voor gemeenschappelijk onderzoek met betrekking tot de voortgangstoets. De leden van het WO zijn de voorzitter van de WiV, alsmede één afgevaardigde uit leden van de WiV per partnerinstelling. De lokale examencommissies van de partners zijn eindverantwoordelijk voor de VT, op de eigen locatie. De iVTG is door elke partner opgenomen als onderdeel van het eigen curriculum. De regels van de iVTG zijn daardoor onderdeel van de examenreglementen van de partners. De organisatiestructuur van de iVTG wordt weergegeven in een organogram, die hieronder is afgebeeld.

Afbeelding 1: Organogram iVTG

6


3.2

Toetsconstructie, toetsafname en toetsverwerking

3.2.1 Toetsconstructie De toetsen worden samengesteld op basis van een blauwdruk. In de blauwdruk wordt aangegeven hoeveel items er uit elk deelgebied in de toets opgenomen dienen te worden. Deelgebieden worden gevormd door het kruisen van twee itemclassificaties (disciplines en categorieën). Met behulp van het Voortgangstoets Service Systeem (VOSYS) wordt volgens deze blauwdruk een pre-selectie van op dit moment 456 items gemaakt die als concepttoets wordt opgeslagen. De pre-selectie wordt voorgelegd aan de voorzitter van het DB die hieruit 200 vragen selecteert voor de voorlopige toets. Vervolgens controleert de voorzitter de toets op ongewenste interactie tussen vragen en past indien nodig nog vragen aan. Als dit gebeurt is, wordt de voorlopige toets voorgelegd aan de Groniningse VBC voor een kwaliteitscontrole (dit houdt in het opsporen van conflicten tussen items en fouten in taal, opmaak of antwoordsleutel). In 2007 is in Maastricht een Engelstalige variant van de bacheloropleiding gestart en in 2009 in Groningen. In deze curricula wordt een rechtstreekse vertaling van de Nederlandse voortgangstoets gebruikt. Op het moment dat de voorlopige toets wordt voorgelegd aan de Groningse VBC ter kwaliteitscontrole, wordt de voorlopige toets simultaan opgestuurd naar het vertaalbureau van UMCG. De vertaalde versie van de voorlopige toets wordt voorgelegd aan een „native speaker MD‟, om de vertaling van de medische termen te controleren. De voorzitter van de WiV/DB verwerkt het commentaar op de voorlopige toets en stelt daarna de toets voor afname vast. Deze toets wordt opgestuurd naar de CiC en in VOSYS ingevoerd. De CiC verwerkt de toets tot een digitaal toetsboekje. De CiC verstuurt dit digitale toetsboekje naar de LiC‟s, die elk op hun eigen manier zorg dragen voor het drukproces. Opstellen antwoordformulieren voor toetsafname Alle deelnemende instelling sturen (elektronische) lijsten met deelnemers, voorzien van studentnummer en meetmoment1, naar Maastricht. De gegevens van deze lijsten worden bewerkt naar gestandaardiseerde antwoordformulieren. Het Memic (Centrum voor Data en Informatiemanagement dat onderdeel is van UM-FHML) in Maastricht verzorgt het drukken van de antwoordformulieren voor Leiden, Nijmegen en Maastricht. Groningen draagt zelf zorg voor het drukken van de antwoordformulieren. De lijsten worden tevens door de Result Admins in VOSYS ingevoerd en meerdere „sessies‟ worden hierbij aangemaakt, zodat elke opleiding (bachelor/master/A-KO/ITM) in een aparte groep komt te staan. Daarna worden de gedrukte papieren antwoordformulieren verstuurd. Hierna kan de toets worden afgenomen. Het totaal aantal activiteiten welke ten uitvoer worden gebracht, in de hierboven beschreven processen, voor toetsafname worden schematisch weergegeven in de tijdsbalk in afbeelding 2. In deze tijdsbalk is ook af te lezen hoeveel tijd (in dagen) er (minimaal en maximaal) op dit moment besteedt wordt aan elke activiteit. Deze getallen zijn gebaseerd op 4 waarnemingen in de periode 2010 – 2011.

1

Voor een student die aan een VT deelneemt, geeft het nominale meetmoment aan in welke fase van het curriculum de betreffende student op dat moment zit. In totaal zijn er 24 meetmomenten, omdat de toets 4 keer per jaar wordt afgenomen in de zesjarige opleiding. De instellingen bepalen zelf het meetmoment van de student (bachelor en master), afhankelijk van hun eigen examenreglement. 7


Afbeelding 2: Het aantal activiteiten en bijbehorende tijdsbesteding voor toetsafname

3.2.2 Toetsafname In Leiden, Maastricht en Nijmegen maken alle studenten de toets in de eigen stad. De Groningse Masterstudenten mogen de toets ook maken in bepaalde affiliatieziekenhuizen wanneer zij daar co-schappen lopen. Dit zijn ziekenhuizen in Almelo, Deventer, Emmen, Enschede, Leeuwarden, Zwolle en op Curaçao. Vanaf 1 september 2007 worden de toetsen ook afgenomen bij derdejaars en hoger van de medische opleiding van de VU Amsterdam. De studenten van de Universiteit Gent nemen een maal per jaar deel in december. Deze universiteiten vallen niet binnen de iVTG-samenwerking en dragen dus ook niet bij aan de itemproductie en -beoordeling. Het aspirantlidmaatschap van de VU Amsterdam is recent verlengd tot 2012. Alle deelnemende studenten maken exact dezelfde toets en de officiële aanvangstijd is voor allen exact gelijk. De studenten hebben maximaal vier uur de tijd om een toets af te leggen. 8


Elke student ontvangt op locatie zijn/haar individuele antwoordformulier. Op dit antwoordformulier staat de naam van de student, het ID-nummer, het typenummer student2, het toetsnummer en het individuele meetmoment vermeld. Het kan voorkomen dat de informatie op het formulier op dat moment onjuist blijkt te zijn, omdat er in de onderwijsadministratie iets fout is gegaan (in het meeste geval is dit het meetmoment). Ook komt het voor dat studenten zich soms vergeten in te schrijven voor aanvang van de toets. Wanneer dat het geval is, wordt er handmatig ter plekke op basis van de informatie die de student aangeeft door de surveillant een leeg antwoordformulier ingevuld met de studentgegevens. Individuele gegevens die achteraf onjuist blijken te zijn, worden middels een mutatiebriefje (afkomstig van de examencommissie) aangepast in het VOSYS systeem door de Result Admins. Bij bijna alle partnerinstellingen zijn de LiC‟s zijn eindverantwoordelijk voor het logistieke proces rondom afname van de toets in de eigen instelling. Dit houdt o.a. in het drukken van het toetsboekje, zaalhuur en surveillanten. Wanneer er ooit in de toekomst besloten wordt om de VT digitaal te gaan afnemen zal dit grote winst opleveren voor het takenpakket van de LiC. Echter het digitaal afnemen van de toets valt buiten de scope van het VGTogether project. 3.2.3 Toetsverwerking Na toetsafname ontvangt de CiC van Leiden, Maastricht en Nijmegen de antwoordformulieren en levert deze af bij de Result Admins. De Result Admins versturen de antwoordformulieren naar Memic die ze vervolgens met behulp van het programma Teleform verwerkt. Memic stuurt de antwoorden in de vorm van SPSS databestanden aan de Result Admins. De antwoordformulieren van de Groningense studenten worden in Groningen zelf verwerkt. Groningen stuurt de files met de Groningse resultaten en meetmomenten voor de resultatenbereking in Maastricht naar de CiC. De CiC stuurt deze files door naar de Result Admins. De Result Admins importeren de databestanden naar VOSYS (zie voor meer technische details deliverable 2.1), waardoor er een itemanalyse kan worden gedaan per sessie en over de iVTG samenwerkende universiteiten (ook wel AMFON 3 genoemd) in totaal. Deze itemanalyses worden samen met de studentcommentaren, zie hieronder, gebruikt om de definitieve lijst met toetsvragen vast te stellen die gebruikt wordt om de uitslag te bepalen. Commentaarverwerking Na afname van de toets mogen de studenten het toetsboekje meenemen. De antwoordsleutels en literatuurverwijzingen worden na afloop van de toetsafname bekend gemaakt en blijven 2 jaar beschikbaar. Studenten (alleen van de iVTG samenwerkende instellingen) kunnen binnen 5 werkdagen na toetsafname via een speciale webpagina (dit is per iVTG-instelling geregeld) commentaar op een vraag geven. Dit commentaar moet goed beargumenteerd zijn en van relevante literatuurverwijzingen voorzien zijn. De CiC verzamelt van alle iVTG-instellingen het studentcommentaar, waarna een totaalbestand inclusief de itemanalyses worden opgestuurd naar de lokale VBC‟s ter bespreking (deze VBC-vergaderingen vinden overigens niet op dezelfde dagen plaats). Daarna bespreken de voorzitters de uitkomsten van alle lokale VBC‟s in het telefonische DB-overleg om een besluit te nemen over het vervallen van items en/of sleutelwijzigingen. De Voorzitter DB neemt hierin definitieve besluiten als anderen stemmen staken. De uitkomst van deze nabespreking wordt vervolgens door de CiC verwerkt in VOSYS. Hierdoor ontstaat de definitieve versie van de toets die door de lokale VBC aan de lokale examencommissie voorgelegd wordt welke de toets formeel moet vaststellen. Hiermee kan de definitieve

2

Typenummers zijn: 0=regulier; 1= A-KO; 2= variabel (in bijv. dec. 2009 = entreetoets); 3= ITM oude cohorten; 4=ITM nieuwe cohorten 3 AMFON staat voor Alliantie Medische Faculteiten Oost-Nederland (Nijmegen, Groningen en Maastricht. Leiden is hier later bijgekomen.) 9


versie van de toets vastgesteld worden en kan er worden gestart met het vaststellen van de normen en het berekenen van de resultaten. Vaststellen van normen Een voortgangstoets bestaat in principe uit 200 meerkeuzeitems. Het aantal antwoordalternatieven varieert per item en bedraagt minimaal twee en maximaal vijf. Daarnaast heeft de student bij elk item de mogelijkheid om een vraagteken in te vullen. Een goed antwoord levert één punt op. Studenten krijgen punten aftrek voor fouten antwoorden. Het aantal punten aftrek is gebaseerd op de gokkans voor een item en wordt berekend door één te delen door het aantal foute alternatieven. Een fout antwoord op een vierkeuzevraag levert dientengevolge een derde punt aftrek op. Voor vraagtekens worden geen punten gegeven. Om de uiteindelijke score op de toets te berekenen wordt het aantal behaalde punten gedeeld door het totale aantal vragen en vermenigvuldigt met 100. Hierdoor ontstaat een procentuele score. Voor de toetsen van de iVGT wordt gebruik gemaakt van relatieve normen. Het resultaat van de student wordt afgezet tegen het resultaat van een relevante referentiegroep. Als referentiegroep worden alle studenten uit hetzelfde meetmoment genomen. De kwalificaties die voor een losse toets behaald kunnen worden zijn: Onvoldoende, Voldoende of Goed. Voor het vaststellen van de drie kwalificaties zijn voor de 24 meetmomenten twee normen nodig: de Onvoldoende/Voldoende-norm (O/V-norm) en de Voldoende/Goed-norm (V/G-norm). De voorlopige O/V-normen worden bepaald door voor elke referentiegroep het gemiddelde (M) minus standaarddeviatie (SD) te bepalen. Het gemiddelde wordt berekend over de correcte gescoorde antwoorden – de incorrecte antwoorden. De voorlopige V/G-normen worden met behulp van de volgende formule bepaald: M + 0.5 x SD. Voorafgaand aan de definitieve normberekening worden de voorlopige normen per meetmoment ingevuld door de Result Admins. Hierna wordt de eerste resultaatberekening gestart. Ten behoeve van de definitieve normberekening wordt de eerste resultatenrekening voorgelegd aan een Psychometricus. Deze zet de voorlopige normen om door middel van het fitten van een kwadratische curve op de verzameling punten M-SD (elk punt gewogen met bijbehorend aantal deelnemers). De hoogte van de gefitte curve levert voor elk meetmoment de gehanteerde norm op. Het punt op de curve behorend bij een meetmoment wordt gebruikt als O/V-norm. Op analoge wijze komt de V/G-norm tot stand middels het fitten van een kwadratische curve op de reeks M+0.5SD punten. In het geval dat een norm lager uitvalt voor een hoger meetmoment, wordt de hogere norm van het voorafgaande meetmoment aangehouden. Wanneer de definitieve normen zijn vastgesteld worden deze in VOSYS ingevoerd. Uitslagberekening Nadat de normen zijn vastgesteld, kan er gestart worden met het berekenen van de uitslagen voor de studenten van alle deelnemende instellingen. In VOSYS wordt per student de score en de kwalificatie (Onvoldoende, Voldoende, Goed) vastgesteld. Daarnaast worden ook de gemiddelden per referentiegroep berekend met behulp van VOSYS. Deze gegevens worden ter goedkeuring voorgelegd aan de Psychometricus. Ter controle op de uitslagberekening wordt in Groningen een eigen resultatenberekening uitgevoerd voor de Groningse studenten. Dit gebeurt met behulp van de in Maastricht berekende definitieve normen. Deze eigen berekening wordt vergeleken met de resultaatberekening (overzicht met scores en kwalificaties van Groningse studenten) die Maastricht heeft gedaan. Indien Groningen, evenals de Psychometricus akkoord is met de resultaatberekening kan er gestart worden met het opstellen van de (elektronische) uitslagdocumenten. Het kan voorkomen dat er voor de eindberekening nog een mutatie in VOSYS doorgevoerd moet worden omdat het meetmoment van een student achteraf onjuist blijkt te zijn. In het geval dat de berekening al opgestart is, wordt er een mutatiebriefje opgesteld zodat deze verandering in meetmoment voor de volgende toetsverwerking in acht wordt genomen. 10


Feedback naar studenten Het individuele uitslagdocument geeft de procentuele score van de student weer en tevens ook de uitslagen per categorie en discipline en wordt gerelateerd aan de juiste referentiegroep. In het overzicht wordt met “+” en “-“ symbolen aangegeven of een uitslag boven of beneden die van de referentiegroep ligt. De LiC‟s van Leiden, Maastricht en Nijmegen ontvangen van de Centrale iVTG Coördinator deze individuele uitslagdocumenten van haar studenten. Groningen werkt met haar eigen resultaten. De instellingen communiceren elk op hun eigen manier de uitslag naar de studenten. Daarnaast wordt de longitudinale feedback interactief via de online applicatie ProF beschikbaar gesteld. Dit gebeurt nadat de officiële uitslag is berekend en bekend gemaakt. De uitslaggegevens worden uit VOSYS geëxporteerd, doorberekend voor aggregaten, cumulatieven en prognoses en geïmporteerd in het ProF systeem (zie ook deliverable 2.2). Studenten (en stafleden) kunnen via SurfFederatie inloggen met hun instellingspassword om de voortgangstoetsresultaten tot dan toe in te zien. Studiepunten De examencommissies van de partners zijn eindverantwoordelijk voor de iVGT op de eigen locatie. Hoe het studieonderdeel heet waarvoor de studenten punten behalen verschilt daardoor per locatie. In Nijmegen en Leiden wordt het studieonderdeel Voortgangtentamen genoemd, in Groningen Kennisprogressie en in Maastricht Voortgangstoets. In elk jaar van de opleiding is dit onderdeel opgenomen. Studenten behalen hun studiepunten voor de iVTG door te voldoen aan een bepaalde combinatie van uitslagen op vier voortgangstoetsen. De mogelijke combinaties zijn opgenomen in een door de WiV opgestelde combinatietabel. De verschillende combinaties kunnen leiden tot de resultaten Onvoldoende, Voldoende of Goed. De tijdsbalk in afbeelding 3 laat het totaal aantal activiteiten zien die worden uitgevoerd in de zojuist beschreven processen vanaf het punt dat de toets is afgenomen. Ook wordt de tijd (in dagen) weergegeven die hieraan besteedt wordt. Bij een aantal activiteiten wordt ook de maximale tijd weergegeven, omdat het aantal benodigde dagen die nodig zijn voor deze activiteiten soms verschillend zijn.

11


Afbeelding 3: Het aantal activiteiten en bijbehorende tijdsbesteding na toetsafname

12


4.

Analyse stakeholders

Voor dit project worden stakeholders als volgt gedefinieerd: ‘betrokkenen die op dit moment direct of indirect belang hebben bij de iVTG’ Ten aanzien van deze betrokkenen kan er een onderscheid gemaakt worden tussen directe en indirecte betrokkenen. De betrokkenen die direct een belang hebben bij de iVTG maken deel uit van de organisatie van de iVTG, te weten: Vragenmakers ofwel auteurs De auteurs zijn docenten die verantwoordelijk zijn voor het schrijven van items. Deze docenten zijn afkomstig van alle disciplines die participeren in het onderwijs in de opleidingen geneeskunde uit één van de iVTG-samenwerkende instellingen. Centrale iVTG Coördinator (CiC) De CiC is verantwoordelijk voor de invoer en het beheer van de itembank en de toetsconstructie. Daarnaast draagt de CiC zorg voor de planning en logistieke coördinatie van de VT in Maastricht Assistent Centrale iVTG Coördinator De assistent ondersteunt de CiC bij het invoeren van items in VOSYS. Lokale iVTG Coördinatoren (LiC) De LiC houdt de stand van zaken bij van het aantal items die volgens de blauwdruk geproduceerd moeten worden en heeft hierover direct contact met de CiC en de eigen lokale VBC. De LiC verzamelt de items die door de VBC zijn beoordeeld en stuurt deze na een redactionele controle op naar de CiC. De LiC is bij de meeste instellingen ook het aanspreekpunt voor de student en de onderwijsadministratie. Lokale VBC’s De lokale VBC‟s dragen zorg voor de itemproductie en itemkwaliteit binnen de eigen instelling en bespreken de toets na. De lokale VBC‟s treffen elkaar jaarlijks op een landelijke VBC dag. Voorzitter DB (tevens Voorzitter WIV) De voorzitter van het DB geeft akkoord op het gehele itembestand en selecteert de items voor de toets. Daarnaast is de Voorzitter eindverantwoordelijk voor de nabespreking en itemverwijdering nadat de toets is afgenomen. WIV De WIV is verantwoordelijk voor de inhoud, de kwaliteit, de vorm en het beleid van en rondom de VT. Result Admins De Result Admins zijn belast met de toetsverwerking, het opstellen van de itemanalyse en het berekenen van de uitslagdocumenten. Psychometricus De Psychometricus stelt de normen vast per meetmoment. VOSYS beheerder Verantwoordelijk voor het beheer en de ontwikkeling van VOSYS. ProF beheerder Verantwoordelijk voor het beheer en de ontwikkeling van ProF. Contactpersoon VU Amsterdam en Gent De contactpersonen communiceren met de CiC. Zij dragen zorg voor de toetsafname en verzamelen de scores van de studenten binnen de eigen instelling. Memic: Centrum voor Data en Informatiemanagement (onderdeel van UM-FHML) Draagt zorg voor de opmaak en het drukwerk van de voor-bedrukteantwoordformulieren voor toetsafname. Daarnaast gebeurt de verwerking van de antwoordformulieren na toetsafname (m.a.w. het inscannen van de individuele scores) door Memic. Externe bedrijven: 13


* Pine Technisch beheerder (m.a.w. hosting) van gebruikersomgeving & database van ProF * ICTS Universiteit Maastricht Technisch beheerder (m.a.w. hosting) van gebruikersomgeving & database van VOSYS * Case Builders Ontwikkelaar gebruikersomgeving van ProF Afbeelding 4 geeft al deze betrokkenen uit de iVTG-organisatie en hun relaties weer.

Afbeelding 4: directe betrokkenen en hun relatie(s) in de huidige iVTG-organisatie

Naast de betrokkenen die direct van belang zijn voor de iVTG zijn er indirecte belanghebbenden voor de iVTG aan te wijzen. Deze zijn: studenten: studenten maken de toets en geven commentaar (vrijwillig) na afname op de items in de toets; examencommissies; onderwijsadministraties; faculteitsdirecteuren; opleidingsdirecteuren; (lokale) afdelingen kwaliteitszorg; onderzoekers van medisch onderwijs; nationale en internationale externe partijen die interesse hebben in de iVGT.

14


5.

Het item-constructie en -beoordelingsproces

Het itemconstructie en -beoordelingsproces is een proces dat ontstaat bij het schrijven van het item door de auteur en daarna voortdurend doorloopt, omdat het item in beoordeling is bij verschillende betrokkenen van de iVTG. Het proces is continue van aard omdat elk item na toetsafname hergebruikt wordt voor een volgende toets(nadat het item 3 jaar geblokkeerd is). Het item wordt vóór hergebruik opnieuw in behandeling genomen door de één van de lokale VBC‟s waar het item oorspronkelijk afkomstig van is. Het itemconstructie en -beoordelingsproces wordt bepaald door de life-cycle van een item. In de life-cycle kan een item meerdere hoedanigheden, ofwel statussen, aannemen. Voordat er een hoedanigheidovergang plaatsvindt, worden er tijdens het itemconstructie en –beoordelingsproces één of meerdere acties ondernomen. De genomen acties zorgen ervoor dat het item een nieuwe hoedanigheid aanneemt. Een hoedanigheid kan ook informatie bevatten over de historie van het item. Bijvoorbeeld de hoedanigheid „conceptversie‟ kan gaan om een item zoals deze voor de eerste keer geschreven is door de auteur of nadat de auteur hetzelfde item herzien heeft en er dus aanpassingen aan het item zijn gemaakt. Tabel 1 geeft een overzicht van alle hoedanigheden, resp. een omschrijving ervan. In deze tabel wordt tevens vermeld welke van deze hoedanigheden in VOSYS zijn „gelabeld‟. Het itemconstructie- en beoordelingsproces kan opgedeeld worden in een tweetal periodes: de periode vóór toetsafname en de periode ná toetsafname. In beide periodes vinden acties plaats. De genomen acties in deze perioden (c.q. het itemconstructie en – beoordelingsproces) en welke hoedanigheden hierop volgen worden schematisch in kaart gebracht in de state-diagram in paragraaf 5.1. Ook wordt in deze paragraaf een overzicht gegeven van alle hoedanigheden, resp. een omschrijving ervan (zie tabel 1). In paragraaf 5.2 en 5.3 wordt er middels een tweetal tabellen meer uitleg gegeven over de acties en welke hoedanigheden een item kan aannemen na een actie in de periode vóór toetsafname (tabel 2) en de periode ná toetsafname (tabel 3). 5.1

State-diagram itemconstructie en -beoordelingsproces

15


Afbeelding 5: State-diagram

16


Tabel 1: Overzicht en omschrijving van hoedanigheden in itemconstructie en -beoordelingsproces

Hoedanigheid Nr. H01

Naam Conceptversie

H02

In controle VBC

H03

In controle LiC

H04

In controle CiC

H05

In controle Voorzitter DB

H05.1

In controle CiC

H06

Akkoord

H07

Preselectie

H08

Geselecteerd (in toets)

H09

Gebruikt (in toets)

H09.1

Buffer

H10

Oude versie

H11

Eliminatie

Omschrijving Het item zoals deze geschreven/ bewerkt wordt door de auteur. Het item is in behandeling bij een lokale VBC ter beoordeling op relevantie Het item is in behandeling bij de Lokale iVTG Coördinator ter redactionele controle Het item wordt ingevoerd door de Centrale iVTG Coördinator in VOSYS en wordt gecontroleerd op ontbrekende informatie en redactionele fouten. Het item wordt beoordeeld door de Voorzitter DB Het item wordt aangepast door de Centrale iVTG Coördinator o.b.v. de opmerkingen van de Voorzitter DB Het item is „akkoord‟ en kan selecteert worden voor de toets Het item is uit VOSYS geselecteerd voor preselectie van de toets Het item is door de Voorzitter DB geselecteerd voor de voorlopige toets Het item is gebruikt in de toets en bevat feedback (eventuele sleutelwijziging, vervallen van vraag en scores uit itemanalyse) Item is gebruikt in toets en na 3 jaar vrijgekomen voor hergebruik De originele versie van het item zoals deze gebruikt is in de toets. Het item is geëlimineerd

5.2 Proces voor toetsafname Onderstaande tabel geeft de volgende acties en hoedanigheden (zie tabel 2) weer die voor toetsafname stap voor stap het itemconstructie en –beoordelingsproces bepalen:

17


Tabel 2: Acties en itemhoedanigheden tijdens itemconstructie en -beoordelingsproces voor toetsafname

Actie

Hoedanigheid Begin

Nr. Omschrijving Nr. Omschrijving Nr. A01 Auteur schrijft het item H01 02 - Auteur dient het item in bij de VBC A02.1 Auteur dient conceptversie H01 Conceptversie H02 (opnieuw) in bij VBC ter beoordeling A02.2 Auteur besluit het item H01 Conceptversie H11 niet voor een volgende keer in te dienen, waardoor het item door de auteur geëlimineerd wordt 03 - De VBC beoordeelt het item A03.1 De VBC accepteert het H02 In controle VBC H03 item, want het item is relevant. (Indien nodig past de VBC het item nog aan.) De VBC dient het item in bij de LiC A03.2 Het item wordt niet H02 In controle VBC H01 geaccepteerd door de VBC, waardoor het item terug gaat naar de auteur* A04 LiC dient na redactionele H03 In controle LiC H04 controle een herziene versie in bij de CiC 05 - CiC voert item in VOSYS in en controleert item op redactioneel niveau A05.1 CiC accepteert item en H04 In controle CiC H05 dient deze in bij de Voorzitter DB A05.2 CiC accepteert het item H04 In controle CiC H02 niet en stuurt het item terug naar de lokale VBC om weer opnieuw in behandeling te nemen** 06 - Voorzitter DB controleert item ter beoordeling A06.1.1 Voorzitter DB accepteert H05 In controle H06 het item. Voorzitter DB A06.1.2 Voorzitter DB accepteert H05 In controle H05.1 het item, mits er een Voorzitter DB kleine mutatie in het item wordt doorgevoerd. Item wordt daarom door de voorzitter terug gestuurd naar CiC A06.1.3 CiC voert mutatie door, H05.1 In controle CiC H06 waarna item direct wordt geaccepteerd A06.2 Voorzitter DB accepteert H05 In controle H01 het item niet. Het item Voorzitter DB wordt door de CiC via de LiC opnieuw ingediend bij

Eind Omschrijving Conceptversie In controle VBC Eliminatie

In controle LiC

Conceptversie

In controle CiC

In controle Voorzitter DB In controle VBC

Akkoord In controle CiC

Akkoord Conceptversie

18


de auteur* CiC dient het item in bij de H06 Akkoord H07 Preselectie Voorzitter DB voor preselectie 08 - De Voorzitter DB ontvangt van de CiC het item voor de preselectie. De voorzitter krijgt in totaal 456 vragen en stelt met deze vragen de toets samen die uit 200 vragen bestaat A08.1 De Voorzitter DB selecteert H07 Preselectie H08 Geselecteerd (in het item uit de preselectie toets) voor de toets. Hij geeft dit door aan CiC A08.2 De Voorzitter DB selecteert H07 Preselectie H06 Akkoord het item niet voor de toets, omdat het item niet past bij de andere vragen die geselecteerd zijn. De voorzitter geeft dit door aan CiC. A08.3 De Voorzitter DB selecteert H07 Preselectie H02 In controle VBC het item niet voor de toets, want hij vindt het item niet van voldoende kwaliteit. Het item wordt door de CiC via de LiC opnieuw ingediend bij de lokale VBC ter beoordeling** A07

* Item kan na deze actie geëlimineerd worden, wanneer de auteur dit heeft besloten. ** Item kan na deze actie geëlimineerd worden, wanneer de VBC dit heeft besloten.

5.3 Proces na toetsafname De volgende tabel geeft de volgende acties en hoedanigheden (zie tabel 3) weer die na toetsafname stap voor stap het itemconstructie en –beoordelingsproces bepalen: Tabel 3: Acties en itemhoedanigheden tijdens itemconstructie en -beoordelingsproces na toetsafname

Actie

Hoedanigheid Begin

Nr. A09

Omschrijving Feedback (sleutelwijziging, vervallen van vraag, itemanalyse) over item wordt toegevoegd aan item door CiC. Item wordt daarna geblokkeerd voor 3 jaar A10 Het item zoals het gebruikt is in de toets wordt vrijgegeven na 3 jaar en komt in de buffer terecht zodat het item opnieuw in behandeling kan worden genomen door de lokale VBC 11 - Item, zoals deze gebruikt is in de toets A11.1 Voordat het weer in behandeling komt bij de VBC, wordt het origineel opgeslagen

Eind

Nr. H08

Omschrijving Geselecteerd (in toets)

Nr. H09

Omschrijving Gebruikt (in toets)

H09

Gebruikt (in toets)

H09.1

Buffer

wordt opnieuw in behandeling genomen H09 Gebruikt (in toets) H10 Oude versie

19


in de databank. Een kopie van het item zoals deze gebruikt is in de toets (incl. feedback) wordt ingediend bij de lokale VBC waar het item afkomstig van is. 12 - Besluit tot eliminatie A12.1 De VBC besluit om het item te en elimineren wel/niet in A12.2 samenspraak met de auteur. A13 Item wordt na 1 jaar uit de databank verwijderd A11.2

H09

Gebruikt (in toets)

H02

In controle VBC

H02

In controle VBC

H11

Eliminatie

H11

Eliminatie

*

Eindpunt

6. Beschrijving van rollen en bijbehorende taken in itemconstructie en -beoordelingsproces Tijdens de gesprekken met de personen of commissies die op dit moment een rol spelen tijdens het huidige itemconstructie en –beoordelingsproces is er gevraagd wat zijn/haar rol is en de bijbehorende taken zijn. Tabel 4 geeft een overzicht van deze rollen en taken weer. De taken zijn dus beperkt tot het itemconstructie en –beoordelingsproces.

20


Tabel 4: rollen en bijbehorende taken in het itemconstructie en -beoordelingsproces

Rol

Taken voor toetsafname

Auteur



Centrale iVTG Coördinator (Judith van den Brink)

 

 



 

Schrijft de vraag voor de categorie binnen zijn/haar discipline (o.b.v. de blauwdruk) Stand van zaken bijhouden t.a.v. het gehele casusbestand. iVTG betrokkenen informeren: - de Lokale iVTG Coördinatoren (LiC‟s) en de VBCleden die deelnemen aan de WIV-vergadering tweewekelijks informeren over de tekorten in itemproductie (van haar eigen instelling) o.b.v. classificaties van de blauwdruk. - de voorzitter van de DB/WIV tweewekelijks informeren over het gehele casusbestand. Deze informatie bevat cijfers over hoeveel items er in behandeling zijn, nieuw, akkoord, geselecteerd zijn voor preselectie, gebruikt en aantal vragen gebruikt per toets per instelling en in totaal. Verzamelen van items bij LiC‟s en deze daarna invoeren in VOSYS. Controle uitvoeren op item na invoer: - wanneer item acceptabel is deze indienen bij de Voorzitter DB ter beoordeling. - item dat niet acceptabel is doorsturen naar de LiC om weer in behandeling te nemen. Aanpassingen doorvoeren in items in VOSYS N.a.v. het commentaar van de Voorzitter DB of wanneer item opnieuw is behandeld door de VBC/auteur en er aanpassingen gemaakt zijn. Items die akkoord zijn bevonden door de Voorzitter DB uit VOSYS halen voor preselectie en deze voorleggen aan de Voorzitter DB. Items die geselecteerd zijn voor de toets invoeren in VOSYS: - eventueel worden er in VOSYS nog kleine

Taken na toetsafname Niet van toepassing 

 



 

Feedback over items verzamelen: - het studentencommentaar van alle andere iVTG-instellingen verzamelen - itemanalyes opvragen bij Result Admins een totaalbestand van al het studentcommentaar en de itemanalyse opsturen naar de VBC’s Doorvoeren van besluit t.a.v. sleutelwijzigingen en vervallen items in VOSYS en opmerkingen van Voorzitter DB over item toevoegen. Resultaatberekening over Groningse studenten en voorlopige normen opvragen aan Result Admins en opsturen naar CiC in Groningen. Akkoord doorgeven aan de Result Admins op de uitgevoerde berekening t.a.v. de Groningse resultaten Opsturen van uitslagdocumenten aan de LiC of andere contactpersonen van de desbetreffende instelling.

21


 Lokale iVTG Coordinator Judith van den Brink

Lottie Datema - UMCG

     

 Liesbeth Gijsbers UMCN



  

aanpassingen in deze items gemaakt. - items die niet geselecteerd zijn uit de preselectie indienen bij de VBC om weer in behandeling te nemen Toetsboekje opstellen en daarna toets verspreiden naar instellingen Verzamelen van items bij VBC Maastricht Uitvoeren van redactionele controle op items Zorg dragen voor de organisatie rond de afname van de toets (incl. drukproces) Verzamelen van items bij VBC Groningen Uitvoeren van redactionele controle op items Contactpersoon voor CiC in Maastricht: - nieuwe items of items die weer in behandeling zijn genomen opsturen naar CiC in Maastricht - vragen van CiC beantwoorden indien een item onvolledig is en hier eventueel actie op ondernemen. Zorg dragen voor het drukproces van de toets voor Groningen



het studentencommentaar van Maastricht verzamelen



Verzamelen van commentaren van Groningse studenten en deze opsturen naar CiC in Maastricht Bereken van uitslagen van Groningse studenten: - via eigen systeem resultaatberekening maken - deze berekening vergelijken met de resultaatberekening uit Maastricht Akkoord doorgeven op resultatenberekening aan CiC

Deelnemen aan wekelijkse VBC-vergadering: - projecteren van items ter bespreking; - documenteren van commentaar dat tijdens bespreking naar voren komt; - eventueel aanpassing aan item maken ter plekke. Opsturen herziene versie van item (incl. commentaar) naar desbetreffende auteur na afloop van VBC-vergadering. Verzamelen van items bij auteurs nadat deze door hen opnieuw bekeken zijn Contactpersoon voor CiC in Maastricht: - nieuwe items of items die weer in behandeling zijn genomen opsturen naar CiC in Maastricht - vragen van CiC beantwoorden indien een item onvolledig is en hier eventueel actie op









Verzamelen van commentaren van Nijmeegse studenten en deze opsturen naar CiC in Maastricht Itemanalyses en studentencommentaren afkomstig van CiC doorsturen naar de VBCleden in Nijmegen

22


Tineke Krommenhoek UMCL

  

Voorzitter DB

   

ondernemen. Op zoek gaan naar itemauteurs en deze doorgeven aan de secretaresse van de afdeling die ze vervolgens gaat benaderen Redactionele controle uitvoeren op items afkomstig van de Voorzitter VBC te Leiden en daarna doorsturen naar de CiC. Ontvangen van toetsboekje en deze doorsturen voor het drukproces Akkoord geven op alle nieuwe items die in de itembank worden opgeslagen. Toets selecteren uit preselectie Toets voorleggen bij Groningse VBC en vertalers Samenstellen van voorlopige toets NE en EN: hierbij feedback meenemen van Groningse VBC en vertalers tijdens samenstellen van Engels- en Nederlandstalige toets.

 

   

Verzamelen van commentaren van Leidse studenten en deze opsturen naar CiC in Maastricht Itemanalyses en studentencommentaren afkomstig van CiC doorsturen naar de VBCleden in Leiden

Evalueren van studentencommentaar en itemanalyse Deelnemen in DB overleg in de rol van voorzitter Doorgeven van besluit t.a.v. sleutelwijzigingen en vervallen vragen aan CiC Opstellen van feedback naar studenten

VBC Groningen

   



Nijmegen



Benaderen van auteurs voor het schrijven van items Indien er geen auteur is die het item kan schrijven, het item zelf schrijven Items beoordelen op relevantie Contact onderhouden met LiC: - t.a.v. stand van zaken itemproductie o.b.v. de blauwdruk - t.a.v. aanlevering nieuwe items of items die door de VBC weer opnieuw in behandeling zijn genomen Beoordelen van voorlopige toets (o.a. opsporen van conflicten tussen vragen, taal-, opmaak- en spelfouten) en daarna uitkomst voorleggen aan Voorzitter DB.



Items beoordelen o.b.v. studentcommentaren en itemanalyses

De VBC-leden verzamelen de items bij de auteurs of schrijven de items zelf.



De VBC beoordeelt de items uit de toets o.b.v. de studentcommentaren (de 23








Leiden

Maastricht

De VBC beoordeelt elke week de (nieuw aangeleverde of in behandeling) items op relevantie, opmaak en verwijzing naar literatuur. Tijdens deze bespreking wordt de VBC ondersteunt door een secretaris. Het commentaar van de VBC wordt ter plekke geregistreerd en het item wordt ter plekke aangepast door de secretaris. De auteur (of het VBC-lid) krijgt een nieuwe versie van het item (incl. Opmerkingen) toegestuurd per mail na afloop van de vergadering. De auteur controleert het item nog een keer en past het item zo nodig aan. De secretaris ontvangt van de auteur een herziene versie van het item. Hierna stuurt de secretaris het item door naar de CiC in Maastricht.

De secretaresse van de VBC heeft i.s.m. met de LiC direct contact met de auteurs. De VBC-leden ontvangen van de auteurs (die binnen hun eigen specialisme vallen) de items en beoordelen deze items. De secretaresse stuurt het item met commentaar van een VBC-lid terug naar de auteur met het verzoek om de vraag aan te passen. De secretaresse ontvangt van de auteur een herziene versie van het item en stuurt deze op naar de Voorzitter van de VBC. De Voorzitter VBC controleert het item en geeft daarna wel/niet een akkoord op de vraag.  

De VBC-leden verzamelen de items bij de auteurs of schrijven de items zelf. De VBC bespreekt wekelijks de (nieuw aangeleverde of in behandeling) items op relevantie, opmaak en verwijzing naar literatuur. Het commentaar van de VBC wordt ter plekke geregistreerd en het item wordt ter plekke

studentcommentaren zijn afkomstig van alle faculteiten) en gebruikt voor het beoordelen van deze items ook de itemanalyse.

Elk VBC-lid beoordeelt de vraag die gerelateerd is aan zijn/haar specialisme o.b.v. het studentencommentaar en de itemanalyse. De VBCleden lichten tijdens de vergadering hun commentaar over de vraag toe, waarna de VBC gezamenlijk een besluit nemen t.a.v. sleutelwijzigingen/vervallen van vragen.



De VBC beoordeelt de items uit de voorlopige toets o.b.v. de studentcommentaren (de studentcommentaren zijn afkomstig van alle faculteiten) en gebruikt voor het beoordelen van deze items ook de itemanalyse.

24






Result Admins

 

aangepast. De auteur doet nog een keer aanpassingen aan het item indien de VBC nogmaals de opinie van de auteur nodig (bv. omdat de vraag inhoudelijk te ver buiten het specialisme van de VBC-leden ligt). Het item wordt teruggestuurd naar de auteur (incl. Opmerkingen). De auteur herziet het item, past deze zo nodig aan en stuurt een herziene versie terug naar de VBC. Contact onderhouden met de CiC De behandelde items worden doorgestuurd naar de CiC. De VBC ontvangt van de CiC regelmatig de stand van zaken t.a.v. de itemproductie Antwoordformulieren voor laten bedrukken - leveren van voor-te-bedrukken gegevens in een MSAccesstabel aan Memic. Sessies aanmaken in VOSYS - dit houdt in een sessie aanmaken voor elke opleiding van elke deelnemende faculteit.

   



Ingevulde antwoordformulieren leveren aan Memic om te laten inscannen Controle uitvoeren op bronbestand met scores van alle studenten om administratieve fouten eruit te halen Importeren van bronbestand naar VOSYS Maken van itemanalyses (geeft P-waarde en RIT-waarde aan van elk item voor elk meetmoment). Itemanalyse wordt gemaakt per: - instelling - AMFON (totaaldocument van alle instellingen) Controleren van invoer in VOSYS m.b.t. vervallen items en sleutelwijzigingen: -nadat de invoer is gedaan door de CiC, in samenspraak met CiC wordt deze controle gedaan.

25


7.

Identificatie knelpunten in itemconstructie en -beoordelingsproces

In dit hoofdstuk worden de knelpunten in het huidige itemconstructie en beoordelingsproces beschreven. De knelpunten zijn geïdentificeerd aan de hand van gesprekken met direct betrokken ICB-stakeholders (zie bijlage 1 voor de lijst met gesprekspartners). Het samenstellen van een voortgangstoets is een complex en tijdrovend proces. Gedurende dit proces moet, onder andere door de verschillende kwaliteitscontroles, met veel verschillende partijen gecommuniceerd worden. Uit de gesprekken is naar voren gekomen dat deze communicatie nog niet overal in het proces optimaal verloopt. Dit is toe te schrijven aan knelpunten in de huidige organisatiestructuur en aan het huidige databasesysteem VOSYS. In de huidige organisatiestructuur (zie afbeelding 1) heeft het merendeel van de stakeholders slechts toegang tot een beperkt deel van de informatie over het (verloop van het) proces. VOSYS, waarin alle informatie samen moet komen, is beperkt toegankelijk en star opgezet. In onderstaande beschrijving wordt een onderscheid gemaakt tussen knelpunten als gevolg van de huidige organisatiestructuur en knelpunten als gevolg van VOSYS. Organisatiestructuur De huidige structuur is om drie redenen kwetsbaar. Ten eerste komt alle informatie over het verloop van het ICB-proces pas samen op één centraal punt, namelijk bij de CiC. Geen enkele andere stakeholder is op de hoogte van het gehele werkpakket van de CiC. Wanneer de CiC uitvalt, kan de toets niet samengesteld worden. Ook de itemanalyse en berekening na toetsafname zijn afhankelijk van de werkzaamheden die de CiC voor het item-constructieproces uitvoert. Het aanleveren van informatie aan de CiC gebeurt veelal via onbeveiligde Word-documenten, die via e-mail worden verstuurd. Dit is een potentieel onveilige omgeving. Ten tweede is het systeem afhankelijk van de productie van items door itemauteurs. Items worden echter vaak beperkt en traag aangeleverd. Bovendien voldoen aangeleverde items vaak niet aan het format en de standaarden waaraan een voortgangstoetsitem moet voldoen. Er worden een aantal mogelijke redenen genoemd voor de knelpunten in de itemproductie. Auteurs zijn bij veel instellingen versnipperd over vele afdelingen. Vaak wordt een verzoek tot het aanleveren van items gedaan aan een afdeling en niet aan een auteur. Afdelingen koppelen terug dat het moeilijk is auteurs bereid te vinden, omdat auteurs bijvoorbeeld aangeven dat het maken van voortgangstoetsitems niet valt binnen de onderwijsinspanningen die genormeerd zijn of dat auteurs onvoldoende tijd beschikbaar hebben door het inkrimpen van personeel op afdelingen. Ook wordt aangegeven dat de voortgangstoets relatief onbekend is bij itemauteurs. Het is niet overal duidelijk voor auteurs wat er precies van het verwacht wordt. Dit laatste zou kunnen komen doordat auteurs slechts beperkte feedback op de aangeleverde items krijgen. In het huidige systeem krijgen de auteurs alleen feedback wanneer een item niet door een kwaliteitscontrole komt. In dat geval wordt het item teruggestuurd naar de auteur ter verbetering. Dit betekent dat de auteur alleen negatieve feedback krijgt, waardoor dit voor auteurs demotiverend kan werken. Voor het geven van positieve feedback zijn beperkte mogelijkheden. Auteurs zijn bijvoorbeeld geïnteresseerd in de resultaten op hun vragen door de verschillende jaargangen. Deze informatie is momenteel niet toegankelijk voor auteurs. Doordat de productie bij het merendeel van de instellingen beperkt is, maken de VBC‟s in de praktijk veel vragen zelf. Dit heeft als gevolg dat er één van de kwaliteitscontroles, namelijk die van een onafhankelijke VBC, ondermijnd wordt. Het derde kwetsbare punt van de organisatiestructuur is dat het hele productieproces zeer snel uitgevoerd moet worden, omdat momenteel steeds gewerkt moet worden om tekorten weg te werken en om de aankomende toets te kunnen vullen. Deze haast heeft 26


tot gevolg dat er een sterke nadruk op productie wordt gelegd, waardoor men het idee heeft dat er vaak minder tijd over blijft voor de kwaliteitscontrole. Het komt voor dat op een later moment in het proces redactionele en inhoudelijke fouten geconstateerd worden, waardoor het herstellen van deze fouten op de verkeerde plek gebeurd. Het gebeurt dat de LiC´s of de CiC items aanpassen, terwijl het onderwerp van het item mogelijk buiten hun expertise ligt. De context kan hierdoor uit het oog verloren worden en nieuwe fouten kunnen gemaakt worden. De VBC-leden en de CiC passen items onder andere zelf aan om het in de huidige opzet geen communicatiemiddel beschikbaar is dat het mogelijk maakt om snel met meerdere groepen te communiceren over de items. Naast het mogelijke kwaliteitsverlies zorgt deze controle op de verkeerde plaats in het proces ook voor extra werkdruk op deze plaatsen. Oorspronkelijk werd verwacht dat er binnen afzienbare tijd een dusdanig grote databank opgebouwd zou zijn dat alleen onderhoud aan buffervragen gepleegd zou moeten worden. De oorzaak dat deze staat nog niet bereikt is, ligt onder andere in het huidige databasesysteem (VOSYS). Dit systeem biedt onvoldoende mogelijkheden om het gehele productieproces rondom de voortgangstoets in kaart te brengen en te begeleiden. De knelpunten rond het huidige databasesysteem worden hieronder besproken. Databasesysteem (VOSYS) De weg die een item doorloopt in het itemconstructie en beoordelingsproces is complex. Zoals te zien in afbeelding 5 neemt een item meerdere statussen aan gedurende het proces. Idealiter zou de doorlopen weg van een item te volgen moeten zijn voor alle stakeholders via het databasesysteem. Door een tweetal redenen is dit momenteel niet het geval. Ten eerste is het huidige VOSYS-systeem ongeschikt om het gehele proces inzichtelijk en traceerbaar te maken. Ten tweede is VOSYS alleen toegankelijk voor de CiC. Dit leidt tot verschillende knelpunten. Zo kunnen auteurs door hun onwetendheid van de inhoud in de itembank, items maken die veel overlap vertonen met items die eerder opgenomen zijn. Door de opzet van VOSYS is het voor de CiC niet gemakkelijk traceerbaar om te kijken of er sprake is van overlap tussen items. Het systeem is niet gebruikersvriendelijk door de starre opzet. Er moeten veel handelingen ondernomen worden voordat een gewenst resultaat bereikt wordt. Dit blijkt onder andere uit het volgende: - Aanpassingen die gelden voor meerdere items kunnen niet tegelijkertijd voor alle items doorgevoerd worden. Zo kunnen de items die geselecteerd zijn voor een toets bijvoorbeeld niet tegelijkertijd in één handeling gemarkeerd worden als geselecteerd. - De volgorde van items in een toets wordt niet door het systeem vastgelegd. Wanneer er na de selectie nog veranderingen moeten worden doorgevoerd (bijvoorbeeld een sleutelwijziging) dan geeft VOSYS het gecorrigeerde item het vraagnummer 1. Hierdoor komen de vraagnummers niet meer overeen met de volgorde uit de oorspronkelijke toets. Dit moet handmatig aangepast worden. - De berekeningen in VOSYS zijn erg „statisch‟. Dit betekent dat de kwalificatie niet automatisch wijzigt in VOSYS als het meetmoment aangepast wordt. - De zoekfunctie van VOSYS geeft alleen resultaten op macroniveau. Het is niet makkelijk om één specifiek item op te zoeken en te verwijderen. Dit heeft tot gevolg dat het „opruimen‟ van de database lastig is. De volgende beperkingen van het systeem zijn benoemd door de stakeholders: - Door de gekozen beveiligingsvorm kan er alleen binnen de UM met VOSYS gewerkt worden. - Statusbeheer van items is slechts beperkt mogelijk. Op dit moment wordt gebruik gemaakt van vijf statussen, maar deze dekken niet het gehele poces. - Het is niet mogelijk om meerdere versies van eenzelfde item aan elkaar te koppelen. Deze verschillende versies worden door VOSYS geregistreerd als unieke items. Daardoor kunnen bijvoorbeeld de vertaalde items niet aan de oorspronkelijke items gekoppeld worden.

27


-

-

-

De layout mogelijkheden zijn beperkt (geen symbolen, subscripties of andere vormen van rich text). Er is in VOSYS geen mogelijkheid om foto's figuren, video/audio, etc. op te slaan bij een item. Bij het samenstellen van de toets selecteert VOSYS de vragen van de universiteiten niet at random op volgorde, maar op alfabet van de naam van de faculteit. De items van de faculteiten komen zo steeds op dezelfde volgorde achter elkaar te staan in de toets. Wanneer er items van een bepaalde discipline nodig zijn, haalt VOSYS „ oude‟ items van het betreffende discipline at random uit het systeem. Oude items die niet uit VOSYS getrokken worden komen zo niet meer in behandeling (status „accepted‟ verandert hierdoor niet) en worden naar verloop van tijd uit het systeem verwijderd. Er kan slechts een beperkt aantal labels aan een item gehangen worden. Het is niet mogelijk op microniveau (zoals naar termen in de stam van een item) te zoeken naar items.

Kwaliteitsslag Uit de gesprekken met de stakeholders is naar voren gekomen dat de betrokkenen trots zijn op de voortgangstoets. Met behulp van inzet op veel verschillende plaatsen wordt een mooi product neergezet. Wel kan er nog een grote kwaliteitsslag gemaakt worden. De partners hebben het gevoel op eilandjes te werken, doordat de mogelijkheden voor snelle, duidelijke en gerichte communicatie onderling beperkt zijn. De informatievoorziening naar de verschillende betrokkenen van de iVTG-organisatie kan sterk verbeterd worden en ook de verwerking van de grote hoeveelheden informatie kan beter. Veel van de in dit hoofdstuk genoemde knelpunten kunnen waarschijnlijk opgelost worden door heldere informatievoorziening en –opslag. Dit zal tot uiting moeten komen in het ICB-systeem. De genoemde knelpunten uit dit hoofdstuk zullen in hoofdstuk 9 en 10 worden omgezet in requirements voor de selectie van een ICB-systeem.

28


8.

Identificatie mogelijke oplossingen

In dit hoofdstuk gaan we eerst in op de in hoofdstuk 7 gesignaleerde knelpunten en zullen per probleem schetsen hoe een ICB systeem daar een oplossing voor kan zijn. Daarna zullen we de uit de interviews met betrokkenen genoemde wensen die niet direct uit knelpunten zijn voortgekomen op een rij zetten. Organisatiestructuur De te grote afhankelijkheid van de CiC wordt door het ICB ondervangen indien:  de workflow-ondersteunende taken die de CiC nu handmatige uitvoert, door het ICB systeem worden uitgevoerd;  een automatische koppeling tussen VOSYS en het ICB systeem de itemanalyses aan de items koppelt;  meer rollen (LiC‟s, Voorzitter DB) direct toegang hebben tot gegevens en overzichten;  meer personen (onderdelen van) de rol van CiC kunnen vervullen. De onveilige communicatie via Word en email kan worden ondervangen indien items online in het ICB kunnen worden bewerkt en van feedback kunnen worden voorzien, onder voorwaarde dat het ICB via een veilige connectie werkt (https). De productie door itemauteurs Om auteurs tot grotere, betere en snellere productie aan te zetten is het nodig dat:  Auteurs zelf toegang tot het ICB systeem hebben en online items kunnen schrijven;  Het ICB systeem controle op de invoer pleegt, zoals verplicht in te vullen velden, een vaste literatuurlijst, en spellingscontrole (ook medisch; Pinkhof);  Auteurs de status en veranderingen van hun eigen items kunnen volgen;  Auteurs feedback (niet alleen de negatieve) kunnen inzien en itemanalyses van de eigen items kunnen bestuderen over verschillende jaren;  Auteurs via email-reminders aangespoord kunnen worden en aan deadlines kunnen worden herinnerd;  Auteurs ondersteuning krijgen in de vorm van online informatie over de specifieke criteria waaraan voortgangstoetsitems qua inhoud, opbouw en relevantie moeten voldoen. Snelheid van het productieproces Om de kwaliteit die tijdens een steeds snellere productie onder druk komt te staan te kunnen waarborgen is het nodig dat:  er minder aanleiding tot redactionele en/of inhoudelijke aanpassing is, door aan de invoerkant (bij de auteur) meer ondersteuning (do‟s en don‟t‟s) en controle in te bouwen;  redactionele aanpassingen direct voor betrokken zijn in te zien (nadat ze bijvoorbeeld via een notificatie zijn gewaarschuwd), en eventueel zijn te corrigeren indien zaken ten onrechte of foutief zijn aangepast;  er eenvoudig met de auteur contact opgenomen kan worden (via het systeem) om eventuele inhoudelijke aanpassingen te bespreken.  de auteur gerichte feedback krijgt waarmee men leert wat de do‟s en don‟ts zijn bij het schrijven van voorgangstoetsvragen. Tekortkomingen in VOSYS Het ICB systeem kan huidige tekortkomingen in VOSYS ondervangen indien: 29


  



 

  

Auteurs en andere betrokkenen inzicht hebben in de actuele status van items, maar ook in het historisch verloop (wanneer heeft welke beslissing of aanpassing plaatsgevonden?) Er online inzage is voor alle gebruikers in: o De opbouw van de blauwdruk; o De quota per instelling en de nog benodigde hoeveelheid productie; Er een uitgebreide zoekfunctie op items is, o Met als zoekmogelijkheden:  Auteur, instelling, blauwdrukonderdeel (discipline, systeem), trefwoord in stam, trefwoord in alternatief, literatuur, datum aanmaak (leeftijd van het item), datum(s) van afname, toets, analyse-gegevens (p-waarde), additionele labels (bijv. raamplantermen);  Die ook (beperkt) te combineren zijn (voornamelijk setverkleining); een te ingewikkelde zoekmachine zal de productiviteit niet ten goede komen; o Waarbij de resultaatset met voldoende informatie wordt getoond (het liefst door de gebruiker in te stellen) – zoals categorie, itemnummer, nummer in toets, etc., en te sorteren is; o Waarbij bepaalde handelingen (zoals akkoord verklaren of opruimen) op de hele set kunnen worden uitgevoerd, met uitsluiting van individuele gevallen (dmv check-boxjes) – indien deze handelingen, vanzelfsprekend, voor de; gebruiker op de betreffende items van toepassing zijn. Het ICB systeem toetsen kan generen en bijhouden: o Op basis van de blauwdruk; o Waarbij de toets handmatig kan worden aangepast (items toevoegen, items weghalen); o Waarbij de volgorde van de items door het systeem volledig gerandomiseerd kan worden; o Zowel het volgnummer in de toets als de unieke item-ids worden getoond; Het ICB systeem alle statussen en rollen die in de processen van belang zijn (zie figuur 5) kan bijhouden. Het ICB verschillende versies van items aan elkaar kan relateren: o Nieuwe versies van éénmaal afgenomen items; o Versies van het item in verschillende talen; o Waarbij één versie van het item wel in meerdere toetsen kan worden gebruikt; o Het moet duidelijk zijn welke id-nummers een vraag in de VOSYS database krijgt (kunnen er meerdere zijn) Het ICB systeem toestaat dat figuren, symbolen, sub- en superscript en andere rich-text elementen mogelijk zijn in de vraagtekst en vraagalternatieven. Het ICB systeem items die lang in de bank zitten kan prioriteren bij de toetsgeneratie, zodat deze niet als wezen in de bank achterblijven. Het ICB systeem moet ook Engelstalige items ondersteunen (is niet identiek aan Engelstalige gebruikersomgeving!)

Naast deze oplossingen voor de knelpunten die in hoofdstuk 7 zijn opgenomen, zijn er tijdens de interviews met de stakeholders een aantal aanvullende wensen voor een toekomstig ICB systeem genoemd die we hier zullen opsommen zonder daar op dit moment een prioritering aan te hangen.   

Laat auteurs een aantal goede vragen zien. Link naar literatuur zodat de auteur die online (tijdens het schrijven) kan inzien Meer auteurs aan één vraag werken, discussie faciliteren: email met link naar collega kunnen sturen zodat die meteen in het item terecht komt zonder inloggen (hier is security natuurlijk wel een issue) 30


                

Signaleren aan VBC wie géén gebruik van het systeem maakt. Toegang tot items voor auteurs: beperken tot eigen instelling? Beperken tot eigen discipline? Beperken tot eigen productie? Een forum waarop auteurs en anderen een vraag kunnen stellen en bediscussiëren (zie werkpakket 6!) Lijst met contactpersonen (VBC-leden) per discipline voor iedere instelling Engelstalige vragen tegelijkertijd met vragen in het nederlands door de auteur laten aanmaken Labelen op subonderwerpen, labelen met „main topic‟ Dit labelen alleen door de centrale coördinator laten doen Suggesties voor inhoudelijke literatuur bij het schrijven van items Overzicht over de productie over de instellingen Schaalbaarheid, zodat het systeem ook voor andere partijen gebruikt kan worden Bijhouden of auteurs nog altijd aanspreekbaar zijn (items zitten langer in de bank dan dat medewerkers beschikbaar zijn) Item moet door andere auteur overgenomen kunnen worden. Het systeem ook kunnen gebruiken voor andere toetsen dan de VT Maximale vervaltijd van een item kunnen instellen Opgewassen zijn tegen een nieuwe blauwdruk Eigen literatuurlijst (voorkeur) per docent Gebruik van een rekenmachine tijdens het schrijven van een item (Windows voorziet standaard in deze functie, dus deze wens laten we buiten beschouwing)

In hoofdstuk 9 en 10 zullen de hier globaal beschreven oplossingen worden omgezet in meer gedetailleerde use-case beschrijvingen en worden uitgewerkt in lijsten met functionele en niet-functionele eisen die voor het te kiezen ICB systeem gelden.

31


9.

Functionele requirements

Naar aanleiding van de bovenstaande mogelijke oplossing voor de knelpunten in het itemconstructie en –beoordelingsproces worden er in de eerste paragraaf van dit hoofdstuk een aantal use-case-diagrammen gepresenteerd die de wenselijke situatie weergeeft zoals deze zal zijn na introductie van het ICB-systeem. Per use-case-diagram worden er een aantal activiteiten (use-cases) weergegeven die de verschillende stakeholders door gebruikmaking van het systeem (moeten) kunnen uitvoeren. Deze activiteiten zullen kunnen worden uitgevoerd met de functies die het ICB-systeem naar onze wens zal hebben. Al deze activiteiten leiden tot een lijst met functionelerequirements, nodig om de activiteiten te kunnen uitvoeren. In paragraaf 9.2 wordt deze lijst weergegeven. 9.1

Use-cases

Hieronder worden de beschrijving van de procedures rond itemconstructie en – beoordeling, zoals beschreven in hoofdstukken 5 en 6, en de oplossingen voor knelpunten zoals die in hoofdstuk 8 vertaald in use-cases. Dit zijn korte beschrijvingen van (bij elkaar horende) activiteiten die de verschillende gebruikers met het toekomstige ICB-systeem zullen moeten kunnen gaan uitvoeren. We hebben de use-cases gegroepeerd in activiteiten rond itemconstructie en – beoordeling, toetsconstructie en ICB-beheer. Voor ieder van deze groepen wordt een zogeheten use-case diagram getoond die aangeeft welke use-cases van toepassing zijn op welke rollen. Activiteiten rondom itemconstructie en -beoordeling

32


Afbeelding 6: Use-cases itemconstructie en - beoordeling

Uitleg van de activiteiten: 1. Items zoeken Een gebruiker wil één of meerdere items opzoeken, bijvoorbeeld om te voorkomen dat een auteur een item gaat schrijven over een onderwerp waar al genoeg items over voorhanden zijn. Indien de zoekactie een aantal treffers laat zien, weet de auteur dat hij beter een ander onderwerp kan kiezen. Het kan ook zijn dat een LiC of CiC één of meerdere items wil wijzigen. De mogelijkheden waarop een gebruiker wil zoeken zijn, bijvoorbeeld: - zoeken op categorie en/of discipline - zoeken op trefwoord(en) - zoeken op vrije tekst - zoeken op instelling - zoeken op auteur De gebruiker wil daarbij zelf bepalen welke velden gepresenteerd worden van de items, zoals resultaten itemanalye, aantal alternatieven, trefwoorden, etc. De gebruiker wil ook de resultaten kunnen ordenen op verschillende manieren, de 33


resultaatset kunnen verkleinen (met additionele criteria) of handmatig items uit de set kunnen weglaten. 2. Item (tijdelijk) opslaan Tijdens het schrijven van een item wil de auteur een item op elk gewenst moment kunnen opslaan, ook al is deze nog niet compleet. De verplichte invoervelden hoeven pas gecontroleerd te worden op het moment dat de auteur het item als „compleet‟ beschouwt en ter beoordeling aanbiedt bij de VBC. 3. Item wijzigen Een bestaand item kan om allerlei redenen gewijzigd moeten worden. Enkele redenen voor het wijzigen zijn: - Het wijzigen van de tekst of inhoud van de vraag (ofwel tekstueel / opmaak ofwel de inhoud van het item) - Het wijzigen van de antwoordsleutel - Het wijzigen van een antwoordalternatief - Het wijzigen van de literatuurverwijzing - Het wijzigen van de classificatie Zowel de auteur als ook de CiC, de LiC en de Voorzitter DB moet een bestaand item kunnen wijzigen. Items die niet meer gewijzigd mogen worden, moeten als zodanig herkenbaar worden gepresenteerd. 4. Item ter beoordeling indienen Zodra een item compleet ingevoerd is in het systeem, kan de auteur het item bij de eigen VBC (eventueel opnieuw) ter beoordeling indienen. De auteur drukt hiertoe op de knop “Indienen bij VBC”. Op dat moment gaat het item de beoordelingscyclus in. Het indienen moet door zowel de auteur als een VBC-lid, de CiC en de LiC gedaan kunnen worden. 5. Feedback inzien Een auteur of andere gebruiker wil zien welke feedback er op een item is opgeslagen. Het kan dan gaan om studentcommentaar op een bepaald item, de itemanalyse van een bepaald item, en opmerkingen van de beoordelaars. In een lijst is duidelijk te zien om welke informatie het gaat en wanneer die is toegevoegd. Deze informatie moet voor iedereen die het item kan inzien beschikbaar zijn. 6. Status inzien Een auteur of andere gebruiker wil zien welke status een item heeft (of heeft gehad). Waar in de beoordelingscyclus is het item nu? Is het al in een toets opgenomen? Wanneer en door wie is het afgekeurd? (zie afbeelding 5). 7. Item verwijderen Een bestaand item moet, indien dat is toegestaan, verwijderd kunnen worden. (eenmaal afgenomen items kunnen bijvoorbeeld niet verwijderd worden.) Het verwijderen moet door zowel de auteur als de CiC gedaan kunnen worden. 8. Item akkoord verklaren of afkeuren Als een item ergens in de beoordelingscyclus akkoord verklaard moet worden, kan de betreffende gebruiker op de knop “Akkoord” drukken. Bij afkeuren drukt de gebruiker op “Afkeuren”. Eventueel kan er bij de akkoord-verklaring of afkeuring een opmerking worden geplaatst. Indien een item in de beoordelingscyclus akkoord wordt verklaard of wordt afgekeurd (zie ook het state diagram op pag. 15), moet het ook als zodanig worden aangegeven. Alle beoordelaars (de VBC, CiC en Voorzitter DB) moeten deze activiteit kunnen uitvoeren.

34


Activiteiten rondom toetsconstructie

Afbeelding 7: Use-cases toetsconstructie

Uitleg van de activiteiten: 1. Voorraadbeheer: Dit is een vrij uitgebreide use-case. Onder voorraadbeheer wordt verstaan, het monitoren van het totaal aantal items in voorraad in de itembank, met name door het bekijken van verschillende soorten overzichten: bijvoorbeeld het aantal items in de buffer per categorie, of per instelling. Ook overzichten per actuele status over de items is heel nuttig. Welke overzichten precies nodig zijn wisselt continu. De gebruiker wil dus zelf overzichten kunnen samenstellen. Het kan handig zijn om deze overzichten ook te kunnen afdrukken of versturen per email (als reminder om de voorraad aan te vullen). Deze activiteiten moeten door zowel de CiC, LiC als de VBC kunnen worden uitgevoerd. 2. Redactionele check van een item: 35


De centrale en/of lokale coördinator controleert een nieuw of herzien item op grammaticale fouten en taal- en spelfouten. Hierbij wordt niet naar de inhoud gekeken. Eventuele fouten worden gecorrigeerd en wijzigingen opgeslagen. Deze activiteit moet door zowel de CiC als de LiC kunnen worden uitgevoerd. 3. Wijzigen van items: Ook tijdens de toetsconstructie kan het nodig zijn een item te wijzigen, bijvoorbeeld omdat: - De inhoud moet worden bijgesteld - De sleutel moet worden aangepast - Een andere codering moet worden aangebracht - De literatuurverwijzing niet meer klopt Deze activiteit moet door zowel de CiC als de LiC kunnen worden uitgevoerd. 4. Toevoegen feedback Na toetsafname kan er vanuit verschillende bronnen feedback op een item komen: - het studentcommentaar; dit is altijd toegespitst op een item. Door dit als een „notitie‟ aan het item te koppelen, is de feedback over het item afkomstig van de student direct beschikbaar vanuit het ICB-systeem . Zowel de CiC als de LiC moeten het studentcommentaar kunnen toevoegen aan een item. - Commentaar en opmerkingen over een item van alle beoordelaars. Feedback kan naar de auteur worden teruggekoppeld als deze informatie bij een item in het systeem wordt toegevoegd. Alle beoordelaars (LiC, CiC, VBC en Voorzitter DB) moeten deze informatie kunnen toevoegen. (De resultaten van de itemanalyse moeten overigens automatisch aan het item worden toegevoegd vanuit VOSYS – zie hoofdstuk 11.) 5. Items selecteren voor preselectie Het systeem moet zelf in staat zijn om een preselectie volledig at random te selecteren voor de toets op basis van een blauwdruk. Deze preselectie moet van een naam worden voorzien en worden opgeslagen. Deze functie moet door zowel de CiC als door de Voorzitter DB kunnen worden uitgevoerd. 6. Toets „initieel‟ maken Bij ieder item uit de preselectie moet worden aangegeven of die wel of niet in de initiële toets moet worden opgenomen. Deze markering moet kunnen worden opgeslagen. Alle gekozen items uit de preselectie, moet worden opgenomen in een nieuwe toets. Deze toets wordt vastgelegd en gemarkeerd als „initieel‟. Het is daarbij essentieel dat de items door de gebruiker zelf kunnen worden geordend. Deze activiteit moet door zowel de CiC als door de Voorzitter DB kunnen worden uitgevoerd. 7. Toets exporteren voor toetsboekje Als de toetssamenstelling bekend is, moet deze geautomatiseerd geëxporteerd kunnen worden naar een bestand dat naar de drukker kan worden gestuurd, zodat deze vanuit het bestand een toetsboekje kan afdrukken. Deze activiteit moet door zowel de CiC als door de Voorzitter DB kunnen worden uitgevoerd. 8. Toets „definitief‟ maken Als de toets is afgenomen, en na overleg tussen de VBC‟s alle sleutelwijzigingen en eliminaties zijn bepaald, wordt de toets „definitief‟ gemaakt. Dit gebeurt door het aanbrengen van eventuele sleutelwijzigingen in de betreffende items en het verwijderen van vervallen items uit de toets. Hierna wordt de toets als „definitief‟ gemarkeerd.

36


Zowel het doorvoeren van de nodige sleutelwijzigingen en het elimineren van vervallen items als het markeren als „definitief‟ moet uitgevoerd kunnen worden door de CiC en door de Voorzitter DB. ICB-beheerder

Afbeelding 8: Use-cases ICB-beheerder

Uitleg van de activiteiten: 1. Gebruikersbeheer Onder gebruikersbeheer wordt verstaan: - het aanmaken van nieuwe gebruikers - het aanpassen van bestaande gebruikers - het aanpassen van de rol / rechten van gebruikers - het verwijderen van gebruikers 2. Databasebeheer Onder databasebeheer wordt verstaan: - Het (preventief) onderhouden van de database - Het doorvoeren van aanpassingen indien nodig - Het beveiligen van de database

37


Deze taak zal waarschijnlijk bij het technisch beheer van de server waarop het ICB systeem draait worden ondergebracht (afhankelijk van het business model). 3. Backup Het maken van backups is erg belangrijk bij een productieomgeving. Door storingen, defecten en andere redenen kan data verloren gaan. Dit kan worden voorkomen door een goed backup-proces in te richten. Deze taak zal waarschijnlijk bij het technisch beheer van de server waarop het ICB systeem draait worden ondergebracht (afhankelijk van het business model). 4. Monitoring „handshake‟ met VOSYS De gegevensuitwisseling die plaatsvindt tussen de database van het ICB-systeem en de database van VOSYS is een belangrijke koppeling tussen de beide systemen. Er vindt een „handshake‟ plaats waarbij gegevens over en weer worden overgedragen. Het monitoren hiervan betekent in feit dat in de gaten wordt gehouden of dit proces goed verloopt. 5. Beheer invoercontrole en templates De invoercontrole die plaatsvindt bij het schrijven van een item moet regelbaar zijn. Op het moment dat een veld verplicht ingevuld moet worden of als dat juist niet meer hoeft, moet dit in het systeem aanpasbaar zijn. Ook de templates die gebruikt kunnen worden voor het schrijven van een item, moeten door de beheerder kunnen worden aangepast indien dat nodig is. 6. Beheer blauwdruk en classificatielijsten Om een item te kunnen classificeren naar een bepaalde discipline, categorie, of andere classificaties, is het noodzakelijk dat deze classificatielijsten ook kunnen worden beheerd in het systeem. De blauwdruk, op basis waarvan toetsen worden geselecteerd, is gebaseerd op deze classificatielijsten en moet dus ook kunnen worden beheerd. Zoals in hoofdstuk 11 wordt aangegeven, is het beheer van de classificaties en blauwdruk mede afhankelijk van het VOSYS systeem. 7. Beheer literatuurlijsten De literatuurverwijzing kan worden gekozen uit een literatuurlijst die in het systeem bekend is. Deze lijsten moeten kunnen worden beheerd in het systeem door de ICB beheerder. 8. Initiële toets exporteren naar VOSYS voor itemanalyse Voor het maken van itemanalyse moet de toets geëxporteerd worden naar VOSYS. (Zie ook hoofdstuk 11.) 9. Definitieve toets exporteren naar VOSYS Nadat de toets als definitief is gemarkeerd moet deze voor het berekenen van de studentresultaten geëxporteerd worden naar VOSYS. (Zie ook hoofdstuk 11.)

38


9.2

Functionele requirements

Om de hierboven beschreven activiteiten uit te kunnen voeren zijn een aantal (systeem-) functies vereist. De functies worden gepresenteerd in de hieronder beschreven lijst van requirements die gaan helpen bij de selectie van een ICB-systeem. De functionele requirements zijn onderverdeeld in de volgende categorieën: A. B. C. D.

Workflowondersteuning Item constructie en -beoordeling Toetsconstructie Beheer

Hieronder volgen de functionele requirements, gesorteerd per categorie:

A.

Workflowondersteuning

A.1

Het ICB-systeem moet alle statussen van een item in het state-diagram (afbeelding 5) kunnen representeren; Het ICB-systeem moet de gebruiker knoppen bieden om in iedere status van een item alleen de juiste beslissingen te kunnen nemen, zoals indienen bij de VBC, akkoord verklaren, afkeuren, verwijderen. Het item moet daarna de juiste status krijgen en bovendien bij de juiste persoon op de werklijst komen; Het ICB-systeem moet de mogelijkheid bieden om de functionaliteit per gebruiker/rol in te stellen (bijvoorbeeld wie welke functie mag gebruiken en vervolgens knoppen uitschakelen); Het ICB-systeem moet voor gebruikers een werklijst tonen van af te handelen items; Het ICB-systeem moet deadlines kunnen bewaken en reminders kunnen sturen; Het ICB-systeem moet het historische verloop van een item (wanneer hebben aanpassingen of beslissingen plaatsgevonden en door wie) aan de gebruiker kunnen laten zien; Het ICB-systeem moet de mogelijkheid geven voor het opstellen van een contactpersonenlijst van auteurs en VBC-leden op lokaal niveau, waarbij de contacten kunnen worden onderverdeeld naar de disciplines en categorieën van de blauwdruk. De auteurs en VBC-leden moeten dus aan elkaar gekoppeld kunnen worden, zodat als een auteur niet meer deelneemt aan de itemconstructie men weet bij welk VBC-lid het item terecht moet komen als het weer in behandeling genomen moet worden; Het ICB-systeem moet de mogelijkheid bieden om het item „in te checken‟, m.a.w. het systeem moet ervoor zorgen dat het item slecht door één gebruiker tegelijk bewerkt kan worden.

A.2

A.3 A.4 A.5 A.6 A.7

A.8

39


B.

Item constructie en -beoordeling

B.1

In het ICB-systeem moeten de items middels een unieke identificatiecode herkenbaar zijn; Het systeem moet een degelijk versiebeheer bieden; a) Elke wijziging aan een item moet kunnen worden getraceerd. Dit kan alleen als het systeem goed kan onderscheiden wie wanneer welke wijziging doorvoert. b) Het ICB-systeem moet meerdere varianten van éénzelfde item aan elkaar kunnen koppelen: - nieuwe versies van éénmaal afgenomen items - versies van het item in verschillende talen - waarbij één versie van het item wel in meerdere toetsen kan worden gebruikt - het moet daarbij duidelijk zijn welke id-nummers een item in de VOSYS database krijgt; Het ICB-systeem moet een uitgebreide, regelbare en beheersbare invoerformat hebben voor het invoeren van een item in de databank; Het item-bewerkscherm moet een aantal velden kunnen bevatten die verplicht zijn voor de auteur wanneer hij item ter beoordeling indient, zoals categorie en discipline, literatuur en paginanr, sleutel, trefwoorden; Het ICB-systeem moet ook het invoeren van een item in de Engelse taal mogelijk maken; Het ICB-systeem moet de mogelijk bieden om een illustratie (kleur en zwart-wit) bij het item toe te voegen; Het ICB-systeem moet de functionaliteit hebben om een item tussentijds te kunnen opslaan (ook al is deze nog niet compleet); Het ICB-systeem moet een Nederlandstalige en Engelstalige spellingscontrole bevatten; Het ICB-systeem moet een medische spellingscontrole bevatten; Het ICB-systeem moet diakritische tekens (zoals â, ä, á), symbolen, sub- en superscript en andere rich-text elementen ondersteunen; Het item-bewerkscherm moet een keuzemenu bieden met verplichte literatuur van de iVTG; Het ICB-systeem moet de auteur kunnen ondersteunen met informatie over de specifieke criteria waaraan voortgangstoetsvragen qua inhoud, opbouw en relevantie aan moeten voldoen; Het ICB-systeem moet de mogelijkheid bieden om feedback (commentaar van beoordelaars, studentencommentaar, itemanalyse) aan een item toe te laten voegen; Het ICB-systeem moet de mogelijkheid bieden om automatisch deze feedback (via een signaal) aan de auteur terug te koppelen; Het ICB-systeem moet de mogelijkheid bieden om een item te (her)classificeren; het systeem moet een degelijk classificatiesysteem bieden; Het ICB-systeem moet automatisch de sleutel mee veranderen indien de volgorde van de antwoordalternatieven wordt aangepast; Het ICB-systeem moet de mogelijkheid bieden om de toegevoegde feedback van een bepaald item in te zien; Het ICB-systeem moet een uitgebreide zoekfunctie bevatten waarbij zowel op trefwoord, auteur en VBC-lid, instelling, discipline/categorie, literatuur, datum aanmaak, toetsanalyse-gegevens en toetsnummer gezocht kan worden; Het zoekresultaat moet verfijnd kunnen worden met additionele criteria; De zoekresultaten moeten kunnen worden geordend op verschillende kolommen; De gebruiker moet kunnen aangeven welke kolommen getoond worden; Het ICB-systeem moet de mogelijkheid bieden om de actuele voorraad van de item-bank te bekijken (dit betekent kwantitatieve gegevens over het totaal aantal aantal items „in buffer‟, „in behandeling‟ en „akkoord‟ per instelling o.b.v. de blauwdruk);

B.2

B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18

B.19

40


Additionele wensen B.20

B.26 B.27 B.28

Het ICB-systeem moet de mogelijkheid bieden om bij ieder item in het Nederlands ook een Engelstalig item in te voeren (elk met eigen ID, maar wel aan elkaar gelinkd); Het ICB-systeem moet de mogelijkheid bieden om door de auteur of een VBC-lid een „maximale houdbaarheidsdatum‟ van een item aan te geven; Het ICB-systeem moet de mogelijkheid bieden om formules in een item te plaatsen; Het ICB-systeem moet de mogelijkheid bieden om een URL (link) naar een item te sturen naar een andere systeemgebruiker (bv. via een mailtje vanuit het systeem). Deze link leidt na opening direct naar het item (na invoering van gebruikersnaam en wachtwoord); Het ICB-systeem moet een plaats bieden voor gebruikers om met elkaar te communiceren of een onderwerp ter discussie te stellen (soort forum); In het item-bewerkscherm moeten er links beschikbaar zijn die de auteur doorverwijzen naar een digitale bibliotheek en online artikelen; Niet alle gebruikers mogen alle items inzien; Niet iedereen mag alle items en toetsen afdrukken; Het is wenselijk dat het systeem zo veel mogelijk soorten vraagtypes ondersteunt.

C.

Toetsconstructie

C.1

Het ICB-systeem moet de mogelijkheid bieden om een toets samen te stellen uit items en deze toets op te slaan met een eigen naam en identificatie; Het ICB-systeem moet de mogelijkheid bieden om een toets at random te „trekken‟ uit een blauwdruk, daarbij rekening houdend met een evenwichtige verdeling over de faculteiten; Het ICB-systeem moet een toets kunnen trekken op basis van verschillende wensen (deze eis is op dit moment niet specifiek voor de iVTG maar maakt het systeem breder toepasbaar), zoals een toets met vragen die een gemiddelde moeilijkheid hebben op basis van eerdere afname data of op basis van een pilot; Het ICB-systeem moet de mogelijkheid bieden om een toets te kopiëren en/of handmatig items van één toets naar een andere toets te slepen; Het ICB-systeem moet de mogelijkheid bieden om de selectie items die in de voorlopige toets terechtkomen, te exporteren naar een tekstbestand voor verdere bewerking, zodat er een toetsboekje van gedrukt kan worden; Het ICB-systeem moet alle items in een toets kunnen markeren als „initieel‟ of „definitief‟; Het ICB-systeem moet vervallen items in een toets kunnen markeren en kunnen aangeven dat sleutels zijn gewijzigd; Een gebruiker moet een toets kunnen inzien en daarbij de actuele status van de items (o.a. vervallen, sleutelwijziging) kunnen zien. Hierbij moet niet alleen het volgnummer van de items in de toets, maar ook hun identificatie zichtbaar zijn.

B.21 B.22 B.23

B.24 B.25

C.2 C.3

C.4 C.5 C.6 C.7 C.8

D.

Beheer

D.1 D.2

Het ICB-systeem moet een uitgebreid gebruikersbeheer bieden; Het ICB-systeem moet de mogelijkheid bieden om de koppeling met de database te beheren. Het beheer van de database zelf zal waarschijnlijk gebeuren buiten het ICB-systeem om; Het ICB-systeem moet de mogelijkheid bieden om te zien of de itemanalysegegevens correct zijn geïmporteerd en beschikbaar zijn voor de gebruikers. Voor de beheerder zal dit een soort logboek zijn met meer technische details, voor de gebruikers meer een status „beschikbaar‟ of „nog niet beschikbaar‟;

D.3

41


D.4 D.5 D.6

10.

Het ICB-systeem moet de mogelijkheid bieden om het rechtsschap voor gebruik in te stellen voor onderdelen van het systeem; Het ICB-systeem moet de mogelijkheid bieden om templates in te voeren in het format; Het systeem moet een degelijk blauwdrukbeheer bieden. Hierbij hoort het beheren van de classificatielijst en de indeling van de blauwdruk(ken).

Niet-functionele requirements

In dit hoofdstuk bespreken we requirements aan het systeem die niet direct gekoppeld zijn aan activiteiten van de gebruikers, maar die wel essentieel zijn voor een goede werking van het systeem. Het gaat dan met name om aspecten van beveiliging en performance. X.1

Het systeem moet webgebaseerd zijn. Omwille van de centrale bereikbaarheid van het systeem is het noodzakelijk dat het ICB-systeem een webgebaseerde gebruikersinterface heeft. Zodoende kan het systeem vanaf elke PC met internetverbinding worden gebruikt, hetgeen de toegankelijkheid en het gebruiksgemak verhoogt;

X.2

Het systeem kent een hoog niveau van gebruikersgemak. Dit betekent een duidelijk interface en niet te veel overbodige clicks;

X3

Het systeem moet het gebruik kunnen registreren. Informatie over hoeveel gebruikers er in het systeem hebben ingelogd en welke acties er zijn ondernomen dient geregistreerd te worden, o.a. ten behoeve van de effectmeting. Toegang tot deze informatie hebben de VBC-leden en de centrale beheerder, zodat zij indien nodig actie kunnen ondernemen wanneer een auteur nooit gebruikt maakt van het systeem;

X.4

Het systeem moet goed beveiligd zijn. Een nadeel van de bereikbaarheid via het web is dat iedereen het systeem kan benaderen en proberen „binnen te dringen‟. Een goede beveiliging tegen hackers en andere kwaadwillenden is essentieel, zowel voor de webapplicatie als voor de database. Mogelijkheden hierbij zijn zogenaamde „Two-Factor Authentication‟ zoals Phone Factor4 of RSA Tokens5;

X.5

Het systeem moet een hoge beschikbaarheid hebben. Om de auteur een zo groot mogelijke flexibiliteit te bieden is het belangrijk dat het systeem te allen tijde beschikbaar is voor de mensen die het willen gebruiken. Beschikbaarheid wordt bereikt door zowel een stabiele internetverbinding vanuit de partij die de server(s) in beheer heeft, als ook door een systeem dat qua capaciteit krachtig genoeg is om genoeg gebruikers tegelijkertijd in het systeem te laten werken;

X.6

De database van het systeem moet op afstand te benaderen zijn. Doordat er gegevens uitgewisseld moeten worden door de database van het ICB-systeem en de database van VOSYS, moet het mogelijk zijn om vanuit een soort „conversieprogramma‟ de database te benaderen. Uiteraard is het niet de bedoeling dat gebruikers de database kunnen benaderen, maar alle handelingen via het webgebaseerde programma verrichten;

4 5

http://www.phonefactor.com/ http://www.rsa.com/node.aspx?id=1156 42


X.7

Het systeem moet op afstand te beheren zijn. De beheerder van het systeem moet zijn beheerstaken op afstand kunnen uitvoeren, ongeacht de geografische locatie van de servers of de beheerder zelf;

X.8

Het systeem moet uitgebreide en flexibele rapportagemogelijkheden bieden over actuele status van items en toetsen in de bank, verdeling over de blauwdrukken, het gebruik van het systeem, doorlooptijd items, etc.;

X.9

Het systeem moet schaalbaar zijn. Het systeem moet met het oog op de toekomst ook grote itembanken en veel gebruikers aankunnen;

X.10

Het systeem moet generaliseerbaar zijn. Het ICB-systeem moet toepasbaar zijn voor andere domeinen dan de iVTG organisatie. Op het moment dat andere domeinen gebruik zouden willen maken van hetzelfde systeem, hebben zij wellicht andere wensen en eisen m.b.t. de functionaliteit ervan. Het is belangrijk dat de items, blauwdrukken en andere onderdelen per organisatie gescheiden van elkaar zijn en gebruikers niet (zomaar) items van andere organisaties kunnen inzien;

X.11

De user interface moet in meerdere talen beschikbaar zijn. Om generalisatie van het ICB-systeem te bereiken is meertaligheid een belangrijk aspect. Met andere talen valt te denken aan Engels, Duits en Arabisch;

X.12

Het systeem moet de mogelijkheid bieden om een volledig aanpasbare huisstijl/schermopbouw conform wensen van de opdrachtgever (style sheets) te realiseren;

X.13

Het ICB-systeem moet extern gehost kunnen worden.

43


11.

Specifieke eisen m.b.t. voortgangstoetsing en het VOSYS systeem

Het ICB-systeem is met name bedoeld om het itemconstructie- en beoordelingsproces te ondersteunen. Het is op dit moment nog niet duidelijk hoe de voortgangstoets digitaal kan worden afgenomen. De afname en de daarmee verbonden wijze van toetsverwerking zullen daarom nog niet wijzigen. Dat betekent dat antwoordgegevens van de op papier afgenomen toetsen op de huidige wijze in VOSYS zullen worden opgeslagen en verwerkt. Het VOSYS systeem blijft dus functioneren voor de itemanalyses, toetsanalyses en het berekenen van de studentresultaten. Om dit te mogelijk te maken moeten er gegevens tussen beide systemen worden uitgewisseld. Zo moeten de toetsgegevens naar VOSYS worden overgeheveld om itemanalyse en resultatenberekening mogelijk te maken. De resultaten van de analyse van de items moeten weer terugkomen in het ICB-systeem, omdat dit essentiële feedback is voor de auteurs van die items. Alhoewel de precieze wijze van uitwisseling tussen het ICB-systeem en VOSYS pas kan worden vastgesteld op het moment dat de technische details van het ICB-systeem duidelijk zijn, kunnen we wel op een meer conceptueel niveau vastleggen welke randvoorwaarden aan deze uitwisseling moeten worden gesteld. Momenten van uitwisseling De uitwisseling van gegevens tussen het ICB-systeem en VOSYS zou weliswaar “live” kunnen plaatsvinden (dwz iedere relevante wijziging in het ene systeem wordt ogenblikkelijk naar het andere systeem doorgestuurd), maar het karakter van de procedures rond voortgangstoets maakt het aannemelijker om de uitwisseling batchgericht op te zetten. Daarbij zijn er een aantal momenten waarop uitwisseling nodig is: 1) Aanmaken voorlopige toets Op het moment dat de voorlopige toets is vastgesteld in het ICB-systeem en het toetsboekje samengesteld wordt, kan de toets in zijn geheel in VOSYS worden aangemaakt. Hierbij moet dus alle voor de analyse relevante informatie van de gekozen items naar VOSYS worden getransporteerd. (dwz: identificatiecode in het ICB-systeem, blauwdruk-labeling, aantal alternatieven, en sleutel). Het aanmaken van de toetssessie met alle noodzakelijke informatie dient in VOSYS zelf te worden gedaan, maar de identificatie van de toets in het ICB-systeem moet worden verbonden aan de identificatie in VOSYS. 2) Resultaten itemanalyse Nadat de toets is afgenomen en de uitslagen zijn verzameld en verwerkt, vindt in VOSYS de itemanalyse plaats. De resultaten van deze analyse moeten worden teruggevoerd naar het ICB-systeem. Hierbij denken we aan een tekstueel rapport dat als commentaar of meta-informatie aan het item kan worden gehangen. Het is dan wel belangrijk dat  het juiste item in ICB-syteem wordt gekoppeld;  de toetsgegevens (datum etc) steeds bij de analyse staat;  er meerdere van dit soort rapporten bij een item kunnen staan; 3) Vaststellen definitieve toets Op basis van de itemanalyse kan het gebeuren dat de sleutel van een item wijzigt of dat een item helemaal vervalt uit de toets. Deze wijzigingen worden eerst in het ICB systeem aangegeven. Wanneer alle wijzigingen zijn verzameld en de definitieve toets is vastgesteld, moeten deze wijzigingen aan VOSYS worden doorgegeven.

44


4) Resultaten Het is nog te bezien of er ná de resultaatberekening informatie weer naar het ICBsysteem moet worden teruggevoerd vanuit VOSYS. Het kan hier bijvoorbeeld gaan om herberekende itemanalyses (bij sleutelwijziging). Incidentele synchronisaties Naast de reguliere uitwisselingen hierboven zijn er ook enkele incidentele synchronisaties tussen de beide systemen nodig die éénmalig (of slechts af en toe) plaatsvinden. a) Bestaande items in VOSYS overzetten Zo zal het wenselijk zijn om de bestaande itembank in VOSYS voor een deel in het ICB-systeem op te kunnen nemen. Hiervoor is het nodig om de items in VOSYS te kunnen exporteren naar een in het ICB-systeem te importeren format. Hierbij horen dan ook afhankelijke gegevens zoals auteurs en eerdere itemanalyses. Dit is een éénmalige actie. b) Literatuurlijsten in VOSYS de bestaande literatuurlijsten moeten ook in het ICB-systeem beschikbaar zijn. Ook dit is een éénmalige actie. c) Blauwdrukwijzigingen De bestaande blauwdruk moet in het ICB-systeem worden opgenomen. Bij toekomstige wijzigingen moeten deze in beide systemen plaatsvinden. d) Deelnemende instellingen Na de keuze voor het ICB systeem zullen bovenstaande punten verder moeten worden uitgewerkt (dit is voorzien in werkpakketten WP2.5 en WP4 2e en 2f.)

45


Bijlage 1

Lijst met gesprekspartners

1. Universiteit Maastricht

Result admins

Paul Gransbergen, Guus Smeets

Centrale iVTG Coördinator

Judith van den Brink

VBC commissie

R. van Driest, W. van Mook, B. Schutte

Itemauteur

B. Verhoeven

Itemauteur

M. oude Egbrink

30 juni 2011

09.00 – 10.30 uur 5 juli 2011 10.00 – 12.00 uur 8 september 2011 14.00 – 15.00 uur 22 september 09.45 – 10.30 2011 uur 29 september 15.40 – 16.00 2011 uur

2. Universitair Medisch Centrum Groningen

Lokale iVTG Coördinator

VBC commissie

Voorzitter WiV/DB

27 juni 2011 L. Datema D. Bogchelman, A. 27 juni 2011 Dubois, J. Fleer, J. Greidanus, J. Mandema, W. Manson, F. Mulder 27 juni 2011 R. Henning

15.00 – 16.00 14.00 – 15.00

13.00 – 14.00

3. Leids Universitair Medisch Centrum

Lokale iVTG Coördinator VBC commissie

T. Krommenhoek I. Biemond, P. Bloemendaal, E. Dubois, J. Eikenboom P. de Jong, L. Kramer, T. Krommenhoek, V. Smit, S. Wagenaar

3 augustus 2011 10.00 – 11.00 26 september 14.15 – 14.45 2011

4. Universitair Medisch Centrum Nijmegen

Lokale iVTG Coördinator VBC commissie

L. Gijsbers E. van de Lisdonk, E. Morava, B. Schouwenberg, A. Thoben

15 juli 2011 10.00 – 11.30 9 september 2011 11.00 – 12.00

46

VGTogether. samenwerken in voortgangstoetsing. Programma Toetsing en Toetsgestuurd Leren

Recommend Documents