Projektdokumentation

Es ist gar nicht möglich, dass sich der Prüfungsausschuss jedes Projekt vor Ort persönlich ansieht. Deshalb müsst ihr das Projekt dokumentieren. Dies ist die Grundlage für die Bewertung des Projektes und ein bedeutender Teil der abschließenden Bewertung. Ich will hier keine komplette Abhandlung über die Dokumentation machen. Vermutlich habt ihr dieses Thema in der Schule bereits behandelt, wo oft auch alte Dokumentationen als gute, manchmal auch als schlechte Beispiele vorhanden sind. Aber es gibt ein paar Dinge, die oft als Kritik zu werten sind und die Bewertung negativ beeinflussen, aber auch ein paar Hinweise, die sich zwar nicht auf die Bewertung nieder schlagen, dennoch oft für den Prüfling unklar sind. Diese möchte ich hier kurz aufzeigen.

Bewertung
Es ist vielen Prüflingen nicht klar, dass die reine Durchführung des Projektes grade mal 30% der Bewertung, also maximal 30 Punkte ausmacht. Eine super Beschreibung der Durchführung alleine reicht also grade mal für eine Note 5 und damit nicht zum Bestehen. Die anderen Teile sind in ihrer Gesamtheit wichtiger. Vergesst sie nicht. Oft werden Planung und Auswertung in 1/2 oder einer Seite abgehandelt. Diese Punkte sind unwiederbringlich verloren. Die Bewertung der Dokumentation setzt sich wie folgt zusammen:

Ausgangssituation/Ist Analyse - 15% (bzw. Punkte)
Ressourcen und Ablaufplanung - 15% (bzw. Punkte)
Durchführung und Bearbeitung - 30% (bzw. Punkte)
Projektergebnisse/Auswertung - 15% (bzw. Punkte)
Gestaltung - 15% (bzw. Punkte)
Kundendokumentation - 10% (bzw. Punkte)

Insgesamt könnt ihr 100 Punkte für die Projektarbeit bekommen. Ihr seht, mit einer guten Analyse der Ausgangssituation, einer perfekten Planung von Zeit, Mitteln und Arbeitskräften und einer gut formulierten Zielstellung mit Lösungsfindung, habt ihr genau so viel gewonnen, wie mit der eigentlichen Durchführung. Die meisten Versäumnisse gibt es jedoch bei der Auswertung. Wenn ihr Tests durchführt, schreibt dies als Testprotokoll nieder. Was habt ihr getestet und wie war das Ergebnis? Wie habt ihr Fehler behoben? Habt ihr euer Ziel mit den geplanten Mitteln erreicht? Es ist übrigens gar kein Problem, wenn die Planung von der Durchführung abweicht. Wenn ihr 40 Stunden geplant und später 43 benötigt habt, ist das völlig in Ordnung und entspricht meist der Praxis. Auch wenn ihr schneller wart ist das keine Schande. Das Gleiche gilt für Mittel und Kräfteplan. Vermeidet ein „Schönrechnen“. Klar solltet ihr große Abweichungen auch begründen können. Wenn z.B. eine Bestandsaufnahmen statt der geplanten 2 Stunden plötzlich 6 dauerte, weil der Kunde mit zwanzig Rechnern maßlos untertrieben hat und die 5 Server im Keller gar nicht erst erwähnte, ist das nur ein Beispiel aus der Praxis.

Lasst uns die einzelnen Punkte noch einmal etwas genauer beleuchten:

Ausgangssituation/Ist Analyse
Wichtig ist, dass ihr in diesem Teil darstellt, worum es bei dem Projekt eigentlich geht. Ein paar erklärende Worte über das Umfeld sind ebenso wichtig, wie eine gute und detaillierte Analyse der Gegebenheiten. Was genau macht das Projekt überhaupt notwendig? Und ist es Teil eines größeren Projektes? Außerdem solltet ihr ein Ziel definieren, dass am Ende überprüft werden kann. Denkt daran, alle für das Projekt relevanten Parameter zu erfassen. Das können z.B. Datenmengen sein oder auch Bandbreiten, die zur Verfügung stehen. Alle Parameter, die für eine gute Planung des Projektes und zur Kontrolle ob das Ziel erreicht wurde notwendig sind.

Ressourcen und Ablaufplanung
Vorab habt ihr gelesen, dass ihr bereits im Projektantrag nachweisen müsst, ein Projekt planen zu können. Nun könnte man meinen, es gibt ja dort schon einen Zeitplan. Das ist zwar richtig, dieser kann aber nicht zur Bewertung herangezogen werden. Ihr könnt ihn aber guten Gewissens übernehmen und natürlich anpassen, wenn sich inzwischen Bedingungen geändert haben. Neben einem Zeitplan gehören auch ein Kräfte- und ein Mittelplan in die Dokumentation. Es ist eher unwahrscheinlich, dass ihr keine Berührungspunkte mit Mitarbeitern habt und Zuarbeiten benötigt. Ebenfalls ist es ausgeschlossen, dass keine Mittel verwendet werden und keine Kosten entstehen. Auch wenn Hardware vorhanden und Software kostenlos ist, verwendet ihr Technik der Firma und vermutlich Strom. Und in der Zeit der Projektarbeit könnt ihr keine anderen Tätigkeiten durchführen, auch das kostet den Betrieb Geld.

Der Punkt Alternativen und Lösungsfindung ist ein weiterer wichtiger Punkt der Planung. Unterschätzt diesen Punkt nicht. Versteift euch nicht auf eine Lösung, schaut was es an Alternativen gibt. Müsst ihr das Tool Programmieren, oder gibt es das schon fertig? Müsst ihr Betriebssystem X einsetzen, oder würde es auch mit Y klappen? Entscheidet gerne nach einer Nutzwertanalyse. Und wenn der Auftraggeber dann doch was anderes bestimmt, weil ihm das Logo der Lösung besser gefällt, ist das ein legitimer Grund, der auch in die Dokumentation gehört. Aber auch wenn diese Entscheidung eigentlich von vornherein schon fest steht, schaut kurz über den Tellerrand. Ich verstehe, dass dieses Thema in der Programmierung schwierig sein kann, z.B. wenn es darum geht, ein Modul für ein komplexes Projekt zu entwickeln. Da gibt es keine Alternativen, die man kaufen kann. Und wie soll man da den Nutzwert analysieren? Dann stellt doch einfach Lösungsvarianten gegenüber, denn meist gibt es viele Wege zum Ziel. Übrigens auch ein Vergleich von Angeboten ist durchaus anspruchsvoll und erfüllt diesen Punkt.

Durchführung und Bearbeitung
Dies ist wiederum ein Teil, der nur selten zu kurz kommt, dem es aber manchmal an Tiefe fehlt. Wir möchten bitte keinen Tätigkeitsbericht was ihr am Montag getan habt und was am Mittwoch und wann ihr bestellt und das ihr die Ware ausgepackt habt. NEIN! Die Durchführung beschreibt die Umsetzung von Eckpunkten der Planung und geht auf Details ein. Sie soll zeigen, dass ihr ausreichend fachliches Wissen habt. Auch auftretende Entscheidungen und die Begründung wieso etwas entschieden wurde, sind Teile der Durchführung. Ein paar Beispiele, was in der Durchführung als fachlicher Inhalt in Frage kommt (natürlich ohne Anspruch auf Vollständigkeit)

Eingestellte Parameter einer VPN Verbindung (mit Begründung)
Auswahl von Standorten von WLAN Accesspoints
Firewallregeln, die konfiguriert wurden
ein SQL Statement, dass besonders interessant ist
Das ER Modell der Datenbank (ggf. Auszüge)
Netzwerkplan des Layer 2 und/oder 3
Berechnung der Reichweite einer Funkstrecke (sowie allgemein alle Berechnungen, die gemacht wurden)
Art und Format der zur Verfügung gestellten Daten
Tests, die während der Durchführung erledigt wurden
Eingerichtete Benutzer und Gruppen für komplexe Systeme
Funktionsweise der Datensicherung
Auswahl von Verschlüsselungsmethoden mit Begründung
u.s.w.

Ihr seht, es gibt viele Dinge, die in die Durchführung hinein gehören. Wählt aus und nehmt alle wichtigen Punkte auf. Die Installation eines Betriebssystems ist eher ein Punkt, den man maximal kurz erwähnen kann, ohne weiter darauf einzugehen. Es sei denn, die Installation war besonders anspruchsvoll und weicht vom „Standard“ ab.

Projektergebnisse/Auswertung
Erinnern ihr euch noch? Ihr habt eine Planung gemacht und ein Ziel definiert. Hier ist der Teil, mal zu schauen, ob denn die Planung geklappt hat oder nicht? Ob das Ziel erreicht wurde, oder nicht? Und bitte, die Gegenüberstellung der Zeiten (Soll und Ist) gehört in diesen Teil, nicht vorne in die Planung. Auch der Teil Tests und Auswertung gehört in diesen Teil. Und bitte nicht nur schreiben, dass die Tests erfolgreich waren. Wir erwarten ein Testprotokoll, aus dem die Punkte Test, erwartetes Ergebnis, Ergebnis sowie der Vergleich zwischen beiden hervorgehen. Testet strukturiert und sinnvoll. Und man kann jedes Projekt testen, es gibt keine Ausreden. Wenn ihr dann am Ende noch ein Fazit habt, ist dieser Teil schon überstanden und hoffentlich nicht nur drei Sätze lang.

Kundendokumentation
Euer Projekt wird ja jemandem übergeben. Dazu ist eine Kundendokumentation erforderlich. Es gibt eigentlich kein Projekt, das keine Kundendoku erfordert. Die kann aber abhängig vom Projekt ganz unterschiedlich ausfallen. So kann z.B. bei einem Programmierprojekt ein Handbuch zur Benutzung entstehen. Wird ein Modul programmiert, so sollte es eine Beschreibung der API geben. Ein neues System muss gewartet werden, so kann die Kundendokumentation z.B. erklären, wie die täglichen Backups laufen und Datenträger gewechselt werden, oder wie neue Benutzer angelegt werden können. Bei einem Projekt im Bereich Netzwerk können z.B. VLANs für den Kunden dokumentiert werden bzw. Hinweise, wie Filterregeln zu ändern sind. Ihr seht, irgendetwas findet man immer, was zu Dokumentieren ist. Die Kundendokumentation kann als eigenes Dokument oder im Anhang der Projektdokumentation enthalten sein. Eure Projektdokumentation ist übrigens keine Kundendokumentation. Die Projektdokumentation macht das Projekt nachvollziehbar, die Kundendoku benutzbar. Ach ja, die Kundendokumentation gehört natürlich vollständig dazu, nicht nur in Auszügen, da sie in die Bewertung einfließt.

Gestaltung
Allein für die Gestaltung könnt ihr 15 Punkte kassieren. Und das sind leicht verdiente Punkte. Achtet auf folgende Punkte, dann seid ihr auf der sicheren Seite:

Achtet auf Rechtschreibung und Grammatik. Moderne Textverarbeitung hat entsprechende Kontrollen. Auch solltet ihr die Arbeit ruhig mal jemandem zum Korrekturlesen geben.
Benutzt eine gute Struktur. Deckblatt, Inhaltsverzeichnis, dann die Kapitel. Ganz ans Ende gehört der Quellennachweis sowie der Anhang.
Jede Seite sollte über eine Seitenzahl verfügen. Natürlich sollten diese mit dem Inhaltsverzeichnis überein stimmen.

Es gibt auch keine Vorschrift zur verwendeten Schriftart oder zum Textmaß. Viele Universitäten bieten Vorlagen für Studenten an. Ihr könnt euch gerne an solchen Vorlagen orientieren.

Noch ein ganz wichtiger Hinweis. In letzter Zeit neigen viele Prüfling dazu alle Bilder und Grafiken sowie Tabellen in den Anhang zu verbannen. Bitte unterlasst das. Es macht das Lesen bei der Korrektur sehr schwer. Tabellen gehören an die Stelle, wo darauf eingegangen wird. Das Gleiche gilt für Grafiken und Bilder.

Umfang
Automatisch stellt sich noch die Frage nach dem Umfang der Dokumentation. Irgendwo kursieren Zahlen, dass man nur eine bestimmte Anzahl von Seiten haben darf. Vergesst das bitte alles schnell wieder. Die Anzahl der Seiten ist natürlich auch stark davon abhängig, wie viele Grafiken ihr verwendet habt. Bei „normaler“ Schriftgröße und durchschnittlicher Verwendung von Grafiken sollte der Umfang der Dokumentation bei 20 bis 25 Seiten liegen, inkl. Deckblatt und Inhaltsverzeichnis. Die Kundendokumentation kann noch mal ein paar Seiten umfassen. Bei Anwendungsentwicklern sind es i.d.R. 10 Seiten mehr. Aber bitte jetzt nicht auf diese Mengen versteifen. Eine knappe Doku kann auf 10 Seiten mehr Inhalt liefern, also eine Doku mit viel Prosa und 30 Seiten.

Soll eigentlich Quelltext in die Dokumentation? Ja, aber! Bitte keine unzähligen Seiten an Quelltext. Zeigt uns zwei oder drei Auszüge, die ihr gerne in den Anhang packen könnt. Eine besonders interessante Stelle darf auch in die Durchführung, das ist kein Problem.

Pflichtenheft
Für Anwendungsentwickler stellt sich oft die Frage, ob ein Pflichtenheft gefordert ist, oder nicht. Diese Frage ist eigentlich ganz einfach zu beantworten. Gibt es für das Projekt ein Pflichtenheft, dann ja. Gibt es keines, braucht ihr euch keines auszudenken. Grade bei innerbetrieblichen Projekten wird oft darauf verzichtet. Damit hier keine Ungerechtigkeit entsteht, wird das Pflichtenheft nicht als separater Punkt bewertet. Es gehört mit in den Teil der Ressourcen und Ablaufplanung. Um sich doppelte Schreibarbeit zu ersparen, könnt ihr in der Planung auf das Pflichtenheft verweisen. Bsp: ihr schreibt in den Abschnitt Zeitplanung: „Siehe Pflichtenheft (Anhang) Seite 5 Punkt 3“. Oder ihr nutzt die beliebten Funktionen Kopieren und Einfügen.

Lastenheft
Und was ist mit dem Lasterhaft? Na wenn es eins gibt, dann her damit. Und da es ja nicht von euch erstellt wurde, gehört es auf den Projektantrag und später in den Anhang der Dokumentation.

Eigenständigkeitserklärung
Bitte versichert uns, dass ihr eure Projektdokumentation wirklich selbstständig und ohne fremde Hilfe angefertigt habt. Als die Projektarbeiten noch in gedruckter Form abgegeben wurden, war diese Seite selbstverständlich. Heute scheint sie irgendwie gerne vergessen zu werden. Klar, eine unterschriebene Seite scannen und anhängen ist uncool. Wie wäre es mit einer digitalen Signatur? Überrascht uns.