libretech
35e7e89010
dhbw-fundament.md: drei meta-lernziele DHBW-spezifisch: 1. industrie-anschluss-fähigkeit (aktuelle tools, 70% stack-vertrautheit für praxis-phase) 2. selbstständig-lernen-lernen (werkzeug-kompetenz > enzyklopädisches wissen, MDN/ARIA/RFC lesen können) 3. theorie-praxis-verbindung (jedes thema braucht erkennbaren anwendungsfall in typischer praxis-phase) HdM-werkzeuge (constructive alignment, advance organizer, mayer-12, informatikdidaktik) bleiben gleich. nur lernziel-INHALTE sind DHBW-spezifisch. 3 offene fragen: tool-stack-fokus (node/docker/git stimmt für DHBW karlsruhe?), praxis-phase-realität, soft-skills-block-tiefe dhbw-pruefungsleistung.md: 8 kompetenzfelder mit 75+10 punkten: 1. projekt-strukturierung+README (10) 2. code-qualität (15) 3. git-hygiene (10) — conventional commits, .gitignore 4. tests (10) 5. docker-containerisierung (10) 6. HTTP/API-design (10) 7. frontend a11y (10, falls UI im projekt) 8. präsentation (5+10 bonus) punkte-skalierung 80-85 sehr gut bis <33 nicht bestanden 4 offene fragen: frontend-pflicht?, punkte-verteilung-gewichtung?, was-zählt-als-bonus?, AI-code-anteile-reglement? danach: lernziele ableiten pro 8 kapitel, bogen pro kapitel, slide-rewrites
78 lines
3.5 KiB
Markdown
78 lines
3.5 KiB
Markdown
# DHBW Technik I — Prüfungsleistung-Kompetenzen (Vorschlag, zur Diskussion)
|
||
|
||
**Status:** Vorschlag von mir, *nicht gelockt*. Du redigierst, dann lock.
|
||
**Kontext:** DHBW Technik I hat keine Klausur, sondern eine **Projekt-Prüfungsleistung** (75 Pkt + 10 Bonus, Code-Abgabe + Präsentation).
|
||
|
||
## Was die Prüfungsleistung zeigen soll
|
||
|
||
Die Projekt-Abgabe sollte demonstrieren, dass Studis die **drei DHBW-Meta-Lernziele** verkörpern (siehe `dhbw-fundament.md`):
|
||
|
||
1. **Industrie-Anschluss-Fähigkeit** — Stack ist aktuell, Konventionen werden eingehalten.
|
||
2. **Selbstständig-Lernen** — Lösung ist nicht 1:1 aus dem Kurs, sondern eigener Pfad mit Doku/Beispielen.
|
||
3. **Theorie-Praxis-Verbindung** — das Projekt löst ein realistisches (kleines) Industrie-Problem.
|
||
|
||
## Vorschlag: 8 Kompetenz-Felder
|
||
|
||
Pro Feld 5–15 Punkte (insgesamt 75 + 10 Bonus möglich).
|
||
|
||
### 1. Projekt-Strukturierung & README (10 Pkt)
|
||
- Klare Verzeichnisstruktur, sinnvolle Namen
|
||
- README erklärt: was tut das Projekt, wie installieren, wie starten, wie testen
|
||
- LICENSE-Datei
|
||
|
||
### 2. Code-Qualität (15 Pkt)
|
||
- Lesbar (sinnvolle Variablen-/Funktions-Namen, kurze Funktionen)
|
||
- Konsistente Formatierung (Prettier/ESLint oder gleichwertig)
|
||
- Keine ungenutzten Imports / Variablen
|
||
- Sinnvolle Aufteilung in Module
|
||
|
||
### 3. Git-Hygiene (10 Pkt)
|
||
- Mindestens 5 sinnvolle Commits, keine `wip` / `fix` ohne Kontext
|
||
- Conventional Commits Format (feat:, fix:, docs: …)
|
||
- `.gitignore` für `node_modules`, `.env`, build-outputs
|
||
- Optionale Bonus: GitHub-Workflow / CI
|
||
|
||
### 4. Tests (10 Pkt)
|
||
- Mindestens 3 Unit-Tests für nicht-triviale Funktionen
|
||
- Tests laufen lokal durch (`npm test`)
|
||
- Test-Coverage-Bericht (optional)
|
||
|
||
### 5. Docker-Containerisierung (10 Pkt)
|
||
- `Dockerfile` baut sauber
|
||
- `docker compose up` startet das Projekt
|
||
- Multi-stage-build (Bonus, falls sinnvoll)
|
||
|
||
### 6. HTTP / API-Design (10 Pkt)
|
||
- Mindestens 3 REST-Endpunkte (z.B. GET/POST/DELETE)
|
||
- Sinnvolle Statuscodes (200, 400, 404, 500)
|
||
- JSON-Antworten mit Schema
|
||
|
||
### 7. Frontend (10 Pkt) *— wenn das Projekt eine UI hat*
|
||
- Funktioniert auf Smartphone + Desktop
|
||
- Mindestens 3 a11y-Kriterien erfüllt (semantisches HTML, alt-Text, Kontrast)
|
||
- Build mit Vite oder gleichwertig
|
||
|
||
### 8. Präsentation (5 Pkt + 10 Bonus)
|
||
- 5 Min Live-Demo des Projekts
|
||
- Erklärung: was war die größte Herausforderung, wie wurde sie gelöst
|
||
- Bonus: kurze Reflexion über Design-Entscheidungen
|
||
|
||
## Punkte-Skalierung
|
||
|
||
| Bewertung | Punkte | Bedeutung |
|
||
|-----------|-------:|-----------|
|
||
| Sehr gut | 80–85 | über den Erwartungen, mit Bonus-Punkten |
|
||
| Gut | 67–79 | alle Kompetenzen mit kleinen Lücken |
|
||
| Befriedigend | 50–66 | alle Kompetenzen wenigstens angeschnitten |
|
||
| Ausreichend | 33–49 | mind. 5 Felder ordentlich, 3 ggf. lückenhaft |
|
||
| Nicht bestanden | < 33 | mehrere zentrale Felder fehlen |
|
||
|
||
## Offene Fragen für dich
|
||
|
||
1. **Frontend-Pflicht oder optional?** Kompetenz 7 ist nur sinnvoll wenn UI-Bestandteil — vielleicht macht es Sinn, das Projekt-Thema so zu wählen, dass UI Pflicht ist (z.B. „kleine Web-App mit Backend + Frontend").
|
||
2. **Punkte-Verteilung 10/15/10/10/10/10/10/5:** stimmt das mit deinem Gewichts-Gefühl überein?
|
||
3. **Bonus-Punkte:** wofür konkret? Vorschläge: Conventional Commits + CI-Workflow + Test-Coverage + Multi-stage-Docker + a11y-Audit. Welche zählst du als Bonus?
|
||
4. **Plagiat-Erkennung:** wie gehst du mit AI-generierten Code-Anteilen um? KI-Hilfe ist Realität — sinnvoll Reglement?
|
||
|
||
**Bitte beantworte → ich finalisiere die Prüfungsleistung-Kompetenzen → leite daraus die Lehrinhalte pro Kapitel ab.**
|