# Wie entwickelt ihr gute Software mit einem GUI?



## DennisXX (19. Okt 2010)

Wie genau ist da eure Vorgehensweise? Ich bin noch recht neu auf diesem Gebiet. Ich vermute mal so:

1. User Storys anlegen (mit Priorisierungen und definieren von Tasks)
2. Use Case Diagramm erstellen
3. Anwendsfälle definieren
4. Szenarien aus den Anwendungsfällen ausarbeiten
5. Textanalyse mit den Anwendungsfällen durchführen und so die Klassen und Methoden herausarbeiten
6. Klassendigramm erstellen
7. Klassendesign entwerfen
8. Jetzt herunterprogrammieren und wenns läuft...

9. das ganze in ein GUI packen (also das GUI programieren).

Kann man das so machen? Vor allem bin ich mir nicht sicher, wie das mit der GUI Programmierung genau laufen soll und ob ich das richtig vermute. Ich bitte um ehrliches Feedback !


----------



## SlaterB (19. Okt 2010)

an der Uni habe ich davon auch gehört, im wahren Leben scheint mir das so realistisch wie 
- Spiegel einstellen
- Schulterblick
usw. beim Auto fahren fest nach Checkliste + noch Ölstand prüfen und Reifenprofil messen,

macht das wirklich jemand?
wenn eine GUI einen neuen Button haben soll, dann wird der reinprogrammiert,
nicht mehr und nicht weniger

bevor ein Programm überhaupt existiert kann man ja gerne paar Monate Papier planen, aber ob das am Ende dann noch so aussehen soll..


----------



## ARadauer (19. Okt 2010)

1. machen ;-)


----------



## DennisXX (19. Okt 2010)

Ja gut aber passt denn wenigstens meine Anordnung in dieser Theorie (also das GUI meine ich), oder muss ich das früher einplanen?

OK aber irgendwie müsst ihr doch auch eure Herangehensweisen in einem Projekt planen oder? Wie macht ihr das denn? Macht ihr euch kein Klassendiagramm zur Hilfe oder so?


----------



## KSG9|sebastian (20. Okt 2010)

Wie du entwickelst bleibt dir überlassen.

Zuerst GUI, oder zuerst Geschäftslogik...ich bzw. wir entscheiden das immer je nach Anforderungen.


----------



## Ezra (22. Okt 2010)

Naja, wenn Du es ganz genau machen willst, käme vor der eigentlichen Programmierung noch die Ausarbeitung des GUI-Entwurfs/-Prototypen hinzu sowie die Erstellung von Testfällen. Reviews nicht vergessen.

In der Praxis findest Du aber viel mehr agile Softwareentwicklung und insbesondere mehr parallele Arbarbeitung der einzelnen Posten. Das, was Du Dir aufgebaut hast, sieht mehr nach Wasserfallmodell aus und das ist tatsächlich nur noch Theorie.


----------



## KSG9|sebastian (22. Okt 2010)

Ezra hat gesagt.:


> ...
> 
> Das, was Du Dir aufgebaut hast, sieht mehr nach Wasserfallmodell aus und das ist tatsächlich nur noch Theorie.



Woooow...ich kenne *deutlich* mehre Firmen welche mit dem V-Modell arbeiten als mit agilen Softwareentwicklungsmethodiken.

SCRUM und Co. wird zwar gepuscht aber der "Wunschgedanke" überall Scrum zu haben ist ziemlich realitätsfremd.
Auch behaupten viele Unternehmen nach Scrum zu arbeiten, letztlich ist es aber ein V-Model in das irgendwie agile Methodiken reingepresst werden.
Gibt es was schöneres? Scrum mit Taskboard und 500 Dokumenten, eine große Iteration und niemand interessiert sich für's Endgame?


----------



## Ezra (22. Okt 2010)

> Woooow...ich kenne deutlich mehre Firmen welche mit dem V-Modell arbeiten als mit agilen Softwareentwicklungsmethodiken.


Es würde mich aber sehr wundern, wenn sie das wirklich Schritt für Schritt umsetzen würden, denn dann könnten sie weder effektiv arbeiten, noch rechtzeitig fertig werden.
Wie ich bereits sagte, werden die Schritte viel mehr parallel abgearbeitet, nicht nacheinander, wie es das Wasserfallmodell vorsieht. 
Aber Du schreibst es auch selbst, dass da Mischmasch betrieben wird und man das Ganze möglicherweise keinem Schema mehr zuordnen kann. Theorie ist eben Theorie.


----------



## Vayu (22. Okt 2010)

1. rudimentäre gui basteln (damit man ma was sieht!)
2. geschäftslogik einbauen
3. gui schicker machen


----------



## Raziell (22. Okt 2010)

Hi,

unterschiedlich aber meist zuerst ein Teil der GUI oder Geschäftslogik und dann das dazu passenden Gegenstück (GUI oder Geschäftslogik). Zwischendrinn wird dann immer mal getestet.

Könnte so grob in Ansätzen in Richtung Prototyping gehen 

Gruß


----------



## Marcinek (22. Okt 2010)

Je größer die Firma, deso mehr wie du geschrieben hast.

Ansonsten, das was die Kunden bezahlen.

Sonst: Hauptsache ein Button kommt ^^


----------



## Landei (22. Okt 2010)

ARadauer hat gesagt.:


> 1. machen ;-)



Manchmal vorher 0.5) Grobe Skizze auf der Rückseite von Wegwerfpapier.


----------



## slawaweis (22. Okt 2010)

DennisXX hat gesagt.:


> Kann man das so machen? Vor allem bin ich mir nicht sicher, wie das mit der GUI Programmierung genau laufen soll und ob ich das richtig vermute. Ich bitte um ehrliches Feedback !


vor allem würde ich sagen: Erfahrung. Es ist schon schwer genug gute Software ohne GUI zu entwickeln. Bei mir war es bisher so, dass immer ausrechend Fachkenntnisse im Team zu GUI-Entwicklung oder einem UI-Framework gefehlt haben. Deshalb ist meine Erfahrung mit der Entwicklung von GUIs, dass ich hinterher verbrannte Finger hatte. Microsoft gibt Millionen aus, nur um ein paar UI-Elemente zu designen, doch die meisten wissen oder verstehen es gar nicht.

Ich habe keine Arbeitspunktliste zu der UI Entwicklung, nur ein paar Grundsätze.

1. Wenn man wenig Kenntnisse von GUIs oder UI-Frameworks hat, sollte man die kleinste Suppe kochen die man kann. Das bedeutet, mächtige Frameworks suchen, wo alles schon fast fertig ist, um möglichst wenig selber schreiben zu müssen. Man wird es so oder so mehrmals umschreiben.

2. Wenn es nicht direkt gefordert wird, kein ausgefallenes Design, keine Experimente. So weit es geht an gängige Standards wie aus hundert anderen Programmen bekannt halten, auch wenn es langweilig wirken wird. Das reduziert den Aufwand neue Sachen zu erfinden und zu testen, weiterhin kann die Zielgruppe der Anwendung besser damit zurechtkommen.

3. Immer in enger Abstimmung mit dem Kunden arbeiten. Die meisten wissen vorher leider nicht, was sie wirklich wollen. Mit Paper und Bleistift anfangen und immer wieder Szenarien auf dem Papier mit dem Kunden durchspielen. Man kann auch gängige Software (z.B. MS Office, Photoshop) vorführen und fragen, ob man so ein "Aussehen und Gefühl" haben will. Auch die zukünftige Zielgruppe, welche mit dem Interface arbeiten wird, so weit es geht miteinbeziehen.

4. Die GUI von dem restlichen Programm strikt trennen, sogar in ein anderes Projekt auslagern. Man sollte gleich davon ausgehen, dass es parallel 3 vollkommen unterschiedliche GUI für das selbe Programm gibt. Das erleichtert später die Entwicklung eines neuen Interfaces, während das Programm mit dem alten GUI schon im Einsatz ist.

5. Ein Interface besteht nicht nur aus Grafik. Die Eingabe spielt eine sehr wichtige Rolle. So sollte die GUI von Anfang an fast vollständig mit Tastaturkürzeln oder Tastatur steuerbar sein. Aber auch die Mauswege müssen für die häufigsten Aufgaben nicht zu lang sein. Der Anwender sollte nicht überfordert werden, also sollte man keine komplizierten Erklärungen, Beschriftungen oder Aufforderungen wählen. Überhaupt sind Programmierer ziemlich schlecht in dieser Sache, das sollten wenn es geht andere machen, z.B. Kommunikationsexperten. Weiterhin sollte man den Anwender nicht mit Fehlermeldungen bewerfen oder durch ständigen modalen Dialoge an der Arbeit behindern, sondern versuchen einen reibungslosen Arbeitsablauf zu gewährleisten, mit klaren verständlichen Hinweisen oder Erklärungen, warum etwas gerade nicht geht oder wie man es anders machen kann.

6. Falls ein Grafikdesigner zu Verfügung steht, welcher eine Oberfläche in Photoshop entwirft, so sollte man sich mit diesem frühzeitig zusammensetzen und zu besprechen, was von der Programmiererseite gut geht und was weniger gut geht. Auch eine direkte Dreiecksbeziehung Kunde-Designer-Entwickler ist sehr zu empfehlen.

Slawa


----------



## DennisXX (23. Okt 2010)

slawaweis hat gesagt.:


> Bei mir war es bisher so, dass immer ausrechend Fachkenntnisse im Team zu GUI-Entwicklung oder einem UI-Framework gefehlt haben. Deshalb ist meine Erfahrung mit der Entwicklung von GUIs, dass ich hinterher verbrannte Finger hatte. Microsoft gibt Millionen aus, nur um ein paar UI-Elemente zu designen, doch die meisten wissen oder verstehen es gar nicht.



Jetzt muss ich nochmla rückfragen, was genau ist der Unterschied zwischen einem GUI und einem UI?


----------



## Marcinek (23. Okt 2010)

Das eine ist grafisch das andere textbasiert oder sogar nur api basis


----------



## ice-breaker (23. Okt 2010)

nicht wirklich richtig, Marcinek.
UI (User Interface) ist der Oberbegriff für alle Benutzerschnittstellen, seien es graphische Benutzerstellen, CLIs, Sprachsteuerung usw.

Von daher hätte ich inde m Post von slawaweis auch keinen Unterschied von GUI zu UI gemacht.


----------



## nocturne (24. Okt 2010)

1. Googlen und abkupfern.
2. Fachkraft bewerten lassen.
3. 1-2 beliebig wiederholen.


----------



## Gast2 (25. Okt 2010)

Wenn du ganz frischt mit einem Programm anfängst würde ich persönlich...
1. Überlegungen zu den Domain Klassen machen und die Models dazu
2. die Geschäftslogik machen und die durch JUnit Test abdecken
3. GUI machen...

es gibt auch Entwickler die zuerst gerne die GUI sehen und dann Logik dazu machen d.h. 2 und 3 vertauschen.


----------



## Spitfire777 (15. Nov 2010)

solange man geschäftslogik und gui trennt ist es meiner meinung nach egal, wie man startet..


----------



## The_S (16. Nov 2010)

Spitfire777 hat gesagt.:


> solange man geschäftslogik und gui trennt ist es meiner meinung nach egal, wie man startet..



Und wie müsste ich starten, wenn ich Geschäftslogik und GUI nicht trenne?


----------



## Landei (16. Nov 2010)

Ich würde auch Geschäft und Logik trennen. Die haben oft nicht viel miteinander zu tun...


----------



## ThreadPool (16. Nov 2010)

The_S hat gesagt.:


> Und wie müsste ich starten, wenn ich Geschäftslogik und GUI nicht trenne?



Du baust deine GUI und lässt sie direkt auf den benötigten Daten arbeiten? Oder du speicherst am Besten deine Daten in der GUI selbst. Das ist so der Windows-Forms-Stil, Delphi wäre so ein Vertreter mit dem du das forcieren kannst, GUI zusammenklicken dann hast du faktisch für jedes Element eine "hook"-Methode die du mit sinnvollem Code ausfüllen kannst.


----------



## The_S (16. Nov 2010)

ThreadPool hat gesagt.:


> Du baust deine GUI und lässt sie direkt auf den benötigten Daten arbeiten? Oder du speicherst am Besten deine Daten in der GUI selbst. Das ist so der Windows-Forms-Stil, Delphi wäre so ein Vertreter mit dem du das forcieren kannst, GUI zusammenklicken dann hast du faktisch für jedes Element eine "hook"-Methode die du mit sinnvollem Code ausfüllen kannst.



Danke für deine Antwort, ThreadPool. Aber muss dich leider enttäuschen, meine Frage war nicht wirklich ernst gemeint  .


----------



## Spitfire777 (16. Nov 2010)

- zu spät gepostet -


----------



## nocturne (24. Jan 2011)

Ich arbeite gerne mit DelphiJava.
In Delphi definiere ich die GUI.
In Java definiere ich das Backend.

auf http://www.e-nexus.de/


----------



## Noctarius (24. Jan 2011)

Irgendwie macht die Homepage jetzt nicht so den professionellen Eindruck, dass ich da bei Komponenten auf die deren Dinge setzen würde. Aber der Eindruck mag ja täuschen


----------



## Marco13 (24. Jan 2011)

> Das Programm rühmt sich damit keinerlei Eigabefelder darzustellen.


 (Die Menüeffekte sind ja einerseits ganz lustig ... ohne JavaScript sieht's da aber mau aus....)


----------



## bygones (26. Jan 2011)

KSG9|sebastian hat gesagt.:


> Woooow...ich kenne *deutlich* mehre Firmen welche mit dem V-Modell arbeiten als mit agilen Softwareentwicklungsmethodiken.
> 
> SCRUM und Co. wird zwar gepuscht aber der "Wunschgedanke" überall Scrum zu haben ist ziemlich realitätsfremd.


was ein scheinbar Deutsches Problem ist. Bei den Firmen im (europäischen) Ausland ist Scrum bzw Agiles wesentlich verbreiteter und auch aktiver eingesetzt. Anders gesagt, bei keiner Firma mit der ich in den letzten 9Monaten Kontakt hatte wurde NICHT agil gearbeitet.

Deutschland ist da immer noch weit hinterher und rühmt sich lieber mit genau solchen Sachen wie "geht doch nicht etc etc"

siehe:
We Tried Baseball and It Didn’t Work | xProgramming.com


----------



## ARadauer (26. Jan 2011)

Bei uns (Österreich) wird auch versucht agile Ansätze zu verwenden. Wir machen auf jeden Fall Scrum... das ist ja schon mal was ;-)


----------



## Mohackl (28. Jan 2011)

Hallo,

ich kann ein wenig von unserer Vorgehensweise berichten. Wir programmieren zu zweit einen Client für einen Kunden. Dieser ist ein Rich-Client, also er verarbeitet die Daten vom Server direkt. 

1. Zuerst ist natürlich die Absprache mit dem Kunden und den Nutzern dran. Hierzu haben wir einen Workshop organisiert in dem wir User-Stories entwickelt haben. Gleichzeitig haben wir dort Programme gesammelt die ähnlich sind, bzw. Usability aufweisen die gerne übernommen werden soll.

2. Wir haben uns für ein Framework entschieden das die Erstellung von GUI-basierten Anwendungen erleichtert. Da wir uns schon mit Eclipse-RCP auskannten, und dieses geschätzt alle Anforderungen erfüllen dürfte, haben wir uns dafür entschieden. Ansonsten wäre in dieser Phase ausprobieren von Frameworks an der Reihe.

3. Wir haben eine einfache GUI gebaut. Ohne Funktion, nur mit Dummy-Dialogen und Infos: "Jetzt würde die Tabelle gedruckt werden!". Hierbei haben wir versucht alle User-Stories unter zu bringen. Alle Buttons hatten jedoch schon ein unterliegendes Command. Also, sie könnten mit Logik gefüllt werden.

4. Der Kunde bekam die erste Oberfläche ohne Funktion. Die einzige Funktion war ein Feedback-Button durch den der Kunde Verbesserungen, Anmerkungen usw. an uns senden konnte. Auch eingebaut war ein Updater, damit der Kunde durch einen Klick seine Version updaten konnte.

5. Jetzt gingen wir nach schöner Scrum-Manier in einzelne Sprints. In diesen bei uns 1-2 wöchigen Zeiten wurden einige User-Stories umgesetzt. Sie wurden direkt in die GUI implementiert. Natürlich Logik getrennt von der GUI - RCP macht es einem da einfach - aber eben doch direkt ansprechbar durch Buttons, anzeigbar durch Listen usw.  Am Anfang dieses Spints wurden sich Gedanken über die konkreten Umsetzungen der User-Stories gemacht. Hierbei ging es genauso um die konkrete Bedienung, die Oberfläche wie auch die Logik. Oberflächenelemente wurden von uns als einzelne Task "auf der grünen Wiese" entworfen und ohne Logik in das Framework integriert. Logik genauso unabhängig, und dann mit den GUI-Elementen verbunden. Die Logik hat bei uns eine konsequente Testabdeckung - die GUI nicht. War zwar geplant hat aber nicht so funktioniert wie wir es uns gedacht haben.

6. Nach dem Sprint bekommt der Kunde eine neue Version.

Soweit.


----------

