Feature Wiki

Information about planned and released features

Tabs

Competence Management for Questions Groups

This is a sub-entry of the feature request Competence-driven Question Groups and Test Parts

1 Initial Problem

Question Groups open up lots of possibilities with respect to measuring competences since...

  • more than one question can be used to assess a learner's competence level
  • question swapping / management would be much easier if competence information was assigned to a question group and not to single questions
It should be possible to assign competence measuring rules to question groups in tests.

2 Conceptual Summary

Key points for the competence management of question groups:

  • with respect to competences a question group acts like a single / individual question and can be addressed by the magical competence logic device of the test module:  (QGRP1 > %75%) & (QGRP2 > #5#)
    • central advantage: you can slip questions in and out of the questions group without destroying the competence measurement assignment magic / logic
  • integration into the existing competence assignment process in test: the competence assignment follows the same process that is implemented for an entire test (using singular questions)
    • multiple competences can be assigned to a single group
    • separate assignment metric / scale for each question group
    • it is possible the define criteria that use combined logical expressions for questions from the group
    • it is not possible to define critieria using questions that are not part of the group
    • a question group can only be adressed as a whole
      • with respect to the score
      • with respect to a competence measurement that has been setup for the questions group (group measurement is used as a competence assignment for the test - "upwards inheritance"

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

  • Author of the Request: {Please add your name.}
  • Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

Samoila, Oliver [oliver.samoila], 2017-03-08: 
Hallo Marko, 
vielen Dank für die vielen Ideen.

Aus meinem Verständnis ist der Weg, ganzen Testteilen Kompetenzen zuzuweisen, kein erstrebenswerter. Bereits innerhalb einer Frage, die nun eine oder mehrere Lücken /Anwortoptionen haben kann, ist es im Falle einer Falschbeantwortung nicht leicht, den korrekten Rückschluss zu ziehen, welcher Fehler oder welche fehlende Kompetenz dafür ursächlich war. Bei der Kombination mehrerer Fragen in einer Fragegruppe bzw. einem Testteil und mehrerer zugewiesenen Kompetenzen zu diesem Testteil dürfte sich das nochmals schwieriger gestalten.
Wenn ich es richtig verstehe, dann möchtest du für eine/n Fragengruppe / Testteil eigenständige Kompetenzschwellwerte vergeben. Hier sehe ich eher die andere Richtung: Wir sollten zusehen, dass wir eine Vergleichbarkeit / kriterienbasierte Wichtung von erhoben Daten realisieren, damit wir auf möglichst hoher Ebene nur mit einem Setting an Schwellwerten arbeiten müssen.  Dann können wir uns weitere Gedanken zur Datenaggregation machen. (Damit würden auch die vielen kleinen Konfigurationsinseln verschwinden.) 
Eine Vermischung von Messungen, Selbsteinschätzungen und Fremdeinschätzungen gilt es zu vermeiden.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.

Last edited: 1. Feb 2022, 09:16, Falkenstein, Rob [rob]