just_me

[erledigt]

Als gebildeter, informierter und redegewandter Erdenbürger solltest du eigenlich so lustige Akronyme wie gTLDs (Ich lerne schnell. Das Apostroph habe ich schon weggelassen, siehst du!?) kennen, von denen mir scheint, dass sie die "klassische ungarische Notation" (kleingeschriebener Präfix + Bezeichner, welcher bei Akronymen ja in den unterschiedlichsten Schreibweisen existiert) aufweisen. Und da du ja sehr bewandert in der Schreibweise von Akronymen bist oder doch wenigstens zu sein scheinst, und dich offensichtlich vornehmlich für Nebensätze und beiläufige Aussagen interessierst, dachte ich daran, unter Ausbeutung deiner Kenntnisse meine Wissenslücken zu reduzieren. Ist das jetzt ein falscher Zusammenhang? edit: In diesem Zusammenhang habe ich gleich noch eine Frage: Nehmen wir an, ich hätte ein MLA, wie beispielsweise MOTSS. Da hier ja bekanntlich der Plural im ersten Wort zu bilden wäre, müsste ich dann also MsOTSS schreiben, ja? Und wie sieht es aus, wenn ich es Motss schreibe? Kann dann Msotss nicht zu Verwirrungen führen? (Würde ich aber MOTSS's oder MOTSSs schreiben, wüsste eigentlich jeder, dass ich einen Plural meine, oder meinst du nicht?)

@Sandrin Vielen Dank für deinen Hinweis. Ich fürchte, du musst jetzt ganz stark sein: Auch ich bin nur ein Mensch. Enschuldige in diesem Zusammenhang also bitte den Lapsus, der mir beim Versuch, aus Akronymen eine "lesbare Mehrzahl" (Gibt es eigentlich eine deutsche Norm, die klar definiert, wie der (umgangssprachliche) Plural [umgangssprachlicher [anglizistischer]] Akronyme zu bilden ist? Heißt es nun IHKs, IHK's, IHK'n oder ganz trivial IHKn? Und was liest sich flüssiger? Btw, werden manche Akronyme in ungarischer und andere in BL-Notation geschrieben? Wo finde ich einen "Duden der Akronyme"? Würde mich über diesbezügliche Hinweise freuen.) zu bilden, unterlief. Natürlich ist mir klar, dass es in diesem Sinne völlig unentschuldbar ist, dass ich, der ich auf andere Dinge achtete, nicht in der Lage war, umgehend den Sinn des Beabsichtigten korrekt zu deuten. Ich werde mich bemühen, derartige Irritationen (also die eigenwillige apostrophierte Schreibweise meiner Akronyme), die offensichtlich völlig vom Inhalt abzulenken imstande sind, zukünftig weitestgehend auszuschließen. @niki Wie ich bereits sagte, letztlich kannst nur du es entscheiden. "Zu viel für einen Punkt" kann allerdings kaum ein Argument sein, wenn es sich um lediglich 10-15 Seiten und über 20 Gliederungspunkte handelt. Eher wäre wohl das Gegenteil der Fall, nicht?

*lol, eben das ist es, was ich meinte. YAFA = Yet Another Fuc*** Abbreviation TLA = Three Letter Acronym

Heißt es nicht "Entity-Relationship-Modell"? Dann nenne es doch auch so. Welchen Grund gibt es, Gutachter mit YAFA's zu malträtieren? Faulheit? Im Übrigen gibt es für etliche TLA's multiple Bedeutungen: ERM = Entity-Relationship-Modell ERM = Enterprise Resource Management Welches ist denn gemeint?

Letztlich bist du der Einzige, der final beurteilen kann, ob diese Gliederung ausreichend ist. IMO sieht sie okay aus. Zweifel hätte ich - da ohne Kenntnis des Kontextes - noch bei Punkt 4.2 sowie bei der Differenzierung zwischen Punkt 4.3 und 4.4, was auf den ersten Blick den Eindruck der "künstlichen Aufblähung" erweckt. Nochmals: Vorsicht im Punkt 1. Deine Projektdokumentation hat als einziges Thema dein Projekt. Überflüssige Darlegungen, wie die Beschreibung deines Schreibtisches oder den Anfahrtsweg zur Tiefgarage deines Unternehmens haben dort nur dann etwas zu suchen, wenn du a) den Schreibtisch oder die Tiefgarage direkt in den Projekt involviert hast. Werbung für dein Unternehmen (1.1) oder für einzelne Abteilungen (1.4, wenn CyberDemon recht hat) á là "Danken möchte ich Susi. Sie hat mir toll geholfen." hingegen mutet in einer Projektdokumentation eher ... ummm ... interessant an. Ich würde dir in jedem Fall, der nicht unmittelbar mit dem Projekt zu tun hat, sofort unterstellen, dass du Informationsmüll produzieren willst, um Seiten zu füllen. Im Übrigen ist die ausschließliche Verwendung von Abbreviationen in Titeln (3.1.2) nicht gern gesehen. Und schließlich: Was die "Abweichungen" (5.1) betrifft, können sie durchaus in deinem "Soll-Ist-Vergleich" (5.2) implizit sein (der ja sonst ziemlich langweilig wäre). Explizit werden sie eigentlich nur ausgewiesen, wenn die Änderungen gravierend waren. Dann jedoch bereits sehr weit oben --- also innerhalb von Punkt 1 (oder zumindest erfolgt dort ein strikter Verweis auf den Punkt "Abweichungen").

Pauschal? Yep. Aber das hängt von vielen Faktoren ab, die nicht immer einfach kontrollierbar sind. Das ist ungefähr vergleichbar mit dem "Malen nach Zahlen" für Kinder. Punkt 2 stellt dabei die Vorlage dar, und Punkt 3 repräsentiert die Farben. Beide zusammen machen den Baum dann "sichtbar". Aber der Hierarchiebaum ist mehr eine Kontrollstruktur als von grafischer Relevanz. Mit seiner Hilfe muss es möglich sein, sich quasi an einem Ast entlanghangelnd, vom Groben bis zu hochauflösenden Details zu gelangen, ohne dass der Datenfluss (beispielsweise beim Übergang zwischen den einzelnen DFD) jemals "hakt" oder "nicht nachvollziehbar" wird. Ich muss also in der Lage sein, den Finger auf ein DFD Level1 zu legen, und dort beginnend, ohne den Finger anheben zu müssen, dem Datenfluss folgen zu können, bis ich ein Blatt (auf Level xx) erreiche. Lege daher bitte nicht allzu gesteigerten Wert darauf, ihn nun "grafisch entdecken" zu müssen.

Wie ich oben bereits erwähnte: 1.1 ... Ist das wirklich notwendig? 1.2 Das ist heikel. Wenn die Ziele nicht sehr umfangreich sind, könnten sie in das SOLL einfließen. Und ist der "Auftrag" nicht identisch mit dem SOLL? 3.1 nach 1 3.2 dito 3.3 in das (neue) Kapitel "Entwurf" (außer 3.3.4 eventuell) 3.4 dito Hint: Deine Ausgangssituation bläht sich gewaltig auf. Der Fokus könnte dabei vom eigentlichen Schwerpunkt verrutschen, falls dieser auf der Realisierung lag ...

Dann würdest du quasi "das Pferd von hinten aufzäumen". 1. Kontextdiagramm (= Übersicht) 2. Rahmen/Auflösungstiefe abstecken (virtuell) 3. DFD + DD erstellen/malen/pflegen 4. Punkt 3 beliebig oft wiederholen 5. die entstandenen Blätter mit den MiniSpecs "festnageln" Fertig. Naja, im Wesentlichen. Oder besser: Was die Erstellung betrifft.

Yep. MiniSpecs beschreiben nur die Blätter. Die "Äste" malst du mit den DFD. Wenn du es so meinst: Yep.

Die Funktion des Baumes ist es, deine Auflösung zu begrenzen. Sonst müsstest du es unendlich fortsetzen ... Du "malst" ihn also nicht, sondern du "begrenzt" ihn, indem du seine Blätter durch MiniSpecs beschreibst. Das Kontextdiagramm ist das oberste DFD. Das "nullte" Datenflussdiagramm heißt "Kontextdiagramm", weil es als einziges den gesamten Kontext (ZUsammenhang) darstellt.

Yep. Das ist schon der ganze Trick. Viel mehr steckt da (Leider oder Gott sei Dank?) nicht hinter. ... Oops: Der Hierarchiebaum wächst normalerweise mit deinen Spezifikationen. Sonst verläufst du dich ganz schnell. Ich meinte es eigentlich nur symbolisch --- obwohl du ihn durchaus auch erst zum Schluss erstellen KANNST.

- Punkt 1.1 ist den einen oder anderen Gedanken in Richtung Reißwolf wert. - Punkt 1.3 ist irritierend. Was meinst du mit Projektumfeld? - Punkt 2.3 ist eigentlich Bestandteil des Entwurfs (als eigenem Kapitel). - Punkt 3.1 ist Bestandteil der Ausgangsituation. - Punkt 3.2 ist ebenfalls Bestandteil der Ausgangssituation. (Gilt nur, wenn der Datenbankentwurf nebenläufiger Bestandteil und nicht Kernthema ist.) - Punkt ? (Datenbankentwurf) ist Bestandteil des Entwurfs. - Punkt ?.1 (Datenanalyse) ist Bestandteil des (Datenbank)Entwurfs. - Punkt ?.2 (Normalisierung) ist Bestandteil des (Datenbank)Entwurfs. Wenn die Entwicklung einer Software Schwerpunkt war/ist/wird, sollte das auch Ausdruck in der Dokumentation finden. Wie wäre es mit einem Punkt Entwurf, in dem du detaillierter auf die Entwurfsphase eingehst? Das Kapitel "Realisierung" beschäftigt sich mit der Umsetzung von "Planung" und "Entwurf". Und schließlich fehlt die Schlussfolgerung deiner Betrachtung völlig. Einen Epilog solltest du schon noch einplanen.

Na dann wollen wir mal schauen, ob wir den Quatsch nicht erklärt kriegen ... Wollen wir wetten, dass das Einzige, was du nicht weißt, eigentlich nur die Tatsache ist, dass du es bereits weißt? Die strukturierte Analyse ist letztlich nichts anderes, als das, was du (fast) jeden Tag machst: Angenommen du siehst einen Kartentrick. Zuerst denkst du "Yep, cool.". Sekunden später denkst du "Hääääää?", und noch ein paar Sekunden später schaust du sehr genau hin, wenn der Trick wiederholt wird. Und je öfter der Zauberer den Trick wiederholt, desto mehr Details fallen dir auf. Du stellst fest, dass bestimmte Bewegungen Voraussetzung für andere Bewegungen sind, und dass die Karten auf eine definierte Art und Weise bewegt werden müssen damit der Trick gelingt. ... Auch wenn dieser Vergleich etwas hinkt, ist er doch geeignet, zu zeigen, dass structured analysis "alltäglich" ist. Nehmen wir mal an, du wolltest den Prozess einer Antragsbearbeitung beschreiben. Zunächst funktioniert es scheinbar wie eine black box: Antrag rein - Ergebnis raus. Die erste Verfeinerung schneidet die black box auf. Du stellst fest, dass mehrere Abteilungen mit der Bearbeitung des Antrags befasst sind --- mit anderen Worten, es fließen Daten zwischen ihnen hin (und her). Der Einfachheit halber nimmt Abteilung 1 (Schnittstelle1) den Antrag (nebenläufige Datenquelle) vom Antragsteller (Datenquelle) entgegen, Abteilung 2 (Schnittstelle2) bearbeitet ihn und Abteilung 3 (Schnittstelle3) schickt das Ergebnis an den Antragsteller (Datensenke) zurück. (Geht der Antrag unterwegs verloren, wäre die Stelle ebenfalls eine Datensenke.) Wir haben also aus einer großen black box drei kleinere gemacht --- und ein neues Problem: Wer genau ist eigentlich der "Antragsteller"? Was ist ein "Antrag"? Und was bedeutet "bearbeiten"? Um das ein für alle Mal zu klären, baust du ein data dict auf. Es beinhaltet eindeutige Beschreibungen (Datendefinitionen). Der Antragsteller setzt sich aus Name + Vorname + Geschlecht + ... + n Attribute zusammen, der Antrag kombiniert Antragsteller + Summe + Datum, und bearbeiten meint Aktionen, wie "genehmigen" oder "ablehnen". Die Darstellung bis hierher wäre ein nettes Kontextdiagramm, weil es die groben Zusammenhänge schon recht gut erläutert. Wenn du die Schnittstelle2 detaillierter auflöst, wirst du feststellen, dass in der Abteilung 2 mehrere Leute hocken, die den Antrag jeweils teilweise bearbeiten. Hier nutzt man Datenflussdiagramme, um den Informationsfluss zu granulieren. Mitarbeiter 1 (Schnittstelle2.1) prüft beispielsweise, ob der Antrag fristgemäß abgegeben wurde. Dabei interessiert ihn aber ausschließlich Attribut "Datum" der Datenquelle "Antrag". Dieses vergleicht er mit einem vorgegebenen Datum aus einer Datenbank (Speicher). Mitarbeiter 2 (Schnittstelle2.2) prüft seinerseits lediglich, ob die Summe nicht zu hoch oder zu niedrig ist. Dazu bezieht er ebenfalls ausschließlich Detailinformationen aus dem Antrag. Im Laufe des Zooms wirst du immer tiefer in die Details hineinblicken und immer detaillierter beschreiben, wie, wann, woher und wohin welche Informationen (Daten) fließen und was dort mit ihnen geschieht (Datenflussdiagramm). Am Ende all deiner Bemühungen steht dann eine wunderschöne und sehr überschaubare Beschreibung (durchaus hochkomplexer) Vorgänge die insbesondere für das Qualitätsmanagement interessant ist. Der Hierarchiebaum entsteht übrigens im wahrsten Sinne des Wortes von alleine, wenn du alle deine Diagramme geordnet aneinanderlegen würdest. Oh, und ein paar weiter Quatsch-Dinger (MiniSpec, Qualitätssicherung, Informationsabgleich, etc.), gibt's da noch, aber die sind für einen ersten Überblick nicht so wichtig.

Du kannst in der Projektdokumentation alle Hilfsmittel heranziehen, die es dem Leser erleichtern, dir zu folgen. Dazu gehört auch Quellcode. Aber Vorsicht! Man tendiert sehr leicht dazu, unreflektiert einfach seitenlange Quelltexte auszudrucken. Das ist nicht nur überflüssig, sondern überdies meistens kontraproduktiv. Kein Mensch wird sich die Zeit nehmen, um sich die sicher tollen aber meist nichtssagenden Ausdrucke genauer anzuschauen. Vielmehr wird es i.d.R. als Last empfunden. Sollte es wirklich, absolut und unumstößlich unumgänglich sein, seitenlange listings zu erzeugen, dann fügt man den Quelltext üblicherweise im Anhang bei. In jedem anderen - und unendlich lieber gesehenen - Fall kann man markante, interessante oder wichtige kurze Auszüge (Selten sind mehr als 10-15 Zeilen notwendig.) direkt in die Dokumentation einfügen. Auf solche hochauflösenden Details geht man in der Projektdokumentation aber für gewöhnlich nur dort ein, wo Besonderheiten zu beachten sind oder waren. Allgemeinplätze, wie die Funktionsweise eines "Exit-Buttons", oder den Quelltext einer UI-Form kann man sich getrost sparen. Wichtig ist nicht Masse, sondern Klasse. Ebenso verhält es sich bei der Verwendung von Werkzeugen. Wenn sich herausstellt, dass man ein Werkzeug nicht benutzen muss, kann man es durchaus auch weglassen. Wurde es - beispielsweise im Projektantrag - erwähnt, würde ich ein paar wenige Worte dazu verlieren, warum ich mich umentschieden habe. Letztlich zählt eben nur, wie man die verfügbare Zeit genutzt hat. Und die Änderung einer Entscheidung aufgrund neuer Aspekte ist absolut nichts Verwerfliches.

*lol, mein Spaßvogel wieder mal ... ... (no comment)

ABSOLUT nein. Ich bin kein Mitglied eines Prüfungsausschusses, aber WÜRDE man so verfahren, wäre es sträflicher Irrsinn. Ich wiederhole es noch einmal: Diese Projektdokumentationen machst du nicht nur, weil es den Leuten von der IHK so gefällt, und weil sie dich so am besten ärgern können; sondern weil solche Dokumentationen "alltäglich" sind (ja ich weiß, timmi-bonn). Ziel der Projektdokumentation ist es, dem Gutachter (Chef, Prüfer, etc.) Gelegenheit zu geben, zu erfahren, WAS du mit der gegebenen Zeit angefangen hast. Es ist NICHT Ziel der Projektdokumentation, fertige Produkte abzuliefern. Wenn es also zu Verzögerungen kam, ist das normal. Nenne diese Verzögerungen, begründe sie, und gib dem Leser die Chance, zu verstehen, was dich so aus der geplanten Bahn geworfen hat... Bewertet - gleichgültig, ob es sich in Punkten oder Lohn äußert - wird vom Gutachter der Projektdokumentation nicht das Produkt, sondern die Art und Weise, wie du mit der Zeit umgegangen bist.

Zeitverschiebungen sind in Projekten eher die Regel als die Ausnahme. AFAIK ist auch für die Prüfung lediglich das Zeitfenster relevant. Somit ergibt sich, dass du - wie später auch - ausschließlich den Zeitraum betrachtest, und in der Projektdokumentation festhältst, was du in dieser Zeit gemacht hast. Sind gravierende Änderungen eingetreten, benennst und begründest du sie gegebenenfalls. Führte das dazu, dass du das Projekt nicht wie geplant abschließen kannst/konntest, benennst und begründest du auch das. Ziel der Projektdokumentation ist nicht, ein fertiges Produkt zu präsentieren, sondern die Arbeit, die innerhalb des gegebenen Zeitfensters dort hineingesteckt wurde ...

Ein gewagter Plan ... Ich schätze, selbst bei einer einfachen Anwendung kommst du dabei schnell auf 10, 20 oder sogar 30 Seiten Ablaufplan, wenn du alle Eventualitäten berücksichtigen willst. Das ist im Pflichtenheft absolut unumgänglich, aber dort wird es i.d.R. aufgabenbezogen und damit ganz sicher nicht als "detaillierter Überblick" dargestellt. In der Projektdokumentation würde ich dir unterstellen, dass du versuchst, künstlich Seiten zu füllen und überflüssigen Informationsmüll zu produzieren. Im Übrigen kann ich mich IJK nur anschließen, denn auch ich würde nicht versuchen, die Anwendung an die Darstellung, sondern die Darstellung an die Anwendung anzupassen. Die UML bietet dir eine ganze Palette wunderschöner Techniken an, die dir alle helfen, (auch grafisch) zu dokumentieren, was du ausdrücken möchtest. Bediene dich ihrer ... Yep. Allerdings kannst du es durchaus auch als Verzweigung darstellen, wenn es nur 2 Alternativen gibt.

Verstehe ich dich richtig, wenn ich folgendes behaupte: - du hast ein hochkomplexes System - dieses hast du in weniger als 70 respektive 35 Stunden entwickelt - es ist so komplex, dass es nicht möglich ist, dieses darzustellen - es existiert real ... bist du mit Einstein verwandt? Gleichgültig wie komplex dein System ist, es lässt sich IMMER detailiert und sauber beschreiben. Da du ja im Vorfeld bereits ein - wahrscheinlich sehr umfangreiches - Pflichtenheft geschrieben hast, in dem du jeden einzelnen Faktor berücksichtigtest, sollte es dir eigentlich nicht wirklich schwerfallen, eine "lockere" Zusammenfassung zu schreiben. Machen wir mal gemeinsam ein Beispiel ... Stelle dir vor, du wolltest ein Auto bauen. Du begründest also ein neues Projekt, welches sich das Auto zum ZIEL erhebt. Zunächst einmal hältst du in einer Wunschliste alles fest, was das Auto können SOLL, DARF, und KEINESFALLS SOLL. Nehmen wir an, es SOLL Blinken, DARF über 100 km/h fahren, und SOLL KEINESFALLS Fliegen können. Nun setzt du dich in eine stille Ecke und reflektierst, wie du das erreichen kannst. Wahrscheinlich wird dir einfallen, dass du verschiedene Details brauchst, um das realisieren zu können. Also machst du einen Entwurf, in dem du all die Details fein säuberlich aufmalst, benennst, ausrechnest, beschreibst, schilderst, ... Wenn du hier Dinge verwendest, beispielsweise die Hupe eines anderen Herstellers, dann hältst du auch diesen Punkt eindeutig fest. Im Laufe deiner Arbeit fällt dir auch ein (oder auf), was und wie du testen kannst, um die gewünschte Funktionalität sicherstellen zu können. So entsteht nach und nach die Bastelanleitung für das Auto. Wenn das getan ist, brauchst du nur noch das Ding zu bauen, zu testen, das Handbuch in das Handschuhfach legen, und schlussendlich zum Händler/Kunden zu bringen. Wie du siehst, steht all das also bereits im Lastenheft respektive im Pflichtenheft. Und was dort redundant sein soll, kann ich nicht erkennen. Deine Projektdokumentation gibt dem Gutachter (Chef, Prüfer, Projektleiter, etc.) lediglich einen Gesamtüberblick aus der Perspektive: "Was hat der Bursche eigentlich in den letzten ein (oder zwei) Wochen getrieben? Was hat er für die Unsummen an Gehalt, die ich ihm jeden Monat in den Rachen werfen muss, an Gegenleistungen erbracht?" Es ist also nicht mehr besonders sinnvoll, dem Gutachter Dinge zu erzählen, die ihn a) nicht oder nur am Rande interessieren und die er - Interesse vorausgesetzt - an anderer Stelle (Archiv, Anhang, etc.) nachlesen kann. Natürlich ist es notwendig, zu sagen, dass so und nicht anders, aber die Begründungen stehen bereits im Pflichtenheft, so dass du diese nur heranziehen und in aller gebotenen Kürze schildern musst. Woran du im Moment sicher hängst, ist ganz einfach zu klären: Jedes Dokument wird mit einem anderen Ziel erstellt. Daher sind die Informationen insbesondere in der SOLL-Anforderung, den ZIELEN, etc. abstrakt durchaus redundant. Das relativiert sich aber, weil du es jedesmal aus einer anderen Perspektive beschreibst. Beispiel: (Achtung: Nur symbolisch!) Lastenheft: (Allgemeine Schilderung des WAS aus der Sicht des Kunden.) Ich will ein Auto, das Blinken kann. Es wäre schön, wenn es auch mindestens 100 km/h fahren kann, muss es aber nicht. Oh, und fliegen will ich damit nicht. Pflichtenheft: (detaillierte Schilderung des WAS aus der Sicht der Techniker.) Das Auto muss Blinken können. Um das realisieren zu können, brauchen wir eine Lampe, 10 m Kabel, eine Energiequelle, und und und ... Projektdokumentation: (Beschreibung des WIE aus der Sicht der Projektinvolvierten.) Wie man dem Pflichtenheft entnehmen kann, musste das Blinken umgesetzt werden. Dazu habe ich die dort dokumentierten Teile so verbaut, dass ich ... ich bitte bitte...

1. Grenze dein System ab Deine Projektdokumentation bezieht sich ausschließlich auf deine Arbeit. Die Schnittstellen zu den anderen Abteilungen/Modulen/Projekten sind zwar implizit, mehr aber nicht. Begründungen zur Programmiersprache und Abgrenzungskriterien zu nebenläufigen Projekten sind Bestandteil der Planung. 2. Der SOLL-Part beschreibt keine Details. Schildere hier die wesentlichen Anforderungen und Bedingungen. (Diese Informationen sind mit Blick auf das Lastenheft (und partiell auch Pflichtenheft) redundant, häufige Querverweise sind daher angebracht.) 3. Der Entwurf ist detailliert. Hier führst du Details zu den unter Punkt 2 genannten Anforderungen und Bedingungen aus. (Diese Informationen sind mit Blick auf das Pflichtenheft redundant, häufige Querverweise sind daher angebracht.) ich bitte ...

Das ist ein öffentliches Forum ... Ich hoffe doch sehr, dass du nicht der einzige Leser bist.

Die beiden Beispiele oben sind absolut identisch ... Einzige Ausnahme: Der erste Text ist detaillierter gegliedert. Entscheide selbst, was du für lesbarer hältst.

1 Prolog Wie immer, so gilt auch hier die folgende klassische Dokumentationsfaustregel. So viel wie nötig. So wenig wie möglich. 2 Ziele Ich gehe davon aus, dass du nicht auf den Preis für das längste Inhaltsverzeichnis hinarbeitest, oder? Falls doch, mache so weiter, du bist auf einem guten Weg. (Vorschlag: Splitte die Installation von der Konfiguration, das bringt noch eine Überschrift mehr.) Falls du aber Wert auf Übersichtlichkeit legst, dann bedenke bitte auch mal das Folgende: Stelle dir ein Buch vor. Du öffnest dieses Buch, und dich grinsen fette Überschriften an --- auf jeder Seite zwei bis fünf Stück. Das liest sich super, nicht? 3 Feldversuch 3.1 These Überschriften sind eyecatcher. Das heißt, sie ziehen unwillkürlich die Aufmerksamkeit auf sich. Je mehr Überschriften du hast, desto weniger wird der Leser seine Aufmerksamkeit auf den Inhalt lenken können. 3.2 Schlussfolgerung Ich weiß, man ist immer versucht, so viel zu gliedern, bis nix mehr geht. Und selbst dann fällt einem noch dieser oder jener Punkt ein, den man noch ein klitzekleines bisschen unterteilen könnte ... ... am Ende hast du dann einen verärgerten Leser, der sich Zettel und Stift holen muss, um die Zusammenhänge zwischen den einzelnen kurzen Textfragmenten mit Hilfe von Notizen wieder herstellen muss. Damit hast du das Gegenteil von dem erreicht, was du wolltest, nicht? 4 Epilog Ich hoffe, du hast diesen Text flüssig und ohne jegliche Schwierigkeiten zusammenhängend erkennen können. Ich habe mich bemüht, ihn so übersichtlich wie irgend möglich (=so viele Überschriften wie möglich) zu gestalten.

1 Prolog Wie immer, so gilt auch hier die folgende klassische Dokumentationsfaustregel. 1.1 Dokumentationsfaustregel So viel wie nötig. 1.2 Ergänzung zur Dokumentationsfaustregel So wenig wie möglich. 2 Ziele 2.1 Gewinn Ich gehe davon aus, dass du nicht auf den Preis für das längste Inhaltsverzeichnis hinarbeitest, oder? 2.2 Weg zum Gewinn Falls doch, mache so weiter, du bist auf einem guten Weg. (Vorschlag: Splitte die Installation von der Konfiguration, das bringt noch eine Überschrift mehr.) 2.3 Alternative Falls du aber Wert auf Übersichtlichkeit legst, dann bedenke bitte auch mal das Folgende. 2.4 Beispiel Stelle dir ein Buch vor. Du öffnest dieses Buch, und dich grinsen fette Überschriften an --- auf jeder Seite zwei bis fünf Stück. Das liest sich super, nicht? 3 Feldversuch 3.1 These Überschriften sind eyecatcher. 3.1 Ableitung Das heißt, sie ziehen unwillkürlich die Aufmerksamkeit auf sich. Je mehr Überschriften du hast, desto weniger wird der Leser seine Aufmerksamkeit auf den Inhalt lenken können. 3.2 Schlussfolgerung Ich weiß, man ist immer versucht, so viel zu gliedern, bis nix mehr geht. Und selbst dann fällt einem noch dieser oder jener Punkt ein, den man noch ein klitzekleines bisschen unterteilen könnte ... 3.3 Erweiterung der Schlussfolgerung ... am Ende hast du dann einen verärgerten Leser, der sich Zettel und Stift holen muss, um die Zusammenhänge zwischen den einzelnen kurzen Textfragmenten mit Hilfe von Notizen wieder herstellen muss. 3.4 Zusammenfassung Damit hast du das Gegenteil von dem erreicht, was du wolltest, nicht? 4 Epilog Ich hoffe, du hast diesen Text flüssig und ohne jegliche Schwierigkeiten zusammenhängend erkennen können. Ich habe mich bemüht, ihn so übersichtlich wie irgend möglich (=so viele Überschriften wie möglich) zu gestalten.