[BUG] Prozentangabe in Lernpfad-Einbindung widersprüchlich

[ralferlebach]

Die prozentuale Angabe des bearbeitungsfortschritts eines Nutzers in der Lehreransicht entspricht augenscheinlich nicht der Anzahl der bearbeiteten/abgeschlossenen Nodes und wirkt daher widersprüchlich.

[cbadusch]

Aus welchem Kurs stammt dieser Screenshot?

[ralferlebach]

Hier das Ergebnis meiner Quelltext-Analyse:

Was ist das Problem?

Die aktuelle Prozentangabe berechnet den höchsten Anteil abgeschlossener Knoten auf einem statischen Start-End-Pfad. Sie bildet damit weder den individuellen Einstieg eines Lernenden noch die tatsächlichen Zugangsvoraussetzungen des Lernpfads korrekt ab.

Insbesondere werden nicht angemessen berücksichtigt:

• bereits bestehende Einschreibungen als valide Einstiegspunkte,
• nicht abschlussbezogene Bedingungen wie Zeitfenster oder Testergebnisse,
• Abhängigkeiten von bestimmten Knoten,
• kompensatorische Bedingungen wie „3 von 5 Knoten abgeschlossen“,
• mehrere alternative oder gemeinsam erforderliche Endknoten.

Dadurch können bereits erlassene Vorgängerknoten weiterhin im Nenner stehen, erreichbare Alternativen fehlen oder strukturelle Verbindungen fälschlich als fachlich notwendiger Lernweg interpretiert werden.

Wie müsste die Lösung fachlich aussehen?

Die Berechnung muss von den potentiellen Endknoten rückwärts über den tatsächlichen Bedingungs- und Abhängigkeitsgraphen erfolgen.

Dabei gilt:

• Jeder Knoten hat das Gewicht 1.
• Eine bestehende Einschreibung gilt als individueller Einstiegspunkt. Die rückwärtsgerichtete Prüfung endet dort; der Knoten selbst gilt aber erst nach seinem Abschluss als abgeschlossen.
• Nicht abschlussbezogene Bedingungen werden als erfüllt, noch erfüllbar oder dauerhaft unmöglich klassifiziert.
• Bei ODER-Bedingungen werden die weiterhin erreichbaren Alternativen getrennt untersucht.
• Bei UND-Bedingungen werden alle erforderlichen Teilmengen vereinigt.
• Bei „k aus n“ werden für den kürzesten Weg nur die noch benötigten günstigsten Alternativen, für den maximalen Umfang dagegen alle weiterhin erreichbaren Alternativen berücksichtigt.
• Knoten werden innerhalb einer Ergebnismenge nur einmal gezählt.

Es werden zwei Werte ausgegeben:

A: Direkter Zielfortschritt

Fortschritt auf der kleinsten noch notwendigen Knotenmenge zwischen einem individuellen Einstiegspunkt und einem gültigen Endknoten:

$$ A = \frac{\text{abgeschlossene Knoten der Minimalmenge}} {\text{alle Knoten der Minimalmenge}} \cdot 100 $$

B: Fortschritt im gesamten erreichbaren Lernumfang

Fortschritt bezogen auf alle Knoten, die von den individuellen Einstiegspunkten aus zu weiterhin erreichbaren Endknoten gehören:

$$ B = \frac{\text{abgeschlossene Knoten der Maximalmenge}} {\text{alle Knoten der Maximalmenge}} \cdot 100 $$

Zusätzlich ist die Erreichbarkeit separat auszuweisen:

• Bei alternativ ausreichenden Endknoten ist der Lernpfad erst dann unerreichbar, wenn alle Endknoten dauerhaft unerreichbar sind.
• Bei gemeinsam erforderlichen Endknoten genügt ein dauerhaft unerreichbarer Endknoten für den Fehlerstatus.
• Nur vorübergehend gesperrte Zeit- oder Testbedingungen dürfen nicht als dauerhaft unerreichbar markiert werden.

Eine gestapelte Darstellung ist nur möglich, solange mathematisch $A ≥ B$ gilt. Da dies bei bereits abgeschlossenen optionalen Zweigen nicht garantiert ist, stapeln sich die Balken folgendermaßen dunkelgrün: $B$ - hellgrün: $max (0, A - B)$ - grau: Rest. Alternativ könnten die beiden Werte entweder als zwei Balken oder als Balken mit zusätzlicher Zielmarke dargestellt werden.

Wie sollte die Lösung technisch umgesetzt sein?

Die Berechnung sollte aus learning_paths::getnodeprogress() in einen eigenen, testbaren Dienst ausgelagert werden, beispielsweise:

local_adele\progress\progress_calculator

Der Dienst sollte:

1. alle Knoten, Einschreibungen, Abschlüsse und Bedingungen gebündelt laden;
2. daraus den fachlichen Abhängigkeitsgraphen aufbauen;
3. potentielle Endknoten bestimmen;
4. deren Bedingungen rückwärts und rekursiv auflösen;
5. an eingeschriebenen Knoten die Rückwärtsauflösung beenden;
6. UND-, ODER- und k aus n-Bedingungen explizit behandeln;
7. die Minimal- und Maximalmengen als Mengen von Knoten-IDs bilden;
8. Mehrfachzählungen durch Set-Operationen verhindern;
9. Rekursionsergebnisse zwischenspeichern und Zyklen erkennen;
10. Prozentwerte und Erreichbarkeitsstatus als strukturiertes Ergebnis zurückgeben.

Beispiel:

[
    'directprogress' => 65.0,
    'overallprogress' => 42.0,
    'reachability' => 'reachable',
    'minimalnodes' => [...],
    'maximalnodes' => [...],
]

Zur Vermeidung von N+1-Abfragen müssen Einschreibungen, Kursabschlüsse und Bedingungsdaten vor der Traversierung gesammelt geladen werden. Die bestehende operative Freischaltungslogik und die Fortschrittsberechnung sollten möglichst denselben Condition-Resolver verwenden, damit Anzeige und tatsächliche Einschreibung nicht unterschiedliche Erreichbarkeiten ermitteln.

Erforderlich sind PHPUnit-Tests mindestens für:

• lineare Pfade,
• bestehende Einschreibung in einem mittleren Knoten,
• alternative ODER-Wege,
• UND-Bedingungen,
• „k aus n“-Bedingungen,
• Zeitbedingungen,
• knotenspezifische Abhängigkeiten,
• mehrere Endknoten,
• dauerhaft unerreichbare Endknoten,
• bereits abgeschlossene optionale Zweige,
• Zyklen und fehlerhafte Referenzen.

[ralferlebach]

Als Zwischenschritt (schnell implementierbar): Anzahl abgeschlossener Nodes / Anzahl aller Nodes (aktuell werden nur UND-Verknüpfungen von Pfaden

Endschritt: Elaborierter Algorithmus, mit optimal/Maximalpfad.