Konzept - Länge?

So, nun endlich nach langer und reifer Überlegung, schreiben wir unser 1. ernstegmeintes Konzept.
Welche Frage uns aber quält ist diese, das wir öfters hören ein Konzept muss 20 - 30 Seiten lang sein. Reicht es nicht, wenn es zwischen 5 und 10 Seiten hat, wenn man es auch auf Anhoeb versteht, was gemeint ist?

> wenn man es auch auf Anhoeb versteht, was gemeint ist?
NEIN! *G*
Genau dieses 'ich versteh schon was gemeint ist', führt zu unwahrscheinlich großen Missverständnissen. Schreibe lieber ein Satz zuviel als ein Satz zuwenig. Gerade im Team kann es dann sein, dass zwei Module absolut nicht passen.
Man kann nie sagen wir groß ein Konzept sein sollte, es kommt darauf an, wie umfangreich euer Produkt sein sollte.
Wichtig ist unter anderem, dass ihr Abläufe beschreibt. Also Abläufe des Seitenablaufes, Abläufe wie der Benutzer eine konkrete Aktion ausführt und Abläufe wie zum Beispiel ein Schiff gebaut wird. Welches Objekt mit welchem agiert (sowohl spielerische Objekte, als auch technische Objekte).

Ich find diese Längenangaben unsinnig.
Ich bin "Kurzschreiber", wofür einige 20 Seiten brauchen, um etwas auszudrücken, brauche ich nur 5, ohne dabei auch nur ein Fuzzelchen an Information weniger zu vermitteln als das halbe Buch.

Ein hoher Detaillierungsgrad im Konzept zu einem sehr frühen Zeitpunkt verursacht in meinen Augen Aufwand der sich nicht auszahlt, außer das Team ist sehr groß und Programmierer != Konzeptersteller oder man hat Programmierer die nur nach Vorgaben arbeiten. Bis die Implementierung bei den Details ankommt, gibt es teilweise gravierende Änderungen was dazu führt, dass man Stunden mit Details vergeudet hat, die nie ins Spiel gelangen. Wem es an Nachlektüre mangelt, der kann dann zig Revisionen des Konzeptes vergleichen mit dem Stand der am Ende ins Spiel gelangt. Teilweise geht es mir in der Konzeptphase so, wie Kindern im Spielzeugladen. Arm weit ausbreiten und am liebsten alles (r)einpacken. Bin ich dann in der Implementierung sehe ich das Konzept mit anderen Augen und frage mich bei einigen Sachen warum ich an dieses oder jenes Detail nicht schon vorher gedacht habe. Nur diesen Blickwinkel für das was fehlt, habe ich erst beim Implementieren. Irgendwie paradox

Nun ja, derzeit beträgt unser Konzept (heute angefangen) 4 Seiten (incl. Titelblatt und Inhaltsverzeichnis). Tatsächliche Textlänge sind ~1,5 Seiten.

Hmm...
Codingstyleguide.odt = 17 Seiten
Grobkonzept_Anwendungssicherheit.odt = 9 Seiten
Grobkonzept_Datenstrukturen.odt = 5 Seiten
Grobkonzept_Kampfsystem.odt = 18 Seiten
Grobkonzept_KolonialKampf_v5.odt = 61 Seiten
Grobkonzept_Maildaemon_v0.1.odt = 9 Seiten
Grobkonzept_Serverkonfiguration.odt = 5 Seiten
Teilweise noch im Entwurfsstatus und noch nicht vollständig.
Ok... Beruflich vorbelastet... ich schreibe lieber mal mehr, als etwas zu wenig

Also ist es sinnvoll, das Konzept in mehrere Dateien zu unterteilen?
[SIZE=10][ot]hehe, auch jemand der OpenOffice benutzt.[/ot][/SIZE]
Edit:// Andere Frage, welche wichtigen Punkte sollte ein Konzept auf jeden Fall beinhalten?

Bitte nimm nicht meine Liste als Vorschlag.
Ich komme aus dem Bereich der Systemprogrammierung/Webentwicklung und bin von Beruf her Programmierer. Alleine schon durch meine Ausbildung habe ich einen vollkommen anderen Blick auf die Softwareentwicklung und erstelle Teilweise auch Dokumente, welche euch nichts bringen würden, oder wo deren Verwendungszweck nicht klar ersichtlich ist ohne das notwendige Hintergrundwissen.
DU als "Projektleiter" definierst welche Dokumentation du für notwendig befindest. Wenn ein "Schmierblatt" als Konzept reicht für dich, dann reicht das auch aus

Es gibt unglaublich unterschiedliche Stadien von Konzept.
Sobald ich Zeit habe, schreibe ich noch ein paar mehr Fausregeln - im Moment verweise ich zur Diskussion von Designdokumenten (Konzepten) auf meinen Artikel zum Thema:
Game Design Dokumente als Gattungsbegriff
Download unter www.x-gd.de/download.php?view.1

Interessante Ansätze.
Aber unsere QSler in der Firma würden mir den Hals umdrehen wenn ich ein Wiki für die Doku nehme *g*
Wenn es nicht wegen dem Streß wäre, würde ich das sogar mal versuchen wollen. Hat einige Vorteile

Es gibt aber Wikis, die zumindest ins .odt-Format exportieren können. Hab ich erst vor kurzem gesehen. Fand es aber nicht so wichtig, weil ich gedacht habe, dass ich so etwas eh nie brauche. Dem Dokument hat man gar nicht angesehen, dass er aus einer Wiki kommt. Zumindest nachdem man bei der Nummerierung der Kapitel etwas nachgeholfen wurde. Fragt mich aber nicht nach Namen, ich tue mir echt schwer mir solchen Kram zu merken.
Aber wenn, dann würde ich gleich ein Mindmapping-Tool verwenden. Vym exportiert meines Wissens auch nach .odt. Und für solche Arbeit finde ich solche Tools pratkischer, da man das große Bild eher vor Augen hat.
Und von .odt nach .doc ist es dann nicht mehr ein großer Schritt. Für den Fall das ihr MSOffice einsetzt. Ist ja heutzutage ja auch nicht mehr so selbstverständlich, wie ich unlängst feststellen musste.
So zumindest die Theorie, wie es in der Praxis läuft kann ich nicht sagen.

Ich setze hier auf UML.
Use-Cases mit bunten Bildchen sagen mehr aus als die längsten Texte. Und ein:
Spielerklick -> tue dies -> tue das -> wenn noch was is dann auch noch das -> zeige es an
ist übersichtlicher als ein 3-Seitiger Text.
Die Erfahrung habe ich als Software-Engineer (sozusagen als Schnittstelle zwischen Kunden und Codern) gemacht.
Mit UML kommt man schön vom "Kunden" bis runter zu dem, was auch der Mathematiker im Keller versteht.
Erheblich einfacher als hunderte Dokumente zu schr eiben.
Nachdem man sich auf ein "Grobkonzept" (Use-Cases) der Funktionalitäten geeinigt hat, lassen sich her evolutionär (also Modul für Modul", Klassendiagramme) einzele Module Stück für Stück feinkozeptionieren (Status-Transitionen, Aktionsdiagramme, Interaktionsdiagramme) und dann implementieren (ich favorisiere den XP-Ansatz).
[OT]OO und ArgoUML[/OT]