Also ich bin jetzt kein gelernet Anwendungsentwickler, fange aber bald an. Trotzdem geb ich dir mal ein paar Tipps wie ich das mache.
Zuerst mache ich mir mal Notizen zu dem Projekt, z.B. was für Funktionen, ungefähres Aussehen, ...
Danach sortier ich mir das erstmal, streiche unnötiges und verbessere es. Je nachdem erstelle ich dann auch ein PAP (Programmablaufplan). Dafür benutze ich dann je nachdem wie umfangreich es wird das Programm: heise.de/download/papdesigner.html
Zudem erstelle ich mir dann noch extra Notizen zu bestimmten Programmfunktionen wie sie aufgebaut sind und was für einen Nutzen sie haben.
Das meiste davon schreibe ich auf Blätter.

Ich hoffe ich konnte dir helfen.

Im Normalfall solltest du zuerst wissen, was für Voraussetzungen gegeben sind, und wie du an die Sache rangehst. Am Ende des Projekts wiederum solltest du nachweisen können, was du gemacht hast.
Für die "Home"-Projektchen, die hier viele so machen, hat man diese Sachen (Wohin "fließen" die Daten, Thema Cloud, wie läuft das Programm im Detail ab) im Kopf, und ist auch niemandem als sich selbst Rechenschaft schuldig.

Bei den "großen Jungs" kann es natürlich sein, dass du jemandem ein Programm erstellst, und dann - als Teil der Vereinbarung - den Quellcode abgibst. Hier ist es natürlich von Vorteil, dass jeder einzelne Schritt nachvollziehbar ist.

Anmerkung: Meine Ausbildung ist schon eine Weile her. Ich kenne die Personen, die eine EXE-Datei haben wollen, die läuft, aber auch die Firmen, die - berechtigerweise - Einsicht in den Quellcode und jeden einzelnen Vorgang haben wollen.

Eine wichtige Frage ist: Welchen Umfang hat das Projekt. Je umfangreicher es werden soll, um so mehr Vorarbeit ist zu tun.
Das Projekt soll doch nicht schon vor der Beta-Version hoffnungslos veraltet sein.
Also: Ein klares Konzept:
Philosophie (PlugIn, DLLs, benötigte Hardware, zu unterstützende Betriebssysteme, Programmiersprache).
Daten (Source, Speicherung, weiterleiten an LAN, Server, ...).
Handling (GUI, Prozess-Abläufe, Algorithmen, ...).
Schutz (Verriegelung von Prozessen, Threads, Quellcode, Dongle).
usw.

Programmablaufwas? Wenn jemand versuchen würde, mir PAPs als modernes Werkzeug nahe zu bringen, würde ich mich höflich bedanken, aber zügig rückwärts den Raum verlassen. Im Ernst: Wenn, dann bedient man sich heute (einem Dialekt von) UML. Das zählt eine Vielzahl aller möglichen Diagrammtypen, derer man sich nach Bedarf bedient. Die fünf wichtigsten fasst Wikipedia in einem Schaubild zusammen, dabei findest du die von dir erwähnten Diagrammansätze im rechten Teil.

In richtig großen Projekten, die nach (aktuellem) Lehrbuch durchgezogen werden, wird erst einmal ein UML-Modell erstellt.
Da macht man Tool-gestützt. z.B. mit Enterprise Architect.
Der hat eine bidirektionale Schnittstelle zu den wichtigen Entwicklungswerkzeugen wie Visual Studio.
Damit kann einerseits der Coderahmen für Visual-Studio erzeugt werden und andererseits werden Veränderungen im Visual-Studio (sofern bestimmte Normen eingehalten werden) gleich im EA-Modell automatisch nachgezogen.

Insbesondere in Projekten, an denen viele Mitarbeiter parallel (und/oder nacheinander) arbeiten, bringt das wesentliche Vorteile.
Es ist aber auch ein Riesen-Overhead, der sich für ein Hello-World-Projekt nicht lohnen würde.

Bei diesem Vorgehen beträgt der Zeitaufwand fürs Coding maximal 20% des Gesamtprojekts.

Ein "normaler Anwendungsentwickler" in solchen Projekten codiert hier nur einzelne Module nach Vorgabe (und hält sich dabei streng an die vorgegebenen Normen).
Das Gesamtmodell wird von erfahrenen Software-Architekten vorgegeben.
Oft werden für die Grundarchitektur Design-Patterns verwendet.

Klassische Programmablaufpläne stammen aus dem letzten Jahrtausend und finden in modernen Software-Architekturen eher selten Anwendung.
Objektorientierte Programmierung lässt sich damit nur rudimentär abbilden.

Wie oben schon geschrieben wurde:
Je kleiner das Projekt ist, desto grösser ist die Wahrscheinlichkeit, dass die Architektur im Kopf des Entwicklers stattfindet und die Dokumentation im oder aus dem Code erfolgt.
Ähnliches gilt für Datenbankmodellierung.
Bei kleinen Projekten erzeuge ich erst mal die Tabellen und Beziehungen in der Datenbank und lasse mir für Präsentations- und Dokumentationszwecke das Datenmodell von der DB generieren.

Wenn ich große Programme schreibe dann mache ich mir eine MindMap oder den Editor für einzelne Funktionen.

Was haltet ihr eiglich von EBC als Architektur-Ansatz und Konzeptions-System?

Weil das Uml was ich bisher gesehen habe war entweder zu abstrakt und hat im Grunde garnichts ausgesagt, oder es war zu detailliert, und wurde daduruch so umfangreich, dass man sich einfacher im ProgrammCode selbst orientieren konnte. Iwie scheint mir UML selbst sehr prozedural orientiert, während EBC-Diagramme eher Objekte abbilden, und wie deren Input und Output zusammengestöpselt wird.

Ricky schrieb:

MindMap oder Editor

Ist jetzt eher ungewöhnlich.
Wie groß sind denn deine "großen" Programme?

ErfinderDesRades schrieb:

Was haltet ihr eiglich von EBC als Architektur-Ansatz

Ich habe noch nie damit gearbeitet.
Entspricht das nicht in etwa einem UML-Sequenzdiagramm?

Weil das Uml was ich bisher gesehen habe war entweder zu abstrakt und hat im Grunde garnichts ausgesagt, oder es war zu detailliert

Ich mag's aus demselben Grund auch nicht besonders.
Es ist unheimlich schwer, den optimalen Mix in der Genauigkeit zu treffen.

Meist sind die Diagramme anfangs zu detailliert und gegen später zu flach