IB CS SL: Die Inhalte, die HL-Arbeiten komplett auslassen

Die meisten IB-Informatik-Lernleitfäden behandeln SL als "HL minus ein paar Themen" und hören dort auf. Das stimmt für den Inhalt, aber nicht für die Prüfungsstruktur, die IA-Anforderungen oder die Art, wie die Case Study getestet wird. Wenn du nur SL machst, gibt es eine Handvoll Dinge, die nie auftauchen, wenn du aus HL-fokussierten Materialien lernst, weil diese Materialien davon ausgehen, dass du Paper 3 ablegen wirst und tiefer in HL-only-Themen gehst. Dieser Leitfaden behandelt die Teile, die tatsächlich für die SL-Prüfung und Moderation relevant sind, nicht die gemeinsamen Lehrplaninhalte, die ohnehin alle wiederholen.

Paper 1 vs Paper 2 Gewichtung, die niemand klar erklärt

SL-Schüler bearbeiten Paper 1 (Multiple Choice, 45 Minuten, alle Themen plus die vorab veröffentlichte Case Study) und Paper 2 (strukturierte Fragen, 1 Stunde 15 Minuten, Coverage Topics 1-4 plus die Case Study). Es gibt kein Paper 3 auf SL-Niveau — das ist nur für HL und behandelt die zusätzlichen HL-Themen (abstrakte Datenstrukturen, Ressourcenmanagement, Kontrolle und das erweiterte Case-Study-Material). Viel Verwirrung entsteht, weil Schüler HL-only Sample Papers studieren und sich fragen, warum die Fragen nicht mit dem übereinstimmen, was sie im Unterricht gesehen haben. Wenn du SL machst, ignoriere die Paper 3 Markierungsschemen komplett; sie testen Inhalte, für die du nicht verantwortlich bist.

Die Case Study verdient mehr Aufmerksamkeit, als die meisten Schüler ihr geben. Sie wird Monate vor der Prüfung veröffentlicht (normalerweise um März für eine Mai-Sitzung) und macht etwa 25% von Paper 1 und einen vollständigen obligatorischen Abschnitt von Paper 2 aus. Lies das Case-Study-Dokument mindestens dreimal vor den Prüfungen: einmal zum Verständnis, einmal mit Anmerkungen für technisches Vokabular (spezifische Systemnamen, Stakeholder, erwähnte Hardware/Software) und einmal rein zum Auswendiglernen von Namen und Rollen, denn Paper 2's Case-Study-Abschnitt erwartet von dir, dass du das Szenario präzise referenzierst, nicht generisch.

Das IA wird anders bewertet als die meisten annehmen

Die interne Bewertung für SL und HL verwendet die gleichen Kriterien (A bis E: Planning, Solution Overview, Development, Functionality und Evaluation), aber SL-Schüler sollen etwas mit geringerer Komplexität produzieren. Prüfer suchen nicht nach einer geringeren Anzahl von Funktionen — sie schauen, ob die Komplexität deinem tatsächlichen in der Schularbeit demonstrierten Fähigkeitsniveau entspricht. Ein häufiger Fehler: SL-Schüler versuchen eine zu ehrgeizige App mit Datenbankbackend und mehreren Benutzerrollen, können dann aber ihren eigenen Code im erforderlichen Screencast nicht erklären, was Criterion C (Development, 6 Punkte) und D (Functionality, 4 Punkte) ruiniert.

Ein besserer Ansatz für SL: wähle ein kundenorientiertes Problem, das du in unter 2000 Worten in der schriftlichen Ausarbeitung vollständig erklären kannst, mit einer Lösung, die 3-5 klare, testbare Funktionen hat. Video- und Audiobeweis (Criterion C) muss tatsächlich die IDE, den laufenden Code und deine Stimme zeigen, die Entscheidungen erläutert — nicht eine Präsentation im Nachhinein. Moderatoren sehen den Unterschied sofort.

Topic 4 (Computational Thinking and Program Design) wird in der Wiederholung untergewichtet

Topics 1-3 (System Fundamentals, Networks und Computer Organization) bekommen die meiste Lernzeit, weil sie sich mehr "lehrbuchhaft" anfühlen. Topic 4 behandelt Algorithmen, Pseudocode und Programmentwurf — Trockenläufe, Flussdiagramme, rekursives vs iteratives Denken und Big-O-ähnliche Effizienzüberlegungen (obwohl IB auf SL-Niveau keine formale Big-O-Notation erfordert, nur relative Effizienzvergleiche). Dieses Thema taucht ständig in Paper 2's strukturierten Fragen auf, weil es leicht ist, eine szenariobasierte Frage dazu zu schreiben.

Übe, Pseudocode von Hand unter Zeitdruck zu schreiben. IB-Pseudocode-Konventionen (Verwendung von loop, end loop, if, then, else, end if) sind spezifisch und Prüfer ziehen Punkte für inkonsistente Syntax ab, auch wenn die Logik korrekt ist. Bearbeite mindestens fünf Past-Paper Topic 4-Fragen aus N19, M19, N18 und N17-Sitzungen (vermeide Papiere nach 2020, wenn dein Lehrplan sich geändert hat, da dieser Leitfaden aus dem 2014-Lehrplan stammt, der erstmals 2016 geprüft wurde, mit der aktuellen Version geprüft bis 2024-Sitzungen, bevor der neue Lehrplan übernahm).

Networks (Topic 2)-Fragen bevorzugen spezifisches Vokabular gegenüber allgemeinem Verständnis

SL-Schüler verstehen Netzwerke oft konzeptionell, verlieren aber Punkte, weil Paper 2 benannte Begriffe will: circuit switching vs packet switching, spezifische Protokollschichten oder der Unterschied zwischen MAC-Adresse und IP-Adresse präzise angegeben. Erstelle ein einseitiges Glossar von Topic 2-Begriffen mit einsatzigen Definitionen in IB-Formulierung, direkt aus dem Glossar-Abschnitt des Lehrplanentwurfs gezogen, und teste dich selbst darin separat von deinen konzeptionellen Notizen.

Wenn du strukturiertere Aufschlüsselungen von Lehrplaninhalten, Algorithmus-Walkthroughs oder IA-Planungsunterstützung möchtest, schau dir die anderen Computer Science und Tutoring-Segmente auf Korra Studio an.