Also:
Lastenheft, Pflichtenheft.
Im Lastenheft wird aufgeschrieben, was der Kunde / Nutzer haben will. Vom grünen Button bis zu Wolkenkukuksheim, negativen Kosten und negativen Laufzeiten und all das sinnlose und sinnvolle Zeugs halt.
Im Pflichtenheft auf Basis dieses Lastenhefts wird aufgeschrieben, was der Entwickler dann tatsächlich implementiert, da sollte eigentlich nur sinnvolles Zeugs drin stehen.
Dieses Pflichtenheft wird von allen Beteiligten (Kunde, Firma / selbst) unterzeichnet und hat dann den Status eines Vertrages.
Dies ist dann die Spezifikation, nach der das Produkt getestet wird.
Noch mal also:
Mach eine gute und detaillierte Spezifikation, eas das Programm können soll, aber auch, was es nicht können soll (z.B. Speichern über FTP oder so). Da kann dann auch stehen: Ab Version 2.0 oder so.
Eine schlechte Spezifikation führt immer zu Ärger, im schlimmsten Fall wird die Leistung nicht bezahlt.
Wenn dies alles steht, werden die ersten Tasten gedrückt.

Das hängt von Deiner Erfahrung und dem Füllegrad Deiner Trickkiste ab.
Außerdem ist es hilfreich, Kollegen um sich zu haben, neben dem Forum natürlich.

mehr allgemeine Vorschläge, als nach der Erstellung des Pflichtenheftes anzufangen kann man glaub nicht geben - kommt auf den Einzelfall an.
Nach meiner Erfahrung (ist auch nicht viel) ergibt sich immer die Notwendigkeit, ein Datenmodell zu erstellen.

Eiglich klingt Backup-Software ja total einfach, aber es ist sicherlich einiges zu konfigurieren: welche DBs zu backupen sind und in welchem Intervall.
Und dann braucht man vmtl. eine Aufstellung der Backupse, und vlt. Konfigurations-möglichkeiten für die Wiederherstellung.

Halt für so Sachen muß ein Datenmodell her, wo der User seine Eingaben machen kann, und dann bei Klick - Abfahren.
Und das Datenmodell muss natürlich persisteable sein, also es muß auch die Buttons "Load Config" und "Save Config" geben oder sowas.

Ach - und betrachte das Pflichtenheft nicht als in Stein gemeißelt: Tun sich während der Entwicklung neue Optionen auf, oder stellen sich bestimmte Pflichten als idiotisch heraus, oder mit anneren Ansätzen viel eleganter umzusetzen, dann besteht sauberes Programmieren darin, Rücksprache zu halten, und das Pflichtenheft zu modernisieren.

Kann übrigens auch sein, dass dem Kunden noch iwas einfällt, um euch auf die Nerven zu fallen. Das ist sein gutes Recht, und kost ja auch extra, und's sichert eure Arbeitsplätze - also freut euch drüber.

Mir hat nach den ersten beiden genannten "Phasen" geholfen, erstmal ein wenig zu konzeptionieren.

Dazu habe ich mir das Lastenheft ausgedruckt und dort erstmal geschaut, was irgendwie zusammen gehört und was nicht. Dazu einfach ein paar Bundstifte her und farblich markieren, was zusammen gehört.

Bspw. Gehört Sichern und Rücksichern zusammen, aber Sichern gehört nicht zum Auswählen, was gesichert werden woll (Das wäre Businnes und im Gegensatz dazu Benutzerinterface bzw. Benutzer-Steuerung).
Also kannst du dort auch super (wie du siehst) trennen, was zum Buseinnes gehört und was zum Benutzer gehört.

Danach würde ich beginnen, was alles zum Businnes gehört: Was muss es können, was wird dafür benötigt, auf was kannst du da zurück greifen etc pp.. Dort bist du dann auch schon beim technischen.

Zu den einzelnen Teilen vielleicht noch PAP´s (evtl. Komponentendiagramme, wenn du es dann schon kannst => Mir hat dazu allerdings schon spezifischer Code gefehlt).

Dann würde ich - mit diesen PAP´s, evtl Komponentendiagrammen und zumindest einer Liste der benötigten Klassen - anfangen das Businnes zu implementieren.
Dazu deine Unittests, damit du es immer testen kannst zwischen drin.

Wenn das alles funktioniert, is tder größte Teil neben der Dokumentation schon getan, das Benutzerinterface stellt vor allem in dem Projekt dann nur noch einen kleinen Teil da, der eben "nur noch" implementiert werden muss und deine geschriebene Klassen-Bibliothek nutzt.

fichz schrieb:

was sind PAPs?

Programm-Ablauf-Plan.
Eher ein Relikt aus der Nicht-OOP-Zeit.
Da wurde der logische Ablauf mit schönen Symbolen aufgemalt:
If Bedungung True ==> Dies; False ==> Jenes
Springe hier hin, mach da weiter und solch.
Gemalt sieht das ganz nett aus.

Ich persönlich bin kein Freund von Programm Ablauf Plänen.
Aber in bestimmten Fällen, zeichne ich mir ein Struktogramm.
Nicht für das gesammte Programm nur für einzelne Algorithmen.
Dafür habe ich mir ein Whiteboard gekauft.
Ich denke aber dass ist geschmackssache, ich persönlich komme beim zeichnen des Problemes schneller zur lösung.

Noch was zum Thema Lasten- und Pflichtenheft. Ich schreibe das mit Hand in ein normales karriertes A4 Schulheft.

Nassi-Shneiderman-Diagramm

also von so Diagrammen bin ich ja nicht so der Freund, und grad der verlinkte Wiki zeigt meine Bedenken schön auf: Da gibtsn Nasi-Diagramm für eine Funktion, und das hat in der Darstellung einen größeren Platzbedarf als die beschriebene Funktion selbst.
Da guck ich doch lieber gleich die Funktion an, die kannich nämlich auch testen.

ERM-Diagramm zur Datenmodellierung findich gut, das ist ja im VS eingebaut.

Und EBC-Diagramme findich toll, weil die bilden tatsächlich den Datenfluss ab - was im Code nicht so erkennbar ist. Aber EBC-Programmierung ist ein ganz spezieller Architektur-Pattern - guggemol Multi-Tutorial

Ich selbst male die Diagramme auch ungern, zumal sie wirklich nicht viel zeigen, aber ich finde sie manchmal einfacher als Code, wenn ich irgendwo nicht auf die Lösung komme.

Vor allem wenn ich mir zu bestehendem Code PAP´s zeichne, fallen mir leicher ungereimtheiten auf, bspw. wenn ich irgendwo etwas sinnlos doppelt lade oder anderen unnötigen Content drinne habe.

Dizzy schrieb:

Noch was zum Thema Lasten- und Pflichtenheft. Ich schreibe das mit Hand in ein normales karriertes A4 Schulheft.

Lasten- und Pflichtenhefte sind (bei Firmen) juristische Dokumente, die gehören nicht in ein Schulheft, da kommen nämlich Stempel und Unterschriften drauf.
@fichz: Unterscheide gleich am Anfang zwischen Must Have und Nice to have. Setze Prioritäten von 1 bis 10, wenn alle Posten die Priorität 1 haben, ist was schief gelaufen.
Die Aussage "Wird erst in Version 2.7 angegangen" ist völlig in Ordnung.
Ein Auto muss fahren können; welche Farbe es hat, ist primär egal.

wie vlt. angeklungen: Es gibt da ein Spannungsfeld zwischen strukturierter Vorgehensweise und gleichzeitig erheblicher Flexiblität. Zw. Top-Down- und Bottom-Up-Developping, zw. Planung und Entwidklung.

Die Projektplanerei grad inne Softwäre-Branche hat da glaub geniale Organisations und Management-Konzepte entwickelt, gugge zB. agile SoftwareEntwicklung

Haben wir eiglich auch BrainStorming mal erwähnt?
Es ist ja möglich, dasses verschiedene Ansätze gibt, was zu lösen: Suche ich mir meine Backup-Elemente in einem Treeview aus? Oder OpenFileDialog? Oder ziehe ich die aussm DateiExplorer auf die Anwendung?
Kann man nicht immer von vornherein entscheiden, und kann auch sein, dass man mal ein oder zwei Proof-of-concept-Projekte schreibt, um was vom späteren Look-and-Feel erahnen zu können.

Aber:
Dies wird normalerweise von der Firma vorgegeben und ist auch abhängig vom jeweiligen Produkt.
Die Software, die ein Laserskalpell bei Augenoperationen steuert
oder
eine Ariadne-Rakete ins All steuert
wird ein wenig anders entwickelt als eine Foto-Bearbeitungs-Software.
Allerdings nur eine winzige Spur.

fichz schrieb:

"Freiraum"

Aha, das hättest Du vllt. im Eröffnungspost erwähnen können.
Trotzdem ist es wichtig, sich bei einer solchen Gelegenheit auch über interne Codierungsrichtlinien Gedanken zu machen, da spart Ihr Euch viel Ärger, wenn gelegentlich Praktikanten was machen.

fichz schrieb:

von dem "alten" Schema welches wir derzeit haben zu lösen

Da kommen ggf. Probleme auf Dich zu, von wegen Kompatibilität, insbesondere bei Datenbanken.
Vielleicht bist Du so stark, durchzusetzen, dass nun, da die Gelegenheit da ist, den Quantum Loop zu machen und keinerlei Kompatibilitätskriterien beachten zu müssen.