Kritische Einordnung der Ergebnisse - oliverbra/Projekt1_HCI_TeamCMTO GitHub Wiki

Formulierung des Nutzungsproblems

Durch die textuelle Formulierung des ausgesuchten Problemfeldes wurde ein Startpunkt für das folgende Semester festgelegt, an der wir die Konzeption orientieren konnten. Dadurch konnten wir die Basis für eine intensive Analyse der Anwendungsdomäne legen und daraus resultierende Ziele verfolgen. Kritisch war der Weg zum endgültigen Nutzungsproblem, da die Domäne zu Beginn sehr umfassend und komplex war. Doch besonders durch das Experteninterview mit Michael Gerhard konnten wir eine geeignete Spezifikation identifizieren und uns fokussieren.

Domänenmodell

Dadurch das schon zu Beginn festgelegt wurde, in welcher Domäne sich das Projekt bewegt, konnte die aktuelle Ist-Situation in einem Modell dargestellt und ein tiefgehendes Verständnis für die Situation erlangt werden. Es wurde deutlich, in welchen Bereichen Handlungsbedarf besteht und wo das System ansetzen kann. Das Domänenmodell stellt die Komplexität und die Zusammenhängen der Konzepte dar. Dabei entstand die Schwierigkeit sich auf das Wesentliche zu konzentrieren und das gewählte Nutzungsproblem nicht zu verlassen.

Stakeholder Analyse

Um eine Idee der Stakeholder zu bekommen, haben wir mit einem Brainstorming begonnen, bei dem jedes Teammitglied diejenigen Stakeholder aufschreiben konnte, die es für wichtig hielt. Anschließend wurden diese in primäre, sekundäre und tertiäre Stakeholder unterteilt. Hierdurch konnten wir schon zu Beginn eine Priorisierung der möglichen Nutzer festlegen, auf die sich weiter fokussiert werden konnte. Die Analyse konnte im weiteren Verlauf des Semesters immer wieder iterativ angepasst werden. Besonders bei der Identifizierung der Erfordernisse ist aufgefallen, dass einige Stakeholder nicht so primär einzuordnen sind, wie wir zunächst dachten. Beispielsweise wurden die Stakeholder Vermieter erstmalig als primäre Stakeholder eingeordnet; doch da nur wenig bis keine Erfordernisse in Betracht des Nutzungsproblems formuliert werden konnten, haben wir daraus geschlossen, dass diese sekundäre Stakeholder sind, da sie lediglich Interesse an den Auswirkungen des Systems haben.

SWOT Analyse

Die SWOT-Analyse, welche wir für die hochpriorisierten Stakeholder vorgenommen haben, hat nochmals einen Einblick darüber gegeben, mit welchen Schwächen und Stärken das System konfrontiert werden kann und worauf wir bei der Konzeption und Planung achten müssen. Des Weiteren konnten wir ein tieferes Verständnis für die Stakeholder aufbauen und die Erkenntnisse als Basis für die Erfordernisse nutzen. Durch die Analyse konnten wir ebenfalls die Stakeholder in ihren Priorisierungen nachjustieren. Die Analyse der einzelnen Aspekte stellte sich dennoch als langwierig heraus, da die einzelnen Teammitglieder jeweils unterschiedliche Ansichten hatten und diese erst zusammengetragen werden mussten. Hierbei haben sich die Schwierigkeiten der gemeinsamen Remote-Arbeit deutlich gemacht. Es stellte sich, als komplex dar die verschiedenen Meinungsströme ohne direkte Kommunikation zu erkennen, wodurch entscheidende Diskussionen vernachlässigt wurden.

User Storyboard

Durch das Storyboard wurde nochmals deutlich, welche Benutzergruppe welche Tasks ausführen werden und welche Aktionen im System auszuführen sind. Wir konnten verdeutlichen, aus welchen Teilaufgaben sich die einzelnen Tasks zusammensetzen und insgesamt das Konzept übersichtlich zu visualisieren. Des weiteren können aus dem User Storyboard die wichtigsten Funktionen und Attribute des Systems identifiziert werden. Bei der Erstellung des User Storyboard konnten wir strukturiert vorgehen, wodurch uns bestätigt wurde, dass unser Conceptual Design ausfürhlich und verständlich gelungen ist.

Prototyp

Durch die Erstellung des Prototyps hatten wir die Möglichkeit, die vorher erarbeiteten Elemente und Charakteristiken zusammenzubringen und zu gestalten. Wir konnten den Prototyp als Grundlage für unseren konzeptionellen PoC nutzen und unser Conceptual Design evaluieren. Schon während der gemeinsamen Zusammensetzung des Prototyps, welcher als Click Dummy funktionieren sollte, wurden erste Aspekte deutlich, die nicht wie gewünscht in das System einzufügen sind. Auch wurde sichtbar, welche Funktionen wir übersehen haben und die nachträglich in das System eingegliedert wurden. Schwierigkeiten entstanden unter anderem bei der iterativen Anpassung des Prototyps. Für die Entwicklung hatten wir uns bewusst für das Design-Tool Adobe XD entschieden, da dies die Möglichkeit zum kollaborativen Arbeiten gab. Leider funktionierte dieses Feature nur bedingt, wodurch nur eine Person an der Anpassung des Prototyps arbeiten konnte. Dabei wurden wiederum die Schwierigkeiten der Remote-Arbeit deutlich, da Tipps und Hilfestellungen zu dem Tool nicht deutlich kommuniziert werden konnten und sich die Entwicklung hinzog.

User Testing & Ergebnisse

Durch das User Testing konnten wir in den direkten Kontakt mit möglichen Benutzern treten und somit rausfinden, ob wir genügend Erfodernisse identifiziert haben. Aufgrund der aktuellen Situation wurde das Testing online durchgeführt, wodurch eine Testperson, aufgrund einer unstabilen Internetverbindung, nicht wie geplant teilnehmen konnte. Dadurch konnten wir kein Testing mit einem von uns als Experten eingestuften Stakeholder durchführen. Die Testergebnisse basieren auf den Aussagen von Nutzern, die wenig bis mittlere Erfahrung mit dem Gärtnern besitzen. Durch die Ergebnisse hatten wir die Möglichkeit, unseren Prototypen nochmals zu evaluieren und fehlende Aspekte, die durch die Testpersonen angemerkt wurden, zu ergänzen sowie neue Erfordernisse zu identifizieren. Dennoch ist besonders beim Protokollieren der User Tests deutlich geworden, dass für die Vorbereitung der Tests eine einheitliche Prokollierweise abgesprochen werden sollte, da wir dadurch Schwierigkeiten bei dem Zusammenfügen der Ergebnisse vermieden hätten können.

UML-Klassendiagramm

Die Modellierung des architektuellen PoC als UML-Klassendiagramm wird im Projekt II von Vorteil sein, da anhand diesen strukturiert die ersten Klassen, Funktionen und Abhängigkeiten implementiert werden können. Des Weiteren half das Klassendiagramm bei der Kontrolle, ob die passenden Issues formuliert wurden. Dies stellte sich zunächst als Schwierigkeit dar, da wir bereits im Modul Design Sprint die ersten Issues anhand des Prototyps formulieren mussten. Diese haben wir dann verworfen, da wir sie als unvollständig, unstrukturiert und wenig hilfreich für die Implemntierung angesehen haben. Mit Hilfe des UML-Klassendiagramms konnte das Formulieren der Issues strukturierter angegangen werden.