@Amelie Wenn das nur für Dich selbst ist, ist das halb so wild.
Firman sollten da bessere Anhaltspunkte liefern.
Für Dich:
Schrfeib einfach detailliert auf, was das Programm können soll.
Schreib auf, was es nicht unbedingt können muss, so wqas kommt dann in die nächste Version.
Je detaillierter das ist, um so besser.
Nun formulierest Du Arbeitspakete, das sind disjunkte Teilaufgaben, die sich mehr oder weniger abhängig von erledigten Arbeitspaketen in einem separaten Projekt lösen lassen.
Also:
Sortiere die nach der Abhängigkeit von anderen Arbeitspaketen.
Erledige die zuerst, die keinen Bezug zu anderen Paketen haben.
Wenn Du dann jedes Paket in einem separaten Projekt abarbeitest, hast Du hinterher eine Menge Snippets, die Du Deiner Sammlung hinzufügen kannst.
Die stahen dann als bereits erledigte Arbeitspakete für die nächsten Projekte zur Verfügung.

Amelie schrieb:

wie gehts dann am besten weiter?

Lass uns zunächst abstrakt über Dein Vorhaben reden, zunächst ohne Bezug zu iwelchem eigenen Code.

Amelie schrieb:

Erst der Code oder erst das Layout oder mischt man?

Layout würde ich nur das Nötigste machen, damit der Code einen Sinn ergibt. Natürlich kannst Du viele Layout-unabhängige Codeteile schreiben. Aber irgendwann brauchst Du ja auch die Interaktion mit dem User. Aber bloß nicht verkünsteln. Mach Dir zwar Gedanken über das, was gebraucht wird. Aber schön(er) kann es später immer noch werden.

Amelie schrieb:

woran erkenne ich nun ob ich mit meinem Code in OOP arbeite

Indem Du nicht alle Aufgaben im Hauptform verarbeitest. Das Teil ist eigentlich nur zur Anzeige und zur Interaktion mit dem User da. Die eigentlichen Arbeitstiere sollten Klassen(objekte) sein. Dazu fällt mir was ein: WinForms Projektentwicklung bzgl. der Rolle des Formulars

Ich finde, das ist schon der zweite Schritt vor dem ersten.
Der erste Schritt war schon ganz richtig: Sich klarwerden, was man programmieren will - etwa durch Erstellung eines Lastenhefts.
Hmm - Der Thread fing aber mit dem Pflichtenheft an.

Also bei uns in Firma gelten folgende Definitionen:

• Das Lastenheft beschreibt, was programmiert werden soll (also was soll das Programm tun?)
  
• Das Pflichtenheft wie (welche Technologien setzen wir ein, es zu erreichen?).

Wenn es kein Lastenheft gibt, ist also nicht definiert, was programmiert werden soll.
Wie aber kann man dann ein Pflichtenheft erstellen - also die Frage beantworten wie man das programmiert, was man sich vorgenommen hat - wenn da garnichts ist?

Also fangt am besten gleich mit dem vierten oder fünften Schritt an, mit Überlegungen zu Layout und Code (Datenmodell überspringen wir sowieso) - lange bevor überhaupt klar ist, was programmiert werden soll, und wie.

Amelie schrieb:

Was ich als Übung machen möchte weiß ich ja.

RodFromGermany schrieb:

Lass uns zunächst abstrakt über Dein Vorhaben reden, zunächst ohne Bezug zu iwelchem eigenen Code.

Amelie schrieb:

OK, was möchtest du wissen....?

Da springe ich mal für RFG in die Bresche: "Was ist dein Vorhaben?" möchte er wohl wissen.

@Amelie Ich programmiere ja auch nur in meiner Freizeit, von daher schreibe ich kaum Dokumentationen. Außer für Programme, die vorzeigefähig sind und groß genug sind, um sie in einem Bewerbungsgespräch erwähnen zu können. Und dann sage ich nicht Pflichten- und Lastenheft , sondern eher nach dem Motto

Dieses Programm dient dazu, das und das zu können. Im Gegenzug zu einem aus dem Netz geladenen Programm kann meines das und das tun. Es ist so gedacht, dass..... Hierbei hatte ich die und die programmiertechnischen Herausforderungen zu lösen, dass habe ich gemacht mittels (kurz umreißen).... Der Vorteil ist, dass nun die GUI nicht hängt,.... Außerdem habe ich darauf geachtet, dass der Benutzer keine falschen Eingaben machen kann. ..

Ich erwähne am Rande auch gerne, dass die Creation Time nicht dasselbe ist wie die Aufnahmezeit des Fotos
Wichtig ist noch als „Vorwort“ zu erwähnen, dass du dich an sämtliche Standards gehalten hast, damit klar ist, dass der Code somit flüssig läuft und nachvollziehbar ist, und der RAM nicht vollgemüllt wird.

Das Einzige, was ich wirklich vorbereite, ist, dass ich gerne mal etwas aufzeichne, wie zum Beispiel in Post #30 meines Kantendetektion-Threads. Mit Papier, Bleistift und Taschenrechner kann ich einfach am besten nachdenken.

Aber alles gut, denn ich arbeite schließlich nicht als Softwareentwickler. Ich wollte dir nur mal meine Meinung aufdrängen. *Nein, Spaß*

Im Ernst: ich nutze für die Dokumentation ganz normales Word und Powerpoint und gute Screenshots. Wenn du willst, kannst du zur Overleaf-Seite gehen und mit LateX schreiben. Dort kannst du dir das Ganze auch als pdf runterladen.