Merge branch 'main' into melo-patch-1
This commit is contained in:
commit
bf284c6251
7 changed files with 700 additions and 0 deletions
84
sitzung-03.md
Normal file
84
sitzung-03.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
# Sitzung 3
|
||||
## Objects First vs. Objects Later
|
||||
|
||||
📅 28.04.2026 | 🔗 [Aufgabenstellung](https://franke-lab.de/lehre/sose/fadiinf/u3.html)
|
||||
|
||||
---
|
||||
|
||||
## Caglar, Melisa
|
||||
|
||||
### Aufgabe 1a: Was ist Objektorientierung?
|
||||
*Beschreiben Sie die Auto-Klasse in eigenen Worten — ohne Programmierbegriffe:*
|
||||
- Was ist `Auto`? allgemeine Beschreibung für ein Auto mit bestimmten Eigenschaften (Marke, Modell, Farbe).
|
||||
- Was ist `mein_auto`? mein_auto ist ein ganz bestimmtes Auto mit bestimmten Eigenschaften, nämlich ein VW Golf in blau;
|
||||
- Was macht `info()`? eine Funktion, welches ein Auto mit den zugehörigen gespeicherten Angaben/Eigenschaften (Marke, Modell, Farbe) auf dem Bildschirm ausgibt
|
||||
|
||||
### Aufgabe 1b: Eigenes Beispiel — Klasse „Schüler:in"
|
||||
*Skizzieren Sie eine ähnliche Klasse mit mind. 3 Eigenschaften und einer Methode:*
|
||||
Code:
|
||||
class Schueler:
|
||||
def __init__(self, name, class, age):
|
||||
self.name = name
|
||||
self.class = class
|
||||
self.age = age
|
||||
|
||||
def info(self):
|
||||
print(self.name, "ist in der" self.class, "und ist", self.age)
|
||||
|
||||
schueler1 = Schueler("Anna", "6a", "11")
|
||||
schueler2 = Schueler("Tom", "7b", "12")
|
||||
|
||||
schueler1.info() # Anna ist in der 6a und ist 11
|
||||
schueler2.info() # Tom ist in der 7b und ist 12
|
||||
|
||||
- Eigenschaft 1:Name
|
||||
- Eigenschaft 2:Klasse
|
||||
- Eigenschaft 3:Alter
|
||||
- Methode:info(self): print(self.name, "ist in der" self.class, "und ist", self.age)
|
||||
|
||||
|
||||
### Aufgabe 2: Objects Later — Diskussion
|
||||
**Vorteile für Lernende ohne Vorkenntnisse:**
|
||||
-Gelernte baut aufeinander auf - erst Grundlagen, dann OOP und Anwendung der gelernten Grundlagen in dem neuen Gebilde
|
||||
|
||||
**Risiken (z. B. fehlende Motivation):**
|
||||
- Wenn man erst Grundkonzepte lernt, fehlt einem danch der Realitätsbezug. Wozu lerne ich das?
|
||||
- Es wird auf einemal kompliziert mit den Klassen und Gefahr Schüler kommen nicht mehr mit (andere Art zu denken bei Objektorientierer Programmierung)
|
||||
|
||||
**Rolle der Motivation in diesem Modell:**
|
||||
- Anfangs Vorhanden -sehr motiviert. Langfristig Motivation sinkt
|
||||
- Motivation kommt wieder, wenn Klassen neu eingeführt werden. Schüler sehen Realitätsbezug und denken sich damit kann man echt coole Sachen machen. Langfristing sinkt hier wieder die Motivation, da es schnell sehr kompliziert wird.
|
||||
|
||||
### Aufgabe 3a: Objects First — implizite Konzepte
|
||||
*Was lernen SuS implizit (ohne explizite Benennung)?*
|
||||
- lernen von Beginn dass OOP Programmierung möglich ist und nehmen diese Denkweise später mit
|
||||
- lernen die Steuerung von Objekten und nicht das schreiben von technischen Anweisungen im Detail
|
||||
|
||||
### Aufgabe 3b: Welche Lernumgebungen folgen Objects First?
|
||||
*z. B. Scratch, TigerJython, Python-in-Pieces …*
|
||||
- Am ehesten folgen Scratch und (in vielen Szenarien) Python-in-Pieces einem Objects‑First‑Ansatz, TigerJython eher weniger.
|
||||
|
||||
### Aufgabe 4: Vergleichstabelle
|
||||
|
||||
| Kriterium | Objects First | Objects Later |
|
||||
|-----------|--------------|---------------|
|
||||
| Einstiegsmotivation | hoch, da sofort was sichtbares funktioniert| Eher mittel: oft sichtbare Ergbnisse erst am Ende|
|
||||
| Verständnis von Syntax |Risiko: Die Objekt-Idee wird verstanden, aber die Schreibweise und Grundprinzipien könnten dabei schwieriger zu erlernen werden | Vorteil: Lernende üben zuerst einfache Grundkonstrukte (Zuweisung, Schleife, Funktion); wenn Objekte kommen, ist die Grundsyntax schon routiniert. |
|
||||
| Transferkompetenz |Vorteil: Wer früh in Objekten denkt kann dieses Modell auf viele Kontexte übertragen, z.B. Spiele, reale Systeme | Man hat Grundkentnisse der Programmierung, aber der Transfer in reale Systeme könnte den Schülern schwerer fallen. Solide Algorithmen- und Strukturkenntnisse erleichtern den Transfer auf andere Sprachen und nicht‑OO‑Kontexte. |
|
||||
| Überforderungsrisiko | eher allgemein geringer | geringer zu Beginn, aber dafür sehr viel höher bei der Umstellung auf Objektdenken |
|
||||
| Eignung für Schulklassen |Besonders geeignet bei motivierten oder leistungsstärkeren Lerngruppen, in Wahlpflichtkursen oder Profilklassen | Gut geeignet für sehr gemischte oder leistungsschwächere Klassen und für enge Zeitbudgets, weil man grundlegende Programmier |
|
||||
|
||||
### Aufgabe 5: Ehlert (2012)
|
||||
1. Fazit der Studie — gibt es einen klaren „Gewinner"?
|
||||
- Ehlert findet keinen eindeutigen „Gewinner“; beide Ansätze haben spezifische Stärken und Schwächen, deren Wirkung stark von Rahmenbedingungen wie Lerngruppe, Vorkenntnissen und Lehrkraft abhängt.
|
||||
|
||||
2. Welche Rahmenbedingungen beeinflussen die Wirksamkeit?
|
||||
- Ehlert betont, dass seine Ergebnisse auf ein sehr spezielles Setting (11. Klasse berufliches Gymnasium, Java, konkrete Lehrkräfte) zugeschnitten sind und daher nicht ohne Weiteres auf andere Schularten oder Altersstufen übertragbar sind. Entscheidend für die Wirksamkeit sind Vorkenntnisse und Leistungsniveau der Lernenden, die Lehrkraft und ihr didaktisches Vorgehen sowie die Organisation und Reihenfolge der Themen, wobei insbesondere leistungsschwächere Schülerinnen und Schüler von einem stufenweisen Einstieg wie OOP‑Later profitieren.
|
||||
|
||||
3. Stimmt das Ergebnis mit Ihrer Einschätzung aus Aufgabe 4 überein?
|
||||
- Meine Einschätzung aus Aufgabe 4 wird im Kern bestätigt: OOP‑First wirkt zwar motivierend, ist aber kognitiv anspruchsvoll und birgt ein höheres Überforderungsrisiko, während OOP‑Later einen systematischeren Aufbau erlaubt und besonders leistungsschwächeren sowie heterogenen Lerngruppen zugutekommt. Überraschend ist vor allem, dass OOP‑Later in vielen objektorientierten Themen im Test signifikant besser abschneidet und OOP‑First auch mit unterstützenden Werkzeugen wie BlueJ die grundlegende Komplexität und Überforderung nicht automatisch auflöst.
|
||||
|
||||
### Persönliches Fazit *(3–5 Sätze)*
|
||||
Für mich zeigt Ehlerts Studie sehr deutlich, dass die Grundintuition vieler Lehrkräfte stimmt. Es gibt keinen „magischen“ Ansatz, der alle Probleme löst, sondern wir müssen genauer auf unsere Lerngruppe schauen. Gerade weil OOP‑Later in vielen OOP‑Themen besser abschneidet, nehme ich für die Schule mit, dass ein behutsamer, gut strukturierter Aufbau (erst grundlegende Kontrollstrukturen, dann Objekte) oft mehr bringt. Vor allem auch bei leistungsschwächeren Schülern, von denen bestimmt paar Schüler in einer Klasse sein werden.
|
||||
|
||||
---
|
||||
252
sitzung-04.md
Normal file
252
sitzung-04.md
Normal file
|
|
@ -0,0 +1,252 @@
|
|||
# Sitzung 4: Didaktische Ansätze zum Programmierenlernen
|
||||
|
||||
## Aufgabe: Entwickeln Sie ein Spiel — didaktisch durchdacht (ca. 60 Min.)
|
||||
Zielgruppe: Klassenstufe 11 (Gymnasium, Wahlfach Informatik)
|
||||
Lernumgebung: Computerraum mit Einzelarbeitsplätzen (1 Gerät pro Schüler*in)
|
||||
Lernvoraussetzungen: Heterogene Gruppe mit unterschiedlicher Programmiererfahrung
|
||||
|
||||
Sie haben verschiedene didaktische Ansätze zum Programmierenlernen kennengelernt. Jetzt wenden Sie diese praktisch an: Sie erstellen mit KI-Unterstützung ein konkretes Spiel, das als Grundlage für Ihren Unterrichtsentwurf dient.
|
||||
|
||||
Bearbeitungsschritte:
|
||||
|
||||
Anforderungen definieren (10 Min.):
|
||||
Versetzen Sie sich in die Rolle der Lehrkraft. Formulieren Sie eine Aufgabenstellung, die Sie Ihren Schülerinnen und Schülern geben würden:
|
||||
Spieltitel und Ziel des Spiels (z. B. Labyrinth, Klickspiel, 2D-Reaktionsspiel)
|
||||
Welche Spielmechanik oder Steuerung enthalten sein soll
|
||||
Welche Programmierelemente die Schüler*innen dabei lernen (z. B. Schleifen, Bedingungen, Events, Kollisionen)
|
||||
|
||||
## Anforderungen an Spiel
|
||||
Aufgabenstellung (für Schüler - Pygame):
|
||||
|
||||
Du programmierst mit Python und der der Bibliothek pygame ein kleines 2D Reaktionsspiel namens „Catch the Target“.
|
||||
- Auf dem Spielfeld bewegt sich ein Ziel Objekt (z. B. ein farbiger Block oder Kreis).
|
||||
- Deine Spielfigur wird mit den Pfeiltasten gesteuert.
|
||||
- Ziel ist es, innerhalb einer vorgegebenen Zeit möglichst viele Ziele zu fangen und Punkte zu sammeln.
|
||||
|
||||
Dein Programm soll mindestens:
|
||||
- Ein Pygame Fenster öffnen (z. B. 800×600 Pixel, Hintergrundfarbe deiner Wahl).
|
||||
- Eine Spielfigur anzeigen (z. B. farbiges Rechteck mit pygame.Rect), deren Position sich mit den Pfeiltasten verändert.
|
||||
- Ein Ziel Objekt anzeigen (ebenfalls z. B. pygame.Rect), das sich automatisch bewegt (waagrecht, senkrecht oder zufällig) und beim Rand abprallt oder die Richtung ändert.
|
||||
- Eine Kollision zwischen Spielfigur und Ziel Objekt erkennen (z. B. mit rect.colliderect(...)).
|
||||
Bei Kollision: Punktestand erhöhen und Ziel Objekt an eine neue zufällige Position setzen.
|
||||
- Eine Zeitbegrenzung (z. B. 30 Sekunden) umsetzen: Nach Ablauf der Zeit endet das Spiel und der erreichte Score wird angezeigt.
|
||||
|
||||
Optionale Erweiterungen für Schnellere:
|
||||
- Mehrere Ziel Objekte mit unterschiedlicher Geschwindigkeit.
|
||||
- „Gefährliche“ Objekte, die Punkte abziehen oder das Spiel vorzeitig beenden.
|
||||
- Anzeige eines Highscores (z. B. in einer Datei speichern und beim Start laden).
|
||||
|
||||
### Programmierelemente, die du verwenden sollst
|
||||
In deinem Pygame Programm sollen folgende Elemente klar erkennbar sein:
|
||||
- **Variablen**
|
||||
Für Positionen (x, y), Geschwindigkeit, Punktestand, Restzeit und Spielzustand (z. B. running = True).
|
||||
- **Schleifen**
|
||||
Eine Hauptspielschleife, z. B.
|
||||
|
||||
python
|
||||
running = True
|
||||
while running:
|
||||
#Events, Logik, Zeichnen
|
||||
|
||||
In dieser Schleife laufen Event Verarbeitung, Spiellogik und Zeichnen ab.
|
||||
|
||||
**Bedingungen (if / elif / else)**
|
||||
- Auswertung der Tastatureingaben (Pfeiltasten, ESC).
|
||||
- Randabfrage für Spielfigur/Ziel Objekte (nicht aus dem Fenster laufen).
|
||||
- Kollisionserkennung mit if player_rect.colliderect(target_rect):.
|
||||
- Überprüfung, ob die Spielzeit abgelaufen ist.
|
||||
|
||||
**Events / Ereignisse**
|
||||
Event Schleife mit for event in pygame.event.get():,
|
||||
Reaktion auf QUIT (Fenster schließen) und KEYDOWN für die Steuerung.
|
||||
|
||||
Arbeitsauftrag in drei Phasen
|
||||
1. Konzeptskizze (ca. 10 Minuten)
|
||||
o Skizziere dein Spielfeld (Fenstergröße, Startposition der Figur, Bewegungsrichtung des Ziels).
|
||||
o Notiere: Wie wird gesteuert? Wann gibt es einen Punkt? Wann ist das Spiel zu Ende?
|
||||
2. Implementierung in Pygame (ca. 60 Minuten)
|
||||
o Installiere pygame (z. B. mit pip install pygame) und binde es dann mit import pygame in das eigene Programm ein.
|
||||
o Starte mit einem minimalen Pygame Grundgerüst: Fenster, Hauptschleife, Event Handling.
|
||||
o Füge zuerst die Spielfigur und ihre Tastatursteuerung hinzu.
|
||||
o Implementiere dann das Ziel Objekt mit automatischer Bewegung und Kollisionserkennung.
|
||||
o Ergänze Score Anzeige (z. B. mit pygame.font) und Zeitbegrenzung.
|
||||
3. Reflexion (Restzeit / Hausaufgabe)
|
||||
o Markiere in deinem Code mindestens eine Schleife und eine Bedingung und kommentiere kurz, warum sie für das Spiel nötig sind.
|
||||
o Schreibe 2–3 Sätze dazu, was dir beim Programmieren mit Pygame geholfen hat (z. B. Rechtecke, Events) und was du beim nächsten Mal anders machen würdest.
|
||||
|
||||
### Code zum Spiel
|
||||
|
||||
import pygame
|
||||
import random
|
||||
import sys
|
||||
|
||||
**Fenstergröße**
|
||||
|
||||
WIDTH = 800
|
||||
HEIGHT = 600
|
||||
|
||||
**Geschwindigkeiten**
|
||||
|
||||
PLAYER_SPEED = 5
|
||||
TARGET_SPEED = 4
|
||||
|
||||
**Spielzeit in Sekunden**
|
||||
|
||||
GAME_DURATION = 30
|
||||
|
||||
pygame.init()
|
||||
screen = pygame.display.set_mode((WIDTH, HEIGHT))
|
||||
pygame.display.set_caption("Catch the Target")
|
||||
clock = pygame.time.Clock()
|
||||
font = pygame.font.Font(None, 36)
|
||||
|
||||
**Spielfigur**
|
||||
|
||||
player_rect = pygame.Rect(50, 50, 50, 50)
|
||||
player_color = (50, 150, 250)
|
||||
|
||||
**Ziel-Objekt**
|
||||
|
||||
target_rect = pygame.Rect(
|
||||
random.randint(100, WIDTH - 100),
|
||||
random.randint(100, HEIGHT - 100),
|
||||
40,
|
||||
40,
|
||||
)
|
||||
target_color = (250, 80, 80)
|
||||
|
||||
target_speed_x = TARGET_SPEED
|
||||
target_speed_y = TARGET_SPEED
|
||||
|
||||
**Spielzustand**
|
||||
score = 0
|
||||
running = True
|
||||
start_ticks = pygame.time.get_ticks()
|
||||
|
||||
def reset_target():
|
||||
global target_rect, target_speed_x, target_speed_y
|
||||
target_rect.x = random.randint(50, WIDTH - target_rect.width - 50)
|
||||
target_rect.y = random.randint(50, HEIGHT - target_rect.height - 50)
|
||||
target_speed_x = random.choice([-TARGET_SPEED, TARGET_SPEED])
|
||||
target_speed_y = random.choice([-TARGET_SPEED, TARGET_SPEED])
|
||||
|
||||
|
||||
while running:
|
||||
# Events / Ereignisse
|
||||
for event in pygame.event.get():
|
||||
if event.type == pygame.QUIT:
|
||||
running = False
|
||||
elif event.type == pygame.KEYDOWN:
|
||||
if event.key == pygame.K_ESCAPE:
|
||||
running = False
|
||||
|
||||
**Tastatureingaben für Bewegung**
|
||||
|
||||
keys = pygame.key.get_pressed()
|
||||
if keys[pygame.K_LEFT]:
|
||||
player_rect.x -= PLAYER_SPEED
|
||||
if keys[pygame.K_RIGHT]:
|
||||
player_rect.x += PLAYER_SPEED
|
||||
if keys[pygame.K_UP]:
|
||||
player_rect.y -= PLAYER_SPEED
|
||||
if keys[pygame.K_DOWN]:
|
||||
player_rect.y += PLAYER_SPEED
|
||||
|
||||
**Randabfrage Spielfigur**
|
||||
|
||||
if player_rect.left < 0:
|
||||
player_rect.left = 0
|
||||
if player_rect.right > WIDTH:
|
||||
player_rect.right = WIDTH
|
||||
if player_rect.top < 0:
|
||||
player_rect.top = 0
|
||||
if player_rect.bottom > HEIGHT:
|
||||
player_rect.bottom = HEIGHT
|
||||
|
||||
**Ziel bewegt sich und prallt am Rand ab**
|
||||
|
||||
target_rect.x += target_speed_x
|
||||
target_rect.y += target_speed_y
|
||||
|
||||
if target_rect.left < 0 or target_rect.right > WIDTH:
|
||||
target_speed_x = -target_speed_x
|
||||
if target_rect.top < 0 or target_rect.bottom > HEIGHT:
|
||||
target_speed_y = -target_speed_y
|
||||
|
||||
**Kollisionserkennung**
|
||||
|
||||
if player_rect.colliderect(target_rect):
|
||||
score += 1
|
||||
reset_target()
|
||||
|
||||
**Zeitbegrenzung prüfen**
|
||||
seconds_passed = (pygame.time.get_ticks() - start_ticks) / 1000
|
||||
time_left = max(0, GAME_DURATION - int(seconds_passed))
|
||||
game_over = time_left <= 0
|
||||
|
||||
**Bildschirm zeichnen**
|
||||
screen.fill((30, 30, 40))
|
||||
pygame.draw.rect(screen, player_color, player_rect)
|
||||
pygame.draw.rect(screen, target_color, target_rect)
|
||||
|
||||
score_text = font.render(f"Punkte: {score}", True, (255, 255, 255))
|
||||
time_text = font.render(f"Zeit: {time_left}s", True, (255, 255, 255))
|
||||
screen.blit(score_text, (20, 20))
|
||||
screen.blit(time_text, (20, 60))
|
||||
|
||||
if game_over:
|
||||
end_text = font.render("Zeit abgelaufen! Spielende.", True, (255, 255, 0))
|
||||
final_text = font.render(f"Gesamtpunkte: {score}", True, (255, 255, 255))
|
||||
restart_text = font.render("Drücke ESC oder schließe das Fenster.", True, (200, 200, 200))
|
||||
screen.blit(end_text, (180, 250))
|
||||
screen.blit(final_text, (260, 300))
|
||||
screen.blit(restart_text, (180, 350))
|
||||
|
||||
pygame.display.flip()
|
||||
clock.tick(60)
|
||||
|
||||
if game_over:
|
||||
# Warten, bis der Spieler das Fenster schließt oder ESC drückt
|
||||
while True:
|
||||
for event in pygame.event.get():
|
||||
if event.type == pygame.QUIT:
|
||||
running = False
|
||||
break
|
||||
elif event.type == pygame.KEYDOWN and event.key == pygame.K_ESCAPE:
|
||||
running = False
|
||||
break
|
||||
if not running:
|
||||
break
|
||||
clock.tick(10)
|
||||
|
||||
pygame.quit()
|
||||
sys.exit()
|
||||
|
||||
## Code analysieren
|
||||
|
||||
**Erkennbare Programmierkonzepte**
|
||||
- Im Code stecken viele grundlegende Programmierkonzepte: Variablen (z.B. WIDTH, score, target_speed_x), eine Schleife für den Spielablauf (while running:), eine Funktion (reset_target()), einfache Datenstrukturen/Objekte (pygame.Rect) sowie Ereignisbehandlung und Bedingungen.
|
||||
|
||||
**Ist der Code für Schüler*innen verständlich? Was würde überfordern?**
|
||||
- Für viele Schüler*innen (v.a. Sek I / frühe Sek II) ist der Code in dieser Form zu komplex: Es kommen auf einmal sehr viele neue Dinge zusammen (externes Modul pygame, Ereignisschleife, Koordinatensystem, Kollision, Zeitmessung, verschachtelte Bedingungen, global in der Funktion), und es ist schwer, die Spielidee vom technischen „Drumherum“ zu trennen.
|
||||
- Aber Einzelne Teile des Codes mit z.B. If-Bedinungen kann man gut vorzeigen und den Schülern verständlich erklären, ohne das es zu Verwirrungen kommt
|
||||
|
||||
**Wie könnte man den Code vereinfachen oder in Teilschritte zerlegen?**
|
||||
- Schrittweiser Aufbau in Unterrichtsphasen
|
||||
- Struktur klarer machen: Den Code in logisch benannte Funktionen aufteilen, z.B. handle_events(), update_game(), draw_screen(), check_collision().
|
||||
- Komplexität reduzieren: Für eine erste Version auf Zeitmessung verzichten (kein GAME_DURATION, keine time_left‑Berechnung).
|
||||
|
||||
### Didaktischen Ansatz wählen und begründen
|
||||
|
||||
- Ich würde eine Kombination aus Spiralansatz und Live‑Coding wählen
|
||||
- Inhaltlich würde ich das Spiel schrittweise ausbauen: Version 1 nur bewegen, Version 2 mit Ziel, Version 3 mit Punkten, Version 4 mit Zeitlimit. Bei Bedarf Live Coding Sessions zu paar Bereichen machen. Dann SuS selber programmieren lassen oder Übungen dazu machen oder Teile weglassen als Vervollständigungsaufgabe.
|
||||
- So werden sie Schrittweise mit Hilfestellung herangeführt und die Komplexität wird Schrittweise gesteigert.
|
||||
- Als Einstieg eignen sich: Die IF-Bedinungen für key oder player
|
||||
|
||||
### Reflexion
|
||||
|
||||
- Bei meinem Ansatz (Spiralansatz + Live‑Coding mit dem Catch‑Spiel) sehe ich vor allem Schwierigkeiten, wenn mehrere neue Ideen gleichzeitig zusammenkommen: Einige Schüler*innen werden zwar die einzelnen Versionen verstehen (z.B. nur Bewegung oder nur Kollision), aber Mühe haben, später das Gesamtprogramm geistig zu überblicken und die Verbindung zwischen den Teilen (Ereignisse, Spiellogik, Zeichnen) zu erkennen.
|
||||
- Sinnvoll sind deshalb gut strukturierte Kommentierung und Hilfestellungen, etwa klar abgegrenzte Code‑Blöcke mit kurzen Überschriften („Eingaben“, „Bewegung“, „Punkte“, „Zeit“) sowie kleine Hinweis‑Karten oder Musterlösungen zu typischen Problemen, und außerdem Partnerarbeit
|
||||
- Die KI‑Unterstützung hat meinen eigenen Arbeitsprozess deutlich erleichtert, weil sie mir schnell Formulierungen, Strukturvorschläge und didaktische Perspektiven geliefert hat; für den Unterricht heißt das aus meiner Sicht, dass KI ein hilfreiches Werkzeug für Planung, Materialerstellung und auch für Schüler*innen beim Erklären und Umformulieren von Code sein kann – aber ich muss bewusst Lernphasen einplanen, in denen die Klasse ohne KI‑„Abkürzungen“ lesen, verstehen und selbst denken muss, damit zentrale Programmierkompetenzen nicht an das Tool delegiert werden.
|
||||
|
||||
|
||||
122
sitzung-05.md
Normal file
122
sitzung-05.md
Normal file
|
|
@ -0,0 +1,122 @@
|
|||
# Gamification
|
||||
|
||||
## Videoeinstieg – Spielelemente im Informatikunterricht
|
||||
|
||||
### Möglichkeiten des Einsatzes:
|
||||
- Klassische Gamification im Unterricht: Punkte, Badges, Level, Ranglisten zur Begleitung von Übungen, Hausaufgaben oder Verhalten.
|
||||
- Game-based Learning: komplette Spiele als Lernumgebung (z. B. CodeCombat, Minecraft‑Edu) für Themen wie Programmieren, Logik, Problemlösen.
|
||||
- Serious Games: speziell entwickelte Lernspiele zu Informatikthemen (z. B. IT‑Sicherheit, Datenschutz, Algorithmen).
|
||||
- RPG‑basiertes Klassenmanagement: Klassen werden in Teams/„Gilden“ organisiert, erhalten Quests, XP und kooperative Herausforderungen (z. B. TeachQuest / früher Classcraft).
|
||||
- Gamifizierte Online‑Plattformen: Quizsysteme, Lernportale und Programmierumgebungen mit Leveln, Fortschrittsbalken, Erfolgsfeedback und Belohnungen (Kahoot, Blooket, Khan Academy, CheckiO, CodeCombat).
|
||||
|
||||
### Argumente für spielerisches Lernen:
|
||||
- Klare Ziele, Regeln, Feedback und Herausforderungen sind zentrale Elemente guter Spiele und zugleich gute didaktische Prinzipien; sie unterstützen Orientierung und Struktur.
|
||||
- Echtzeit‑Feedback, Fortschrittsanzeigen und Erfolgserlebnisse fördern Selbstwirksamkeit und Motivation, besonders bei wiederholtem Üben (z. B. Programmieraufgaben).
|
||||
- Entscheidungsfreiheit und alternative Lösungswege erlauben exploratives, kreatives Lernen und können Flow‑Erleben begünstigen.
|
||||
- Spiele sprechen die Lebenswelt der Lernenden an und können Zugang zu abstrakten Informatikinhalten erleichtern (z. B. Schleifen/Bedigungen in CodeCombat).
|
||||
|
||||
## TeachQuest erkunden
|
||||
|
||||
Funktionsumfang
|
||||
- Charakterklassen mit unterschiedlichen Rollen (z. B. Defender, Wizard, Healer, Augmentor).
|
||||
- Erfahrungspunkte (XP) und Levelaufstieg für Schüler:innen; Belohnungssystem für positives Verhalten und erledigte Aufgaben.
|
||||
- Quests (individuelle Aufgaben) und Raids (Team‑Challenges) mit Story‑Rahmen.
|
||||
- „Gold“ oder ähnliche Währung für In‑Game‑Belohnungen, Ausrüstung, Vorteile.
|
||||
- Lehrkraft‑Dashboard zur Verwaltung von Teams, Punkten, Quests und Ereignissen im Unterricht.
|
||||
|
||||
Einsatzszenarien
|
||||
- Langfristiges Klassenmanagement (z. B. über ein Halbjahr) zur Förderung von Zusammenarbeit, Arbeitsverhalten und sozialem Klima.
|
||||
- Projektarbeit/ Projektphasen, Teamentwicklung
|
||||
- Nicht ideal für kurze, prüfungsnahe Phasen
|
||||
|
||||
Schwierigkeiten
|
||||
- Technik: Geräte, WLAN, Ausfälle
|
||||
- Ablenkung durch Punkte/Avatare
|
||||
- Fairness/Ausgrenzung, Rollenfixierung
|
||||
- Datenschutz/Serverstandort
|
||||
|
||||
Voraussetzungen
|
||||
- Schule: Infrastruktur, Datenschutzfreigabe
|
||||
- Lehrkraft: Einarbeitung, klare Regeln
|
||||
- Schüler:innen: Medienkompetenz, Akzeptanz
|
||||
|
||||
Vergleich mit Classcraft
|
||||
- Ähnliche Datenschutzrisiken
|
||||
- Gefahr von Ausgrenzung/„Low‑Level“-Schüler:innen (Verliererrollen)
|
||||
- Fokus auf Verhalten, wenig Inhaltsbezug (Fachliche Kompetenz)
|
||||
- Stark extrinsisch motivierendes Belohnungssystem
|
||||
|
||||
## CheckiO – Gamifiziertes Programmieren mit Python
|
||||
|
||||
Gamification-Elemente
|
||||
- Missionen auf „Inseln“, Level‑System
|
||||
- Punkte/Score, Ranglisten/Erfolge
|
||||
- Community‑Lösungen, Classroom‑Funktion
|
||||
|
||||
Zielgruppe / Niveau
|
||||
- Fortgeschrittene Anfänger ab Ende Sek I
|
||||
- Lernende mit Basiswissen in Python (if, Schleifen, Funktionen)
|
||||
|
||||
Einsatz im Unterricht
|
||||
- z. B. Kl. 9, nach Einführung in Python
|
||||
- 2–3 Missionen in Einzel-/Partnerarbeit
|
||||
- anschließend Vergleich von Lösungswegen und Reflexion
|
||||
|
||||
Vergleich mit CodeCombat
|
||||
- CodeCombat: mehr Story, Grafik, RPG; weniger Codetiefe
|
||||
- CheckiO: weniger Story, mehr abstrakte Aufgaben, höhere Codetiefe
|
||||
- CodeCombat: eher jüngere Einsteiger,
|
||||
- CheckiO: eher ältere/fortgeschrittene Lernende, mehr Lösungsfreiheit.
|
||||
|
||||
## Wissenschaftliche Vertiefung - Dissertation Computergestützte Gamifizierung in Sek I
|
||||
|
||||
### Begriff und Wesen von Gamification
|
||||
|
||||
**Gamification** = Integration einzelner Spielelemente in Nicht‑Spiel‑Kontexte, ohne ein vollständiges Spiel zu bauen.
|
||||
Ziel: Motivation, Selbststeuerung und fokussiertes Arbeiten durch klare Ziele, Rückmeldungen, Herausforderungen und Wahlmöglichkeiten.
|
||||
|
||||
Gamification-Kategorien (ab S. 63)
|
||||
- Punkt-/Statussysteme: Punkte, Level, Badges zur Visualisierung von Fortschritt.
|
||||
- Herausforderungen/Missionen: strukturierte Aufgaben mit klaren Zielen und steigender Schwierigkeit.
|
||||
- Story/Setting: narrative Rahmung, Avatare, Rollen, die Identifikation erhöhen.
|
||||
- Feedback-/Belohnungssysteme: unmittelbare Rückmeldungen, Ranglisten, Erfolge.
|
||||
- Sozialmechaniken: Kooperation, Wettkampf, gemeinsame Ziele (Teams, Gruppenquests).
|
||||
|
||||
### Spieltypische Design-Elemente im Bildungskontext (4.3.4)
|
||||
|
||||
- Klar formulierte Ziele und Herausforderungen (Missionen, Quests).
|
||||
- Fortschrittsanzeigen (Level, Balken, Checklisten).
|
||||
- unmittelbares Feedback (z. B. Punkte, Status‑Updates).
|
||||
- Belohnungsstrukturen (Badges, virtuelle Güter, Freischaltungen).
|
||||
- Story, Rollen, Avatare zur Identifikation.
|
||||
- Kooperative und kompetitive Elemente (Teams, Rankings).
|
||||
|
||||
### Kritik an Gamification (3.3.2)
|
||||
|
||||
**Genannte Kritikpunkte bei Stöcklin**
|
||||
- Gefahr rein extrinsischer Motivation (Punktejagd statt inhaltlichem Interesse).
|
||||
- „PBL‑Schale“ (Points–Badges–Leaderboards) ohne echten didaktischen Mehrwert.
|
||||
- Ablenkung: Oberfläche wirkt spielerisch, Inhalte bleiben unverändert/banal.
|
||||
- unklare oder überzogene Erwartungen an Motivationswirkung und Lernerfolg.
|
||||
- mögliche Ungerechtigkeit (Leistungsunterschiede, Rankings, soziale Vergleiche).
|
||||
|
||||
**Meine Pro-/Contra-Sicht für den Informatikunterricht:**
|
||||
|
||||
Pro:
|
||||
- Motiviert zu wiederholtem Üben (z. B. Programmieraufgaben, Debugging).
|
||||
- Visualisiert Fortschritt, unterstützt selbstgesteuertes Arbeiten.
|
||||
- Passt zur digitalen Lebenswelt, kann Einstiegshürden senken.
|
||||
|
||||
Contra:
|
||||
- Risiko, dass Syntax‑„Abfarmsen“ wichtiger wird als Verständnistiefe.
|
||||
- Gefahr einer reinen Belohnungsökonomie, wenn alles „XP“ ist.
|
||||
- Stärkere Schüler profitieren mehr von Rankings, schwächere fühlen sich abgehängt.
|
||||
|
||||
Gamification im Informatikunterricht ist aus meiner Sicht sinnvoll, wenn sie eng an fachliche Lernziele und sinnvolle Aufgaben (z. B. echte Programmierprobleme) gekoppelt ist und Punkte/Boni nur unterstützende Struktur liefern, nicht das eigentliche Lernmotiv ersetzen.
|
||||
|
||||
## Persönliches Fazit
|
||||
|
||||
- Mich überzeugt am meisten CheckiO, weil dort Gamification direkt mit echten Programmieraufgaben verknüpft ist und unterschiedliche Lösungswege sichtbar macht.
|
||||
- Sinnvolle Gamification beginnt für mich dort, wo Punkte, Levels und Storyline Lernprozesse strukturieren und reflektierbar machen; sie wird zur Ablenkung, wenn nur die Oberfläche „bunt“ ist.
|
||||
- Extrinsische Motivation (XP, Badges) kann ein Einstieg sein, sollte aber langfristig in intrinsisches Interesse an Problemlösen und Coden übergehen.
|
||||
- Im Informatikunterricht passt Gamification besonders gut, weil Programmieraufgaben sich leicht in Missionen übersetzen lassen und digitale Tools ohnehin zentral sind.
|
||||
103
sitzung-06.md
Normal file
103
sitzung-06.md
Normal file
|
|
@ -0,0 +1,103 @@
|
|||
# Bildungsplan-Entscheidungen
|
||||
|
||||
## Bundesland, Schulart, Klassenstufe
|
||||
- Bundesland: Baden Württemberg.
|
||||
- Schulart: Gymnasium (Sekundarstufe I).
|
||||
- Klassenstufe: Klasse 7 (oder 8), Fach „Informatik und Medienbildung“ bzw. Informatik-Wahlfach in der Sekundarstufe I.
|
||||
|
||||
**Vorkenntnisse, die Sie annehmen:**
|
||||
- erste Erfahrungen mit Scratch (z. B. in Klasse 5/6 oder im Basiskurs Medienbildung),
|
||||
- einfache Sequenzen, Ereignisse, Grafiken,
|
||||
- grundlegende Vorstellungen von Variablen und Schleifen aus kleineren Übungen.
|
||||
|
||||
### Bezug zum Bildungsplan - adressierte Kompetenzen
|
||||
Im Bildungsplan BW für Informatik/Medienbildung (Sekundarstufe I) werden u. a. diese Kompetenzbereiche für Programmierung genannt:
|
||||
Schülerinnen und Schüler
|
||||
- „entwickeln und analysieren einfache Programme mit einer geeigneten (ggf. visuellen) Programmiersprache“ (Kompetenzbereich Algorithmen / Programmierung).
|
||||
- „verwenden Kontrollstrukturen wie Wiederholungen und Verzweigungen“.
|
||||
- „nutzen Variablen zur Speicherung und Verarbeitung von Daten“.
|
||||
- „strukturieren Programme in sinnvolle Bausteine und dokumentieren sie adressatengerecht“.
|
||||
|
||||
### Stoffverteilungsplan & Einordnung im Schuljahr
|
||||
**Verortung im Schuljahr**
|
||||
- im 2. Halbjahr, nach einer Einführungsphase zu Grundlagen der Programmierung (Sequenzen, Schleifen, Bedingungen) und einer kurzen Einheit zu Daten/Variablen.
|
||||
|
||||
**Dauer der Einheit:**
|
||||
- ca. 6–8 Doppelstunden (je nach Unterrichtsorganisation), verteilt über 4–6 Wochen.
|
||||
|
||||
**Voraussetzungen aus vorherigen Themen:**
|
||||
Schülerinnen und Schüler können
|
||||
- einfache Scratch Programme lesen und verändern,
|
||||
- einfache Ereignis gesteuerte Abläufe (z. B. beim Klicken der Figur) umsetzen,
|
||||
- mit Schleifen (wiederholende Bewegungen, Animationen) experimentieren,
|
||||
- Bedingungen (if / if else) in kleinen Beispielen einsetzen,
|
||||
- einfache Variablen (z. B. Punktestand) anlegen und verändern.
|
||||
|
||||
### Zielformulierung je Stunde (Beispielplan)
|
||||
6 Doppelstunden à 90 Minuten.
|
||||
|
||||
**Stunde 1 – Projektstart & Spielanalyse**
|
||||
- Die Schülerinnen und Schüler können Beispiele von Scratch Spielen analysieren und grundlegende Elemente (Spielfiguren, Steuerung, Ziel, Regeln) beschreiben.
|
||||
- Sie können Anforderungen des Projekts (technische und kreative Kriterien) in eigenen Worten wiedergeben.
|
||||
|
||||
**Stunde 2 – Konzeptentwicklung & Storyboard**
|
||||
- Die Schülerinnen und Schüler können in Zweiergruppen ein eigenes Spielkonzept mit Ziel, Spielfiguren, Steuerung und Schwierigkeitsgrad entwickeln.
|
||||
- Sie können den Ablauf ihres Spiels in einem Storyboard oder Flowchart grafisch darstellen.
|
||||
|
||||
**Stunde 3 – Grundgerüst programmieren**
|
||||
- Die Schülerinnen und Schüler können die wesentlichen Spielfiguren anlegen und mit einfachen Ereignis gesteuerten Sequenzen (z. B. Tastensteuerung) versehen.
|
||||
- Sie können mindestens eine Variable (z. B. Punktestand, Leben) in ihr Spiel integrieren.
|
||||
|
||||
**Stunde 4 – Steuerung, Schleifen, Bedingungen**
|
||||
- Die Schülerinnen und Schüler können Schleifen einsetzen, um wiederkehrende Abläufe (z. B. Bewegung von Gegnern) effizient zu programmieren.
|
||||
- Sie können Bedingungen verwenden, um Spielregeln (z. B. Kollision, Gewinn-/Verlustbedingung) umzusetzen.
|
||||
|
||||
**Stunde 5 – Feinschliff & Debugging**
|
||||
- Die Schülerinnen und Schüler können Fehler im eigenen Spiel finden und beheben (Debugging) und einfache Testprotokolle führen.
|
||||
- Sie können das Benutzerinterface (z. B. Startbildschirm, Instruktionen, Rückmeldungen) zielgruppenorientiert gestalten.
|
||||
|
||||
**Stunde 6 – Präsentation & Reflexion**
|
||||
- Die Schülerinnen und Schüler können ihr Spiel in einer Kurzpräsentation vorstellen und wesentliche Programmierkonzepte (Variablen, Schleifen, Bedingungen) erläutern.
|
||||
- Sie können ihren Entwicklungsprozess reflektieren und Verbesserungsvorschläge formulieren.
|
||||
|
||||
### Wahl der Programmiersprache / Umgebung
|
||||
|
||||
**Entscheidung: Scratch**
|
||||
- Scratch ist eine visuelle Programmiersprache, die speziell für 8 bis 16 Jährige entwickelt wurde und sich besonders für Projekte wie Spiele, Animationen und interaktive Geschichten eignet.
|
||||
- Scratch bietet eine integrierte Entwicklungsumgebung mit visueller Oberfläche (Bühne, Figuren, Blockpalette), wodurch Lernende schnell sichtbare Ergebnisse erzielen und sich stärker auf Konzepte als auf Syntax konzentrieren können.
|
||||
Didaktische Begründung bezogen auf Ihre Zielgruppe:
|
||||
- Klassenstufe 7/8 in BW befindet sich meist in der Phase der ersten systematischen Programmiererfahrungen; Scratch reduziert die Einstiegshürde.
|
||||
- Lernziele (Schleifen, Bedingungen, Variablen, Ereignisse, Objekt artige Sprites) lassen sich direkt und ohne syntaktische Überforderung umsetzen.
|
||||
- Scratch unterstützt kollaboratives Arbeiten und Teilen von Projekten über die Online Plattform, was zur Projektarbeit in Zweiergruppen passt.
|
||||
|
||||
## Anforderungskatalog (technisch & kreativ)
|
||||
|
||||
### Technische Anforderungen
|
||||
Pflichtanforderungen:
|
||||
- **Variablen**: Mindestens 1 Variable (z. B. Punktestand, Leben, Zeit) wird angelegt und sinnvoll im Spielverlauf verändert.
|
||||
- **Schleifen**: Mindestens 1 Schleife (z. B. „wiederhole fortlaufend“, „wiederhole X mal“) steuert eine wiederkehrende Aktion (z. B. Bewegung eines Gegners, Animation).
|
||||
- **Bedingungen:** Mindestens 2 Bedingungen (if/if else), z. B. Kollision Spieler–Gegner, Gewinn- oder Verlustbedingung, Levelwechsel.
|
||||
- **Ereignissteuerung:** Spiel startet durch ein Ereignis (z. B. „wenn grüne Flagge angeklickt“), Figuren reagieren auf Tasteneingaben oder Berührung.
|
||||
- **Mehrere Sprites / „Objekte“:** Mindestens 3 verschiedene Sprites mit jeweils eigenen Skripten (quasi objektorientiert: jedes Sprite kapselt Verhalten).
|
||||
|
||||
**Optionale/Erweiterungsanforderungen (für höhere Leistungsstufen):**
|
||||
- Verwendung von Nachrichten (Broadcasts) zur Koordination zwischen Figuren.
|
||||
- Verwendung von Listen oder fortgeschritteneren Variablenstrukturen.
|
||||
- Ein Levelsystem (z. B. steigendem Schwierigkeitsgrad).
|
||||
|
||||
### Kreative Anforderungen
|
||||
- **Eigenständige Spielidee:** Spiel darf nicht nur eins zu eins aus einem vorhandenen Scratch Projekt kopiert werden; Inspiration ist erlaubt, aber wesentliche Elemente müssen verändert/weiterentwickelt sein.
|
||||
- **Narratives oder thematisches Konzept**: Spiel hat ein klares Ziel (z. B. Einsammeln von Objekten, Ausweichen, Rätsel lösen) und eine in sich stimmige „Spielwelt“.
|
||||
|
||||
**Benutzerfreundlichkeit**
|
||||
- Steuerung ist klar kommuniziert (z. B. Anweisungen im Startbildschirm),
|
||||
- Rückmeldungen für Spieler:innen (Punktestand, Soundeffekte, visuelle Effekte) sind erkennbar.
|
||||
|
||||
### Dokumentation & Darstellung des Spielablaufs
|
||||
- Schriftliche Kurzbeschreibung des Spiels (Ziel, Steuerung, Spielfiguren).
|
||||
- Storyboard oder Flowchart, das die wichtigsten Zustände und Übergänge im Spiel zeigt (z. B. Start, Spiel läuft, Gwin/Verlust, Levelwechsel).
|
||||
- Kommentierte Screenshots oder fotografierte Notizen, die den Entwicklungsprozess dokumentieren.
|
||||
|
||||
|
||||
|
||||
|
||||
84
sitzung-07.md
Normal file
84
sitzung-07.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
# Bewertungsbogen
|
||||
## Programmierprojekt „Eigenes Spiel in Scratch“
|
||||
|
||||
### Übersicht der Kategorien und Gewichtung
|
||||
|
||||
Kategorie | Gewichtung
|
||||
----------|-----------
|
||||
A) Technik & Code | 40 %
|
||||
| B) Kreativität & Spielkonzept | 25 % |
|
||||
C) Dokumentation & Darstellung | 20 % |
|
||||
D) Präsentation & Reflexion | 15 %
|
||||
|
||||
### A) Technik & Code (40%) – Grundstandard + Kür
|
||||
|
||||
| Kriterium | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte (Kür‑Niveau) |
|
||||
|----------------------------------|----------------------------------------|----------------------------------------------|-------------------------------------------------------------------------|--------------------------------------------------------------------------------------|
|
||||
| Variablen | Keine Variable oder fehlerhaft | Variable vorhanden, begrenzt sinnvoll | Mindestens 1 Variable sinnvoll integriert (z. B. Punkte, Leben) | Mehrere Variablen sinnvoll genutzt (z. B. Punkte, Leben, Level) |
|
||||
| Schleifen | Keine Schleife | Schleife vorhanden, aber kaum funktional | Schleife steuert wiederkehrende Aktion (z. B. Bewegung Gegner) | Mehrere Schleifen, effizient eingesetzt (z. B. Muster, Animationen) |
|
||||
| Bedingungen (if / if‑else) | Keine Bedingungen | Bedingungen vorhanden, teils fehlerhaft | Mindestens 2 korrekte Bedingungen (z. B. Kollision, Gewinn) | Vielfältige Bedingungen, die Spielverlauf reichhaltig steuern |
|
||||
| Ereignissteuerung & Spiellogik | Spiel startet nicht zuverlässig | Start/Steuerung teilweise unzuverlässig | Spiel startet zuverlässig, Steuerung meist stabil | Spiellogik robust, wenige Fehler, klar strukturierter Ablauf |
|
||||
| Struktur & Lesbarkeit des Codes | Unübersichtlich, schwer lesbar | Teilweise strukturiert, viele „Lose Enden“ | Skripte überwiegend strukturiert, nachvollziehbar | Sehr gut strukturierte Skripte, ggf. sinnvolle Kommentare, Wiederverwendung von Bausteinen |
|
||||
| Fortgeschrittene Konzepte (Kür) | Keine | – | – | Einsatz fortgeschrittener Konzepte (z. B. Nachrichten, eigene Blöcke, Listen) |
|
||||
|
||||
Die maximale Punktzahl in A) kann auch ohne das letzte (Kür )Kriterium bereits eine gute Note ermöglichen; das Kür Kriterium dient zur Aufwertung besonders anspruchsvoller Projekte.
|
||||
|
||||
### B) Kreativität & Spielkonzept (25%)
|
||||
|
||||
| Kriterium | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte |
|
||||
|--------------------------------|----------------------------------------|------------------------------------------------|-------------------------------------------------|-------------------------------------------------|
|
||||
| Originalität der Spielidee | Weitgehend Copy‑Paste eines Beispiels | Leicht abgewandelte Standardidee | Eigenständige, nachvollziehbare Spielidee | Besonders kreative, stimmige und ggf. thematisch relevante Idee |
|
||||
| Kohärenz von Thema & Mechanik | Unklare oder widersprüchliche Spielwelt| Ansätze von Thema, aber inkonsistent | Thema und Mechanik passen zusammen | Sehr stimmige, atmosphärisch dichte Spielwelt |
|
||||
| Benutzerfreundlichkeit (UX) | Steuerung unklar, kaum Rückmeldungen | Steuerung teilweise verständlich, wenige Hinweise | Steuerung klar kommuniziert, grundlegende Rückmeldungen | Sehr benutzerfreundlich: klare Anleitungen, sinnvolle Rückmeldungen, gute Lesbarkeit |
|
||||
|
||||
### C) Dokumentation & grafische Darstellung (20%)
|
||||
|
||||
| Kriterium | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte |
|
||||
|--------------------------------------|----------------------------------|-------------------------------------------|-------------------------------------------------------------|--------------------------------------------------------------------------------------------|
|
||||
| Schriftliche Spielbeschreibung | Fehlt oder unverständlich | Kurze Beschreibung mit Lücken | Vollständige Beschreibung (Ziel, Steuerung, Figuren) | Sehr ausführliche, verständliche Beschreibung inkl. Zielgruppe, Besonderheiten |
|
||||
| Storyboard / Flowchart des Spielablaufs | Fehlt | Vorhanden, aber unvollständig oder unklar | Zeigt Hauptzustände und Übergänge nachvollbar | Klar strukturiert, deckt tatsächlichen Ablauf ab, ggf. mit Legende |
|
||||
| Entwicklungsdokumentation (Prozess) | Kein Einblick in Prozess | Vereinzelte Notizen, wenig strukturiert | Kurze Prozessdokumentation (z. B. 2–3 Schritte, Probleme, Lösungen) | Differenzierte Prozessdokumentation, Reflexion von Problemen und Lösungswegen |
|
||||
|
||||
### D) Präsentation & Reflexion (15%)
|
||||
|
||||
| Kriterium | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte |
|
||||
|-------------------------------|--------------------------------------|-------------------------------------------------|-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
|
||||
| Klarheit der Präsentation | Unstrukturiert, schwer nachvollziehbar | Grundstruktur erkennbar, aber lückenhaft | Klare Gliederung (Idee, Demo, Technik), verständlich | Sehr klare, adressatengerechte Präsentation mit sicherer Vortragstechnik |
|
||||
| Erläuterung der Programmierkonzepte | Kann zentrale Konzepte nicht erklären | Erläutert Teile, aber mit Unsicherheiten | Erläutert eingesetzte Konzepte (Variablen, Schleifen, Bedingungen) verständlich | Erklärt Konzepte sicher, nutzt Fachbegriffe korrekt, kann Fragen beantworten |
|
||||
| Reflexion des Lernprozesses | Keine Reflexion | Sehr kurze, oberflächliche Reflexion | Reflektiert Stärken, Schwächen und Lernerfahrungen | Tiefe Reflexion inkl. Ideen für Weiterentwicklung und Transfer |
|
||||
|
||||
## Differenzierung in Projekt & Bewertung einbauen
|
||||
### Diagnose: Wie erheben Sie zu Beginn den Lernstand Ihrer Klasse? Skizzieren Sie eine kurze Eingangsaufgabe oder Selbsteinschätzung.
|
||||
|
||||
**Eingangsaufgabe**
|
||||
Die Schülerinnen und Schüler erstellen einzeln ein Scratch Projekt, in dem eine Figur ein Quadrat mit Seitenlänge 50 läuft; sie sollen dazu möglichst wenige Blöcke verwenden.
|
||||
Erweiterung: Wenn die Figur das Quadrat beendet hat, wird eine Variable runden um 1 erhöht.
|
||||
So erkenne ich, ob Schleifen sinnvoll eingesetzt, Variablen korrekt angelegt und verändert werden und wie sicher die Lernenden die Scratch Oberfläche bedienen.
|
||||
|
||||
**Selbsteinschätzung**
|
||||
Ergänzend füllen die Lernenden einen Kurzfragebogen aus (Likert Skala), z. B.: „Ich kann eine Figur mit Pfeiltasten steuern“, „Ich kann Schleifen einsetzen“, „Ich kann Variablen anlegen und verändern“, „Ich habe schon einmal ein Spiel programmiert“.
|
||||
Aus Eingangsaufgabe und Selbsteinschätzung leite ich meine Differenzierungsangebote ab.
|
||||
|
||||
### Pauschale Angebote: Welche Differenzierungsangebote stellen Sie für alle bereit? (z. B. gestufte Hilfekarten, Pflicht-/Küraufgaben, Lerntheke)
|
||||
Ich setze vor allem pauschale Angebote ein, aus denen alle Lernenden wählen können.
|
||||
- **Gestufte Hilfekarten** (Stufe 1: allgemeine Tipps, Stufe 2: Hinweise/Teilsnippets, Stufe 3: teilweise ausgearbeitete Code Bausteine).
|
||||
- **Pflicht und Küraufgaben:** Ein gemeinsamer Pflichtkern (mindestens eine Variable, eine Schleife, zwei Bedingungen, funktionsfähiges Grundspiel) und optionale Kür Aufgaben wie zusätzliche Level, Nachrichten, High Score oder besondere Gestaltung.
|
||||
|
||||
### Qualitativ & quantitativ: Geben Sie je ein konkretes Beispiel für eine qualitative und eine quantitative Differenzierung in Ihrem Projekt.
|
||||
|
||||
**Quantitative Differenzierung**
|
||||
Langsamere Lernende gestalten ein stabiles, spielbares Grundlevel; schnellere Lernende erweitern ihr Spiel um weitere Level oder zusätzliche Gegner, ohne dass mehr Umfang automatisch mehr Punkte bedeutet.
|
||||
|
||||
**Qualitative Differenzierung**
|
||||
Schwächere Lernende können ein vorbereitetes Grundgerüst nutzen (z. B. Figur mit Pfeiltastensteuerung und einfachem Gegner) und ergänzen Variablen, Kollisionsbedingungen und Game Over Bildschirm.
|
||||
Stärkere Lernende entwerfen eine eigene Spielmechanik und setzen anspruchsvollere Konzepte wie Nachrichten, Listen oder eigene Blöcke ein.
|
||||
|
||||
### Bewertung & Fairness: Wie berücksichtigt Ihr Bewertungsbogen differenzierte Anforderungen? Wird für alle dasselbe verlangt, oder gibt es ein gemeinsames Grundniveau mit gestuften Zusatzkriterien? Begründen Sie, wie Sie trotz Differenzierung fair bewerten.
|
||||
|
||||
Im Bewertungsbogen ist ein gemeinsamer Grundstandard mit gestuften Zusatzkriterien verankert:
|
||||
- Gemeinsamer Kern: Für alle gelten dieselben Mindestanforderungen (Variable, Schleife, Bedingungen, funktionierendes Spiel, Basisdokumentation). Dieser Kern reicht aus, um eine gute Note zu erreichen.
|
||||
- Gestufte Zusatzkriterien: Fortgeschrittene Konzepte (z. B. Nachrichten, eigene Blöcke, mehrere Level) werden als Kür mit Zusatzpunkten bewertet, sind aber nicht verpflichtend.
|
||||
|
||||
Hilfekarten und Grundgerüst stehen allen offen und gelten daher als legitime Binnendifferenzierung; in der Präsentation müssen Lernende zeigen, dass sie ihre eingebauten Teile verstehen.
|
||||
So bleiben die Anforderungen transparent, der Kern für alle gleich und zugleich werden leistungsstarke Lernende für Mehrleistung fair belohnt, ohne schwächere zu benachteiligen.
|
||||
|
||||
22
sitzung-08.md
Normal file
22
sitzung-08.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Makroplanung:
|
||||
## Sekundarstufe I, Klasse 7 (Gymnasium BW), Fach Informatik / Basiskurs Programmieren mit Scratch
|
||||
**Kontext**
|
||||
- Einführung / Vertiefung grundlegender Programmierkonzepte mit Scratch im Rahmen eines Informatik- oder ITG-/Medienbildungskonzepts.
|
||||
|
||||
**Zentrale Kompetenzbereiche:**
|
||||
- Algorithmen und Programmierung (Sequenz, Schleife, Bedingung, Variable, Ereignissteuerung)
|
||||
- Modellierung und Problemlösen (z. B. Spielabläufe planen)
|
||||
- Reflexion und Kommunikation informatischer Lösungen
|
||||
|
||||
### Stundenübersicht für Klasse 7 in BW (Makroplanung):
|
||||
| Stunde | Thema / Schwerpunkt | Lernziel je Stunde (operationalisiert): Die SuS können… | Bezug zum Bildungsplan | Aufbau-Bezug |
|
||||
|---------|-------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|
|
||||
| 1 | Einstieg & Diagnose + Selbstreflexion | … eine Figur in Scratch ein Quadrat mit möglichst wenigen Blöcken laufen lassen und eine Variable (z. B. Runden) sinnvoll einsetzen. | Algorithmen und Programmierung: einfache Abläufe in einer visuellen Sprache darstellen; Wiederholung von Sequenzen, Schleifen und Variablen als Grundkonzepte. | Einstieg und Lernstandserhebung, Vorbereitung der Differenzierung. |
|
||||
| 2 | Projektvorstellung und Erklärung + Beginn SuS-Spielideen & Planung (Konzept) | … eine eigene Spielidee entwickeln und in einem Storyboard/Flowchart mit Zuständen (Start, Spiel, Gewinn/Verlust) darstellen. | Modellierung und Problemlösen: informatische Probleme analysieren und Lösungswege als Modelle (Diagramme, Abläufe) entwerfen; Planung vor der Umsetzung im Programm. | Lehrer erklärt Projekt und Aufgaben, SuS legen das inhaltlich-technische Konzept des Projekts fest. |
|
||||
| 3 | Technische Grundlagen wiederholen, anwenden & grafische Vorbereitung | … Variablen, Schleifen und Bedingungen in kleinen Übungsaufgaben (Bewegung, Kollision, Punkte) gezielt einsetzen. | Algorithmen und Programmierung: Steuerstrukturen (z. B. Wiederholung, Auswahl) anwenden; Verhalten von Objekten in einer Programmierumgebung mithilfe dieser Strukturen steuern. | Festigt die Kernkonzepte, die für das eigene Spiel benötigt werden. |
|
||||
| 4 | Umsetzung I: Grundspiel entwickeln | … ein funktionierendes Grundspiel mit Start-Ereignis, Spielersteuerung und ersten Bedingungen (z. B. Kollision) implementieren. | Algorithmen und Programmierung: ereignisgesteuerte Programme entwerfen und umsetzen; mehrere Objekte (Sprites) mit jeweils eigenem Verhalten programmieren. | Überträgt die geübten Konzepte auf das eigene Projekt (Prototyp). |
|
||||
| 5 | Umsetzung II: Spiellogik erweitern | … ihr Spiel um Variablen (Punkte/Leben) und Gewinn-/Verlustbedingungen erweitern und einfache Rückmeldungen für Spielende einbauen. | Algorithmen und Programmierung: Zustände eines Systems (z. B. Spielzustände) modellieren; Programme testen, Fehler finden und beheben; einfache Benutzerschnittstellen gestalten. | Ausbau des Prototyps zu einem vollständigen Grundspiel mit klarer Spiellogik. |
|
||||
| 6 | Differenzierung & Erweiterung (Pflicht/Kür) | … ihr Spiel je nach Niveau entweder stabilisieren (Fehlersuche, Aufräumen) oder durch Level, Nachrichten, Listen o. Ä. erweitern. | Vertiefung: Anwendung und Kombination bekannter Konzepte; Einsatz fortgeschrittener Strukturen (z. B. Ereignisnachrichten, eigene Blöcke, Listen) als Erweiterung; selbstständiges Problemlösen. | Qualitative und quantitative Differenzierung; technische und kreative Abrundung. |
|
||||
| 7–8 | Dokumentation & Darstellung des Spielablaufs + überlegen, wie man Spiel, Code und Konzept vorstellen kann | … ihr Spiel schriftlich beschreiben (Ziel, Steuerung, Figuren), ein passendes Flowchart finalisieren und ihren Entwicklungsprozess festhalten. | Reflexion und Kommunikation: informatische Artefakte adressatengerecht beschreiben und dokumentieren; den eigenen Lösungsweg und wesentliche Entscheidungen nachvollziehbar darstellen. | Bereitet Präsentation und Bewertungsbogen vor, schafft Transparenz über den Lernprozess; Lehrkraft zeigt beispielhaft ein kleines Spiel zur Präsentation. |
|
||||
| 9 | Präsentation & Reflexion | … ihr Spiel präsentieren, zentrale Programmierkonzepte anhand ihres Projekts erklären und ihren Lernprozess reflektieren. | Reflexion und Kommunikation: Ergebnisse vorstellen und erläutern; eingesetzte Konzepte (Variablen, Schleifen, Bedingungen, Ereignisse) erklären; eigene Lernfortschritte reflektieren. | Schließt die Einheit ab, macht Kompetenzen sichtbar, Anknüpfung an Bewertung und Differenzierung. |
|
||||
|
||||
33
sitzung-09.md
Normal file
33
sitzung-09.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
# Mikroplanung einer Einzelstunde
|
||||
|
||||
### Entschluss Stunde 3 ausplanen:
|
||||
- Technische Grundlagen wiederholen, anwenden & gemeinsame Vorbereitung graphischen Anwendung– hier werden Variablen, Schleifen und Bedingungen in klaren Übungsaufgaben geübt.
|
||||
|
||||
### Schulform:
|
||||
- Sekundarstufe I, Klasse 7 (Gymnasium BW), Fach Informatik / Basiskurs Programmieren mit Scratch
|
||||
|
||||
### Kontext:
|
||||
- Einführung / Vertiefung grundlegender Programmierkonzepte mit Scratch im Rahmen eines Informatik- oder ITG-/Medienbildungskonzepts.
|
||||
|
||||
### Einordnung im Bildungsplan:
|
||||
|
||||
**Inhaltsbezogene Kompetenzen – Algorithmen (Klasse 7):**
|
||||
- Die Schüler:innen können Algorithmen mithilfe elementarer Anweisungen und Kontrollstrukturen (Anweisung, Bedingung, Schleife) beschreiben und in einer (grafischen) Programmiersprache implementieren.
|
||||
- Sie lernen Variablen als änderbaren Wertespeicher kennen und nutzen diese zur Steuerung von Abläufen, z. B. Punktestand.
|
||||
|
||||
**Prozessbezogene Kompetenzen:**
|
||||
- Modellieren und Implementieren: Abläufe in einer grafischen Programmierspra-che implementieren, Programme testen und Fehler beheben.
|
||||
- Kommunizieren und Kooperieren: eigene Lösungswege erläutern und im Team programmieren.
|
||||
|
||||
### Stundenziel:
|
||||
- Wiederholung der technischen Grundlagen (Variablen, Schleifen und Bedingungen), um Programmierprojekt gut umsetzten zu können
|
||||
- Die Schüler:innen können in Scratch Variablen, Schleifen und Bedingungen so definieren, schreiben und einsetzen, sodass eine vorgegebene Spielszene korrekt funktioniert.
|
||||
|
||||
| Zeit | Phase | Lehreraktivität | Schüleraktivität | Sozialform | Medien |
|
||||
|------|-------------------------|-----------------|------------------|-------------------|---------------------------------|
|
||||
| 5’ | Einstieg | Zeigt ein kleines Scratch‑Projekt, die grundlegende Bedienung der grafischen Oberfläche und führt das Programm aus: Eine Figur sammelt Sterne, der Punktestand wird angezeigt. Stellt Leitfragen: „Was passiert hier? Welche Bausteine erkennt ihr?“ | Beobachten das Projekt und benennen bekannte Elemente (Variable „Punkte“, Bewegung, Bedingung „wenn berührt …“). | Plenum | Beamer, Scratch |
|
||||
| 8’ | Erarbeitung I (Input) | Wiederholt anhand des Beispiel‑Scratch‑Projekts die Bausteine: Variable (Punkte), einfache Schleife („dauernd“ / „wiederhole 10 mal“) und Bedingung („wenn Figur Stern berührt“). Zeigt die entsprechenden Stellen im Code und erklärt, wie man Variablen anlegt, initialisiert und verändert. Formuliert bzw. wiederholt mit der Klasse 2–3 Merksätze („Eine Variable speichert einen veränderbaren Wert wie Punkte“, „Eine Schleife wiederholt Befehle“, „Eine Bedingung prüft, ob etwas zutrifft“) und schreibt sie an die Tafel. | Verfolgen die Demonstration, stellen Verständnisfragen, ergänzen ihre Unterlagen und notieren die Merksätze. | Plenum | Beamer, Scratch, Tafel |
|
||||
| 5’ | Erarbeitung II (Auftrag)| Erklärt den Arbeitsauftrag (Pflichtaufgaben + Kür). Die SuS erhalten ein Scratch‑Projekt, in dem an markierten Stellen Blöcke fehlen, die sie ergänzen müssen. Zeigt kurz jede der vier Aufgaben und erklärt, welcher Baustein im Fokus steht (1. Variable, 2. Bedingung, 3. Schleife, 4. Kür für schnelle/gute SuS). Verteilt gestufte Hilfekarten. | Lesen die Aufgaben, klären Verständnisfragen, bilden Partnerpaare und öffnen das vorgegebene Scratch‑Projekt. | Plenum → Partnerarbeit | Arbeitsblatt, Hilfekarten, PC |
|
||||
| 17’ | Erarbeitung II (Üben) | Geht durch den Raum, beobachtet die Umsetzung. Gibt zunächst mündliche Hinweise, bei Bedarf Hilfekarten (Syntaxstützen, Debug‑Tipps). Achtet darauf, dass nicht nur fertige Lösungen kopiert, sondern Kontrollstrukturen verstanden und angewandt werden. | Programmieren in Partnerarbeit: Bearbeiten der Aufgaben (zunächst Pflichtaufgaben, schnelle SuS bearbeiten Zusatzaufgaben). Testen und verbessern ihre Lösungen (Bewegung, Kollision, Punkte). | Partnerarbeit | PCs/Laptops, Scratch, Arbeitsblatt |
|
||||
| 8’ | Sicherung | Lässt 1–2 Gruppen ihre Lösung am Beamer zeigen (unterschiedliche Niveaus). Fragt gezielt: „Wo sehen wir hier die Variable? Wo die Schleife? Wo die Bedingung?“ und greift typische Fehler aus der Beobachtung auf. | Präsentieren ihre Aufgabenlösungen/Codes, benennen die verwendeten Konzepte; Mitschüler:innen identifizieren Variablen, Schleifen, Bedingungen und geben Feedback. | Plenum | Beamer, Tafel |
|
||||
| 2’ | Transfer/Abschluss | Stellt eine Transferfrage/Knobelaufgabe für schnelle SuS: „Wie könntet ihr mit Variablen, Schleifen und Bedingungen einen Timer oder eine Lebensanzeige für euer eigenes Spiel bauen?“ Verweist auf die nächste Stunde (Umsetzung I: Grundspiel). | Notieren ihre Idee stichwortartig. | Einzelarbeit | Heft |
|
||||
Loading…
Reference in a new issue