Graag onderschrijf ik dit probleem: Graag aanpassen!

Bij het aanbieden van een dynamische toets blijven de vragen per vragenpool en deelonderwerp bij elkaar. Bij het genereren van een statische toets uit deze dynamische toets staan alle vragen door elkaar, ook als ik aangeef dat de volgorde vast is. 

Ook ik loop tegen dit probleem aan. Zou mooi zijn als dit wordt aangepast.

Hallo @nietj,

De functionaliteit die je veronderstelt bestaat niet. Bij het genereren van een statische toets wordt een set van vragen getrokken op basis van de matrijs van de dynamische toets. Vervolgens kunnen deze getrokken vragen in een vaste volgorde aangeboden worden, of per toetsafname variabel. De statische toets heeft echter geen koppeling meer met deelonderwerpen. Ze kunnen daarom niet per deelonderwerp gegroepeerd worden.

Het is wel mogelijk om in te stellen dat de vraagvolgorde vast moet zijn en handmatig de volgorde te bepalen in de statische toets. Dan kun je de gewenste vraagvolgorde in ieder geval beïnvloeden.

Een andere optie is om een dynamische toets te maken op basis van een vragenpool waarbij alle vragen getrokken worden. Zo kun je er voor zorgen dat de vragen per deelonderwerp gegroepeerd worden. De volgorde binnen een deelonderwerp kun je dan weer niet beïnvloeden.

Ik zou graag willen weten of er ook andere organisaties zijn die de huidige functionaliteit aangepast zouden willen zien. En wat is daarbij de reden dat bovenstaande methoden onvoldoende zijn?

Ook wij lopen helaas tegen dit probleem aan.

Voor toekomst mooi uitgangspunt om dit aan te passen.

Het is duidelijk dat dit een breed gedragen wens is binnen Hogeschool Rotterdam. Wat me nog niet duidelijk is, in welk scenario deze functionaliteit nou precies wenselijk is. 

Verder hoor ik graag van andere organisaties of zij deze wens onderschrijven en waarom.

Men wil vragen die bij elkaar horen, bijvoorbeeld omdat ze over een bepaalde casus gaan, bij elkaar houden. Stel ik heb een casus over meneer Janssen, mevrouw Pietersen en meneer Klaasen.  Bij iedere case ontwikkelt men 15 vragen, 5 op kennis, 5 op inzicht en 5 op toepassingsniveau.

In de toetsmatrijs staat dat een bepaalde toets 2 kennisvragen, twee inzichtvragen en twee toepassingsvragen moeten krijgen van casus 1, idem van casus 2 en idem van casus drie.

Als je dit uitzet in een dynamische toets, werkt het precies zoals gewenst. Vragen per casus blijven bij elkaar. Het probleem dan is dat studenten andere vragen krijgen, wat de analyse bemoeilijkt.

De oplossing lijkt beschikbaar: trek een statische toets op basis van de dynamische toets. Helaas staan dan alle vragen door elkaar. Dat geeft een ongewenste cognitive load voor studenten.

Het met de hand in de juiste volgorde zetten van de vragen is dan de enige oplossing. Mijns inziens valt dat onder de categorie “beetje suf werk”.

@m.v.brunschot Ok, dat begrijp ik. Maar wat is dan nog het nut van het maken van 5 vragen als er 3 vragen zijn die je niet in de uiteindelijke toets wilt opnemen? Je kunt dan de vragenpool kopiëren en de vragen die je niet wil stellen er uit verwijderen en op basis van die pool de dynamische toets samenstellen. Klopt het dat je dan gewenste eindresultaat krijgt?

wat is dan nog het nut van het maken van 5 vragen als er 3 vragen zijn die je niet in de uiteindelijke toets wilt opnemen?

Dat heeft te maken met het constructieproces. Je zit als itemauteur met een casus in je hoofd. Daar zijn tal van zaken over te bevragen op verschillende niveaus. In mijn voorbeeld kan je x vragen op kennis / reproductie niveau bedenken (kan ik de feiten opnoemen). Je wil y vragen stellen op het niveau van inzicht (begrijp ik de betekenis van die feiten) en tenslotte wil je x vragen op het niveau van toepassing (als je de feiten kent en weet wat ze betekenen, wat gebeurt er dan in een bepaalde situatie).

Onder jouw vraag lijkt de opvatting te liggen: ga er een andere keer nog eens voor zitten en verzin nieuwe, andere vragen als je ze nodig hebt, bijvoorbeeld voor de herkansingstoets.  Dat is een beetje inefficiënt.

IQualify beschikt, met de vragenpools, dynamische toetsen en de mogelijkheid om statische toetsen te trekken uit dynamische toetsen, waarbij ook nog vragen uitgesloten kunnen worden die in andere toetsen voorkomen  over een prachtige oplossing voor het genereren van verschillende toets-versies.  Alleen een beetje jammer dat vragen die uit een bepaalde vragenpool komen niet bij elkaar gehouden kunnen worden. Dát is de essentie van de vraag van Joris, die ik van harte ondersteun.

vragenpool kopiëren en de vragen die je niet wil stellen er uit verwijderen

Dat vraag om een hoop handwerk door een inhoudsdeskundige. De kans dat je deze werkwijze binnen een opleiding kan implementeren lijkt mij niet zo groot. Inhoudsdeskundigen zijn niet allemaal helemaal dol op ICT, zal ik maar zeggen.

en op basis van die pool de dynamische toets samenstellen. Klopt het dat je dan gewenste eindresultaat krijgt?

Met een dynamische toets op basis van vragenpools die je helemaal “leeg trekt” krijg je voor de student inderdaad het gewenste resultaat: vragen die bij elkaar horen (bijvoorbeeld omdat ze over een casus gaan, of bij hetzelfde vak of thema horen) blijven bij elkaar. 

Je zou het ook op kunnen lossen met verschillende deeltoetsen in één leerperiode, maar beide gevallen ben je de analysemogelijkheden van iQualify kwijt.

Wat Joris in wil leveren om de analysemogelijkheden te kunnen gebruiken, is de variabele vraagvolgorde.

Ik begrijp dat mijn bovenstaande suggesties niet optimaal zijn, ik probeer vooral mee te denken binnen de huidige mogelijkheden.

Stel dat je bij het genereren van een statische toets kiest voor een vaste vraagvolgorde. En stel dat de vragen daardoor een sortering krijgen zodat ze per deelonderwerp bij elkaar staan. Dan staan de vragen per deelonderwerp wel bij elkaar, maar is er geen koppeling met het deelonderwerp. Je kunt dus niet zien welke vragen bij welk deelonderwerp horen. Zou dat afdoende zijn?

Ik weet het met een aan zekerheid grenzende waarschijnlijkheid dat het niet benoemen van de deelonderwerpen geen probleem is.

@nietj Joris, dat klopt toch?

@Janice Fritzen Voor jou hoeft dat toch ook niet?

Dus de vragenpools worden wel onderverdeeld in deelonderwerpen, maar bij de vraag is niet te zien uit welk deelonderwerp deze vraag komt?

het klopt dat bij het tentamen het niet te zien is uit welke deelonderwerp de vraag komt. een vraagverdeling voor die specifieke tentamen kan in de introductie tekst van het tentamen toegevoegd worden. wat we doen is hier handmatig per vraag zoeken uit welk onderwerp ze komt. het systeem is hierin niet geautomatiseerd.

vragen uit een casus doen wij bij ieder afzonderlijke vraag de casus toevoegen. dus bij 5 vragen uit een casus krijg de student de casus 5 keer te zien. dat vinden studenten niet erg.

@nietj Zoals ik van jou begrepen heb is dat geen probleem

@Janice Fritzen Wat Joris beschrijft maakt jou leven ook nog mooier: je organiseert de onderdelen van je matrijs in vragenpools. Per casus maak je andere vragenpools. In het geval van Joris, onderverdeeld naar een taxonomie.  In de dynamische toets (vragen per deelonderwerp bij elkaar houden) die je trekt, richt je letterlijk je matrijs in, waarbij de cases separaat vermeld worden. Dán komt de truuk: trek een vaste toets.  

De constatering van Joris was dat daarbij de volgorde van de vragen over de hele toets gerandomiseerd worden. Dat kan je met vast volgorde wel beïnvloeden, maar dat is véél werk en een klusje wat je niet snel kan overdragen. (In Rotterdam hebben ze nog geen SVAK  ).

De vraag van Joris is dus: als ik een vaste toets trek uit de dynamische toets dan wil ik vragen op een vaste volgorde, waarbij de vragen per deelonderwerp bij elkaar staan. Gesteld dat de andere functies onveranderd blijven, kan je dus, bij voldoende gevulde vragenpools, met de spreekwoordelijke druk op de knop verschillende toetsversies uitdraaien. Hierbij kan je “vragen uitsluiten” gebruiken, zolang de voorraad strekt. 

@Thomas de Groot Dat het deelonderwerp niet als tussenkopje vermeld wordt is geen probleem.

Dat er geen deelonderwerp vermeld wordt bij de toets is geen probleem, wij gebruiken de deelonderwerpen alleen op de achtergrond om een toets op te bouwen conform de toetsmatrijs uit ons onderwijs. Het plaatsen van meer vragen in een vragenpool dan nodig voor de toets is inderdaad zoals Martin (@m.v.brunschot) als beschreef bedoeld om meerdere kansen voor de zelfde toets makkelijk te genereren. Wat bij ons nu ook hel goed lukt, m.u.v. het punt van de vragenvolgorde. 

Met het bij elkaar houden van vragen willen we 3 dingen bereiken. 

1. Het bij elkaar houden van onderwerpen, voor onze opleiding (fysiotherapie) is het erg onhandig als vragen over hartfalen, kniepijn, psychologie, hoofdpijn, fysiologie en hersenaandoeningen door elkaar heen worden aangeboden.
2. In jaar 2 werken we veelal met vragen die aan een casus zijn gebonden, het betreft dan 2 tot 5 vragen per casus. Hiervoor geldt ook het bovenstaande argument, maar daarnaast zijn het uitgebreide casussen en is het niet wenselijk dat de vragen uit de verschillende casussen door elkaar heen worden aangeboden. Dit is voor studenten erg veel schakelen in onderwerpen en het is verwarrend dat een casus die bij vraag 1 aan bod is gekomen ook bij vraag 5, 21 en 35 terug komt. De student moet de casus dan iedere keer volledig lezen en ziet niet gemakkelijk dat dit dezelfde casus is als eerder in de toets.
3. De toetsinzage vindt bij ons plaats op basis van de toetsmatrijs. Er is geen fysieke inzage in de toets, maar een overzicht van welke vragen bij welk leerdoel horen met verdeling conform taxonomie (Bloom). Als de vraagvolgorde vast is conform de ingevoerde toetsmatrijs dan is het makkelijk om achteraf aan studenten een overzicht te geven waarin staat dat vraag 1 tm 6 horen bij leerdoel 1 (2 kennis, 2 inzicht, 2 toepassing), vraag 7 tm 15 bij leerdoel 2, enz. Op die manier kunnen studenten zelf bepalen op welke onderdelen ze zich moeten focussen in geval van een herkansing. 

Ik bedoel natuurlijk Marcel ipv Martin 

@nietj Joris, bij gelegenheid moeten we het nog eens hebben over de toetsinzage, als jullie eenmaal digitaal toetsen. Bij verschillende andere iQualifygebruikers was men in eerste instantie ook wat huiverig, maar als je beschikt over de hardware capaciteit, blijken studenten het in kunnen zien van hun gemaakte fouten en daarbij de mogelijkheid krijgen om opmerkingen op vraagniveau te maken, te waarderen. Zeker als de vragen voorzien zijn van een kennisflits wordt de inzage een duidelijk leermoment .

Helemaal mee eens Marcel, ik zie heel veel voordelen voor studenten en uiteindelijk ook voor ons om de inzage anders te organiseren. De keuze voor deze vorm van inzage is door anderen gemaakt. Maar als helder is hoe we de inzage via iQualify kunnen laten verlopen en welke facilitaire voorwaarden daaraan hangen dan ga ik dit nog eens onder de aandacht brengen.

Ik maak uit bovenstaande op de dat mijn voorgestelde oplossing het belangrijkste probleem oplost. Ik zal eens kijken of we dit kunnen realiseren. Ik kan hiervoor nog geen toezeggingen doen. In ieder geval fijn dat we een oplossingsrichting hebben die voor de meeste situaties goed toepasbaar is.

Als deze aanpassing gerealiseerd kan worden dan zijn wij daar erg blij mee. 

Beste Thomas, is er al iets meer bekend over de mogelijke aanpassingen? 

@nietj 

Nee hier is nog niets over bekend. We communiceren hier ook geen verwachtingen over. In dit topic leggen we uit hoe we met ideeën om gaan en waarom: https://community.infoland.nl/community-ideeen-33/hoe-gaat-infoland-met-ideeen-om-937

@nietj in release 5.6.1 is de logica voor het bepalen van de vraagvolgorde voor het genereren van een statische toets gewijzigd. Als in de dynamische toets de vragen gegroepeerd worden én er voor een vaste vraagvolgorde wordt gekozen voor de statische toets dan worden de vragen standaard in een volgorde geplaatst waarbij de vraaggroepering gerespecteerd blijft. Dit is de oplossing zoals ik de eerder binnen dit topic had aangedragen.

Ik ben benieuwd naar je ervaringen.

Zie https://update.infoland.nl/2020/11/23/iqualify-5-6-1/ om te zien wat er verder allemaal in deze release gewijzigd is.