| Angabe | Inhalt |
|---|---|
| Projekttitel | StudyDesk |
| Verfasser/in | Matteo Rotzer, [Klasse folgt] |
| GitHub-Repository | https://github.com/mat058/study-desk |
| Aktuelle App | https://study-desk-mr.netlify.app |
| Getestete Version | [Link; Commit/Tag] |
| Testzugänge | [Testkonten je Rolle oder Bereitstellungsweg; andernfalls «Nicht erforderlich»] |
| Figma / Referenz-Mockup | [Direkter Link] |
| Weitere Artefakte [Optional] | Projektboard: https://github.com/users/mat058/projects/2 |
Zugriff: Stellt sicher, dass alle Dozierenden auf das Repository, die App und die verlinkten Artefakte zugreifen können.
Testzugänge: Verwendet eigens eingerichtete Testkonten mit unkritischen Daten. Bei einem öffentlichen Repository gebt ihr hier nur den vereinbarten Bereitstellungsweg an. Persönliche Passwörter, API-Schlüssel und andere Geheimnisse dürfen nicht im Repository stehen.
- Ausgangslage
- Lösungsidee
- Vorgehen & Artefakte
- Erweiterungen [Optional]
- Projektorganisation [Optional]
- KI-Deklaration
- Anhang [Optional]
Hinweis: Massgeblich sind die im Unterricht und auf Moodle kommunizierten Anforderungen.
Kurz beschreiben, welches Problem adressiert wird und welches Ergebnis angestrebt ist. Wem nützt die Lösung, wer ist beteiligt oder betroffen?
- Problem: Studierende erhalten Termine, Abgaben und Leistungsnachweise über viele Kanäle (Moodle, Semesterprogramm-PDFs, E-Mail, Teams). Es gibt keinen vollständigen, verlässlichen Überblick: Die Moodle-Deadline-Ansicht ist unvollständig, Angaben widersprechen sich teilweise zwischen den Kanälen, und mangels Schnittstellen muss alles manuell in eigene Tools (z. B. Apple Erinnerungen, Notion) übertragen und nachgeführt werden. Beispiel: Für dieselbe Abgabe stehen in Moodle, im Semesterprogramm und in einer Mail unterschiedliche Daten – man muss jedes Mal nachfragen, welches gilt. Allein das Erfassen zu Semesterbeginn dauert rund eine Woche.
- Ziele:
- Alle Module, Abgaben und Leistungsnachweise eines Semesters an einem Ort
- Auf einen Blick sehen, was als Nächstes fällig ist und welche Wochen intensiv werden
- Widersprüchliche oder geänderte Termine erkennen statt übersehen
- Weniger Aufwand fürs Erfassen und Nachführen
- Primäre Zielgruppe: Bachelor-Studierende der ZHAW (insbesondere Vollzeitstudierende mit vielen Modulen und Studierende mit Nebenjob), die ihr Semester selbst organisieren.
- Weitere Stakeholder [Optional]: Dozierende (pflegen Moodle und Semesterprogramme; Quelle der Termine), Mitstudierende (Austausch über gültige Termine).
Details: Übung 8 – Understand & Define (PDF)
Beschreibt die Lösungsidee. StudyDesk ist ein persönlicher Semester-Hub: Module, Leistungsnachweise und Deadlines werden an einem Ort erfasst, und das Dashboard zeigt sofort, was als Nächstes dran ist.
- Kernfunktionalität: (Details: Requirements – Epics, User Stories, MoSCoW)
- Konto: Registrieren, an- und abmelden; jede Person sieht nur ihre eigenen Daten.
- Module verwalten: Modul erfassen, bearbeiten, löschen (Name, Kürzel, Semester, ECTS, Dozierende, Farbe); pro Modul ein Modul-Space mit allen Infos und Abgaben.
- Abgaben verwalten: Abgabe/Prüfung/Übung mit Modul, Typ, Deadline und Priorität erfassen, bearbeiten, löschen; Status mit einem Klick ändern (offen → in Arbeit → erledigt).
- Überblick: Dashboard mit den nächsten fälligen Abgaben und Schnellbuttons «+ Abgabe» / «+ Modul».
- Geplante Ergänzungen (Should/Could): Filter, Notizen, Fortschritt, Kalenderansicht, Semester-Archiv, PDF-Import von Semesterprogramm und Modulbeschreibung, Noten & Notenpunkte, Lernzeit.
- Annahmen [Optional]: (werden im Usability-Test geprüft)
- Eine Abgabe lässt sich in unter 30 Sekunden erfassen – schnell genug, dass Studierende die App wirklich nachführen.
- Das Dashboard beantwortet die Frage «Was ist jetzt dran?» ohne weiteres Klicken.
- Ein Modul-Space pro Modul wird als übersichtlicher empfunden als die Suche in den einzelnen Moodle-Kursen.
- Abgrenzung [Optional]: Keine direkte Anbindung an Moodle oder andere Hochschulsysteme (keine offene Schnittstelle), keine KI-Erkennung von PDFs (falls Import, dann reine Code-Erkennung), keine Gruppen-/Teilen-Funktionen, keine Push- oder Mail-Benachrichtigungen, keine native Mobile-App (Web-App, responsive).
Die Durchführung erfolgt phasenbasiert; dokumentiert die wichtigsten Ergebnisse je Phase.
- Zielgruppenverständnis:
- Problemräume: vier Problemräume gesammelt (fehlender zentraler Überblick, fehlende Schnittstellen, zu viele Apps für den gleichen Zweck, Faszination KI); gewählt wurde «Studium organisieren», weil selbst täglich betroffen und die Zielgruppe für Tests direkt erreichbar ist.
- Problemraum-Analyse: Nutzergruppen (Vollzeit, Vollzeit mit Nebenjob, Teilzeit, Erstsemestrige), heutige Tools mit Schwächen, typischer Ablauf bei einer neuen Abgabe, Bedürfnisse.
- How Might We: (1) Wie könnten wir Studierenden helfen, alle Abgaben und Leistungsnachweise eines Semesters an einem Ort zuverlässig im Blick zu behalten? (2) Wie könnten wir das Erfassen und Nachführen von Terminen so vereinfachen, dass keine Änderung verloren geht und klar ist, welches Datum gilt? (3) Wie könnten wir Studierenden mit Nebenjob helfen, früh zu erkennen, welche Wochen intensiv werden?
- Recherche: Moodle, Apple Erinnerungen/Kalender, Notion-Vorlagen, Studienplaner-Apps (z. B. MyStudyLife), To-do-Apps.
- (Proto-)Personas: Julian – Vollzeit mit Nebenjob, knappe Zeit, will eine verlässliche Quelle und die Wochen-Auslastung sehen · Leonie – Erstsemestrige ohne Job, überflutet von Kanälen, braucht sofort «Was ist jetzt dran?».
- Requirements (zusätzliche Methode aus Requirements Engineering): 7 Epics, 35 User Stories mit Akzeptanzkriterien, MoSCoW-Priorisierung und Datenmodell-Entwurf → Requirements. Die Must- und Should-Stories sind als Issues im Projektboard erfasst (#16–#34).
- Vollständige Ausarbeitung: Antworten Übung 8 · PDF
- Wesentliche Erkenntnisse:
- Es gibt viele Tools, aber jedes deckt nur einen Teil ab – der Überblick entsteht erst im Kopf der Studierenden.
- Der grösste Aufwand liegt im Erfassen und Nachführen, nicht im Anschauen.
- Verlässlichkeit (welches Datum gilt?) ist mindestens so wichtig wie Vollständigkeit.
- Ohne offene Schnittstellen der Hochschulsysteme muss die Lösung manuelles Erfassen so schnell wie möglich machen und Mehrwert auf den erfassten Daten bieten (z. B. Widersprüche, Belastung).
- Variantenüberblick: [kurz]
- Erste Ideen (Crazy 8s, Übung 9): In der Kleinklasse entstanden acht schnelle Ideenskizzen (Crazy 8s) mit Peer-Voting und eine ausgearbeitete Skizze (Overview + Deadlines-Tabelle). Sie dienten als erster Ideenspeicher; die massgeblichen Varianten für StudyDesk wurden danach separat ausgearbeitet (siehe unten). → Crazy 8s · Ausgearbeitete Skizze
- Skizzen: [Mehrere Varianten; Unterschiede kurz dokumentieren.]
- Gewählte Variante & Begründung: [Entscheidkriterien nennen]
- End-to-End-Ablauf: [Beschreibung inkl. User Journey Map]
- Mockup: Link siehe «Figma / Referenz-Mockup» in der Projektübersicht. [Screenshots mit kurzen Beschreibungen]
Beschreibt die Gestaltung und Interaktion.
Hinweis: Hier wird der Prototyp beschrieben, nicht das Mockup.
- Informationsarchitektur: [z. B. Seiten/Navigation: Konzept, nicht die technische Umsetzung]
- User Interface Design: [wichtige Screens: Screenshots mit kurzen Erläuterungen]
- Designentscheidungen: [zentrale Entscheidungen und Begründungen]
Fasst die technische Realisierung zusammen.
- Technologie-Stack: SvelteKit 3 (verbindliche Vorgabe). [Verwendete Bibliotheken ergänzen, falls genutzt.]
- Tooling: Visual Studio Code, Git & GitHub (Repository, Issues, Project Board), MongoDB Atlas (Datenbank, Gratis-Cluster M0), Netlify (Deployment, automatisch bei Push auf
main), Figma (Mockup). Den Einsatz von KI beschreibt Kapitel KI-Deklaration. - Vorgehen bei der Implementierung: [Wie wurde die Umsetzung schrittweise erarbeitet? Wie wurden Funktionen entwickelt, geprüft und überarbeitet? Bei KI-Unterstützung: Zusammenspiel zwischen eigener Arbeit und KI kurz beschreiben und für Details auf Kap. 6 verweisen.]
- Struktur & Komponenten: [Seiten, Routen, State/Stores, wichtige Komponenten]
- Daten & Schnittstellen: [Wie werden Daten gespeichert, verwaltet, abgerufen?]
- Deployment: Link siehe «Aktuelle App» in der Projektübersicht.
- Besondere Entscheidungen: [z. B. Trade-offs, Vereinfachungen]
Hinweis: Die Evaluation muss nachvollziehbar dokumentiert sein. Belegt die beschriebenen Beobachtungen und Resultate durch geeignete Nachweise und verlinkt diese im Feld «Nachweise». Die Materialien können im Repository abgelegt oder im Anhang aufgeführt werden. Personenbezogene Angaben sind zu anonymisieren.
- Getestete Version: Separat deployt; Link und Commit/Tag siehe «Getestete Version» in der Projektübersicht.
- Ziele der Prüfung: [welche Fragen sollen beantwortet werden?]
- Vorgehen: [moderiert/unmoderiert; remote/on-site]
- Stichprobe: [Mit wem wurde getestet? Profil; Anzahl]
- Aufgaben/Szenarien: [Ausformulierte Testaufgaben]
- Kennzahlen & Beobachtungen: [z. B. Erfolgsquote, Zeitbedarf, qualitative Findings]
- Nachweise: [Verweise auf anonymisierte Testprotokolle, Beobachtungsnotizen, Auswertungstabellen oder andere geeignete Belege für die beschriebenen Beobachtungen und Resultate]
- Zusammenfassung der Resultate: [Wichtigste Erkenntnisse; 2-4 Sätze]
- Abgeleitete Verbesserungen: [Anforderungen, die als nächstes umgesetzt werden sollten, priorisiert, kurz begründet. Umgesetzte Verbesserungen hier kurz beschreiben. Gehen sie über den Mindestumfang hinaus, zusätzlich nach dem Schema in Kap. 4 dokumentieren.]
Dokumentiert hier Erweiterungen über den Mindestumfang hinaus. Ordnet jede Erweiterung einem der beiden Unterkapitel zu und beschreibt sie einzeln.
Hinweis zur Bewertung: Nur dokumentierte Erweiterungen werden bewertet. Für nicht dokumentierte Erweiterungen oder Erweiterungen, deren Beschreibung bzw. Nachweise die folgenden Vorgaben nicht erfüllen, werden keine Punkte vergeben.
Verbindliche Struktur: Jede Erweiterung muss vollständig und exakt nach dem Schema des jeweiligen Unterkapitels beschrieben werden. Alle Felder sind mit unveränderten Bezeichnungen und in der vorgegebenen Reihenfolge auszufüllen. Wiederholt das Schema für jede weitere Erweiterung und nummeriert die Einträge fortlaufend (4.1.2, 4.1.3 bzw. 4.2.2, 4.2.3). Zusätzliche Erläuterungen innerhalb der Felder sind möglich.
Erforderliche Nachweise: Fügt zu jeder Erweiterung nach Möglichkeit mindestens einen aussagekräftigen Screenshot mit kurzer Erläuterung ein. Falls ein Screenshot nicht sinnvoll möglich ist, begründet dies kurz im Feld «Nachweise» und gebt einen anderen geeigneten Nachweis an. Bei Erweiterungen mit Code sind zusätzlich die relevanten Codestellen zu referenzieren, beispielsweise durch Links auf Dateien und die betreffenden Funktionen oder Zeilenbereiche.
Hierzu gehören zusätzliche Funktionen und technische Verbesserungen am Prototyp.
- Beschreibung & Nutzen: [Was wurde erweitert und welchen Mehrwert bietet es?]
- Abgrenzung zum Mindestumfang: [Was geht konkret über die verbindlichen Anforderungen hinaus?]
- Umsetzung: [Wie und wo wurde die Erweiterung umgesetzt?]
- Nachweise: [Screenshot(s) mit Erläuterung; Referenzen auf die relevanten Codestellen; gegebenenfalls weitere Belege]
- Bezug zur Evaluation: [Wurde die Erweiterung aus der Evaluation abgeleitet? Falls ja: auf die betreffende Beobachtung bzw. das Issue verweisen. Andernfalls: «Nein».]
Hierzu gehören beispielsweise zusätzliche Methoden, Planungs- und Analyseartefakte, Verbesserungen der Projektorganisation oder Anpassungen eines KI-Agenten-Workflows.
- Beschreibung & Nutzen: Aus Personas und Problemanalyse wurden 7 Epics und 35 User Stories mit prüfbaren Akzeptanzkriterien abgeleitet, nach MoSCoW priorisiert und daraus ein Datenmodell-Entwurf erstellt. Nutzen: klarer, begründeter Umfang (was ist Mindestumfang, was Erweiterung), direkt testbare Kriterien für den Usability-Test und eine Grundlage für das Issue-Management.
- Abgrenzung zum Mindestumfang: Der Unterricht verlangt Problemverständnis, Personas und Ideenfindung; User Stories mit Akzeptanzkriterien, MoSCoW-Priorisierung und Datenmodell stammen aus dem Modul Requirements Engineering und gehen darüber hinaus.
- Umsetzung: Epics im Frage-Antwort-Verfahren erarbeitet (Entscheide in Abschnitt 1.1 der Requirements), Machbarkeit des PDF-Imports anhand echter ZHAW-Semesterprogramme geprüft, Stories mit Personas verknüpft, Must- und Should-Stories als GitHub-Issues (#16–#34) mit Akzeptanzkriterien als Checklisten angelegt.
- Nachweise: Requirements-Dokument · Issues #16–#34 im Projektboard · [Screenshot Board mit Feature-Issues folgt]
- Bezug zur Evaluation: Nein (vorgelagert). Die Akzeptanzkriterien und Annahmen (z. B. «Abgabe erfassen < 30 Sekunden») dienen als Grundlage für die Testaufgaben in Kap. 3.5.
Hinweis: Verbesserungen der Projektorganisation, für die Erweiterungspunkte beansprucht werden, müssen nach dem Schema in Kap. 4.2 dokumentiert werden. Verweist dort bei Bedarf auf die Beschreibung in diesem Kapitel, um Wiederholungen zu vermeiden.
Beispiele:
- Repository & Struktur: Repository-Link siehe Projektübersicht. Code in
src/(DB-Zugriff zentral insrc/lib/server/db.js), alle Artefakte nach Phasen indocs/(Übersicht), Entscheide in decisions.md, KI-Einsatz in ai-log.md, Quellen in sources.md. - Issue-Management: Ein Issue pro Arbeitspaket bzw. User Story, mit Akzeptanzkriterien als Checkliste. Meilensteine je Phase (0 Setup bis 6 Abgabe), Labels (z. B.
feature,prio: must/should,artefakt,docs,usability), Project Board als Kanban. Findings aus dem Usability-Test werden als eigene Issues erfasst. - Commit-Praxis: Kleine Commits mit einem Thema, Conventional Commits auf Deutsch (
feat:,fix:,docs:,refactor:,chore:) mit Issue-Referenz (z. B.#16); Features auf Branchesfeat/<name>, Merge per Pull Request.
Die folgende Deklaration ist verpflichtend und beschreibt den Einsatz von KI im Projekt.
Hinweis: Dokumentiert den KI-Einsatz im gesamten Projekt, einschliesslich der Implementierung und eines allfälligen Einsatzes von KI-Agenten (Agentic Coding). Beschreibt die tatsächlich praktizierte Arbeitsweise. Falls keine KI eingesetzt wurde, gebt dies ausdrücklich an; die Unterkapitel 6.1–6.3 können dann entfallen.
- Eingesetzte Tools: Claude (Anthropic) in der Desktop-App «Cowork» mit Zugriff auf den Projektordner, Modell claude-opus-5-5. [wird bei weiteren Tools ergänzt, z. B. Claude Code in VS Code]
- Zweck & Umfang: [wie, wofür und in welchem Ausmass wurde KI eingesetzt (z. B. Textentwürfe, Codevorschläge, Tests, Refactoring); welche Teile stammen (ganz/teilweise) aus KI-Unterstützung?]
- Eigene Leistung (Abgrenzung): [was ist eigenständig erarbeitet/überarbeitet worden?]
- Arbeitsablauf & Aufgabenverteilung: [Wie wurde mit KI gearbeitet? Welche Aufgaben wurden selbst übernommen, welche an KI übertragen? Bei Agentic Coding: Welche Handlungsspielräume hatten die Agenten und wann wurde eingegriffen?]
- Prompt-Vorgehen & Kontext: [Wie wurden Aufgaben formuliert und relevante Informationen bereitgestellt? Grundlegende Vorgehensweise beschreiben; konkrete Prompts höchstens als Beispiele aufführen.]
- Konfiguration & Werkzeuge: Projektspezifische Agenten-Anweisungen in CLAUDE.md (Projektkontext, Code-Konventionen, Git- und Doku-Regeln, Grenzen wie «keine Secrets, kein Push ohne Bestätigung»); wiederverwendbare Befehle in .claude/commands/ (
doku-check,erweiterung,session-end); Prompt-Rezepte in docs/prompts/. Jede KI-Session wird in ai-log.md protokolliert. - Prüfung & Überarbeitung: [Wie wurden KI-Ergebnisse auf Korrektheit, Qualität und Urheberrecht/Quellen geprüft? Wie wurden Fehler erkannt und Ergebnisse überarbeitet?]
[Nutzen, Grenzen, Risiken/Qualitätssicherung, ...]
Hinweis zu Quellen und Urheberrecht: Bei Verwendung fremder Inhalte (z. B. Code, Texte, Bilder, Icons, Vorlagen oder Modelle) sind die Quellen und die geltenden Lizenzen bzw. Nutzungsbedingungen anzugeben und einzuhalten. Diese Angaben sind verpflichtend, auch wenn der Anhang weggelassen wird. Sie können alternativ an den betreffenden Stellen der Dokumentation oder in einer verlinkten Quellenübersicht im Repository stehen. Erforderliche Hinweise direkt im Code oder bei verwendeten Inhalten bleiben zusätzlich bestehen.
Beispiele:
- Quellen: siehe Quellen & Lizenzen
- Testskript & Materialien: [Link/Datei]
- Rohdaten/Auswertung: [Link/Datei]