Modul 245 Alle Aufgaben

Aufgabe 12: Projekt 4.0 – Code-Prototyp

Achtung: Diese Aufgabe wird benotet.

Sie zählt zur Note 2 (Projekt 4.0), Kriterien B und F sowie der erste Teil von Kriterium C. Welche Aufgaben in welche Note einfliessen, steht in Aufgabe 8 unter «Benotung im Modul».

Ausgangslage

Der Figma-Prototyp aus dem Design Sprint war eine Fassade: Er hat gezeigt, ob die Idee verstanden wird. Der Code-Prototyp zeigt, ob sie sich bauen lässt. Die kritischen Teile funktionieren echt, und der Prototyp ist online erreichbar.

Design-Prototyp Code-Prototyp (PoC)
Zweck Idee testen Machbarkeit beweisen
Werkzeug Figma, Miro Gewähltes Framework
Funktion Nur Fassade Kritische Teile echt
Zugang Link für Testpersonen Online bereitgestellt

Zeitbedarf: 2 Lektionen à 45 Minuten, also 90 Minuten Unterricht (Woche 13)
Hilfsmittel: Internet, KI-Assistent, Git (GitHub oder GitLab), Hosting auf IaaS oder PaaS
Sozialform: Ihre Vierergruppe aus Aufgabe 11

Lernziele

Teil 1: Framework wählen (ca. 10 Minuten)

Nutzen Sie Ihre Matrizen aus Aufgabe 7 (Ökosystem, Leistung, Kosten, Skalierbarkeit). Wählen Sie ein Framework aus den bewerteten Kandidaten und begründen Sie die Wahl in wenigen Sätzen. Das Team muss damit arbeiten können; ein bekanntes Framework ist oft die bessere Wahl als ein neues.

Teil 2: Repository und erstes Deployment (ca. 15 Minuten)

  1. Legen Sie ein Repository auf GitHub oder GitLab an. Alle Teammitglieder haben Zugriff.
  2. Veröffentlichen Sie schon in der ersten Lektion eine leere Startseite. Wer erst am Schluss deployt, findet die Probleme zu spät.
  3. Committen Sie regelmässig und in kleinen Schritten. Alle Teammitglieder tragen Commits bei.

Teil 3: CI/CD-Pipeline einrichten (ca. 20 Minuten)

Jeder Push auf main soll den Prototyp bauen, testen und veröffentlichen, ohne dass jemand von Hand deployt.

flowchart LR
  A[Push auf main] --> B[Build]
  B --> C[Unit-Tests]
  C --> D[E2E-Tests]
  D -->|alle grün| E[Deploy]
  D -->|ein Test rot| F[Kein Release]

Verwenden Sie GitHub Actions oder GitLab CI/CD. Die Konfiguration liegt im Repository. In dieser Woche genügt eine Pipeline mit Build, mindestens einem Test und Deploy. Ein roter Test muss das Deployment stoppen. Die vollständigen Tests folgen in Aufgabe 13.

Teil 4: Kritische Punkte umsetzen (ca. 30 Minuten)

Bauen Sie zuerst die Punkte, die Sie in Aufgabe 11 als kritisch bestimmt haben. Wenn eine Fremd-API das grösste Risiko ist, steht die Anbindung an diese API vor jedem Formular und jeder Startseite.

Teil 5: Eigenständig gestalten (Kriterium F, ca. 10 Minuten)

KI-Werkzeuge erzeugen schnell Oberflächen, die alle gleich aussehen. Das gibt Punkteabzug:

Volle Punkte gibt es, wenn Farben, Schrift und Name zur Idee passen, die Texte Ihre Zielgruppe ansprechen und jede sichtbare Funktion auch funktioniert. Das Team muss jede Gestaltungsentscheidung erklären können.

Teil 6: Stand prüfen (ca. 5 Minuten)

Prüfen Sie am Ende der Woche im Team: Welche kritischen Punkte laufen? Welche fehlen noch? Halten Sie den Stand kurz fest.

Bewertung dieser Aufgabe

Kriterium 3 Punkte, wenn …
B: Prototyp erarbeiten Die kritischen Punkte aus Aufgabe 11 sind umgesetzt, und der Prototyp ist online erreichbar
F: Eigenständig gestalten Gestaltung und Texte passen zur eigenen Idee, es gibt keinen KI-Einheitslook, und das Team kann jede Entscheidung erklären
C: Prototyp validieren (Teil 1) Die Pipeline baut, testet und deployt bei jedem Push auf main; ein roter Test stoppt den Release

Kriterium C wird nach Aufgabe 13 gesamthaft bewertet.

Abgabe

  1. Link zum Git-Repository
  2. URL des deployten Prototyps
  3. Begründung der Framework-Wahl
  4. Kurzer Stand: welche kritischen Punkte laufen, welche fehlen

Checkliste