Hinweise zur Erstellung der IHK-Projektdokumentation

 

Hinweis:

Bei diesem Text handelt es sich um eine Orientierungshilfe für alle Fachinformatiker Systemintegration. Es kann aber keinerlei Verantwortung/ Haftung dafür übernommen werden, das diese Angaben von allen Prüfungsausschüssen/ Prüfern so gesehen werden!

Der Inhalt dieser Seite existiert auch als PDF-Datei!


 

Das Wichtigste vorne weg:

Bei der Projektdokumentation handelt es sich um die Beschreibung des Projektablaufs – also nicht um eine technische Anleitung. Die Technik ist mehr oder weniger nur Mittel zum Zweck – und soll nur in sofern aufgeführt werden, dass der PA sieht, dass das Projekt selbstständig durchgeführt wurde und dass Entscheidungen aufgrund von Wissen gefallen sind. Nähere technische Informationen (z. B. Ausprägung von Rechnern etc.) sind im Anhang gut aufge­hoben.

Ein Projekt umfasst immer eine Ist-Analyse (Wo soll ich eine Brücke bauen? Wie sieht der Untergrund aus? Gibt es Rahmenbedingungen wie z. B. Hochwasser), die SOLL-Beschreibung (Was baue ich? Eine Autobahnbrücke, einen Fußgänger-Überweg oder ein Eisenbahn-Viadukt) und den Weg (Projektablauf) dorthin. Hierbei werden am Anfang des Projektes alle das Projekt betreffende Entscheidungen getroffen (Wie tief wird das Fundament? Welche Baumaterialien verwende ich? Welche Vorgaben sind zu berücksichtigen [z. B. es darf nur nachts gebaut werden/ 5 Mio. Euro dürfen nicht überschritten werden]). Die Entscheidungen sind das A und O eines Projektes!

Um sich am Ende des Projektes bzw. der Projektdoku die Arbeit zu erleichtern, sollte Folgendes berücksichtigt werden: Verweise (zunächst) mit einem eindeutig und immer gleichen Platzhalter dargestellt (also z. B. „Seite XYZ“).

Die Beschreibung des Umfelds soll dem Leser/ Prüfer helfen, das Projekt ein zusortieren. Deswegen ist die Größe des Unternehmens (ggf. Abteilung), Umsatz, Mitarbeiterzahl, Systemlandschaft wichtig. Werbeaussagen und Marketingfloskeln sind hier nicht hilfreich und unerwünscht!

Bereits hier festigt sich im Kopfe des Lesers/ Prüfers ein erster Eindruck – weswegen diesem (und dem nächsten Kapitel) besondere Aufmerksamkeit gewidmet werden sollte.

Die Ausgangslage beschreibt grob und vergleichsweise untechnisch die Situation vor dem Projekt(antrag) – so wie sie der Auftraggeber schildert.

Der Auftrag schildert (ebenfalls relativ untechnisch), was der Auftraggeber wünscht. Der Auftrag ist praktisch die Grundlage des Projektantrages (= „Kostenvoranschlag“).

Die IST-Analyse beschreibt das Umfeld aus der Sicht des Projektleiters. D.h. es ist die Grundlage für Entscheidungen und die Projektrealisierung (Baumaterialien, die hier nicht erwähnt werden, können für den Brückenbau nicht genutzt werden).

Im SOLL-Zustand wird – ebenfalls aus Sicht des Projektleiters (d.h. auf einer technisch, dezidierten Sicht/ Ebene) das angestrebte Ergebnis beschrieben.

Die Vorgaben (wirtschaftlich, technisch, organisatorisch, zeitlich etc.) beschreiben Einschränkungen denen das Projekt (meistens aufgrund von Kundenwünschen) unterliegt! Alle 4 Arten von Vorgaben müssen in einem Projekt angesprochen werden.

Auf den Kostenaspekt ist besonderer Wert zu legen. Hier kann/ sollte ggf. eine Wirtschaftlichkeitsbetrachtung oder die Begrenzung des Budgets angeführt werden. Der Hinweis, dass ein Projekt möglichst kostengünstig abgewickelt werden soll ist  – genau genommen – eine Nullaussage; denn in welchem Projekt soll möglichst viel Geld verschwendet werden? Eine sinnvolle Aussage kann sein, dass der Kostenaspekt Vorrang vor der Funktionalität bzw. der Performance haben soll bzw. dass (kleine) Performance-Einbußen in kauf genommen werden können/ sollen.

IST- und SOLL-Zustand, so wie die Vorgaben stellen im Prinzip das Pflichtenheft dar!

Bevor in die Realisierung eingetreten werden kann, müssen Entscheidungen getroffen und u. a. die verwendeten Komponenten festgelegt werden. Also z. B. welche Materialien/ Geräte verwendet werden bzw. ob die vorhandenen genutzt werden können – bzw. ob sie neu beschafft werden müssen! Es gibt an keiner anderen Stelle in der Doku Entscheidungen bzw. Begründungen! (mögliche Ausnahme: Betriebsnahe Entscheidungen: z. B. in welchen Slot eines 19“-Racks ein Rechner eingebaut werden soll).

Auch notwendige Änderungen während des Projektablaufs sind hier anzusprechen (mit Verweis auf Anpassungen/ Abweichungen).

Anschließend erfolgt die Tätigkeitsplanung. Hier wird praktisch der komplette zeitliche Ablauf aus dem Projektantrag übernommen. Er kann ggf. weiter aufgeschlüsselt, sollte aber nicht verändert werden. Parallel hierzu sollte ein Projektablaufplan erstellt werden. Dieser kann in den Anhang, sollte aber von hier aus referenziert werden!

Die Projektdurchführung beschreibt grob, welche Tätigkeiten durchgeführt wurden. Für vorgenommene Einstellungen sind – so fern nicht unter „Entscheidungen“ geschehen – die Begründungen zu liefern. Allerdings gehören in die Projektdoku nur Informationen, die dazu dienen den Projektablauf zu verstehen. Konkrete Installationsbeschreibungen (im schlimmsten Fall noch mit Screenshots) haben hier nichts verloren, stören den Lesefluss (und damit das Verständnis) und sind daher Bestandteil des Anhangs. An dieser Stelle ist nochmals sehr kritisch zu prüfen, ob/ bzw. dass keine Entscheidungen getroffen werden! Es ist zu überprüfen, in wie weit bereits bei der Projekdurchführung qualitätssichernde Maßnahmen vorgenommen werden!).

Ein wichtiger Bestandteil der Projektdoku ist der Hinweis auf Probleme, Anpassungen und Abweichungen. Es gibt kein Projekt, das so abläuft, wie es ursprünglich geplant war. Diese Abweichungen sind zu benennen, zu erklären und die Lösung (so fern möglich) zu beschreiben. Hierbei ist es ganz wichtig zu beachten, dass eine Abweichung in einem Projekt nicht automatisch zu einer Abwertung des Projektes führt. Im Gegenteil: Ein gut geschildertes Problem und die Lösung dessen (ggf. aber auch der Nachweis, dass das Problem nicht lösbar war), wertet eine Projektdoku eher auf. Wichtig ist allerdings, dass keine essentiellen Dinge aus dem Projektantrag (z. B. Erstellen einer AD) weggelassen werden, da dadurch der Projektcharakter verändert wird und das Projekt u.U. nachträglich seine Genehmigung verlieren kann! Außerdem sind alle Änderungen mit dem Auftraggeber abzusprechen!

Ein weiteres wichtiges Kapitel ist die Qualitätssicherung. Diese sollte sich zumindest in ausführlichen Funktions- und ggf. Sicherheitstests niederschlagen, deren Ergebnis in Form von Prüf- bzw. Messprotokollen (gehören in den Anhang) auch dokumentiert wird. Die Aussage „Server läuft“ ist keine Aussage, die eines Fachinformatikers würdig ist. Häufig ist es auch sinnvoll die o. g. Protokolle zu kommentieren bzw. wichtige Ergebnisse hervorzuheben.

Im Soll-/ Ist-Vergleich sind deutliche Abweichungen zu begründen. Deutlich sind hierbei große absolute Zeitunterschiede oder auch große relative Zeitabweichungen.

Im der Kostenaufstellung sind im Minimum die durch die eigene Arbeit verursachten Personalkosten zu benennen. Häufig entstehen aber auch zusätzliche Kosten z. B. durch die Nutzung von DSL-Leitungen oder die Konfiguration von Geräten (z. B. Firewalls, Server), die durch andere Kollegen vorgenommen wurden.

Das Fazit ist eine (subjektive) Zusammenfassung des Projektergebnisses (ggf. auch des Ablaufs, wenn größere Probleme aufgetreten sind). Gut macht sich auch immer ein Ausblick, für was das durchgeführte Projekt alles genutzt werden kann bzw. welche Ausbaumöglichkeiten bestehen. Da es sich hierbei um das letzte Kapitel der Doku handelt (das dem Leser/ Prüfer in Erinnerung bleibt), sollte dem Fazit besondere Aufmerksamkeit geschenkt werden und es sollte auch nicht zu kurz ausfallen. Hier lohnt es sich etwas kreativ zu sein.

Die Obergrenze der Projektdoku liegt – ohne Deckblatt und Inhaltsverzeichnis und abzüglich von Grafiken und Tabellen – bei den meisten IHKs bei 15 Seiten (geringe Überschreitungen werden häufig toleriert bzw. mit nur geringen Punktabzug "geahndet"). Es gibt zwar keine Untergrenze, allerdings ist es schwer vorstellbar, dass ein ordentlich ausformuliertes Projekt deutlich unter 15 Seiten liegt. Projektdokumentationen mit 10 und weniger Seiten können erfahrungsgemäß nicht wirklich gut sein!

In den Anhang gehören alle Dokumente, die zum technischen Verständnis des Projektes benötigt werden. Insbesondere sind das Stücklisten (also z. B. Aufstellung von Hard-/ Software), Gegenüberstellungen (Minimal-Anforderung an ein Gerät vs. verwendetes/ eingesetztes Gerät), Konfigurationsschritte (wo nötig/ sinnvoll mit Screendumps), Konfigurationsdateien und – ganz wichtig – die kompletten Prüf- bzw. Testprotokolle. Hierbei kann es sich z. B. um den Screendump eines erfolgreichen „Pings“ oder den (Bildschirm-)Ausdruck eines Port-Scans sein.

Der Anhang unterliegt prinzipiell keiner Längenbeschränkung – zählt allerdings zur Projektzeit, so das sich z. B. ein 100-seitiger Anhang schlecht in 8 h Projektdokumentation schreiben lässt. Ein sinnvoller Umfang liegt erfahrungsgemäß bei 20 – 40 Seiten.

Die Kundendokumentation ist genau genommen ein eigenständiges Dokument und richtet sich an den Auftraggeber. Die Zielgruppe sollte daher genau spezifiziert werden (die Bedienungsanleitung für einen Internetzugang im Altenheim sieht bestimmt anders aus, als die Konfigurationsbeschreibung eines VPN-Server für eine Facheinheit). Prinzipiell sollte aber in allen Benutzerdokumentationen Informationen über das Projektergebnis (IP-Adressen, Port-Nr., Netzpläne etc.) enthalten sein, die notwendig sind das Projektergebnis zu betreiben ggf. auch nach zu bauen.

Die Kundendokumentation ist häufig nicht Bestandteil der Projektzeit und kann daher beliebig groß ausfallen. Daher kann es klug sein, Teile des Anhangs in die Kundendoku auszulagern. Es ist prinzipiell möglich, aus der Projektdoku bzw. dem Anhang in die Kundendoku zu referenzieren – die umgekehrte Richtung geht natürlich nicht!

Es ist darauf zu achten, dass die Kundendoku nicht zu gering ausfällt. Eine Untergrenze ist bei 10 bis 15 Seiten sehen.

Vor der Abgabe sollten, zu guter letzt, nochmals alle Verweise auf ihre Vollständigkeit untersucht (global search auf „Seite XYZ“) und (händisch!) auf Richtigkeit überprüft werden. Das Layout und die Formatierung sind zu kontrollieren. Stimmen alle Seitenumbrüche, gibt es im Blocksatz keine zu großen Leerräume (ein FISY sollte die Silbentrennungsfunktion beherrschen!), ist die Schrift überall im gleichen Font und gleich groß, sind die Überschriften und Zeilenumbrüche einheitlich usw.

Und natürlich: Sind Rechtschreibung und Zeichensetzung okay. Hier helfen ggf. auch Mitmenschen, die keine fachlichen (aber Deutsch-) Kenntnisse besitzen.

Auch soll es vorkommen, dass das automatisch erstellte Inhaltsverzeichnis anders aussieht, als man sich das vorgestellt hat (ggf. gibt es sogar Differenzen zwischen Bildschirmdarstellung und Ausdruck!!!).

Das bedeutet: Vor dem Ausdruck der für die IHK benötigten Exemplare, sollte immer eine Probeausdruck erfolgen, der auf die o.g. Punkte untersucht wird. Prinzipiell kann ein solche Dokument gar nicht oft genug und auch nicht von genügend unterschiedlichen Lesern kontrolliert werden!

Die Projektdoku + Anhang + Kundendoku sollten als ein Dokument (mit jeweils neu beginnender Seitenzahl) abgegeben werde. Bei umfangreichen Kundendokumentationen kann diese auch als separates „Werk“ gebunden werden.

Ringbindung hat sich als geeignete Abgabeform und guten Kompromiss zwischen Aussehen und Korrigierbarkeit erwiesen.



Überblick:

Typischer Inhalt der Dokumentation und empfohlene Reihenfolge

1.      Deckblatt

2.      Inhaltsverzeichnis

3.      Kopie des zugelassenen Antrages der betrieblichen Projektarbeit mit Unterschrift (ca. 3 Seiten)

In dieser Auftragsbeschreibung sollen der Ausgangszustand und der angestrebte Zielzustand enthalten sein, sowie die Beschreibung der wirtschaftlichen, technischen, organisatorischen und zeitlichen Vorgaben.

4.      Ablaufplanung (Ablaufprotokolle)

oder entsprechend: Arbeitsbericht, Verlaufsprotokoll oder Tätigkeitsangabe mit Zeitraster, Planungsunterlage u. ä.

5.      Protokoll über die Beaufsichtigung des betrieblichen Projektauftrages

6.      Durchführung und Auftragsbearbeitung (Realisierung)

Durchführen von Prozessschritten, Vorgehensweise und Qualitätssicherung. Begründung von Abweichungen und Anpassungen.

7.      Projektergebnis (Technische Unterlagen)

Qualitätskontrolle zum Beispiel Abnahmeprotokoll, Inbetriebnahmeprotokoll, Prüfprotokoll, Messprotokoll, Fehlerprotokoll, Übergabeprotokoll, Funktionsbeschreibungen, Stückliste, Schaltplan, usw.

8.      Gestaltung des Portfolios

Gestaltung der äußeren Form, sowie die inhaltliche Form, Strukturierung, fach- und normgerechte Darstellung.

9.     Kundendokumentation

Kundengerechte Anfertigung

 

Das Dokument existiert auch als (aktuelle) PDF-Datei:
http://www.fachinformatiker-systemintegration.info/hinweise_projektdoku.pdf

 

 


Zurück zu:
[TCP/IP-INFO.DE] - [FACHINFORMATIKER-SYSTEMINTEGRATION.INFO]

(Diese Seite wurde erstellt am 04.04.2009,
letzter Update am 05.04.2010 - um 16:00 Uhr
)