Achtung: Diese Aufgabe wird benotet.
Sie zählt zur Note 2 (Projekt 4.0), Kriterium A. Welche Aufgaben in welche Note einfliessen, steht in Aufgabe 8 unter «Benotung im Modul».
Mit dieser Aufgabe beginnt das Projekt 4.0. Bis Woche 17 setzen Sie Ihre Idee als Proof of Concept (PoC) um: einen kleinen, funktionierenden Prototyp, der zeigt, ob die Idee technisch machbar ist. Ein PoC ist kein fertiges Produkt. Er beantwortet die Frage, ob sich eine grössere Investition lohnt.
Bevor Sie Code schreiben, klären Sie, was schiefgehen kann. Die riskantesten Punkte bauen Sie in Aufgabe 12 zuerst.
Zeitbedarf: 2 Lektionen à 45 Minuten, also 90 Minuten Unterricht
(Woche 12)
Hilfsmittel: Internet, KI-Assistent, Ihre Unterlagen aus Aufgabe 7 bis
10
Sozialform: Vierergruppe (bisherige oder neue Zusammensetzung), bleibt
bis Semesterende zusammen
Unterrichtszeit für das ganze Projekt 4.0: 12 Lektionen in den Wochen
12–17, also 9 Stunden
flowchart LR
A[Risiken<br/>Aufgabe 11] --> B[Prototyp<br/>Aufgabe 12]
B --> C[Tests<br/>Aufgabe 13]
C --> D[PoC-Dokument<br/>Aufgabe 14]
D --> E[Pitch<br/>Aufgabe 15]Legen Sie Team und Idee fest. Meist ist es die Idee aus dem Idea-Projekt, ein Wechsel ist möglich. Schreiben Sie eine kurze Projektbeschreibung: Problem, Zielgruppe, Lösung und was der Prototyp am Ende können soll.
Sammeln Sie alle technischen Risiken, die Ihnen einfallen. Typische Quellen sind Fremd-APIs, ein unbekanntes Framework, Datenmengen, das Deployment oder fehlendes Wissen im Team. Bewerten Sie jedes Risiko in einer Tabelle:
| Risiko | Wahrscheinlichkeit | Auswirkung | Massnahme |
|---|---|---|---|
| Fremd-API zu langsam | mittel | hoch | Früh testen, Cache einplanen |
| Framework unbekannt | hoch | mittel | Tutorial vorab durcharbeiten |
| Deployment scheitert | mittel | hoch | Am ersten Tag veröffentlichen |
Die Beispiele zeigen das Format. Ihre Tabelle enthält die Risiken Ihres eigenen Projekts. Benennen Sie Annahmen offen, auch wenn sie unangenehm sind: «Niemand im Team hat bisher mit einer Karten-API gearbeitet» ist ein brauchbares Risiko.
Risiken mit hoher Wahrscheinlichkeit und hoher Auswirkung kommen zuerst. Für jedes davon legen Sie fest, wie Sie es vermeiden oder verkleinern. Oft lautet die Massnahme, genau diesen Teil im Prototyp echt umzusetzen.
Leiten Sie aus den Risiken die zwei bis vier Punkte ab, die der Prototyp in Aufgabe 12 auf jeden Fall zeigen muss. Meist sind das die Kernfunktion, die Anbindung externer Dienste und der Datenfluss vom Anfang bis zum Ende. Login, Einstellungen und Feinschliff im Design kommen später oder fallen weg.
| Kriterium | 3 Punkte, wenn … |
|---|---|
| A: Risiken eruieren | Die Risikoliste ist vollständig, jedes Risiko ist nach Wahrscheinlichkeit und Auswirkung bewertet und hat eine passende Massnahme |