Projekt aus verschiedenen Modulen

[Ente19]

Ich habe da noch ein Problem mit der Unterteilung der eigentlichen Entwicklung. Mein Projekt umfasst zwei Module in unterschielichen Skriptsprachen.

Ein in HTML und PHP entwickelte Anwendung die Daten in die MySQL schreibt, und ein Systemseitiges Skript in Perl welches die Daten ausließt und verarbeitet.

Wie mache ich das am besten in der doku klar? Es sind ja eigeneltich unabhängige Vorgänge. Sollte man das unter einem Punkt abarbeiten das man zwei Module hat, oder sollte man alle Schritte für jedes Modul einzeln besprechen?

Hat vielleicht jemand ähnliches gemacht oder ne Idee wie man das Übersichtlich in die Dokumentation eingliedern kann. Es geht hier um den Überpunkt Realisierung bzw. Entwicklung.

[CyberDemon]

Original geschrieben von Ente19

Wie mache ich das am besten in der doku klar? Es sind ja eigeneltich unabhängige Vorgänge. Sollte man das unter einem Punkt abarbeiten das man zwei Module hat, oder sollte man alle Schritte für jedes Modul einzeln besprechen?

Ich habe etwas ähnliches gemacht. Eine Funktion zur Erzeugung einer Textur und eine weitere Funktion zum Anzeigen und Testen der Textur.

Ich habe diese beiden Funktionen in je einem eigenen Punkt erläutert.

Ungefähr so:

1. Realisierung

1.1 Funktion zur Erstellung der Textur

1.2 Funktion zum Anzeigen und testen der Textur

[just_me]

Wie mache ich das am besten in der doku klar? Es sind ja eigeneltich unabhängige Vorgänge. Sollte man das unter einem Punkt abarbeiten das man zwei Module hat, oder sollte man alle Schritte für jedes Modul einzeln besprechen?

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.

[Ente19]

Aber wenn ich ein einigermaßen gutes Pflichtenheft habe, dann kann ich die normalertweise gewünschten Punkte einer Dokumentation "Ist-Analyse und Sollkonzept" doch vergessen. Diese stehen doch auch in einem Pflichtenheft ausführlich drin.

Diese Punkte möchte ich eigentlich alleine aus Verständnisgründen in der Dokumentation lassen.

[just_me]

Diese Punkte möchte ich eigentlich alleine aus Verständnisgründen in der Dokumentation lassen.

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.

[Ente19]

Original geschrieben von just_me

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.)

Also um da vielleicht mal ein bisschen Anschauung rein zu bekommen, man würde also im Pflichtenheft genau schreiben was an Hardware vorhanden ist, wie der Ablauf im Detail von Abteilung zu Abteilung ist, und die Fehler aufzeigen. Zeitprobleme, Fehlerquellen die durhc manuelle Bearbeitung passieren können und und und.

In der Dokumentation schreibe ich dann als Überblick kurz zusammen das momentan die verarbeitung Manuelle abläuft und die Hardware dazu vorhanden ist oder auch nicht vorhanden ist.

Habe ich das so korrekt verstanden?

[just_me]

In der Dokumentation schreibe ich dann als Überblick kurz zusammen das momentan die verarbeitung Manuelle abläuft und die Hardware dazu vorhanden ist oder auch nicht vorhanden ist.

Habe ich das so korrekt verstanden?

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.

[Ente19]

mehr nicht? Mensch, dann weiß ich nicht was ich den ganzen Tag mache

Ich bin Anwendungsentwickler kein Autor Danke für die Hilfe.

[just_me]

Ich bin Anwendungsentwickler kein Autor

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 ...

[Ente19]

Das ist mir schon bewußt. Ich habe auch nichts gegen Dokumentationen. Aber es ist auch klar das man sich mehr mühe und mehr gedanken darüber macht wenn es die Prüfung ist. Denn hier veruscht man den Prüfern ein gutes Bild zu geben.

Wenn man nur wirklich einen Status oder Projektrelevante Dinge nennt in einer Form die so gut wie immer die selbe ist, dann ist das auch alleine vom Gedanken her schon was anderes.

Das mit dem Autor war eigentlich auch nur so daher gesagt als kleiner Witz. Ich gebe Dir vollkommen recht das man auch in der Lage sein muss zu Dokumentieren was man macht und vorallem wie und warum...