Jump to content
Die PEN, OM-D & E-System Community
tFranz

Semesterarbeit: Umfrage zu einem Online-Tool für Fotografen

Empfohlene Beiträge

vor 14 Stunden schrieb Nieweg:

Es gibt sehr viele Apps und Privat-Webseiten mit Formeln und interaktiv etc.

Und es gab bei der Umfrage auch ein Feld, wo man das eintragen konnte 😉 

Viele Grüße 
Christian 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Vielen Dank für die bisherige Mithilfe!

Wer Interesse hat, kann sich gerne den ersten Design-Prototypen ansehen – und uns beim Ausfüllen eines weiteren (kürzeren) Bewertungsbogens helfen:

https://studium.fusbfg.de/hcd/ueq/

(Hinweis: Diesmal keine bösen Cookies, kein Tracking, kein Google, ...  🙂

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Richtig interessantes Thema! Find ich echt spannend. Großen Respekt an euch!

Ich würde mich sehr freuen, wenn ihr uns hier immer ein paar Updates zum Thema geben könnt. Das ist ein Tool, das ich auch selber nutzen würde.

 

Viel Erfolg noch!! 🙂

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Am 13.1.2021 um 12:59 schrieb tFranz:

und uns beim Ausfüllen eines weiteren (kürzeren) Bewertungsbogens helfen:

habe ich getan und in das Kommentarfeld ein paar Hinweise eingefügt. Es wär interessant, die App live auf dem Smartphone zu testen.

bearbeitet von ManfredP
Tippfehler

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Danke für das Feedback – auch in der Umfrage: das hilft uns alles weiter.

Und ich gebe Dir Recht: Nur anhand der Screenshots kann sich nicht jede Funktion erschließen – manches müsste man Ausprobieren können, um es beurteilen zu können.

Für uns hat die Arbeit mit dem Dummy den Vorteil, dass wir schon _vor_ der aufwändigen Programmierung Hinweise bekommen, was wie angenommen oder verstanden wird. Je später die Änderungshinweise kommen, desto aufwendiger und damit unwahrscheinlicher werden sie umgesetzt.

Diesen Prozess zu Lernen ist Teil dieses Studiengang-Kurses ... ;-)

Viele Grüße, Tobias 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 2 Stunden schrieb tFranz:

 Je später die Änderungshinweise kommen, desto aufwendiger und damit unwahrscheinlicher werden sie umgesetzt.

Wenn diese Aussage jetzt schon so kommt, ist das ein ziemlich starkes Indiz dafür, dass das Softwaredesign eher ungünstig für Veränderungen gewählt wurde.

vor 2 Stunden schrieb tFranz:

Diesen Prozess zu Lernen ist Teil dieses Studiengang-Kurses ... 😉

Das liest sich für mich nicht so, als würde da die metaphorische agile Sau durch Eure Uni getrieben, sondern als wärt Ihr in einem anderen Vorgehensmodell unterwegs.

Kannst Du dazu bitte etwas sagen?

E.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 51 Minuten schrieb EckyH:

Wenn diese Aussage jetzt schon so kommt, ist das ein ziemlich starkes Indiz dafür, dass das Softwaredesign eher ungünstig für Veränderungen gewählt wurde.

Das Software-Design wurde nicht spezifiziert und ist auch (noch) nicht Teil der Aufgabe. Bei dem Kurs dreht es sich allein um den Ansatz des "Human Centered Designs" als Hilfsmittel des Requirement Engineerings. 

Aber das steht trotzdem nicht gegen die generelle Aussage, dass Änderungen umso aufwendiger/teurer/unwahrscheinlicher werden, je später sie kommen – auch aus eigener Erfahrung. Das hat auch nicht unbedingt etwas mit einer agilen Arbeitsweise zu tun – auch wenn diese oft sinnvoll sein kann und in der Regel gut mit dem HCD-Ansatz harmoniert.

Fehler in einer frühen Phase der Softwareentwicklung zu beheben ist in der Regel kostengünstiger (nachzulesen z.B. in "Ebert, C., 2010. Systematisches Requirements Engineering", als diese erst nach der Umsetzung zu "reparieren" – es lohnt sich also auch finanziell, sich im Vorfeld der Softwareentwicklung klare Gedanken zu den Anforderungen gemacht zu haben. Und in diesem Vorfeld befinden wir uns zur Zeit.

(Software-Projekte scheitern übrigens häufig daran, dass Anforderungen und Ziele nicht ausreichend definiert wurden – siehe auch folgende Studie auf Seite 8: https://www.gpm-ipma.de/fileadmin/user_upload/GPM/Know-How/Ergebnisse_Erfolg_und_Scheitern-Studie_2008.pdf

 

vor 51 Minuten schrieb EckyH:

Das liest sich für mich nicht so, als würde da die metaphorische agile Sau durch Eure Uni getrieben, sondern als wärt Ihr in einem anderen Vorgehensmodell unterwegs.

🙂 Das an diesem Beispiel festzumachen wäre zu einfach und zu verallgemeinernd. Der eine Ansatz für das Requirement Engineering einer potentiell folgenden Softwareentwicklung – egal ob agil oder nicht – hat ja nur bedingt etwas mit der Art der späteren Softwareentwicklung zu tun. Uns geht es erstmal nur darum, herauszufinden, was eine potentielle Software überhaupt können sollte. Und um das rauszufinden, werden in diesem Fall unterschiedliche Werkzeuge des Human Centered Designs genutzt.

Die "agile Sau" – schönes Bild – wäre also ein potentiell aufgezeigter Weg, welcher nach Rom führt. Welche Wege das alternativ noch sein können – das zu zeigen ist Aufgabe solch eines Studiengangs.

Ich hoffe, das war jetzt nicht zu viel Text und hat etwas Klarheit gebracht, um was es uns bei diesem Projekt geht.

Viele Grüße, Tobias

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 5 Stunden schrieb tFranz:

Danke für das Feedback – auch in der Umfrage: das hilft uns alles weiter.

Und ich gebe Dir Recht: Nur anhand der Screenshots kann sich nicht jede Funktion erschließen – manches müsste man Ausprobieren können, um es beurteilen zu können.

Für uns hat die Arbeit mit dem Dummy den Vorteil, dass wir schon _vor_ der aufwändigen Programmierung Hinweise bekommen, was wie angenommen oder verstanden wird. Je später die Änderungshinweise kommen, desto aufwendiger und damit unwahrscheinlicher werden sie umgesetzt.

Diesen Prozess zu Lernen ist Teil dieses Studiengang-Kurses ... 😉

Viele Grüße, Tobias 

Im Prinzip macht ihr ja etwas, das man heute als DesignLabs bezeichnet. D.h. zu nächst mal mit den potentiellen Anwendern zusammmen über Prototypen und Studien, die später umzusetzende Funktionalität abstecken und die Handhabung der Anwendung konzipieren. Zu diesem Prozess gehört auch die Umfrage hier.

Das ist heute eine übliche Praxis. Auf diese Weise werden derzeit viele eGovernment Verfahren entworfen und später umgesetzt. Ob das agil erfolgt oder eher in klassischen iterativen Verfahren hängt von den Stakeholdern des Projektes und den weiteren Umständen ab.

bearbeitet von tgutgu

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 1 Minute schrieb tgutgu:

Im Prinzip macht ihr ja etwas, das man heute als DesignLabs bezeichnet. D.h. zu nächst mal mit den potentiellen Anwendern zusammmen über Prototypen und Studien, die später umzusetzende Funktionalität abstecken und die Handhabung der Anwendung konzipieren. Zu diesem Prozess gehört auch die Umfrage hier.

Ja, korrekt – das fällt definitiv in den Bereich!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


  • Wer ist Online   0 Benutzer

    Keine registrierten Benutzer online.

×
×
  • Neu erstellen...

Wichtige Information

Wenn Sie diese Seite nutzen, stimmen Sie den Community-Regeln zu. Wir haben Cookies gesetzt, um die Bedienung des Forums zu verbessern. Du kannst deine Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass du damit einverstanden bist. Mehr Informationen in unserer Datenschutzerklärung