Ratschläge zur Vorgehensweise bei Projekt gesucht

Hallo zusammen,

Ich entwickle zur Zeit ein Software Programm, das auf einen Pocket PC laufen soll.

So bin ich vorgegangen um die Anwendung zu entwickeln (ich arbeite zur Zeit noch dran).

Also ich habe mir die Anforderung gesammelt, habe danach angefangen das Layout der Anwendung zu entwerfen.

Ich wollte natürlich bevor ich anfange zu programmieren, alles mit UML durchgehen lassen und so weiter - Diese klassische Softwareengineering Sachen -, das habe ich leider net gemacht.

Nachdem ich das Layout entworfen habe, habe ich mir gedacht, dass jede Schaltfläche auf der Anwendung entspricht eine Funktionalität.

Ich wollte bitte Ratschläge von euch haben ob diese Vorgehenweise sehr schlimm ist oder ob es noch akzeptable ist.

Ich muss das ganze noch dokumentieren. Welche Punkte muss man betrachten wenn man ein Software dokumentieren muss?

Welche Bücher oder Links sind gut für die Softwareentwicklung??

Ich habe auch eine ganz wichtige Frage, ich wollte mich in einem Bereich vertiefen, habe aber 2 Alternativen (J2EE oder .NET), Welche von dem Beiden ist zukunftsicher (besser), Mir gefällt .NET am besten aber weiss net ob irgendwann mal J2EE .NET überholt wird oder hat .NET schon überholt oder muss .NET noch an J2EE nachholen muss.

MfG

Willy

Hallo willy,

Ich habe auch eine ganz wichtige Frage, ich wollte mich in einem Bereich vertiefen, habe aber 2 Alternativen (J2EE oder .NET), Welche von dem Beiden ist zukunftsicher (besser)

Welche Antwort erwartest du darauf in einem .NET Forum? 🙂

Also ich habe mir die Anforderung gesammelt, habe danach angefangen das Layout der Anwendung zu entwerfen.

Das Vorgehen ist durchaus möglich und sinnvoll, ersetzt aber nicht das Programmdesign.

Nachdem ich das Layout entworfen habe, habe ich mir gedacht, dass jede Schaltfläche auf der Anwendung entspricht eine Funktionalität. Ich wollte bitte Ratschläge von euch haben ob diese Vorgehenweise sehr schlimm ist oder ob es noch akzeptable ist.

Das ist eine funktionale Herangehensweise, die meist ungeeignet für objektorientierte Programmiersprachen ist. Die Überlegung hätte lauten müssen: was sind die Objekte, um die es geht (oder wenn dir das lieber ist: auf die sich die Funktionen beziehen). Aber wenn ich dich richtig verstehe, ist es jetzt eh zu spät.

Ich muss das ganze noch dokumentieren. Welche Punkte muss man betrachten wenn man ein Software dokumentieren muss?

Das ist ein weites Feld. Gibt schon mal drei große Bereiche: Benutzerhandbuch/-dokumentation, Entwurfs-/Programmdokumentatuion, Kommentare im Code. Und jede ist wieder ein Thema für sich.

herbivore

Ich weiss das für diese Anwendung schon bissi spät ist, wollte nur wissen um diese Fehler beim nächste mal zu vermeiden.

Ich habe natürlich im Code Kommentare gesetzt, Benutzerhandbuch/-dokumentation, Entwurfs-/Programmdokumentation weiss ich leider net wie ich das umgehen sollte. Ist klar dass es von Programm zu Programm abhängig ist aber das Grundkonzept wie es gemacht wird, habe ich nicht.

Danke dir für deine Antwort..

MfG

Willy

Naja, mit der GUI würde ich mich erst am Schluss beschäftigen. Die Anforderungen sammeln ist gut, aber ich würde weniger funktional denken, sondern problemorientiert. Und die Probleme teilst du auf in Zusammenhängende Gruppen und irgendwann kristallisiert sich schon fast der nötige Aufbau des Programms heraus.

Hallo willy,

was Benutzerhandbücher angeht: Da gibt es ja genug reale Vorlagen. Such dir aus, was dir gefällt und mach es entsprechend.

Die Entwurfs- und Programmdokumentation ist sehr stark abhängig von Art und Umfang des Projekts. Da allgemeine Regeln zu geben, muss wohl wohl Büchern überlassen werden. Ansonsten siehe: UML Diagramme

herbivore

Hallo talla,

Naja, mit der GUI würde ich mich erst am Schluss beschäftigen.

das GUI ist aber das, womit man mit den zukünftigen Anwendern am besten sprechen kann - von Use Cases mal abgesehen. Deshalb steht der Entwurf des GUIs oft am Anfang. Aber ich sagte ja, dass das Programmdesign auf einem anderen Blatt steht.

herbivore

Hallo,

Original von herbivore
das GUI ist aber das, womit man mit den zukünftigen Anwendern am besten sprechen kann - von Use Cases mal abgesehen. Deshalb steht der Entwurf des GUIs oft am Anfang. Aber ich sagte ja, dass das Programmdesign auf einem anderen Blatt steht.

Wie man jetzt aber am besten anfängt, hängt auch immer davon ab, was zu tun ist.

Ich habe es schon erlebt, daß ein Auftraggeber Anforderungen stellte, die ausschließlich aus GUI und entsprechenden UseCases bestand. Dann bleibt einem meist nicht viel anderes übrig übrig als auch damit anzufangen.
Wenn man allerdings die Wahl hat, würde ich immer zuerst damit anfangen, die Programmlogik aufzubauen.
In beiden Fällen ist es ratsam, GUI und Anwendungslogik zu trennen, das erleichtert Erweiterung und Pflege und man hat evtl. die Möglichkeit, das Prog mit verschiedenen GUIs auszustatten, je nachdem wie man es nutzen will...

Bzgl. der Benutzerdokumentation (ich denke mal, dass ist es was Du mit Dokumentation meinst), kann man mindestens zwei grundsätzliche Ansätze unterscheiden.
Entweder Du schreibst eine Dokumentation, die sich an dem Aufbau Deines Programms (z.B. an den einzelnen Masken) orientiert und diesen dann Punkt für Punkt erklärt. So nach dem Motto: Hier haben wir die Eingabemaske und hier können Sie dies und jenes tun und achten Sie darauf, dass Sie folgende Werte nicht eingeben dürfen.
Ein anderer Weg ist es, die Dokumentation problemorientiert zu verfassen. Das kann man dann mit einer FAQ-Sammlung vergleichen. DAs ganze sähe dann so aus: Wenn Die einen neuen Datensatz eingeben wollen, dann gehen Sie auf folgende Maske und tragen Sie diese Werte ein. Anschließend können Sie auf einer anderen Maske überprüfen, ob alles eingetragen wurde usw.

Ich finde es immer super, wenn es beider Varianten gibt. Die erste für absolute Neulinge und die zweite für Profis, die nur die eine oder andere Funktionalität vergessen haben oder noch nicht kannten.

Das ist also eine Art Benutzerhandbuch oder?

MfG

Willy