LB02 - Portfolio - 55%

Dauer: 4 - 8 Lektionen
Hilfsmittel: Openbook
Sozialform: Einzelarbeit
Wann: Nach LU06
Gewichtung: 55%

Die Lernenden erarbeiten ihr eigenes Portfolio (OneNote, Word, Notion) auf Basis des Kompetenzrasters des Modul 323.

Das Kompetenzraster umfasst 15 Kompetenzfelder: fünf Kompetenzbänder (A1, B1, C1, C2, D1) auf je drei Niveaus (B = Beginner, I = Intermediate, A = Advanced).

Praxisprojekt

Erstellen Sie eine Flask-Applikation die möglichst viele Funktionale-Komponenten enthält. Es darf sich bei der Anwendung nicht um eine Todo-Liste oder um eine Einkaufsliste handeln.

Tipp: Wählen Sie ein Projekt, bei dem echte Daten verarbeitet werden (z.B. Suche/Filter/Sortierung, Statistiken, Imports/Exports, Berechnungen, Regeln). Dann können Sie die Kompetenzbänder C1 und C2 einfacher belegen.

Portfolio

Für jedes Kompetenzfeld (A1B, A1I, A1A, B1B, etc.) muss ein Lernnachweis erstellt werden, zusätzlich muss ein Code-Beispiel eingefügt werden (die Zeichen im Code zählen nicht zum Textteil dazu). Das verwendete Code-Beispiel dazu, muss aus der Flask-Applikation des Praxisprojektes sein. Ein Lernnachweis könnte folgendermassen aussehen –> Beispiel

Der Umfang des Textteils richtet sich nach dem Niveau des Kompetenzfeldes:

Niveau	Textteil (Zeichen, ohne Leerzeichen)
B – Beginner	mind. 600
I – Intermediate	mind. 1000
A – Advanced	mind. 1400

Sie können auch einen Lernnachweis über ein ganzes Kompetenzband machen, z.B. A1B, A1I, A1A. Dieser Nachweis muss dann den Umfang aller drei Niveaus zusammen erreichen (3000 Zeichen) und drei Code-Beispiele enthalten. Laden Sie diesen Nachweis dann in jeder passenden Moodle-Abgabe hoch.

Ausnahme C2: Für das Kompetenzband C2 sind keine Sammelnachweise zugelassen. Die drei Niveaus C2B, C2I und C2A müssen einzeln belegt werden, und zwar an drei verschiedenen Features Ihrer Applikation. Derselbe Codeauszug in zwei Niveaus gibt maximal 1 Punkt.

Ein Lernnachweis soll zeigen, dass Sie ein Konzept verstanden, im Projekt angewendet und reflektiert haben.

Pflichtbestandteile pro Kompetenzfeld

Textteil: Umfang gemäss Niveau (siehe Tabelle oben), Beschreibung/Reflexion/Dokumentation
Code-Beispiel: Auszug aus Ihrem Flask-Projekt (Code zählt nicht zum Textteil)
Pflicht-Artefakt: das für dieses Kompetenzfeld verlangte Element (siehe Tabelle unten)
Bezug zur Kompetenz: Im Text muss klar werden, *was* genau an Ihrem Beispiel die Kompetenz belegt

Kompetenzfeld: (z.B. C2I)
Feature im Flask-Projekt: (z.B. Statistik-Seite, Suche/Filter, Import/Export, Auth, etc.)

Kontext & Ziel: Was soll das Feature lösen? Welche Inputs/Outputs gibt es?
Konzept/Erklärung: Erklären Sie das Konzept in eigenen Worten (nicht nur Definition).
Umsetzung im Projekt: Vorgehen, Entscheidungen, Alternativen (warum diese Lösung?).
Code-Beispiel + Einordnung: Codeauszug + 2–5 Sätze, *was* daran die Kompetenz zeigt.
Test/Überprüfung: Mind. 2 konkrete Testfälle (Input → erwarteter Output) oder Debugging-Nachweis.
Reflexion & Transfer: Was war schwierig? Was gelernt? Wie würden Sie es nächstes Mal besser machen?

Das Kompetenzraster gibt pro Niveau vor, welche Denkleistung Sie zeigen müssen. Achten Sie auf die Verben:

Niveau	Verben im Raster	Ihr Beleg muss zeigen
B	beschreiben, benennen, erklären, aufzählen, anwenden	korrekte Begriffe und ein funktionierendes Beispiel
I	erläutern, formulieren, entwerfen, kombinieren, umsetzen	eigenständige Anwendung auf ein Problem Ihres Projekts
A	vergleichen, bewerten, einschätzen, analysieren, auswählen	zwei Varianten gegenübergestellt und begründet entschieden

Ein Beleg auf Niveau A, der nur beschreibt statt zu vergleichen, erfüllt das Kompetenzfeld nicht – unabhängig davon, wie lang der Text ist.

Feld	Der Lernnachweis enthält zwingend
A1B	eine Prozedur und eine pure function aus Ihrem Projekt nebeneinander
A1I	ein Codebeispiel mit Mutation und die immutable Variante davon
A1A	dieselbe Aufgabe in OO, prozedural und funktional, mit Bewertung
B1B	die Elemente des Functional Design im eigenen Projekt benannt, je mit Fundort
B1I	ein Design-Blatt: deklarative Anforderungen, Datenfluss, geplante Operatoren
B1A	eine imperative Route deklarativ umgesetzt, Vor- und Nachteile begründet
C1B	ein Algorithmus des Projekts mit Beispieldurchlauf Input → Output
C1I	derselbe Algorithmus in Teilfunktionen zerlegt, mit Signaturen
C1A	Komposition zu einem Ablauf, mit Testfällen inkl. Edge Case
C2B	Funktion in einer Variable gespeichert, Map/Filter/Reduce je einzeln
C2I	Lambda-Ausdruck und verkettetes Map/Filter/Reduce, anderes Feature
C2A	Aggregation oder benutzerdefinierte Sortierung, drittes Feature
D1B	drei Refactoring-Techniken und zwei Performance-Massnahmen, je mit Zweck
D1I	Vorher/Nachher aus Ihrer Commit-Historie, gleiches Verhalten per Test belegt
D1A	Messung vorher/nachher und Begründung der gewählten Datenstruktur

A1 (Paradigmen / Konzepte): Begriff korrekt erklären, Vergleich zu OO und prozedural, Bezug zum Projekt (wo und wie angewendet, oder bewusst nicht angewendet und warum).
B1 (Deklarative Anforderungen und Design): Unterschied imperativ/deklarativ; Elemente des Functional Design (immutable data types, constructors, composable operators); für ein Feature ein Design entwerfen, statt es nachträglich zu beschreiben.
C1 (Algorithmen): Algorithmus aus dem Projekt erklären, in Teilfunktionen zerlegen, zu einem Ablauf zusammensetzen und auf Korrektheit und Lesbarkeit prüfen.
C2 (Funktionen als Objekte, Lambda, Map/Filter/Reduce): Funktion speichern und weitergeben; Funktion als Argument; Lambda nur, wenn es lesbar bleibt (sonst lieber benannte Funktion, z.B. für Sortierung mit key=…); Map, Filter und Reduce auf echte Projektdaten anwenden und kombinieren.
D1 (Refactoring und Optimierung): Technik benennen, Vorher/Nachher beschreiben, sicherstellen dass das Verhalten gleich bleibt (Tests, Edge Cases); zusätzlich Massnahmen zur Leistungsverbesserung und die Wahl von Algorithmus oder Datenstruktur begründen.

Zu viel Theorie/Projektbeschreibung, zu wenig Kompetenzbezug und Reflexion
Code-Snippet ohne Erklärung, wo es im Projekt hingehört (Route/Service/Helper/Template)
Keine Überprüfung: „hat funktioniert“ ohne Testfälle/Beleg
Die geforderte Zeichenzahl wird mit Fülltext erreicht statt mit konkreten Learnings/Entscheiden
Auf Niveau A wird nur beschrieben statt verglichen und bewertet
In C2 dreimal dasselbe Feature verwendet

Laden Sie die Lernnachweise nach Kompetenzfeld geordnet in Moodle hoch. Das genaue Format der Abgabe klären Sie bitte mit Ihrer Lehrperson.

Achten Sie darauf die Kriterien zu erfüllen:

Textteil im Umfang des jeweiligen Niveaus (600 / 1000 / 1400 Zeichen)
Code-Beispiel aus dem Flask-Praxisprojekt
Pflicht-Artefakt gemäss Tabelle
Klarer Bezug zum Kompetenzfeld (A1B, C2I, D1A, …)

In diesem Kurs verwenden wir eine Punkteskala von 1 bis 3, um eure Lernnachweise im Kompetenzraster zu bewerten. Hier ist die Bedeutung jeder Punktzahl:

0 Punkte: Das Pflicht-Artefakt fehlt oder es besteht kein erkennbarer Bezug zum Kompetenzfeld.

1 Punkt: Die Arbeit erfüllt minimale Anforderungen, aber es fehlen entscheidende Elemente oder es gibt mehrere Fehler. Es besteht deutliches Verbesserungspotenzial.

2 Punkte: Die Arbeit ist solide und erfüllt die meisten, wenn nicht alle Anforderungen. Kleinere Fehler könnten vorhanden sein, aber sie beeinträchtigen das Gesamtverständnis nicht wesentlich.

3 Punkte: Die Arbeit ist ausgezeichnet und übertrifft die Anforderungen. Sie zeigt ein tiefes Verständnis des Themas und/oder besondere Kreativität oder Eigeninitiative.

Was braucht es typischerweise für 3 Punkte?

Begründete Entscheidungen (warum diese Lösung, welche Alternative?)
Konkrete Nachweise (Testfälle, Edge-Cases, Debugging-Fix)
Sauberer, passender Codeauszug mit kurzer Einordnung (nicht einfach reinkopiert)
Reflexion + Transfer (wie wiederverwenden? was verbessern?)

Total sind 15 Kompetenzfelder zu belegen. Jeder Beleg gibt maximal 3 Punkte, womit das Total bei 45 Punkten liegt. Das Praxisprojekt (Flask-Applikation) gibt 10 Punkte. Maximum: 55 Punkte.

Die Note berechnet sich als Note = 1 + 5 × Punkte / 55.