@MajorOli In der realen Welt gibt es Design-Vorschriften, Design-Werkzeuge, Lastenhefte und wenn man Glück hat Pflichtenhefte. Und dann gibt es noch Testprojekte.
Diagramme sind was für Manager, die keine Ahnung von der Softwareentwicklung haben.
Design-Vorschriften legen sowohl fest, wie GUIs auszusehen haben als auch wie Quellcode auszusehen hat.
Also z.B.:

• Klassen mit maximal 1000 Zeilen Quellcode ohne Kommentare, Prozeduren mit maximal 100 Zeilen ohne Kommentare, Verschachtelungstiefe, Namensgebung, Format der Header-Kommentare usw.
  
• Design-Werkzeuge generieren einmal Diagramme für Manager und zum anderen überwachen sie den gerade geschrieben werdenden Quellcode auf Einhaltung der Design-Regeln.
  
• In Lastenheften beschreibt der Kunde oder das Produktmanagement, was er / es will,
  
• in Pflichtenheften beschreibt die Softwareentwicklung, was davon wie getan wird und was nicht oder später gemacht wird.
  
• Testprojekte kann man automatisch generieren lassen, da wird für jede Klasse, jede Prozedur ein (zunächst leerer) Aufruf generiert, der dann ausgefüllt werden muss.
  Ziel ist, den gesamten Quellcode abzudecken, alle denkbaren Fälle aufzulisten und dann in automatischen Prüfläufen die Tests ablaufen zu lassen.
  Damit wird gesichert, dass beim weiteren Programmieren kein Unsinn verzapft wird.
  

RodFromGermany schrieb:

Diagramme sind was für Manager, die keine Ahnung von der Softwareentwicklung haben.

Wobei ich minimal eingrenzen würde: Von SWE im weiteren Sinne (Projektmanagement etc.) haben sie vlt durchaus die Ahnung, und vlt gibts in dem Metier auch sinnvolle Diagramme.
Aber Code stellt sich am besten selber dar.

Obwohl: Bei konsequenter Entwicklung nach EBC (Event-based components) ergeben die Komponenten-Diagramme durchaus Sinn.
Es sind sogar Designer denkbar, mit denen man EBC konziperen könnte, und die dann Rumpf-Klassen generieren können.

Aber scheints setzt sich EBC leider nicht durch.

MajorOli schrieb:

Z.b. ob mit Tab oder Leerzeichen eingerückt wird sowie das der Quelltext für andere leicht lesbar ist.

naja, das ist unwichtig, weil das kann man im Visualstudio jederzeit so umstellen, wies einem am besten gefällt.
Nee - Code-Richtlinien sind viel weitergehend, wie Properties ticken sollen, wann man Methoden nimmt, wann Interfaces etc, pp,
Und alle Richtlinien machen noch immer keinen guten Code, und das ist eben die Haupt-Frage: Wodurch zeichnet sich guter Code aus?
"Messbare" Richtlinien-Einhaltung ist da nur ein klein Detail, hinzu kommen allerlei Prinzipien und Pattern und sonstige Konzepte.

Es geistert eine vielbeachtete "Clean-Code"-Kampagne im INet herum - die haben hervorragendes geleistet für den (wohl niemals endeneden) Diskurs über guten Code.

ich hebe nochmal das Stichwort "Clean-Code" oder "Clean-Code-Developper" - kurz "CCD" hervor.
Dort finden diese Fragen ein System von sehr überzeugenden und praktisch anwendbaren Antworten.

MajorOli schrieb:

wenn z.b. jemand aus einer Fachabteilung eine Idee hat wie was gemacht werden könnte.

Fachabteilung wofür?
Ein Softwareentwickler lässt sich von "unbeteiligten Dritten" nicht vorschreiben, wie er was zu tun hat. Man schreibt ihm vor, was er tun soll. Den Rest erledigen die Softies dann unter sich, es sei denn, die Maschine, die sie ansteuern sollen, funktioniert nicht.
Allerdings:
Es gibt nur zwei Sorten von Softwareentwicklern:

• überdurchschnittliche Softwareentwickler
  und
  
• Spitzen-Softwareentwickler.
  

Ich würde sagen es kommt auf die Größe des Unternehmens an.
Code stellt sich nun mal einem Anforderer nicht am Besten dar.

Ich kenne es so das von den Fachabteillungen oftmals BPMN Modelle kommen um den Prozess zu beschreiben (Siehe Bizagi). Häufig wird mit Excel ein Form Mock up gemacht.

Bei einigen Softwarearchitekten ist UML sehr beliebt. Man ist in der Lage etwas zu schaffen in der beide Welten, Anforder und Umsetzer, eine gemeinsame Sicht haben und eine Diskussionsgrundlage. Hier sei mal Sparx Enterprise Architekt erwähnt.

MajorOli schrieb:

Die Fachabteilung sollte so früh wie möglich bei der Entwicklung mit dabei sein und begleiten.

Wunsch und Wirklichkeit.
Bei einer einzigen Firma habe ich erlebt, dass eine Entwicklung erst beschrieben und dann exakt so durchgezogen wurde.
Da wurden sogar (Software-)Fehler, die in einer Prototyp-Software vorhanden waren, mit vollem Wissen in die Produktsoftware übernommen, nur damit die Ergebnisse (Pixel-)identisch sind.
das Problem ist eigentlich, dass meist bei der Dokumentation gespart wird. So lange dieselben Leute dran arbeiten, ist das kein Problem. Geht jedoch ein alter Mitarbeitr raus und es kommt ein neuer rein, und der findet einen undokumentierten Code vor, dauert das Einarbeiten mehr als doppelt so lange. Ich meine jetzt hier nicht die Bedienungsanleitung, sondern die Kommentare im Code, warum an dieser Stelle dies und jenes gemacht wird.
Das sieht die Fachabteilung nicht. Die sehen nur den Zeitdruck wegen der Auslieferung des Produkts, nicht aber die Notwendigkeit, das Produkt pflegbar zu halten bzw. zu machen.
Also:
Pflichtenheft, da steht drin, was gemacht wird, was nicht gemacht wird (es muss auf jeden einzelnen Punkt im Pflichtenheft eingegangen werden) und warum, und was in eine spätere Version verschoben wird.
Design-Spezifikation, da steht drin, welche PC-Konfiguration (Betriebssystem, Architektur), welche Entwicklungsumgebung, Framework, erforderliche Hardware, Third-Party-DLLs, ...
Das ist wichtig, um dann dem neunmalklugen Kunden, der das ganze auf ein anderes System portiert, zu sagen, dass das Produkt (Hard-, Soft- und Firmware) für diese Konfiguration nicht freigegeben ist.
Hatte ich bereits: Als ich unter Win10 bei einer Kauf-Software Macken entdeckte, sagte man mir, dass diese Software für Win10 nicht freigegeben ist. Dafür sei die (kostenpflichtige) nächste Version zu nehmen.