FI-AE ProjektDoku

adonis

Guten Tag,

ich mache frühjar 2011 meinen abschluss als FI-AE, als
Projekt habe ich eine Authentifizierung uber USB gemacht die
keine Key-Datei oder ähnliches benötigt. Nun soll ich eine
Projekt Dokumentation schreiben, nur hat mir keiner gesagt wie die
aussehen soll. ich habe es so ein bischen wie ein Pflichtenheft aufgebaut.
Folgenden Inhalt hab ich schon drin:

Deckblatt
Inhaltsverzeichnis
Der Betrieb
Zielbestimmung (Musskriterien/Sollkriterien)
Produkteinsatz (Anwendungsbereich, Zielgruppe)
Produktübersicht
Produktfunktionen
Produktdaten
Produktleistungen
Benutzeroberfläche
Technische Produktumgebung
Spezielle anforderungen an die Entwicklungsumgebung
Ausgangssizuation
Zeichtliche Planung der Umsetzung(Gantt-Diagramm mit 6 punkten

           1 Recherche Problemanalyse
           2 Ablaufpläne/Pseudocode Erstellen
           3 Umsetzung der entsprechend der Zielbestimmungen
           4 Testen Blackbox
           5 Testen Whitebox
           6 Dokumentation
           ? Soll/Ist Verlgeich noch mit reinbringen?

Rechnerche zu Preisen  Magnetkarten/Chipkarten + Lese -und Schreibgerät, USB-
                       Sticks)

Problemanalyse         Pro und Contra Diagramme zu dem finanziellen Faktor
                       Bestellung von 500 karten oder Sticks + 25 Lesegeräte
                       Schnittpunkte werden Gezeigt. Entscheidung + Begründung

weiter bin ich bis jetzt noch nicht und ich hab erst 7 seiten + Deckblatt und
Inhaltsverzeichnis. 16 sollen es werden .

Was muss unbedingt noch rein, und hab ich sachen drin die garnicht reingehören?

Für Tipps bin ich sehr Dankbar

PS: achja, wie soll so ein Projektantrag aussehen?

Jester

Du hast die Sachen wahrscheinlich einfach nur ganz ganz knapp aufgeschrieben. Ich weiß ja nicht wie groß Dein Projekt ist, aber selbst bei eher kleinen Sachen kommt man allein mit den Punkten

Zielbestimmung (Musskriterien/Sollkriterien)
Produkteinsatz (Anwendungsbereich, Zielgruppe)
Produktübersicht
Produktfunktionen
Produktdaten
Produktleistungen
Benutzeroberfläche

locker auf zehn und deutlich mehr Seiten. Geh am besten nochmal drüber und frag Dich bei allem, ob man das wirklich auch dann verstehen kann wenn man das Projekt nicht kennt und nicht Du ist. Oder gib es jemand anders zum Lesen, da kommen bestimmt ne Menge Fragen.

adonis

Es ist nicht groß, ich lese Informationen über den USB-Stick
berechne einen Hashwert und gucke, ob der in der Datenbank existiert,
wenn ja, wird geguckt welcher Modus der Nummer zugeordnet ist, und startet
die Software in dem Modus. Also eher etwas Banales.

Diese Authentifizierung hab ich in die Software implementiert.
und die Software ist auch nix großes, ist eine Branchensoftware,
ein Player ausgelegt für Tanzvereine/Clubs und Turniere.

So umfangreich sind die funktionen nicht.
Und ich hab gelesen, Schriftgröße soll zwischen 10 und 12 sein.
die Texte sind alle in Schriftgröße 10.

Aber ich werd die Dokumentation mal ein paar Leuten geben.

also das wäre zu wenig ja?

Zielbestimmung

Musskriterien
•	Authentifizierung über Chipkarten, Magnetkarten oder USB-Sticks
•	Anpassung der Datenbank
•	Ändern der Datenbankanfrage
•	Nach Authentifizierung soll der entsprechende
Programmmodus gestartet werden, oder Fehler
Ausgegeben werden
•	Anpassung der Login – Oberfläche

Sollkriterien

Der Programmcode soll möglichst so gestaltet sein, dass er in allen .NET
Framework Versionen Funktioniert. Das heißt, die derzeitige Software nutzt 
.NET 2.0, nächste Version soll in WPF umgesetzt werden, welches .NET 3.5
voraussetzt

Keine weiteren Kriterien

zwutz

den großteil sollte die konkrete Realisierung beanspruchen. Bei den anderen Punkten solltest du dich knapper ausdrücken. Du kannst auch ein wenig schummeln, also Schriftgröße und Zeilenabstand rauf, Tabellen, Diagramme und Quellcodeauszüge wo angebracht unterbringen und so weiter. Es zeigt sich aber in der Regel, dass man einiges davon später wieder rückgängig machen muss, um doch nicht zu viel zu haben (weswegen der Anhang nicht selten dicker ist als die Doku)
Du könntest kritische Punkte etwas ausführlicher darstellen und auf sonstige Besonderheiten auch im Hinblick auf das Umfeld deines Programmes eingehen (auf welchen Systemen muss es laufen; müssen diese Systeme gewisse voraussetzungen erfüllen; welche Datensicherheits- und -sicherungskonzepte sind geplant oder vorhanden; etc)
Dabei aber nie vergessen: die Realisierung sollte der längste Teil sein.

Und vergiss nicht, Fährten zu legen, also Stichpunkte einzustreuen, bei denen du dir sicher bist, dass während des Fachgesprächs danach gefragt wird

Fast vergessen: Wenn du erklärst, wie du ein Problem gelöst hast, vergiss nicht zu erklären, warum du es nicht anders gelöst hast (warum .NET, warum WPF? Manchmal reicht der Hinweis, dass der Kunde es so vorgegeben hat, aber erwähn es trotzdem)

adonis

Fast vergessen: Wenn du erklärst, wie du ein Problem gelöst hast, vergiss nicht
zu erklären, warum du es nicht anders gelöst hast (warum .NET, warum WPF?
Manchmal reicht der Hinweis, dass der Kunde es so vorgegeben hat, aber erwähn
es trotzdem)

Reicht es wenn ich dann auf die Zielbestimmungen verweise, weil
Soll -und Musskriterien sind ja die Wünsche des Chefs/Kunden.

Bei der Realisierung gibt es da Punkte auf die, die Kammer besonders Wert
legen, die nicht Fehlen dürfen.

Hat jemand seine alte Projektdokumentation noch, damit ich mir die Struktur
mal ein bischen angucken kann.

zwutz

adonis schrieb:

Reicht es wenn ich dann auf die Zielbestimmungen verweise, weil
Soll -und Musskriterien sind ja die Wünsche des Chefs/Kunden.

für einige Dinge, ja. Aber auch Dinge, die in deiner Entscheidungsgewalt lagen, sollten begründet werden. Man soll ja sehen, dass du dir Gedanken gemacht hast

adonis schrieb:

Bei der Realisierung gibt es da Punkte auf die, die Kammer besonders Wert legen, die nicht Fehlen dürfen.

Bei der Realisierung überraschenderweise weniger, da die ja vollständig in deiner Hand liegt. Selbstverständlich solltest du da aber zeigen, dass du was von deinem Fach verstehst.
Wichtig sind eher so Dinge wie ein Soll-Ist-Vergleich, durchgeführte Softwaretests, und solche Späßchen

adonis schrieb:

Hat jemand seine alte Projektdokumentation noch, damit ich mir die Struktur mal ein bischen angucken kann.

schreib mir mal hier übers Forum eine E-Mail, ich lass dir dann meine zukommen. Ich hatte zwar keinen Kaufmännischen Teil, da die Software weder verkauft wurde, noch dafür was eingekauft wurde, aber ein paar Anhaltspunkts, auch was den Detailgrad angeht, kann man daraus ziehen.