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
• In der Schule wird als Programmiersprache zukünftig Javascript eingesetzt. Was ist eure begründete Meinung dazu? Wo seht ihr Schwierigkeiten, Herausforderungen und Chancen?
• In eurem eigenen Unterricht möchtet ihr mit den Schüler:innen ein Softwareprojekt umsetzen. Wo seht ihr die größten Schwierigkeiten? Wo legt ihr eure Schwerpunkte?
• Termin: t.b.a.