Teamprojekt

Wintersemester 2025/26

Shortcuts

• S Speaker View
• F Fullscreen
• Esc Folienübersicht
• G Zu Folie springen
• Alt + ↖ Zoom
• F1 Alle Shortcuts anzeigen
• zur Druckversion

Teamprojekt

Einführungsveranstaltung

Formale Voraussetzungen

• Lehramt
• Fachdidaktik II:
  Fachdidaktik I abgeschlossen
• Teamprojekt:
  Programmieren oder SWT abgeschlossen
• Zeitgleiche Teilnahme an beiden Modulen

Wasserfall

Scrum

Teams & Weekly

¹ Ersatztermin Anfang der Woche ² Ansprechpartner: Tobias Antensteiner

Orga und so...

• Kolloquium inkl. Abgabe nach jedem Sprint
  → Kritische Beleuchtung des Projektfortschritts und Abschluss einer Phase,
  Teil der Prüfungsleistung
• Je 1-2 Verantwortliche für jede Phase
  → Managen und koordinieren das Team, halten Kontakt, leiten Besprechungen
• Folien:
  tp.lehr-lern-labor.info
• zum Drucken:
  tp.lehr-lern-labor.info?print-pdf

Teamprojekt

Themenfindung

Das Thema

• Entscheidung der Teams
• Absprache mit Betreuern
• Zielprodukt im Unterricht sinnvoll einsetzbar
• Didaktische Überlegungen
• Web-Applikation

To Do

• Zielgruppe?
  Klasse, Vorwissen
• Ziel?
  Inhalte, Lernziele
• Zielprodukt?
  Skizzen, Beschreibungen

Teamprojekt

Technische Einführung

Scrum

Product Backlog

• Produkt-Ziel
  schriftlicher Pitch der Software
• Funktionalitäten (User Stories (inkl. Tasks) / Kriterien)
  (vollständige) Definition der Software
• Definition of Done
  Checkliste zur Überprüfung, ob ein Increment fertig ist
• Definition of Fun
  Vereinbarungen über Zusammenarbeit
• Wichtige Entscheidungen
• Projektplanung
  Verteilung der Scum-Master-Tätigkeit

Scrum Board

Software

• Versionskontrolle
• IDE / Entwicklungsumgebung
• Scrum Board
• Skizzen & Diagramme
• Terminal / Konsole / Commandline / ...

Projekt einrichten

• Node.js installieren
• Git-Repository anlegen
• Vue-Projekt initialisieren
  

  
                              $ npm create vue@latest -y
  
                              ◇  Project name (target directory):
                              │  Teamprojekt
                              │
                              ◇  Package name:
                              │  teamprojekt
                              │
                              ◇  Select features to include in your project: (↑/↓ to navigate, space to select, a to      
                              toggle all, enter to confirm)
                              │  ◻ TypeScript
                              │  ◻ JSX Support
                              │  ◻ Router (SPA development)
                              │  ◻ Pinia (state management)
                              │  ◼ Vitest (unit testing)
                              │  ◻ End-to-End Testing
                              │  ◼ ESLint (error prevention)
                              │  ◼ Prettier (code formatting)
                              └
                          

• Anweisungen aus Terminal und Readme folgen

Tipps & Tricks

• Options API vs. Composition API
• Primevue

To Do

• Toolchain ausarbeiten
  • Git-Repository anlegen
  • Scrum-Board anlegen
• Hello-World-Programm implementieren
• Projekt planen

Teamprojekt

Sprint 1: Anforderung

Aufwandsabschätzung

Abgabe

Abgabe der Sprint-Dokumentation bestehend aus
• Product Backlog inkl. Änderungsvermerk
• Scrum-Board inkl. Sprint-Backlog
• Burn-Up- bzw. Burn-Down-Chart
• Entwurfsdokumente (falls vorhanden)
  z.B. Klassendiagramm, GUI-Entwürfe, Sequenzdiagramme
• Testdokumentation (falls vorhanden)
  z.B. Testprotokolle
• Quellcode
  z.B. als Release auf Codeberg

→ Abgabe spätestens bis 23:59 Uhr am Vortag des jeweiligen Kolloquiums per Mail an vielsack@kit.edu

Checkliste Sprint-Ende 1

• Sprint-Dokumentation (als zusammenhängende PDF-Datei)
  • Produkt-Ziel
  • Product-Backlog (User Stories inkl. Tasks, evtl. in Scrum-Board integriert)
  • Sprint-Backlog (Aktueller Stand, vmtl. im Scrum-Board)
  • Definition of Done
  • Definition of Fun
  • Projektplanung (Scrum-Master-Tätigkeit, Burn-Up/Down-Chart)
  • Entwurfsdokumente (mind. GUI-Entwürfe und evtl. ein Epic)
• Quellcode als Release auf Codeberg
• URL für Projekt festlegen: https://test.lehr-lern-labor.info/<projektname>
• Abgabe von PDF und Link zum Release an vielsack@kit.edu (→ Mi, 23:59 Uhr)

Teamprojekt

Sprint 2: Entwurf

Checkliste Sprint-Ende 2

• Sprint-Dokumentation (als zusammenhängende PDF-Datei)
  • Organisatorisches
  • Produkt-Ziel
  • Definition of Done & Definition of Fun
  • Projektplanung (Scrum-Master-Tätigkeit, Burn-Up/Down-Chart)
  • Wichtige Entscheidungen
  • Product-Backlog (User Stories inkl. Tasks, Änderungsvermerk, evtl. in Scrum-Board)
  • Sprint-Backlog (Aktueller Stand, vmtl. im Scrum-Board)
  • Entwurfsdokumente [🔍] (mind. GUI-Entwürfe, Epic, Klassen- und Sequenzdiagramm)
• Quellcode als Release auf Codeberg
• Abgabe von PDF und Link zum Release an vielsack@kit.edu (→ Mi, 23:59 Uhr)

Teamprojekt

Sprint 3: Qualitätssicherung

Testen

• Komponententest
  Entwickler → Module, Unterprogramme, Units, Klassen
• Integrationstest
  Tester → Schnittstellen
• Systemtest
  IT-Unternehmen → System in Testumgebung
• Abnahmetest
  Kunde → System in Produktionsumgebung

Testprotokoll Systemtest

• Für jeden Testfall:
• Eingabe
• Erwartete Ausgabe
• Ergebnis des Tests je Testdurchlauf (Pass/Fail→Details)
• Für jeden Testdurchlauf:
• Version (Git-Hash)
• Gerät
• Browser

Checkliste Sprint-Ende 3

• Sprint-Dokumentation (als zusammenhängende PDF-Datei)
  • Organisatorisches
  • Produkt-Ziel
  • Definition of Done & Definition of Fun
  • Projektplanung (Scrum-Master-Tätigkeit, Burn-Up/Down-Chart)
  • Wichtige Entscheidungen
  • Product-Backlog (User Stories inkl. Tasks, Änderungsvermerk, evtl. in Scrum-Board)
  • Sprint-Backlog (Aktueller Stand, vmtl. im Scrum-Board)
  • Entwurfsdokumente (mind. GUI-Entwürfe, Epic, Klassendiagramm, Sequenzdiagramm)
  • Testdokumentation (Komponenten- und Systemtests)
• Quellcode als Release auf GitHub
• Abgabe von PDF und Link zum Release an vielsack@kit.edu (→ Mi, 23:59 Uhr)

Teamprojekt

Sprint 4: Projektabschluss

Was benötigt Software für die "Veröffentlichung"?

(Zusammenfassung von Studi-Antworten)

• Funktionalität
• Gesicherte Qualität durch bestandene Systemtests / keine Bugs
• Dokumentation
• Veröffentlichung (URL, Server etc.)

Checkliste Sprint-Ende 4

• Sprint-Dokumentation (als zusammenhängende PDF-Datei)
  • Organisatorisches
  • Produkt-Ziel
  • Definition of Done & Definition of Fun
  • Projektplanung (Scrum-Master-Tätigkeit, Burn-Up/Down-Chart)
  • Wichtige Entscheidungen
  • Product-Backlog (User Stories inkl. Tasks, Änderungsvermerk, evtl. in Scrum-Board)
  • Sprint-Backlog (Aktueller Stand, vmtl. im Scrum-Board)
  • Entwurfsdokumente (mind. GUI-Entwürfe, Epic, Klassendiagramm, Sequenzdiagramm)
  • Testdokumentation (Komponenten- und Systemtests)
• Quellcode als Release auf Codeberg (inkl. README)
• Finale Abgabe an vielsack@kit.edu & tobias.antensteiner@kit.edu (→ Mi, 23:59 Uhr)

Teamprojekt

Exkurs: Open Source

Welche Vorteile hat Open Source?

(Zusammenfassung von Studi-Antworten)

• Vertrauen schaffen
• Wiederverwendbarkeit von Code
• Individuelle Anpassungen
• Kollaboration
• Schnelle / weitere Verbreitung
• Keine Kosten (→ Chancengleichheit)
• Verbesserung der (Code-)Qualität

Welche Nachteile hat Open Source?

(Zusammenfassung von Studi-Antworten)

• Andere verdienen an eigenem Code
• Eigener Code lässt sich schlechter vermarkten
• Schlechte Dokumentation
• Verbreitung von Malware
• Verwendung für ungewollte Zwecke
• Finden (und Ausnutzen) von Schwachstellen
• Nutzererlebnis nicht unbedingt im Vodergrund
• Qualität u.U. nicht gesichert

Open Source

• Lizenzen, die den Kriterien der Open Source Initiative (OSI) entsprechen
• Liste aller von der OSI genehmigten Lizenzen (opensource.org/licenses)
• Zusammenfassung einiger Open Source Lizenzen (tl;dr) (tldrlegal.com)
• Hilfestellung bei der Suche nach einer passenden Lizenz (choosealicense.com)
  → hier können die Lizenztexte auch sehr einfach kopiert werden, um sie ins Projekt zu übernehmen

Creative Commons

• Lizenzen für verschiedene Werke, z.B. Texte, Bilder, Musik
• Nicht geeignet für Quellcode

Open-Source-Definition I

• Freie Weitergabe
  Niemand darf daran gehindert werden, die Software zu verkaufen oder diese zusammen mit anderer Software weiterzugeben.
• Verfügbarer Quelltext
  Die Software muss im Quelltext für alle Nutzer verfügbar sein.
• Abgeleitete Arbeiten
  Modifizierte Versionen unter derselben Lizenz wie die originale Software müssen erlaubt sein.
• Integrität des Autoren-Quelltexts
  Das Verteilen von Software, die auf einer modifizierten Version des Originals beruht, muss erlaubt sein.
• Keine Diskriminierungen von Personen oder Gruppen
  Einzelnen Personen oder Gruppen darf die Nutzung der Software nicht verweigert werden.

Open-Source-Definition II

• Keine Nutzungseinschränkung
  Der Verwendungszweck der Software darf nicht einschränkt werden.
• Lizenzerteilung
  Die verbundenen Rechte müssen für alle gelten, an die Software weitergegeben wird.
• Produktneutralität
  Die verbundenen Rechte dürfen nicht davon abhängen, ob die Software Teil eines bestimmten Softwarepakets ist.
• Keine Softwareeinschränkung
  Keine Einschränkungen für andere Software, die zusammen mit der lizenzierten Software vertrieben wird.
• Technologieneutralität
  Keine Bestimmung der Lizenz darf auf eine einzelne Technologie gestützt werden.

Teamprojekt

Abschlussveranstaltung

Abschlussveranstaltung

• Präsentation der fertigen Software
• Reflektion des Projekts (Herausforderungen, Meilensteine)
• Fachdidaktische Überlegungen
  → Schriftlich in Präsentation festhalten
• 30 Minuten Präsentation (Tool & Fachdidaktik) + 15 Minuten für Fragen
• Termin: 16.04.2026 ab 16 Uhr (Teachers Dinner ab 18 Uhr)

Fachdidaktische Überlegungen

• In ihrem eigenen Unterricht möchten Sie mit den Schüler:innen ein Softwareprojekt umsetzen. Wo sehen Sie die größten Schwierigkeiten? Wo legen Sie Ihre Schwerpunkte?
• Wir haben über den Minimalismus bzgl. Programmiersprachen gesprochen. Eine entsprechend minimale Sprache kann auch erreicht werden, indem man eine Untermenge einer bestehenden Sprache nimmt. Zum Beispiel wurde «Processing» so aus Java abgeleitet.
  
  Welche Elemente aus JavaScript würden Sie in eine «minimale didaktische Sprache» übernehmen und warum? Gemeint ist also eine Programmiersprache, die für den Unterricht bestimmt ist und vollständig auf der Syntax und Semantik von JavaScript beruht, aber nicht alle Elemente von JavaScript umfasst. Wichtig bei Ihrer Antwort ist vor allem eine gute Begründung für das «Design» Ihrer Sprache; es gibt nicht «die» korrekte Antwort.