Umfrage »Dokumentation jedes Kontakts mit dem DiveKit zur Sammlung von Input für dessen Weiterentwicklung aus Studenten-Sicht.« (SV-1)
- Acronym
- beobachtungstagebuch
- Subject
- Dokumentation jedes Kontakts mit dem DiveKit zur Sammlung von Input für dessen Weiterentwicklung aus Studenten-Sicht.
- Stakeholder Role
- Distribution Channels
- Number of Participants
- Reference Population
- Responsible
- Miriam Wiedmann, Ali Mazlum, Jannis Lüchtefeld, Kay Ruck, Deniz Uzun, und Alexander Kosmehl
- History
- (v1) 2021-06-17 - Metadata added
- (v2) 2021-06-18 - added description and concept
- (v3) 2021-06-27 - added list of participants, results and corresponding documents
- (v4) 2021-07-16 - changed results into rohdatenformat
Erläuterung
Die Studierenden wurden in der Zeit vom 20.05.2021 bis zum 04.06.2021 mit einem Beobachtungstagebuch ausgestattet. Damit sollten Sie ihre Erfahrungen bei der Verwendung des Divekit im Modul Softwaretechnik 2 dokumentieren. Die Durchführung fand komplett anonymisiert statt. Um die Tagebücher dennoch zuordnen zu können, wählten die Teilnehmer persönliche Pseudonyme. Die Teilnehmer wurden explizit darauf hingewiesen aktiven Input über das Beobachtungstagebuch zu liefern. Aufgrund der gegebenen Anonymität wurden sie explizit darauf hingewiesen nicht vor Kritik zu scheuen. Die Bereitstellung und Abgabe des Beobachtungstagebuchs erfolgte über Ilias.
Konzept
Das erarbeitete Beobachtungstagebuch bestand aus acht Abschnitten zu denen die Teilnehmer aufgefordert waren Antwort zu geben. Die verwendeten Abschnitte sind nachfolgend erläutert:
Sehen: “Hier soll alles beschrieben werden, was du siehst und als nennenswert empfindest. Gerne kannst du hier beispielsweise aufschreiben, ob es Bugs gab, etwas anders war als sonst oder auch welches Feedback du für die Meilensteine bekommen hast.”
Machen: “Hier beschreibst du was du genau gemacht hast, währen du mit dem Divekit gearbeitet hast. Außerdem kannst du hier aufschreiben, wie du deine Aufgaben mithilfe des Divekit erledigt hast.
Fühlen: “Beschreibe in einem Wort oder in einem Satz, wie du dich vor, während oder nach der Benutzung des Divekit gefühlt hast. Auch ein kleiner Sketch, wenn die Worte fehlen, ist möglich.
Wünsche für das Divekit: “Hier geht es darum Wünsche für die Zukunft zu formulieren. Diese können gerne in Anlehnung an die Felder “Das gefällt mir gut / Das gefällt mir nicht” entstehen. Gibt es etwas, das unbedingt noch umgesetzt werden muss bzw. etwas, das dich bei der Verwendung stört und verändert oder entfernt werden sollte?”
Das gefällt mir gut: “Bitte beschreibe, was dir bei der Verwendung des Divekit gut gefallen hat. Hierbei kannst du dich auf die Verwendung während der Entwicklung als auch auf die Anzeige der Ergebnisse fokussieren, oder gerne generelle Dinge beschreiben, die dir im Gesamtkonzept gut gefallen haben.”
Das gefällt mir nicht: “Bitte beschreibe, was dir bei der Verwendung des Divekit nicht gefallen hat. Auch hier solltest du alle Phasen berücksichtigen, in denen du das Divekit verwendest.”
Das hat mich begeistert: “Hier kannst du Punkte nennen, die dich über “Das gefällt mir gut” hinaus besonders angesprochen haben. Dazu können bestimmte Funktionalitäten, das Design, oder die Nutzung zählen, aber auch Dinge, von denen du überrascht und daher begeistert warst.”
Kreativbereich/Sonstiges: “In diesem Feld bist du frei Dinge aufzuschreiben oder zu illustrieren, die du uns gerne mitteilen möchtest, aber nicht in eine der anderen Kategorien gepasst haben. Du bist hier nicht nur an das Wort gebunden, sondern kannst gerne kleine Sketche oder Mindmaps verwenden.”
Teilnehmer (anonymisiert)
- Percival Craig (PC)
- Harvey Specter (HS)
- Rick Dalton (RD)
- PSSG (PS)
- Peter Pan (PP)
- Flaschenhals (FH)
- Weißer Wolf (WW)
- Anonym (AN)
- Averroes (AV)
- Besoffski (BE)
- Snake (SN)
- Kaktus (KA)
- Phil Banks (PB)
Ergebnisse
Percival Craig (mwi)
(PC1) Das System muss in der Lage sein Fehlermeldungen anzuzeigen.
(PC2) Das System muss in der Lage sein Studierenden zu nicht bestandenen Tests Feedback anzuzeigen.
(PC3) Das System sollte eine simple Gliederung der Testseite haben.
(PC4) Das System muss so aufgebaut sein, dass der (Kennen)Lernprozess nicht zu aufwendig ist.
(PC5) Das System muss eine kurze Refresh-Time haben.
(PC6) Das System muss in der Lage sein, die durch die Studierenden eingestellten Tests zur Testseite hinzuzufügen, sobald sie im richtigen Projektordner abgelegt wurden.
(PC7) Das System sollte in der Lage sein eine visuelle und/oder textuelle Rückmeldung nach der Prüfung der Tests zu geben, um die Übersichtlichkeit zu verbessern.
(PC8) Das System muss in der Lage sein dem Prüfer nach Abschluss eines Tests eine Benachrichtigung zuzusenden, damit manuelles Feedback zeitnah durchgeführt werden kann und Wartezeiten verringert werden.
(PC9) Das System muss in der Lage sein dem Studierenden nach durchgeführtem Feedback eine Benachrichtigung zu senden, damit das Feedback direkt eingesehen werden kann und Wartezeiten verringert werden.
(PC10) Das System muss in der Lage sein dem Studierenden zu bestandenen Test und/oder zu allgemeinen Dingen Feedback zu geben. Es soll zudem eine Aussage darüber geben wie “gut” eine Lösung ist.
(PC11) Das System sollte in der Lage sein den Studierenden ein Feedback Archiv zur Verfügung zu stellen, um vorherige Kommentare einsehen zu können.
Harvey Specter (mwi)
(HS1) Das System muss in der Lage sein die Ergebnisse eines Tests auf der gleichen Seite und nicht auf einer extra Seite anzeigen zu können.
(HS2) Das System muss in der Lage sein den Studierenden mithilfe von visuellen Mitteln anzuzeigen, bei welchen Komponenten es Probleme gab beziehungsweise welche Aufgaben noch nicht bearbeitet wurden.
(HS3) Das System sollte Usern die Möglichkeit bieten das Design individuell festlegen zu können.
(s. PC7) Das System muss in der Lage sein dem Prüfer nach Abschluss eines Tests eine Benachrichtigung zuzusenden,
damit das manuelle Feedback zeitnah durchgeführt werden kann.
(s. PC8) Das System muss in der Lage sein dem Prüfer nach Abschluss eines Tests eine entsprechende Benachrichtigung
(entweder automatischoder durch eine interne Mailing-Funktion für Studierende) zuzusenden, damit das manuelle
Feedback direkt durchgeführt werden kann.
(s. PC4/7) Das System muss einfach aufgebaut sein, damit der User direkt einsehen kann, welche Aufgaben zu erledigen
sind und welche bereits erledigt wurden.
(s. PC5) Das System muss kurze Lade-/Refreshzeiten haben.
Rick Dalton (mwi)
(RD1) Das System sollte Studierenden die Möglichkeit bieten sich Hilfe oder (Code-) Reviews bei anderen Studierenden suchen zu können.
(RD2) Das System sollte in der Lage sein Studierenden weiterführende Informationen (z.B. Videos/Webseiten/Vorlesungsmaterialien) zu konkreten Fehlern zur Verfügung zu stellen.
(RD3) Das System sollte in der Lage sein Studierenden anzuzeigen, wie lange die Korrektur der Aufgaben dauert bzw. welchen Stand die Korrektur gerade hat.
(s. PC2/7) Das System muss in der Lage sein Studierenden Rückmeldung zu ihren Aufgaben zu geben.
(s. PC3/7) Das System muss einfach aufgebaut sein, damit der User schnell einsehen kann, welche Aufgaben zu erledigen
sind und welche bereits erledigt wurden.
(s. PC5) Das System muss kurze Lade-/Refreshzeiten haben.
(s. PC7/HS2) Das System muss in der Lage sein den Studierenden mithilfe von visuellen Mitteln anzuzeigen, bei
welchen Komponenten es Probleme gab.
(s. PC8) Das System muss in der Lage sein dem Studierenden nach Feedback durch den Prüfer eine entsprechende
Benachrichtigung zu senden, damit das manuelle Feedback direkt eingesehen werden kann.
(s. PC7) Das System sollte den Studierenden nach einer erledigten Aufgabe eine allgemeines kurzes Feedback geben können.
(s. HS3) Das System sollte über einen Darkmode verfügen.
(s. PC11) Das System sollte in der Lage sein den Studierenden Fehlermeldungen /Kommentare älterer Tests/Abgaben
auch nachträglich zur Verfügung zu stellen.
PSSG (jlü)
(PS1) Das System sollte dem User die Möglichkeit bieten Tests lokal auszuführen.
(PS2) Das System muss die Pseudonyme der korrigierenden Personen eindeutig angeben können.
(PS3) Das System sollte die Zeitzone an den Nutzenden anpassen können.
(PS4) Das System sollte dem User die Möglichkeit bieten einsehen zu können, wann die Aufgaben manuell korrigiert werden.
(PS5) Das System muss in der Lage sein Usern mit Farbfehlsichtigkeit, insbesondere Usern mit Rot-Grün-Schwäche, die Interpretation der Ergebnisse zu ermöglichen.
(PS6) Das System muss unverständliche und nicht nachvollziehbare Fehler in der Aufgabenstellung sowie im Testablauf vermeiden.
(PS7) Das System sollte die Durchführung von manuelle Korrekturen vor der Abgabe ermöglichen.
(s. PC5) Das System muss Testergebnisse schnell bereitstellen können.
Peter Pan (jlü)
(PP1) Das System soll mehr Tests bereitstellen, die den Code testen.
(PP2) Das System sollte das Durchlaufen von Tests bei falschen Lösungen verhindern.
(s. PC3) Das System muss die abzugebende Lösung übersichtlich darstellen.
(s. PC4) Das System soll dem Nutzenden die Möglichkeit bieten direkt starten zu können.
(s. PC5) Das System sollte in der Lage sein schnelles Feedback zu den abgegebenen Lösungen zu ermöglichen.
(s. PC4) Das System muss Usern einen leichten Einstieg in neue Aufgabentypen bieten.
(s. PC7) Das System sollte über einen Indikator verfügen, der mitteilt ob alle Tests bestanden wurden.
Flaschenhals (ako)
(FH1) Das System sollte in der Lage sein den User einfach zwischen Meilensteinen wechseln zu lassen.
(FH2) Das System sollte Studierenden die Möglichkeit bieten ohne Medienbruch Fragen an betreuende Personen stellen zu können.
(s. PC5) Das System sollte die schnelle Auswertung von Tests fördern.
(s. RD2) Das System sollte Usern Informationen oder Tutorials zur Verwendung des Systems bereitstellen können.
(s. PB1) Das System sollte dem User nicht ermöglichen für die Teststruktur notwendige Objekte verschieben zu können.
Weißer Wolf (ako)
(s. PC9) Das System muss den Studierenden nach abgeschlossener automatischer Kontrolle der Tests eine Benachrichtigung
schicken.
(s. PC9) Das System muss den Studierenden nach abgeschlossener manueller Kontrolle der Tests durch die Prüfer eine
Benachrichtigung schicken.
Anonym (ama)
(AN1) Das System darf den Status eines Tests erst dann auf grün setzen, wenn der Benutzer die Aufgabe erfolgreich bearbeitet hat.
(AN2) Das System sollte in der Lage sein den Zeitstempel der letzten Aktualisierung des Codes anzeigen zu können.
(s. PC1) Das System sollte in der Lage sein dem Benutzer eine genaue Fehlermeldung anzeigen zu können, falls die
Testseite nicht generiert werden kann.
(s. PC9) Das System sollte den Benutzer auch über andere Services als Discord über einen erfolgreichen Test
benachrichtigen können.
(s. RD3) Das System sollte dem Benutzer die Möglichkeit bieten die voraussichtliche Korrekturdauer eines Tests
anzeigen zu können.
(s. PC6) Das System muss in der Lage sein den vom Benutzer geschriebenen Quellcode auf der Testpage einzubinden.
(s. PC10) Das System muss in der Lage sein dem Benutzer nach der manuelle Kontrolle des eigenen Codes zugehörige
Informationen anzuzeigen.
Averroes (kru)
(AV1) Das System sollte in der Lage sein die Testseite nach der Prüfung eines Test selbstständig zu aktualisieren.
(s. HS3) Das System sollte über einen Darkmode verfügen.
(s. PC5) Das System sollte in der Lage sein Aktualisierungen ohne Latenz durchzuführen.
(s. PC9) Das System muss dem Studierenden nach einer durchgeführten Korrektur eine Benachrichtigung schicken.
(s. PS5) Das System sollte zur Rückmeldung eines Tests mehr als zwei Farben verwenden.
Besoffski (kru)
(BE1) Das System sollte in der Lage sein dem Studierenden die Deadline der zu bearbeitenden Aufgabe auf der Testseite anzeigen zu können.
(s. PC8) Das System sollte in der Lage sein dem Prüfer nach Abschluss eines Tests eine Benachrichtigung zuzusenden.
(s. PC7) Das System sollte in der Lage sein den Studierenden zusammenfassende Informationen über die eigenen Tests
zur Verfügung zu stellen.
Snake (kru)
(s. RD3) Das System sollte dem Benutzer die Möglichkeit bieten die voraussichtliche Korrekturdauer eines Tests anzeigen zu können.
(s. PC3) Das System sollte nur eine bestimmte Anzahl der letzten Tests anzeigen, um die Testseite übersichtlich zu halten.
Kaktus (duz)
(KA1) Das System sollte über eine Schnittstelle für Anbindungen anderer Systeme verfügen.
(s. PC10) Das System sollte dem Benutzer auch bei bestandenen Tests ein Feedback ausgeben können.
(s. PC5) Das System muss über eine schnelle Rückmeldezeit verfügen.
(s. PC9) Das System sollte in der Lage sein dem Prüfer eine Benachrichtigung zu senden, wenn ein Test durchlaufen wurde.
(s. PC9) Das System sollte in der Lage sein dem Prüfer automatisch zu benachrichtigen, wenn ein Test durchlaufen wurde.
(s. PC9) Das System sollte über eine Schnittstelle verfügen, über welche ein Discord-Bot dem Prüfer mitteilen kann,
dass ein Test durchlaufen wurde.
Phil Banks (duz)
(PB1) Das System muss in der Lage sein Änderungen an Dateien automatisch zu registrieren.
(PB2) Das System sollte in der Lage sein dem Benutzer einfache Qualitätstests, wie Ausführungszeit, Ressourcenauslastung, etc. bereitzustellen.
(s. PC2) Das System sollte in der Lage sein zu nicht bestandenen Tests detailliertes Feedback anzuzeigen.
(s. RD1) Das System sollte Studierenden die Möglichkeit bieten den eigenen fehlerhaften Code durch andere Studierende
reviewen zu lassen.
(s. PC10) Das System sollte in der Lage sein dem Studierenden darstellen zu können, wie „gut“ die eingereichte Lösung war.
(s. RD1) Das System sollte dem Studierenden die Möglichkeit geben den eigenen Code mit dem Code anderer Studierender
zu vergleichen und Vorschläge zu erhalten, wie die Aufgabe gelöst werden könnte.
(s. PC10) Das System sollte dem Studierenden detailliertes und weitreichendes Feedback zu seinen Tests geben.
(s. PC8) Das System sollte dem Studierenden die Möglichkeit bieten Feedback durch einen Prüfer ohne Verzögerung anzufordern.
(s. KA1) Das System sollte über eine Schnittstelle zur Anbindung anderer Systeme verfügen.
Dokumente
Beobachtungstagebuch Anforderungen