just_me

Was hat der Punkt 3.2 Zeitplan in der Realisierung zu suchen? Realisierst du einen Zeitplan(er)? Oder ist das ein Zeitplan? Mein Vorschlag: 3 Implementierung 3.1 Vorbedingungen (Ressourcen, Rechte, etc. soweit noch nicht in früheren Teilen erwähnt) 3.2 Realisierung (Installation, Konfiguration, batches, scripts, etc.) 3.3 Test Das ist überschaubarer und angesichts der Kürze des Projektes sicher angemessener.

Ok, ernsthaft. Ist Novell dein Projekt? [_] Ja [_] Nein Ist Novell integraler Bestandteil deines Projektes? [_] Ja [_] Nein Hat Novell mit deinem Projekt mehr zu tun, als die Plattform zu stellen? [_] Ja [_] Nein Wenn du mindestens zwei Fragen mit "nein" beantworten kannst, solltest du darauf verzichten, runde 13'000 Seiten Anwenderdokumentation für Novell anzuheften. Vertraue darauf, dass die Gutachter deines Projektes wenigstens in den Grundzügen wissen, was Novell (Linux dito) ist, und dass sie sich im Bedarfsfall das Handbuch selbst kaufen. Das hat nicht das geringste mit "(vorhandener oder nicht vorhandener) Professionalität" zu tun, sondern liegt ganz einfach am Schwerpunkt. Wenn dein Betrachtungsschwerpunkt auf einer hochauflösenden Interaktionsebene Novell <-> Projekt 'no idea' liegt, dann solltest du diese Schnittstellen durchaus tiefer ausführen, denn tiefgreifende Detailkenntnisse kann man nicht immer voraussetzen. In jedem anderen Fall ist es müßig, den Leuten Basisfunktionalität nahebringen zu wollen, denn es fände - s.o. - einfach kein Ende. Daher die konsequente Schlussfolgerung: So viel wie nötig - so wenig wie möglich.

Fantastische Idee. Und wenn du schon dabei bist, füge doch bitte auch gleich noch eine Erklärung für den Texteditor ein, mit dem du die Dokumentation getippt hast, und eine Erläuterung, wie der Computer, auf dem sich die Textverarbeitung befindet, funktioniert, und natürlich auch eine Erläuterung, wie der Strom erzeugt wird, den du brauchst, um deinem Rechner Leben einzuhauchen. Oh, und vergiss bitte auch nicht, eine Erläuterung des Lebens einzufügen, denn schließlich lebst du ja, und wirst zur Durchführung des Projektes ebenfalls benötigt. Naja, und die Funktionsweise des Finanzapparates solltest du auch nicht unterschlagen, immerhin bezahlt irgendjemand dein Gehalt, und das wiederum unterstützt dich beim Leben. Habe ich was vergessen?

Vorsicht. Wenn ich dich richtig verstehe, denkst du daran, 2 Inhaltsverzeichnisse des Pflichtenheftes zu erzeugen? Eines im Anhang, und das zweite als Bestandteil des Pflichtenheftes? Das Pflichtenheft ist ein einheitliches Dokument. Wenn du es "zersägst", und nur Teile in den Anhang übernimmst, dann ist es durchaus empfehlenswert, eine Gliederungsübersicht im Anhang einzufügen. Im Fall, dass du das komplette Pflichtenheft anhängst, bringt dieses bereits seine eigene Gliederung mit. Es ist daher nicht mehr nötig, dies zusätzlich im Anhang auszuweisen.

nope. Im globalen Inhaltsverzeichnis listest du entweder nur "Anhang ... 60" auf, und überlässt es den Leuten, zu erraten was drinstehen könnte (Das ist vorteilhaft bei sehr kurzen und überschaubaren Anhängen, oder dann, wenn der Anhang aus nur einem Dokument besteht.), oder du listest die Anhänge einzeln auf, also etwa "Anhang A ... A-1, Anhang B ... A-15". Wenn du einen sehr umfangreichen Anhang hast, kannst du am Anfang des Anhangs ein zusätzliches Inhaltsverzeichnis einfügen. Zusätzlich (oder ersatzweise) kannst du in jedem Anhang ein Inhaltsverzeichnis einfügen, wenn dies die Übersicht verbessert.

@Sandrin Das klingt wie ein Zitat aus einem Glossar. Könntest du bitte die Quelle nennen? (Ich hoffe, da sind weitere Begriffe definiert?)

Es handelt sich um eigenständige Dokumente, die partiell oder vollständig beigelegt werden. Diese eigenständigen Dokumente besitzen auch einen eigenen "Stil". Würdest du sie - und sei es auch nur stilistisch - anpassen, wäre es gleichbedeutend mit einer Änderung des Dokumentes. Wenn dieses Dokument nicht von dir verfasst wurde, hast du kein Recht, dieses zu verändern (UrhG). Wenn dieses Dokument von dir verfasst wurde, besteht keine Notwendigkeit es zu ändern, da es lediglich zusätzliche, erläuternde Informationen birgt. (Im Übrigen wäre es schon rein logisch Wahnsinn, jedesmal alle Dokumente aneinander anzupassen. Bei einer vollständigen Dokumentation hast du schnell hunderte Seiten dutzender verschiedener Dokumente. Das würde schnell dazu führen, dass du daraus zehntausende Seiten "Dokumentation" produzierst, die unglaublich redundant wäre ...) Natürlich bleibt die Gliederung dir überlassen, aber "üblicherweise buchstabiert" man Anhänge, etwa "Anhang A - Pflichtenheft", "Anhang B - CodeSnippets", etc.; oder man gibt ihnen römische Zahlen, etwa "Anhang I - Pflichtenheft", "Anhang II - CodeSnippets". Das sorgt dafür, dass der Anhang auch optisch sauber vom Dokument getrennt wird --- denn letztlich ist er "nur Anhang" (in des Wortes wahrstem Sinne). Wird ein Anhang untergliedert - was sich insbesondere bei Auszügen aus Dokumenten oder Code anbietet - beginnt eine neue Numerierung. Beispiel: "Anhang II - CodeSnippets", "1. Redundanzcheck", "1.1 automatische Prüfung", "1.2 semiautomatische Prüfung". Hier folgt zunächst eine kurze Erläuterung, wenn es notwendig ist (Insbesondere bei Quellcode gern gesehen, weil es die Zeit zum Einlesen merklich reduziert.). Im Text kannst du dann so darauf verweisen "(vergl. Anhang II CodeSnippets:1.1 automatische Prüfung)". Ziel ist es, gerade bei umfangreichen oder "zusammengestückelten" Anhängen schnellstmögliche Zugriffe zu gewährleisten. Wenn es notwendig oder nützlich ist, ja. Redundante Information "um Platz zu füllen", nein. Yep.

Basierend auf dem Umstand, dass es sich um losgelöste Dokumente handelt, ist es weder möglich noch nötig, ihre äußere Form derjenigen der Dokumentation anzupassen. Trenne die Anhänge deutlich vom Dokument, und "lege die anzuhängenden Dokumente einfach bei". Die Gliederung des Anhangs muss sich jedoch in die des Dokuments einfügen, da sie Bestandteil des Dokuments ist. Mein Vorschlag: Produziere Trennseiten: Überschrift, und ein paar erklärende Worte, falls das angehängte Dokument nicht selbsterklärend ist. Ebenso muss die Seitennumerierung durchgehend sein. Zwar könntest du im Anhang mit einer neuen Numerierung beginnen, etwa A-1, A-2, A-3 oder A1-1, A1-2, A2-1, etc., aber selbst dann musst du eine durchgehend konsistente Lösung finden. Wenn zusätzliche Restriktionen (Kopf- und/oder Fußzeilen) bestehen, gelten diese natürlich primär.

Interessanter Begriff. Was meinst du damit? Wenn du das "Anwenderhandbuch", die Online/offline-Hilfe oder sonstige diesbezügliche Dokumente meinst: Falls du meinst, ob es in die Projektdokumentation gehört: Das weißt du am Besten. Ist sie wirklich notwendig, um zu verstehen, was du getan hast? (Das dürfte nur in den seltensten Fällen gegeben sein - u.a. dann, wenn du reverse engineering betrieben hast.) Wenn sie aber (zwingender) Bestandteil deines Projektes ist, solltest du sie wohl (wenigstens auszugsweise) mit anheften.

Ein landläufiger Irrtum, wie mir scheint ... Als guter "Anwendungsentwickler" kannst du deine Anwendungen selbst entwickeln. Das impliziert tiefgreifende Kenntnisse der UML, OOA, OOD - und, man mags kaum glauben - der Dokumentation. Allein die Kommentare im Quelltext, die du ja sicher reichlich und ausführlich einfügst, würden zusammengefasst schon ein umfangreiches Dokument ergeben, in dem du deine poetischen Fähigkeiten unter Beweis gestellt hast. Und sei nicht überrascht, wenn du später gelegentlich den Satz hörst: "Herr Ente19, es wäre nett, wenn Sie uns bis morgen mal eine Übersicht Ihrer bisherigen Arbeit geben könnten --- Ich denke so 15 Minuten sollten reichen.". Alternativ - Chefs haben das auf der Uni trainiert (Es gibt extra Seminare dafür.) - kommt Freitag nachmittag, kurz vor Feierabend, der Satz: "Gut dass, ich Sie noch antreffe, Herr Ente19. Ich brauche Montag früh eine Übersicht zum Projektverlauf. Der Kunde kommt vorbei. Ich wollte es Ihnen schon vor 14 Tagen sagen, aber ich hab's irgendwie vergessen. Schreiben Sie nicht zuviel, so 10-15 Seiten sollten reichen. ... Ein schönes Wochenende, ich fahre mit meiner Familie an den Strand - und was machen Sie so?" Glücklich, wer für solche Fälle vorsorgt ...

Worauf genau willst du hinaus? In deine Projektdokumentation gehören alle Dokumente, die notwendig sind, um den Verlauf eindeutig zu beschreiben. Das kann (nicht muss) Vorabdokumentationen (beispielsweise aus Referenzprojekten), Lastenheft, Pflichtenheft, codesnippets, Diagramme, Tabellen, und und und ... betreffen. Was genau, kannst nur du selbst entscheiden, denn du bist der Einzige, der den vollen Umfang des Projektes kennt und daher weiß (wissen müsste), was notwendig ist. Ein Lastenheft ohne das entsprechende Pflichtenheft beizulegen, macht beispielsweise dann Sinn, wenn die Projektierung durchschaubar und ohne weiteres nachvollziehbar ist. Es birgt aber die Gefahr, dass zumindest einer der Gutachter, für die du diese Dokumentation ja letztlich entwickelst, sich auf die Hinterbeine stellen und sagen könnte "Hey, da sehe ich jetzt aber nicht durch. Das ist übel ... ganz übel, für den Schreiberling dieser Dokumentation.". Wenn du mich fragst, würde ich mir darüber also länger als fünf Minuten Gedanken machen, ob ich das Pflichtenheft "mal eben" weglasse. *mööööööp*! Falsch! BEIDE Dokumente zusammen ergeben erst eine sinnvolle Übersicht. Das Lastenheft beschreibt grob und kundenorientiert, was gefordert wird - das Pflichtenheft beschreibt detailliert und zielorientiert, was gefordert wird. Was willst du daran weglassen? Und warum? Wenn du das sauber(!) begründen kannst, ziehe ich meine Behauptung zurück.

Abgesehen davon, dass ich mich Jaraz' Frage nach dem Sinn anschließe, denn eine simple SELECT-Anweisung könnte wahlweise Datum oder Zeit zurückgeben, ... ... guckst du hier

Diese Antwort ist einfach: Es gibt da ja diesen "klassischen" Vergleich, wonach jetzt die Frage kommen müsste: "Was würdest du tun, wenn andere ins Feuer (wahlweise: aus dem Fenster) springen würden? Hinterherspringen?". These: Nicht alles, was andere verzapfen, ist richtig. Ableitung: Nicht alles, was andere verzapfen, ist nachahmenswert. Schlussfolgerung: Mach's richtig, oder doch wenigstens besser.

Um es einmal korrekt darzustellen: Dieser Fall ist durchaus möglich und oft auch "üblich", aber eher "ungewöhnlich" und abseits jeder Empfehlung, Richtlinie und Norm (Ja, ich weiß, timmi-bonn.). Da das Pflichtenheft normalerweise von kryptischen Fachbegriffen, Diagrammen, Plänen, usw. nur so wimmelt, wird der Auftraggeber sich schwer hüten, irgendwas zu unterschreiben, was er nicht eindeutig entziffern kann. Oder würdest du eine in einem südostchilenischen Hochlanddialekt verfasste Steuererklärung unterschreiben? Statt dessen wird eigentlich so vorgegangen, dass der Auftraggeber einen Anforderungskatalog zusammenstellt oder zusammenstellen lässt, welcher im Allgemeinen "Lastenheft" genannt wird. Dort stehen solche Sachen, wie "Ich will eine Software, die, wenn ich auf diesen Knopf drücke, laut *quiek* macht.", drin. Diesen Auftrag besiegeln beide - also Auftraggeber wie Auftragnehmer - mit ihrer Unterschrift. Aus diesem Lastenheft wird anschließend eine detaillierte Arbeitsaufgabe erarbeitet, deren Ziel und Zweck es ist, die Anforderungen für die beteiligten Mitarbeiter (Programmierer, Techniker, etc.) sehr genau zu beschreiben. Da schreibt man dann rein, wo sich der o.g. Knopf genau befindet, wie er genau aussieht, und was genau passiert, wenn man 1x, 2x, ..., X-Mal, draufklickt. Das Resultat dieser Arbeit nennt man Pflichtenheft. Wenn all das getan ist, kann die "handwerkliche" Arbeit beginnen: Wir basteln uns eine Software. Da wir ja ein überaus detailliertes Pflichtenheft haben, können wir Punkt für Punkt auf der Liste abhaken. Wenn alle Punkte markiert sind, ist der Auftrag erfüllt, und kann abgerechnet werden. That's it ... (jedenfalls was den "technischen Part" betrifft).

Ich möchte den Prüfungsausschuss sehen, der es wagen würde, dir aus einer ZeitUNTERschreitung von ganzen 5,71% einen Strick zu drehen. Allerdings wäre ich - vorausgesetzt, ich wäre Gutachter - der Erste, der es dir ankreiden würde, käme ein Flüchtigkeitsfehler zutage ...

Wenn es der Ralität entspricht, natürlich. Immerhin ist es ein wichtiger Faktor, oder meinst du nicht? Zweifellos ist das nur "eine Frage", aber die Antwort würde genaugenommen mehrere Bücher füllen. Bezogen auf das SOLL-Konzept hat im Pflichtenheft jedes relevante Detail der drei Primärkriterien "Muss", "Wunsch" und "Abgrenzung" zu stehen. Doch das ist eigentlich nur die "Aufwärmrunde". In den folgenden Kapiteln beschreibst du dann jeden Handgriff, jede Methode, jeden Anwendungsfall, jede ... einfach alles, was dein Projekt betrifft, haarklein und bis ins Letzte detailliert. Am Ende ist das Pflichtenheft - salopp ausgedrückt - eine "Bastelanleitung für das Projekt 'hYpe'". Mit anderen Worten, du könntest mir das Pflichtenheft geben, und ich müsste anhand dieser Dokumentation ohne weiteres in der Lage sein, dein Projekt nachzubauen.

Absolut korrekt. Fasse es nicht ZU kurz, damit der Überblick nicht verloren geht - und gehe nicht zu sehr ins Detail, damit du nicht die Zeit der Leute verschwendest. Das ist die ganze Kunst. Mehr steckt nicht dahinter.

Genau das solltest du auch. Im Pflichtenheft hast du dich ausführlich mit dem "Für & Wider" beschäftigt, hast analysiert, detailliert beschrieben, und und und ... In der Projektdokumentation gibst du einen netten anschaulichen Bericht, wie es anfangs war (IST), und was dabei herauskommen sollte (SOLL). Dabei gehst du aber keineswegs auf jedes Detail ein, sondern beschreibst es prägnant, zielorientiert und präzise. (Details überlässt du fein dem Pflichtenheft.) Ziel der Übung ist es, einem Gutachter (Vorgesetzter, Prüfer, etc.) einen sauberen Abriss deiner Arbeit zu geben. Dieser muss mit Hilfe der Projektdokumentation, sowie den Anlagen in der Lage sein, a) dein Projekt nachvollziehen und die Arbeit bewerten zu können.

Das hängt maßgeblich davon ab, wie du die Übersichtlichkeit besser gestalten kannst. Manchmal vermischen sich die Prozesse (Bsp: simultane Bearbeitung). Dann ist es sicher besser, dies zusammenhängend darzustellen - beispielsweise anhand des workflows. Meistens ist es aber wahrscheinlicher, dass die strikte Trennung nach Aufgaben zu mehr Übersicht führen wird. wichtiger Hinweis: Verweise wo immer möglich auf das Pflichtenheft. Vermeide redundante Informationen. Die Projektdokumentation zielt auf den Überblick zum Verlauf des Projektes, nicht auf dezidierte Beschreibungen von Prozessen oder Modulen.

Eine Prozessschnittstelle definiert die Art & Weise, wie Akteure (also dein Chef) mit Hilfe eng beschriebener Aktivitäten den Prozessverlauf und damit das resultierende Artefakt (also das Ergebnis) beeinflussen können. Definiere diese Schnittstelle(n). Was kann wann, wie und wo gemacht werden? Was ist das primäre und was das sekundäre Ziel deines Projektes? Wenn du die Antwort auf diese Frage gefunden hast, hast du auch gleichzeitig die Antwort auf deine andere Frage.

Das hängt von der Wichtung ab. Sind sie nebenläufig, reicht es, sie in der Konzeption zu erwähnen. Sind sie primär, müssen sie in der Planung Berücksichtigung finden. Dafür ist dieser Punkt gedacht. Ja. Die Auslösung definiert die Ursachen, die Ziele definieren zwangsläufig die Aufgabe und damit die Inhalte. Persönliche Meinung? Ich würd's dir nicht abkaufen. Reichlich oberflächlich, flüchtig und mit einer markanten Schwerpunktverschiebung auf die Auslösung des Projektes. (Möglicherweise hat's ja Ursachen, bspw. weil die Entscheidungsfindung schwerer als die Projektdurchführung war.) Und auch der Punkt "Projektdurchführung" liest sich ... interessant: "1. Prozess", "2. Prozess" ... Das ist nicht dein Ernst, oder? Überschriften sollten markant auf den Inhalt verweisen. Warum beschreibst du nicht auch die Komponenten deines Computers, den du verwendet hast, um die Dokumentation zu tippen? Ein Überblick reicht. Wenn dieser nachvollziehbar und die Testumgebung reproduzierbar ist, hast du alles getan, was notwendig war. Vorausgesetzt, du hast nicht 100% aller Möglichkeiten ausgeschöpft, könnte ja jemand nachfragen, warum du dieses oder jenes nicht getan hast. Dann wäre es praktisch, das Kapitel "Abgrenzung" zu finden ...

So? Warum nicht? Der Rest der nebenläufigen Informationen sagt im Kern aus: Erkundige dich, wie's die Damen und Herren wünschen, und ob sie eventuell Bedarf danach verspüren, deine Arbeit zu vereinzeln. Wenn sie sagen, dass es ihnen gleichgültig sei: s.o. Wenn sie sagen, dass es ihnen nicht gleichgültig sei: s.o. Wo siehst du das Problem?

Versuch's mal mit "Starten ohne Debuggen" [CTRL] + [F5] ...

Der Begriff "Produktdokumentation" umfasst eine ganze Reihe verschiedener Dokumente, wie beispielsweise "Datenblätter", "Produktinformationen", "Werbebroschüren", "Handbücher", "Referenzen", etc. Es wäre also angebracht, dass du, wenn du nicht mit der Antwort "Alles, was die Beschreibung des fertigen Produktes zum Ziel hat." zufrieden bist, zumindest Zielgruppe und Zweck deiner "Produktdokumentation" spezifizierst.

informell: Was ist das Thema? Welches Ziel verfolgst du? Vorbedingung: Aufgrund fehlender Informationen ist die nachfolgende Analyse spekulativ. Weiter unten erwähnte Irritationen könnten sich beispielsweise eventuell aus dem Kontext lösen lassen. Dieser Kontext ist nicht bekannt. - Punkt 1 scheint sehr umfangreich zu sein? Ist das wirklich notwendig? (Die Durchführung des Projektes muss nicht mehr begründet werden. Das geschah bereits mit der Entscheidung für dieses Projekt. Eine Klarstellung der Situation reicht daher i.d.R. aus. Ziel ist es lediglich, knapp aufzuzeigen, wie es vorher war.) - Warum grenzt du Punkt 2, Punkt 3 und Punkt 6 voreinander ab? - Punkt 4 "Methode" ist ... was? - Punkt 5 "Risikoanalyse" ist ... was? - Punkt 7 "Planung" ist irritierend betitelt. Du "planst" bereits ab Punkt 2. (Vorschlag: "Entwurf". Der "Entwurf" ist die "Planung" der "grob ausgedachten" Strukturen und Grenzen en detail.) - Punkt 8 "Durchführung des Projekts" ist irritierend betitelt. Die "Durchführung" beginn bereits bei Punkt 1. (Vorschlag: "Realisierung". Die "Realisierung" ist die Umsetzung der vorangegangenen Schritte "Planung" und "Entwurf".) - Punkt 8.1.1 "Sollkonzept" ist formal Bestandteil von Punkt 2, evtl. gemäß deiner Struktur auch Punkt 3 "Leistungsbeschreibung". - Punkt 8.1.2 "(Verweis auf Anhang)" ist nicht zu empfehlen. (Verweise statt dessen im Text, wenn nötig.) - Punkt 8.2 "Design" beinhaltet ... was? (Falls es Bestandteil der Vorbereitung ist, gehört es logisch in den Punkt 7 "Planung". Falls nicht: Nenne es beim Namen. Also beispielsweise "Graphische Schnittstelle" oder "Implementierung")