Planung von Softwareprojekten

[niceWork]

Hallo zusammen!

Ich lerne gerade die Programmiersprache JAVA, einerseits aus Interesse und andererseits als Vorbereitung auf eine Berufsausbildung zum JAVA Entwickler (ich habe mich um ein Stipendium beworben und nächste Woche wird verlost).
Jedenfalls bin ich mittlerweile soweit fortgeschritten, dass ich mich an ein kleines Projekt heranwagen kann bzw. möchte.

Da ich leidenschaftlich gerne Paragleiten gehe, kam ich auf die Idee, mir als Projekt eine Anwendung zu entwickeln, welche einerseits ein Logbuch für die Flüge darstellt, und andererseits mich erinnert, wann z. B. Termine für Service/Retterpacken etc. fällig sind. Bin mir sicher mir fallen während der Umsetzung noch viele andere Dinge ein.

Allerdings halte ich es nicht für sinnvoll, einfach drauflos zu entwickeln, ich möchte gerne vorher effizient planen - Klassen, Vererbungshierachie, Instanz-/Klassenmethoden, usw. ....
Mich würde jetzt interessieren, wie ihr da bei solchen Projekten beginnt bzw. diese durchplant? Gibt es quasi eine "Standard"-Vorgehensweise, oder macht das jeder ganz anders? Leider findet man weder in Lehrbüchern noch im Internet Informationen, die für Anfänger brauchbar sind. Bin für jeden Tipp dankbar!

Gibt es eventuell auch eine PC-Anwendung, die man dafür gut nutzen kann?
Habe sowohl hier als auch im Internet gesucht, jedoch noch nichts brauchbares gefunden.

Freue mich auf eure Antworten!

Vielen Dank!

Christian

 

[Kirby.exe]

Also dein Software Konzept könntest du mit UML aufstellen draw.io ist dafür ein schönes Tool

 

[mihe7]

Ich lerne gerade die Programmiersprache JAVA

Das wage ich zu bezweifeln, vermutlich lernst Du Java.

Mich würde jetzt interessieren, wie ihr da bei solchen Projekten beginnt bzw. diese durchplant?

Mit Dritten als Auftraggeber:

Phase 1 - Einstieg ins Projekt

1. Grenzen des Systems bestimmen -> danach weißt Du grob, worum es geht, wichtiger aber: was nicht umzusetzen ist.
2. Innerhalb der Systemgrenzen identifizierst Du Anwendungsfälle - immer noch sehr grob. Dabei überlegst Du Dir auch, wer von den jeweiligen Use Cases (auch mittelbar) betroffen ist.
3. Du definierst ein Minimum Viable Product (MVP), wählst also die Anwendungsfälle aus, die ein erstes, gerade noch einsetzbares System ausmachen.
4. Aus den in 3. ausgewählten Use Cases wählst Du möglichst solche aus, an denen das Projekt scheitern könnte. Die siehst Du Dir dann im Detail an und setzt sie um (je nachdem, ggf. nicht alle). Feedback einholen.

Am Ende dieser ersten Phase solltest Du einen kleinen Teil des Projekts umgesetzt und etwas Einblick in die Materie erhalten haben. Außerdem solltest Du an der Stelle auch wissen, ob es sich lohnt, weiter zu machen. Wenn nicht, wäre das ein guter Zeitpunkt, das Ganze einzustampfen.

Phase 2 - weitere Iterationen

1. Berücksichtige Feedback aus der vorherigen Iteration. Dieses kann sich auf Anforderungen, den Entwurf aber natürlich auch das Programm auswirken.
2. Wähle weitere Anwendungsfälle aus, die umgesetzt werden sollen (zuerst natürlich diejenigen aus 3.)
3. Analysiere die Anwendungsfälle wieder im Detail und setze sie um. Dabei das zuvor erhaltene Feedback berücksichtigen. Danach: neues Feedback einholen.
4. Nächste Iteration (falls notwendig): weiter mit 1

Das ist mal eine Vorgehensweise grob umschrieben. In der Praxis findest Du dieses Prinzip in verschiedenen Ausprägungen (auch andere Terminologien und "Formalismen" sind gebräuchlich), letztlich machen aber alle das gleiche: Schritt für Schritt vom Groben ins Feine. Grundsätzlich ist nichts in Stein gemeißelt.

Klassen, Vererbungshierachie, Instanz-/Klassenmethoden, usw. ....

Naja, das ist Bestandteil eines jeden Entwurfs. Visualisieren ist grundsätzlich eine gute Idee, verhaspel Dich aber nicht in irgendwelchen UML-Details. Ein paar Kästchen, Striche dazwischen und gut ists, am besten einfach auf Papier (Bleistift). Es geht nicht um das Diagramm, sondern um die Zusammenhänge.

Wenn Du Dein eigener Auftraggeber bist, ist Punkt 1 aus Phase 1 besonders wichtig. Wenn Du Dir nicht selbst eine Grenze setzt, wirst Du sonst nie fertig. Sollten Dir während des Projekts weitere Wünsche in den Sinn kommen: aufschreiben fürs Folgeprojekt.

Und noch was: glaube nicht, dass das ein Durchmarsch wird. Du wirst des öfteren etwas korrigieren/über den Haufen werfen müssen. Das ist normal.

 

[temi]

Das hat jetzt nicht unmittelbar mit der Planung von Softwareprojekten zu tun, sondern eher mit deren Umsetzung, aber:

Was leider beim Lernen von Java häufig ausbleibt, bzw. ausgelassen wird, ist das frühzeitige Verwenden von Tools, die einem bei der Entwicklung unterstützen. Aus eigener leidvoller Erfahrung, bleibt da auch viel Zeit auf der Strecke, bis man da einigermaßen durchblickt. Aber irgendwann kommt man an die Stelle, wo man etwas ausprobiert, das schiefgeht und man leider immer noch keine Versionsverwaltung einsetzt, um den Versuch schnell rückgängig machen zu können. Oder man möchte externe Bibliotheken einsetzen (was ja sehr sinnvoll ist) und liest in deren Beschreibung "Maven" oder "Gradle" und fragt sich nur noch: Was wollen die da von mir?

Darum sollte man sich, sobald man mit der Programmiersprache an sich gut zurecht kommt, unbedingt auch mit Buildtools, Versionierung und Testen auseinander setzen, also z.B. mit Maven/Gradle, Git und JUnit, ungefähr in dieser Reihenfolge.

Gerade bei einem kleinen Projekt, kann man da noch gut experimentieren ohne sofort die Übersicht zu verlieren.

EDIT: Leider habe ich keine gute Adresse, wo eine taugliche Einführung in alle diese Themen gemacht wird. Als Buch kann ich höchstens "Der Weg zum Java-Profi" von Michael Inden nennen, das neben guten Programmiertechniken auch auf solche Sachen eingeht.

 

[LimDul]

Neben den bereits sehr guten Vorschlägen will ich auch noch meinen Senf ergänzen.

Bleib agil, nutze die Refaktoring Möglichkeiten der IDE. Dementsprechend halte ich es nicht für sinnvoll zu viel vorher zu planen und dann erst umsetzen. Es gibt das durchaus wahre Sprichwort "Planung ersetzt Zufall durch Irrtum".
Einen grobes Schema, wie man es strukturiert, was man für Komponenten hat - das ist definitiv sinnvoll. Aber die schon komplett auszumodellieren, eher selten.

Man neigt da dann gerne zum over-engineering. So würde ich empfehlen, auf Vererbung weitestgehend zu verzichten und lieber auf Komposition zu setzen. Wenn man merkt, man hat zwei Klassen die gemeinsame Schnittstellen / Funktionalität habe und ich habe einen Mehrwert, wenn ich den abstrahiere => Refaktoren und idealerweise gemeinsames Interface oder Oberklasse extrahieren. Aber nicht von vornherein eine komplexe Vererbungshierarchie ausdenken. Objekt-Orientierte Programmierung heißt nicht Vererbung!

Ein Beispiel von mir aus der Praxis.

Ich hatte einen fachlichen Teilaspekt, der fachlich komplex war und in Software gegossen werden sollte. Der sollte hatte sehr flexibel sein, viele Möglichkeiten bieten, einfach zu konfigurieren sein hinterher in der Anwendung und am Horizont stehende Anforderungen bereits perspektivisch berücksichtigen. Ist im Endeffekt eine Quadratur des Kreises und irgendwo wird man Abstriche machen müssen bei sowas.

Ich hab mich also ein paar Stunden hingesetzt, in Umlet etwas gemalt und einen groben Schnitt was landet wo gemacht. Die Anforderungen (und Modellierungs-Varianten die ich ausgeschlossen habe) in eine Mini-Powerpoint gepackt. Dann einen Termin mit 2 Kollegen von mir gemacht, die auch viel Erfahrung mit Modellierung solcher Aspekte haben und mit denen das diskutiert. Da kam dann im Brainstorming eine neue Variante raus, die definitiv besser war.

Die also aufgemalt und ein gutes Gefühl bei gehabt. Angefangen umsetzen. Im Rahmen der Umsetzung festgestellt - Ja, das trägt, aber den Vererbungen was geschraubt, Interfaces eingezogen, Datenmodell etwas geändert, etc. Sprich, nochmal (wenn nur noch an relativ wenigen Stellen) umgebaut.

Zum Code-Review gestellt. Vom Kollegen der das Review gemacht hat Anmerkungen bekommen und basierend auf den Anmerkungen noch mal Änderungen am Modell vorgenommen (Diesmal nur minimal)

Da sieht man, dass das, was man am Anfang sich überlegt, wenn man dann auf die Praxis kommt immer noch - teilweise großen - Änderungen unterworfen ist. Dementsprechend so viel modellieren, das man das Konzept, die Zuständigkeiten etc. definiert hat. Ob die Methode nun Apfel oder Birne heißt oder es vielleicht zwei Methoden werden - Implementierungsdetails.

Das wichtigste ist - Refaktoren, sobald man merkt, man packt jetzt in eine Klasse/Komponente Dinge rein, die da eigentlich nicht rein sollten. Oder wenn man feststellt, die Methode/Klasse wird länger und länger. Mit steigender Erfahrung wird das Abstraktionslevel immer höher und man macht mehr Dinge von Anfang an sauberer, die Einheiten die man betrachtet werden größer etc. Aber das Prinzip bleibt gleich.