Teamprojekt

Sprint 2: Entwurf

Exkurs: 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 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, ein Epic und Klassendiagramm)
  • Testdokumentation (mind. Testprotokoll für User-Tests) [OR: Sequenzdiagramm]
• Quellcode als Release auf GitHub
• Abgabe von PDF und Link zum Release an vielsack@kit.edu (→ Do, 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

To Do

• Recherche MVC / MVVM und Zuordnung im Klassendiagramm
• erster Entwurf Sequenzdiagramm (bzw. Testprotokoll)
• Einarbeitung in Vitest

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 (→ Do, 23:59 Uhr)

Teamprojekt

Sprint 4: Projektabschluss

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

(Zusammenfassung Menti )

• 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 GitHub (inkl. README)
• Abgabe von PDF und Link zum Release an vielsack@kit.edu (→ Do, 23:59 Uhr)

Teamprojekt

Exkurs: Open Source

Welche Vorteile hat Open Source?

(Zusammenfassung Menti )

• 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 Menti )

• 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)
• Github bietet Vorlagen beim Hinzufügen einer neuen Datei mit Namen license

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
• 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: 15.04.2026 ab 16 Uhr