Bewertungsraster Arduino-Projekt: Abgabeformular und Portfolio

Wenn du ein Arduino-Projekt nur mit der Frage „Funktioniert es?“ bewertest, bekommt am Ende vielleicht jemand, der den Code vom Nachbarn kopiert hat, dieselbe Note wie jemand, der die Schaltung dreimal neu gesteckt und den Fehler selbst gefunden hat. Ein faireres Bewertungsraster für Arduino-Projekte schaut auf fünf Dimensionen: die Schaltung (richtig und ordentlich aufgebaut?), den Code (kann die Schülerin oder der Schüler etwas gezielt ändern?), das Verständnis (kann sie oder er eine Zeile erklären, die du auswählst?), den Prozess der Fehlersuche (was passierte, als es nicht lief?) und Dokumentation und Präsentation (kann sie oder er zeigen, was gemacht wurde?). Schaltung, Code und Dokumentation messen das Produkt, Verständnis und Fehlersuche den Prozess. Kommt mehr als die Hälfte der Note aus dem Prozess, verstecken die Lernenden ihre Fehler nicht mehr, sondern erklären sie.

Dieser Beitrag ist ein Vorlagenset, das du morgen mit in den Unterricht nehmen kannst: ein Hauptraster mit 6 Kriterien und 4 Stufen, eine Gewichtung, ein einseitiges Abgabeformular, eine 40-minütige Abgabestunde, eine 5-Minuten-Checkliste für den Tisch, Bögen zur Selbst- und Peer-Bewertung, ein Portfolio für das Halbjahr und eine Schritt-für-Schritt-Notenberechnung für eine Person. Die Beispiele gehen von einer angenommenen Klasse mit 24 Lernenden in Dreiergruppen aus. Wenn du für die schnelle Beobachtung in wöchentlichen Stunden eine kürzere Tabelle mit 3 Stufen suchst, nimm das Raster aus dem 8-Wochen-Unterrichtsplan für Robotik und Programmieren; das Set hier ist für die Note am Ende eines Projekts gedacht.

Warum „Funktioniert es?“ nicht reicht: 5 Dimensionen

Bei Arduino-Projekten liegen Produkt und Lernen nicht immer an derselben Stelle. Eine Ampel, deren LEDs brav nacheinander leuchten, kann bedeuten, dass der Code hochgeladen wurde, ohne ihn je zu lesen. Ein Nachtlicht, das nie angeht, kann dagegen der Versuch sein, bei dem jemand den Sensorwert im seriellen Monitor gemessen und einen schlecht gewählten Schwellwert gefunden hat, also genau das Ziel der Stunde erreicht hat. Deshalb hilft es, das Raster in zwei Familien zu teilen. Auf der Produktseite schaust du auf Schaltung, Code und abgegebene Unterlagen; diese Belege liegen auf dem Tisch, auf Papier und im Foto. Auf der Prozessseite schaust du darauf, wie jemand spricht und welchen Weg er bei der Fehlersuche geht; das siehst du nur durch Fragen und Beobachten. Die Tabelle fasst zusammen, worauf du in jeder Dimension achtest und woher der Beleg kommt.

Das Hauptraster: 6 Kriterien, 4 Stufen und Gewichtung

Zu den fünf Dimensionen kommt ein sechstes Kriterium: Arbeitsweise, Sicherheit und Zusammenarbeit. Im Arduino-Unterricht mit Gruppen gehört es ebenfalls zum Lernen, ob jemand bei eingestecktem USB-Kabel Drähte umsteckt oder seine Rolle liegen lässt. Jede Stufe ist als beobachtbares Verhalten formuliert; statt deutungsoffener Wörter wie „versteht gut“ stehen dort Dinge, die du am Tisch sehen kannst, etwa „erklärt die gewählte Zeile richtig und sagt, was bei einer Änderung passiert“. Um jemanden einer Stufe zuzuordnen, reicht es, das Verhalten aus dieser Zelle einmal gesehen zu haben. Schwankst du zwischen zwei Stufen, notiere die niedrigere mit einer kurzen Bemerkung; beim nächsten Projekt schaust du zuerst darauf.

Die Gewichtung ist bewusst gewählt: 45 % der Note kommen aus dem Produkt (Schaltung, Code, Dokumentation), 55 % aus dem Prozess (Verständnis, Fehlersuche, Arbeitsweise). Das Verständnis wiegt am meisten, weil in einem Unterricht, in dem Code leicht kopiert werden kann, die eigene Erklärung am verlässlichsten zeigt, was wirklich gelernt wurde. Bei den ersten Projekten kannst du den Schaltungsaufbau auf 25 % anheben und den Code auf 10 % senken; in den ersten Wochen wird ohnehin meist fertiger Code hochgeladen. In der zweiten Hälfte des Halbjahres, wenn die Lernenden zwei Projekte verbinden oder eigene Verhaltensweisen ergänzen, ist es sinnvoller, den Code auf 20 % zu erhöhen und die Schaltung auf 15 % zu senken. Die Summe bleibt immer 100, und die Gewichtung teilst du vor Projektbeginn mit; wer weiß, was Punkte bringt, füllt auch das Abgabeformular sorgfältiger aus.

Vorlage: Abgabeformular für das Projekt

Das Abgabeformular hat eine Seite, und die Gruppe füllt es aus, bevor sie das Projekt vorführt. Es soll kein schöner Bericht sein, sondern die Belege für das Raster an einer Stelle sammeln: Teileliste und Verbindungstabelle belegen die Schaltung, die geänderte Zeile den Code, Fehler und Lösung die Fehlersuche, Foto und Video die Dokumentation. Die letzte Zeile „Was macht diese Zeile?“ füllst du selbst aus. Das Beispiel unten ist das Formular einer angenommenen Gruppe, die das kostenlose BlueGrays-Projekt Nachtlicht mit LDR gebaut hat. Die Teileliste stammt aus dem Abschnitt Benötigte Bauteile des Projekts, die Verbindungen aus dem Schaltplan. Leere beim Kopieren die dritte Spalte.

Die Stärke der Frage „Was macht diese Zeile?“ liegt darin, dass sie selbst bei kopiertem Code zeigt, was wirklich verstanden wurde. Wähle für jedes Gruppenmitglied eine andere Zeile und schreib die Antwort in die letzte Zeile des Formulars. Eine gute Zeile verändert das Verhalten des Programms: ein pinMode(), ein analogRead() oder digitalRead(), eine if-Bedingung, ein delay(). Nimm keine geschweifte Klammer und keine Leerzeile. Frag in zwei Schritten: zuerst „Was macht diese Zeile?“, dann „Was passiert, wenn du die 13 in dieser Zeile zu 12 machst?“ Wer die zweite Frage richtig beantwortet, landet beim Verständnis auf Stufe 3; wer den ganzen Programmablauf erklären kann, auf Stufe 4. Bei fertigen Projekten helfen dir die Erklärungen unter Schritt für Schritt im Tab Code verstehen, die Kernzeilen des Programms schnell zu finden. Wie man diesen Tab aus Sicht der Lernenden liest, steht im Beitrag Code verstehen und Probier es selbst.

Abgabestunde: 8 Gruppen in 40 Minuten bewerten

5-Minuten-Checkliste am Tisch

Druck diese Liste auf A4 und nimm für jede Gruppe ein Exemplar. Die Reihenfolge ist Absicht: zuerst Strom und Schaltung, dann Code, zum Schluss die mündlichen Fragen. Funktioniert das Projekt nicht, brich die Liste nicht ab; die restlichen Punkte sammeln Belege für das Kriterium Fehlersuche. Plane höchstens 5 Minuten pro Gruppe ein; nach einigen Abgaben dauern die meisten Kontrollen 4 Minuten.

• Strom: Das Board wird über USB versorgt, die Power-LED auf dem Board leuchtet.
• Gemeinsames GND: Die Minusschiene des Breadboards ist mit dem GND-Pin des Arduino verbunden; Sensor und LED hängen an derselben Schiene.
• Bauteile: Die LED sitzt richtig herum (langes Bein auf der Plusseite), vor jeder LED ist ein Widerstand, die Widerstandswerte stimmen mit dem Formular überein.
• Abgleich mit dem Schaltplan: Die verwendeten Pins sind genau dieselben wie in der Verbindungstabelle des Abgabeformulars.
• Code: Der Code auf dem Board enthält die Änderung aus dem Formular; bist du unsicher, lass die Gruppe ihn noch einmal hochladen.
• Verhalten: Das Projekt tut, was es soll; wenn nicht, kann die Gruppe den Grund nennen oder sagen, welchen Schritt sie gerade prüft.
• Änderung live zeigen: Die Gruppe setzt den geänderten Wert auf den alten zurück und zeigt den Unterschied.
• Was macht diese Zeile? Jedem Mitglied wurde eine andere Zeile gestellt, die Antwort steht im Formular.
• Fehlerprotokoll: Für dieses Projekt gibt es mindestens einen Eintrag: Symptom, Versuche, Lösung.
• Beleg: Es gibt ein scharfes Foto der Schaltung von oben und ein Video mit 10–20 Sekunden, in dem sie läuft.

Bogen zur Selbstbewertung

Mit dem Selbstbewertungsbogen geben die Lernenden ihrem eigenen Lernen einen Namen, und du bekommst einen zweiten Blick, den du mit deinem Raster vergleichen kannst. Jede Person füllt ihn allein aus, es ist kein Gruppenbogen. Die letzte Spalte ist die wichtigste: Wer „Ja“ ankreuzt, schreibt einen Beleg dazu. Die Selbstbewertung fließt nicht in die Note ein; liegen deine Stufe und das Kreuz aber zwei Stufen auseinander, ist das ein guter Anlass für ein einminütiges Gespräch. Manchmal schätzen sich Lernende zu niedrig ein, manchmal erinnern sie sich an einen Moment, den du nicht gesehen hast.

Bogen zur Peer-Bewertung

Der Peer-Bogen wird ausgefüllt, während die Gruppen gegenseitig ihre Projekte ausprobieren. Leg die Regel vorher fest: keine Punkte, nur Beobachtungen und Vorschläge. Wenn Lernende sich gegenseitig benoten, ist das weder fair noch gut für die Stimmung in der Klasse; die Struktur „zwei Dinge, die mir gefallen, ein Vorschlag“ zeigt dagegen, wie gutes Feedback geht. Die Qualität des geschriebenen Vorschlags kannst du, wenn du willst, als Beleg für die Zusammenarbeit nutzen. Gib den ausgefüllten Bogen der Gruppe zurück, der das Projekt gehört; er wandert in ihr Portfolio.

Portfolio: was über das Halbjahr gesammelt wird

Ein Portfolio erzählt die Geschichte des Halbjahres, nicht eines einzelnen Projekts. Legst du am Ende das Abgabeformular des ersten LED-Projekts neben das des letzten Projekts, zeigt das die Entwicklung besser als jede einzelne Zahl. Ob auf Papier oder digital, ist egal; wichtig ist, dass in jedem Projekt dieselben Teile mit derselben Benennung dazukommen. Für ein digitales Portfolio reicht der Cloud-Ordner oder die Lernplattform, die deine Schule ohnehin nutzt: ein Ordner pro Person, ein Unterordner pro Projekt, Dateinamen beginnen mit Projektnummer, Projektname und Version. Für die Papierversion genügt ein Ringordner mit einem Trennblatt pro Projekt.

Der wertvollste Teil des Portfolios ist das Fehlerprotokoll, denn dort liegt der Beleg für das Kriterium Fehlersuche. Jede Zeile beantwortet sechs Fragen: Datum und Projekt, Symptom (was ist passiert?), erste Vermutung, Versuche (der Reihe nach), tatsächliche Ursache und was ich beim nächsten Mal mache. Eine Beispielzeile: „12. November, Nachtlicht mit LDR; LED geht nie an; Vermutung: LED verkehrt herum; LED umgedreht, keine Änderung, Wert im seriellen Monitor ausgegeben; Ursache: Schwellwert 50 war für das Licht im Klassenraum zu niedrig; nächstes Mal messe ich zuerst den Sensorwert.“ Ein Protokoll mit 10–15 Zeilen im Halbjahr zeigt, welche Fehler jemand nicht mehr macht. Lass auch Kompilierfehler eintragen; die häufigsten finden die Lernenden im Beitrag über Arduino-Kompilierfehler, das Auslesen von Sensorwerten im Beitrag seriellen Monitor nutzen.

Daten aus der App: was BlueGrays liefert und was nicht

Wenn deine Lernenden BlueGrays auf ihren eigenen Handys nutzen, liefern einige Bereiche der App kleine, aber brauchbare Belege für die Bewertung. Allen gemeinsam ist, dass die Lernenden dir die Information auf ihrem eigenen Bildschirm zeigen; die App schickt sie nicht gesondert an die Lehrkraft. Nutze sie deshalb nicht allein als Note, sondern als Beleg, der ein Gespräch eröffnet und das Portfolio ergänzt.

• Gebaut: Wer ein Projekt beendet, tippt auf der Projektseite auf diese Kachel, und das Projekt landet unter Werkstatt > Abgeschlossene Projekte. Bitte bei der Portfoliokontrolle darum, diese Liste zu öffnen; so entsteht ein schnelles Verzeichnis der Projekte im Halbjahr. Das Markieren ist ein einziger Tipp, also eine Aussage und kein Beweis: Such für jedes Projekt auf der Liste ein Abgabeformular oder ein Foto im Portfolio.
• Mündliche Kontrolle mit Probier es selbst: Die Aufgabe Probier es selbst am Ende des Tabs Code verstehen geht einen Schritt weiter als „Was macht diese Zeile?“. Lies die Aufgabe laut vor und bitte darum, ohne Blick aufs Handy zu sagen, welche Zeile wie geändert wird; danach wird die Änderung umgesetzt und hochgeladen. Vereinbart vorher, dass offen gesagt wird, ob Tipp oder Lösung anzeigen genutzt wurde: mit Tipp gelöst kann beim Verständnis Stufe 3 sein, ohne Tipp gelöst und begründet Stufe 4.
• Wenn du nicht weiterkommst und Fehlerbehebung: Eine Gruppe, die den Abschnitt Wenn du nicht weiterkommst in Code verstehen oder, falls vorhanden, die Liste Fehlerbehebung des Projekts der Reihe nach durchgeht, zeigt bei der Fehlersuche eine Methode. Frag, bei welchem Punkt sie den Fehler gefunden hat, und lass es ins Fehlerprotokoll schreiben.
• Fragen des Tages und Mein Level: Das täglich neue Fragenset, die XP und die Level von A1 Erstes Licht bis C2 Werkstattmeister halten die Lernenden zwischen den Stunden mit Elektronik beschäftigt, aber mach daraus keine Note. Die Fragen werden zu Hause und allein gelöst, das Level sinkt nie, und das Ergebnis hängt davon ab, wie viel Zeit jemand hat. Nutze sie zur Motivation: Wer möchte, teilt am Ende der Woche sein neues Level mit der Klasse, niemand wird dazu verpflichtet.

Beispiel für die Notenberechnung: die Punktzahl einer Person

Angenommen, Mia ist in der Gruppe mit dem Projekt Nachtlicht mit LDR für das Code-Lesen zuständig. Deine Beobachtungen aus der Abgabestunde: hat die Schaltung nach Schaltplan fehlerfrei aufgebaut (Schaltung 3); hat den Schwellwert geändert, aber kein neues Verhalten ergänzt (Code 2); hat die if-Zeile erklärt, gesagt, dass die LED bei einem Schwellwert von 600 statt 300 schon bei weniger Dunkelheit angeht, und den ganzen Programmablauf erklärt (Verständnis 4); hat vorgeschlagen, den Wert im seriellen Monitor auszugeben, als die LED nicht anging, und es ins Protokoll geschrieben (Fehlersuche 3); im Abgabeformular war ein Foto, aber die Verbindungstabelle fehlte (Dokumentation 2); hat die Rolle erfüllt und der Nachbargruppe geholfen (Arbeitsweise 4). Es gibt zwei Wege zur Punktzahl. Bei der linearen Methode zählt jedes Kriterium Stufe geteilt durch 4 mal Gewicht. Bei der weichen Umrechnung zählen die Stufen als 1 = 50 %, 2 = 70 %, 3 = 85 %, 4 = 100 %; so bekommt jemand, der angefangen hat, aber kämpfen musste, in keinem Kriterium fast null Punkte.

Mia kommt mit der linearen Methode auf 77,5 von 100 Punkten, gerundet 78; mit der weichen Umrechnung auf 86,5, also 87. Welche Methode du auch wählst, nutze das ganze Halbjahr dieselbe, erkläre sie vor dem ersten Projekt und rechne den Prozentwert dann in eure Notenskala um. Die Tabelle liefert mehr als eine Zahl, sie zeigt auch den nächsten Schritt: Mias zwei schwächste Kriterien sind Code und Dokumentation. Beim nächsten Projekt kannst du als Ziel setzen, ein neues Verhalten zu ergänzen (zum Beispiel bei Dunkelheit zusätzlich zur LED einen kurzen Summerton) und die Verbindungstabelle selbst zu erstellen. Trägst du Gewichtung und Umrechnung in eine Tabellenkalkulation ein, erscheinen die Punkte aller 24 Lernenden, sobald du die Stufen eingibst.

Faire Bewertung: Gruppenarbeit, Schaltungen, die nicht laufen, kopierter Code

• Einzelleistung in der Gruppe: Produktkriterien (Schaltung, Code, Dokumentation) können der Gruppe gemeinsam gegeben werden, Prozesskriterien (Verständnis, Fehlersuche, Arbeitsweise) sind immer individuell. Wenn du jedem Mitglied mit „Was macht diese Zeile?“ eine andere Zeile stellst, ergibt sich diese Trennung von selbst. Wechsle die Rollen (Aufbau, Kontrolle, Code-Lesen) bei jedem Projekt, damit am Ende des Halbjahres alle jede Rolle mindestens einmal hatten.
• Schaltung, die nicht läuft: Funktioniert das Projekt bei der Abgabe nicht, gib bei der Schaltung höchstens 2, senke aber die Prozesskriterien nicht. Wer systematisch gesucht, protokolliert und erklären kann, wo es hakt, kann bei der Fehlersuche 3 oder 4 bekommen. Wenn du willst, gib bis zur nächsten Stunde eine Chance zur Korrektur und bewerte die Schaltung neu.
• Kopierter oder fertiger Code: Von einem fertigen Projekt auszugehen ist kein Abschreiben; im Unterricht wird ohnehin mit fertigem Code gearbeitet. Entscheidend ist, was mit dem Code gemacht wurde. Da das Kriterium Code auf die Änderung und das Kriterium Verständnis auf die Erklärung schaut, bleibt Code, der von einer anderen Gruppe stammt, aber nicht verstanden wurde, in diesen beiden Zeilen von selbst niedrig. Die Zeile „Von welchem Projekt bin ich ausgegangen?“ macht es zur Gewohnheit, die Quelle zu nennen statt sie zu verstecken.
• Code aus dem Chatbot: Bei Projekten, die zu Hause entstehen, kann der Code mit einem KI-Werkzeug geschrieben worden sein. Statt es zu verbieten, verstärke bei der Abgabe die mündliche Kontrolle: Punkte bekommt, wer den Code erklären und ändern kann, nicht wer ihn geschrieben hat.
• Defekte Teile und Fehlzeiten: Ist der Sensor einer Gruppe defekt oder fehlt jemand am Abgabetag, füll das Raster an diesem Tag nicht aus; ergänze es in der nächsten Stunde mit einer kurzen Kontrolle am Tisch. Ein Problem durch das Material darf nicht in die Note einfließen.
• Alle kennen dieselbe Tabelle: Lies das Raster vor dem ersten Projekt gemeinsam mit der Klasse und zeig für jede Stufe ein Beispiel. Wer die Stufenbeschreibungen kennt, fragt nach, was für die nächste Stufe nötig ist, statt über die Note zu streiten.

Für den ersten Einsatz des Rasters musst du nicht auf ein großes Projekt warten: Beginne mit einem Projekt für eine Stunde wie Nachtlicht mit LDR oder Ampel, nutze Abgabeformular und Checkliste einmal und passe danach die Gewichtung an deine Klasse an. Steht die Bewertung am Ende eines längeren Programms, passt die Vorlage für die 3-minütige Präsentation aus dem Beitrag zum 5-tägigen Arduino-Workshop gut zu diesen Bögen. Öffnen deine Lernenden die Projekte in BlueGrays, sind Teileliste, Schaltplan und die Schritte in Code verstehen, aus denen die Frage „Was macht diese Zeile?“ schöpft, schon da; du kannst mit 60 kostenlosen Projekten starten, 20 pro Plattform, und wenn du zu Premium-Projekten wechselst, verteilst du Codes aus einmal bezahlten, sich nicht verlängernden Paketen mit 5 oder 10 Codes unter Profil > Lehrer-Pakete, statt dass jede Person ein eigenes Abo abschließt.