Aufbau der Projektdoku

[Crow T. Robot]

Hallo zusammen!

Ich habe - wie so viele andere zur Zeit auch - einige Fragen zum Aufbau der Dokumentation. Zur Zeit verwende ich eine Gliederung wie unten gezeigt.

Wo und in welcher Reihenfolge gehören dort die noch fehlenden Punkte Funktionstest, Integration, Endabnahme, Einweisung und Dokumentation hinein? Gehören die alle noch zur eigentlichen Durchführung oder einiges bereits zu den Ergebnissen (z.B. die Doku-Erstellung)?

Ist das ansonsten vollständig, habe ich was übersehen oder gar schon zu stark untergliedert?

Bin für alle Hinweise dankbar.

1 Projektbeschreibung

1.1 Einführung

1.2 Einbindung in den Geschäftsprozeß

1.3 Ausgangslage

1.4 Projektziel

1.5 Änderungen gegenüber dem Projektantrag

2 Ablauf- und Ressourcenplanung

2.1 Ablaufplanung

2.2 Sachmittel- und Raumplanung

2.3 Personal- und Kostenplanung

3 Durchführung

3.1 Grobkonzept I / Ist-Zustand

3.2 Grobkonzept II / Soll-Konzept

3.3 Technische Schnittstellen / Technisches Umfeld

3.4 Feinkonzept I / Systementwurf

3.5 Feinkonzept II / Programmentwurf

3.6 Implementierung

4 Projektergebnisse

4.1 Soll-Ist-Vergleich

4.2 Schlußbetrachtung

5 Anhang

5.1 Glossar

5.2 Quellenverzeichnis

5.3 Anlagenverzeichnis

[Crow T. Robot]

Möchte sich eventuell noch jemand erbarmen mir ein paar Tipps zu geben. Vor allem interessiert mich wo und in welcher Reihenfolge die noch fehlenden Punkte (Integration, Test, Übergabe, Einweisung der Benutzer, Erstellung der Doku) am besten untergebracht werden.

[timmi-bonn]

Originally posted by Crow T. Robot

[...] Vor allem interessiert mich wo und in welcher Reihenfolge die noch fehlenden Punkte (Integration, Test, Übergabe, Einweisung der Benutzer, Erstellung der Doku) am besten untergebracht werden.

Ganz an den Schluß. Als Reihenfolge schlage ich vor:

Integration, Erstellen Testkonzept, Testphase, Erstellung der Doku, Übergabe. Die Einweisung der Anwender kann auch außerhalb des Projektes erfolgen oder in den Test als Pilotphase integriert werden; die dadurch gewonnene Zeit würde ich als Pufferzeit hinter den Test hängen. Btw., das Testkonzept leitet sich aus dem (guten) Fachkonzept (Pflichtenheft) direkt ab.

gruß, timmi

[Crow T. Robot]

Hallo Timmi!

Danke für deine Antwort!

Originally posted by timmi-bonn

Ganz an den Schluß. Als Reihenfolge schlage ich vor:

Integration, Erstellen Testkonzept, Testphase, Erstellung der Doku, Übergabe.

Die Reihenfolge finde ich einleuchtend und entspricht so ziemlich meinen Vorstellungen, war aber noch unsicher... "Ganz an den Schluss" heisst also, dass das alles nicht mehr zur Durchführung gehört? Oder sollte/könnte ich das als eigenes Kapitel zwischen Durchführung und Projektergebnisse packen?

Originally posted by timmi-bonn

Die Einweisung der Anwender kann auch außerhalb des Projektes erfolgen oder in den Test als Pilotphase integriert werden; die dadurch gewonnene Zeit würde ich als Pufferzeit hinter den Test hängen. Btw., das Testkonzept leitet sich aus dem (guten) Fachkonzept (Pflichtenheft) direkt ab.

Originally posted by timmi-bonn

Die Einweisung der Anwender kann auch außerhalb des Projektes erfolgen oder in den Test als Pilotphase integriert werden; die dadurch gewonnene Zeit würde ich als Pufferzeit hinter den Test hängen.

Das sollte besser nicht ausgelagert werden, denn die Einweisung ist tatsächlich auch als Pilotphase gedacht, bei der erste Problemfälle aufgegriffen werden sollen.

Originally posted by timmi-bonn

Btw., das Testkonzept leitet sich aus dem (guten) Fachkonzept (Pflichtenheft) direkt ab.

Gut dass du nochmal drauf hinweist, aber das habe ich von dir schon so oft gelesen, dass ich das niemals mehr vergessen werde.

[timmi-bonn]

Originally posted by Crow T. Robot

[...]

Die Reihenfolge finde ich einleuchtend und entspricht so ziemlich meinen Vorstellungen, war aber noch unsicher... "Ganz an den Schluss" heisst also, dass das alles nicht mehr zur Durchführung gehört? Oder sollte/könnte ich das als eigenes Kapitel zwischen Durchführung und Projektergebnisse packen?

Das ist im Prinzip egal. Wichtig ist, daß jedes Projekt mit der Abnahme/Übergabe endet.

Das sollte besser nicht ausgelagert werden, denn die Einweisung ist tatsächlich auch als Pilotphase gedacht, bei der erste Problemfälle aufgegriffen werden sollen.

Hmmm, schon schon ... Aber die Pilotphase ist, streng genommen, bereits nicht mehr Bestandteil des Projektes. Denn mit Beginn der Pilotphase sind die (Alfa-)Tests (und nur die gehören in das Projekt hinein) bereits abgeschlossen. Als Piloten bezeichnet man klassisch die Einführung in die Produktion - aber halt nur für einen begrenzten Personenkreis.

Daher hatte ich diesen Trick gewählt: In die (Alfa-)Testphase eine Art Pilot zu integrieren. Man könnte das auch als "Unterstützung durch die Fachabteilung" nennen. Aber dann wäre das kein Projekt mehr, welches Du alleine durchführst. ;-)

gruß, timmi

[Crow T. Robot]

Originally posted by timmi-bonn

Hmmm, schon schon ... Aber die Pilotphase ist, streng genommen, bereits nicht mehr Bestandteil des Projektes. Denn mit Beginn der Pilotphase sind die (Alfa-)Tests (und nur die gehören in das Projekt hinein) bereits abgeschlossen. ...

So hatte ich das auch nicht gemeint. Gedacht ist, daß mit der Integration und Einweisung ein Teil des Testkonzeptes (Integrations- und Funktionstest) abgearbeitet wird. Wenn bei der Einweisung Fehler auftreten oder von den Anwendern Wünsche bzw. Fragen geäußert werden, wird das Produkt ggfs. überarbeitet. Erst danach erfolgt die endgültige Abnahme.

Ist das in dieser Form problematisch? Schliesslich lag die Durchführung immer noch allein bei mir.

[timmi-bonn]

Originally posted by Crow T. Robot

[...] Gedacht ist, daß mit der Integration und Einweisung ein Teil des Testkonzeptes (Integrations- und Funktionstest) abgearbeitet wird. Wenn bei der Einweisung Fehler auftreten oder von den Anwendern Wünsche bzw. Fragen geäußert werden, wird das Produkt ggfs. überarbeitet. Erst danach erfolgt die endgültige Abnahme.

Ist das in dieser Form problematisch? Schliesslich lag die Durchführung immer noch allein bei mir.

Neenee, das ist so schon OK. Hauptsache ist, daß das Testkonzept von Dir erarbeitet wurde ... und daß auch danach getestet wird.

gruß, timmi

[Crow T. Robot]

Originally posted by timmi-bonn

Neenee, das ist so schon OK. Hauptsache ist, daß das Testkonzept von Dir erarbeitet wurde ... und daß auch danach getestet wird.

gruß, timmi

Das stammt natürlich von mir und das Testkonzept ist im Pflichtenheft als eigenes Kapitel definiert. Dort ist beschrieben, was wann wie und wo zu testen ist. Die einzelnen Kriterien beziehen sich jeweils auf unterschiedliche Phasen des Projekts (Modultest bei der Kodierung, Funktionstest bei der Integration, sowie begleitende und nachgelagerte Maßnahmen zur Qualitätssicherung.

Also danke für deine Mühe und deine hilfreichen Tipps!

[Dani_Various]

Also in meiner Firma wurde eine Vorlage benutzt, die relativ umfangreich ist!

Es ist eine Vorlage einer Firma, die sich fast ausschliesslich auf die Erstellung von Pflichtenheften spezialisiert hat!

http://www.hdvo.de

Kennt man warscheinlich schon zu genüge, aber ich finds trotzdem gut.

unter Downloads findet man ne gute Vorlage zum Pflichtenheft!!!

Grüße

-Dani-

[Crow T. Robot]

Danke für deinen Beitrag, aber die Seite kannte ich schon.

Allerdings hält sich meine Begeisterung in Grenzen, da die PH-Vorlage sehr weit von dem entfernt ist, was ich gewohnt bin. Außerdem habe ich mit der PH-Erstellung auch keinerlei Probleme, mir ging es um die abschließende Projektdoku.

Das hat sich aber inzwischen erledigt, ich habe mir einige Informationen zum Projektmanagement aus dem Internet und einigen Büchern geholt.

[KingKong]

SYSTEMENTWURF was kann ich da rein schreiben, wenn ich ich ein Datenbankeditor rogrammieren will? :confused: Danke :cool: