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.