Hauptteil
Eigenschaften einer Einleitung
Die Einleitung soll den Leser mit knappen präzisen Worten zum Kernproblem der Arbeit führen. Auch hier gilt die Regel: wenig, wichtig, wuchtig!
- Die ?Ich-Form? ist bis auf wenige zwingende Ausnahmen zu vermeiden.
- Position / Situation des Prüflings innerhalb der Firma mit Aufgabengebiet darstellen (von global zu lokal)
- Situation der auftraggebenden Firma beschreiben / das Umfeld der Aufgabenstellung aber die Aufgabenstellung selbst nur anreißen, die Erörterung des Auftrags folgt erst in der Problemdefinition!
- Ein Verweis auf das Glossar (?Abkürzungen werden 1x ausgeschrieben und im Glossar aufgeführt? ) sowie weitere technische Angaben zur Projektarbeit bezüglich Zitaten, Quellennachweisen, etc. werden am Ende der Einleitung eingefügt.
- Weitere Verweise auf Anhänge bzw. Unterlagen, die zur Dokumentation des Projektes gehören können noch eingefügt werden.
Einzelne Projektphasen untergliedern die Arbeit
Der Hauptteil der Dokumentation beginnt mit der Definition der einzelnen Projektphasen. Ein Projekt ist grundsätzlich in mehrere Projektphasen unterteilt:
- Definitionsphase
- Planungsphase
- Umsetzungsphase
- Abschlussphase
Definitionsphase
In der Definitionsphase müssen grundlegende Bedingungen für das Projekt geklärt werden. Neben dem Auftraggeber und dem Auslöser (Begründung) für das Projekt, müssen das Umfeld und die Schnittstellen mit ihren Auswirkungen auf das Projekt klar und eindeutig beschrieben sein. Die Grundüberlegungen für die spätere Vorgehensweise werden hier ebenso beschrieben, wie Gründe für eventuelle Abweichungen vom Projektantrag. Als Ergebnis der Definitionsphase sollen mehrere Lösungswege angesprochen werden und die Auswahl eines Lösungsweges für das Projekt begründet werden.
Problembeschreibung
Die Problembeschreibung erklärt den Auslöser für das Projekt oder warum der Kunde ursprünglich den Kontakt zu einem IT-Dienstleister aufgenommen hat.
Mögliche Probleme des Kunden sind:
- kein Support
- fehlende Kompatibilität
- geringe Kapazität
- Image ist gefährdet durch ?altes? Erscheinungsbild bei Kundenkontakt
- neue Sicherheitsauflagen
- Rechtslage geändert
- hohe Kosten durch Produktionsausfall
- undefinierbare wechselnde Fehlerquellen im System
- häufiger Systemausfall
- veraltete Hardware
- kein ausreichender Virenschutz
- unzureichende Firewall
- unterschiedliche und verteilte Datenbestände
- Schwankungen im Stromnetz
- Unzufriedenheit am Arbeitsplatz
- Performanceprobleme
- geringer Automatisierungsgrad
- hohe Fehlerquote durch manuelle Eingriffe
- fehlende Fachqualifikation des Kunden
- etc.
Zieldefinition
Im Laufe eines Kundengespräches (siehe Expertengespräch) ergeben sich meist
Zielvorstellungen, die sich vom ursprünglichen Problem unterscheiden. Hier muss eine Feinziel-Analyse erfolgen, die Gegenstand des Projektauftrags wird!
Mögliche Ziele des Kunden sind:
- einfache kostengünstige Administration
- Erweiterbarkeit
- maximale Ausfallsicherheit
- geringe Lizenzgebühren
- maximale Sicherheit im Datenschutz
- Effizienzsteigerung
- minimaler Zeitaufwand zur Datenrekonstruktion
- Zukunftssicherheit
- Imageförderung
- ausreichende Rechenleistung für jeden Anwender
- automatisiertes Backup
- automatisierte Defragmentierung zur Performanceerhaltung
- zentrale Hardwaresteuerung
- graphische Analyse / Anzeige
- etc.
Ist-Analyse
Um einen Lösungsweg entwerfen zu können, ist eine genaue Kenntnis der Kundensituation notwendig. Eine Arbeitsplatzbeschreibung der Mitarbeiter ist dabei ebenso wichtig wie eine Bestandsaufnahme der Hard- und Softwareausstattung.
Für die Hardware bietet sich eine tabellarische Aufzählung an!
Soll-Konzept
Mehrere Lösungswege werden kurz gegenüber gestellt und gegeneinander abgewogen.
Nach der Entscheidung für einen Lösungsweg muss die weitere Vorgehensweise definiert werden, mit der das definierte Ziel erreicht werden soll.
Lastenheft-Pflichtenheft
Zur Übersicht noch einmal die Einordnung in das Dokument bzw. die Projektplanung innerhalb der Definitionsphase:
- Problemdefinition
- Zieldefinition (Lastenheft)
- Ist-Analyse
- Soll-Konzept (Pflichtenheft)
Lastenheft
Ein Lastenheft (teils auch Anforderungsspezifikation, Kundenspezifikation oder Requirements Specification) beschreibt die unmittelbaren Anforderungen durch den Auftraggeber eines Produktes.
Das Lastenheft beschreibt in der Regel somit, was und wofür etwas gemacht werden soll (Fachkonzept). Die Adressaten des Lastenhefts sind der (externe oder firmeninterne) Auftraggeber sowie die Auftragnehmer. In der Softwaretechnik ist das Lastenheft das Ergebnis der Planungsphase und wird in der Regel einvernehmlich von den Bestellern und den Entwicklern als Vorstufe des Pflichtenhefts überarbeitet.
Wurde ein Lastenheft angenommen, folgt mit dem Pflichtenheft die nächste Phase - dieses beschreibt, was und womit etwas realisiert werden soll. Dabei können gewöhnlich jeder Anforderung des Lastenhefts eine oder mehrere Leistungen des Pflichtenheftes zugeordnet werden. So wird auch die Reihenfolge der beiden Dokumente im Entwicklungsprozess deutlich: Die Anforderungen (requirements) werden durch Leistungen (features) erfüllt.
Pflichtenheft
Das Pflichtenheft ist die vertraglich bindende, detaillierte Beschreibung eines zu
erstellenden Werkes, zum Beispiel des Aufbaus einer technischen Anlage, der Konstruktion eines Werkzeugs oder auch der Erstellung eines Computerprogramms. Die dazu erforderliche Arbeit liegt allein in der Verantwortung des Herstellers oder Auftragnehmers, diese ist zunächst nicht der Einrede des Bestellers oder Auftraggebers unterworfen, es sei denn, beide arbeiten gemeinsam an dem zu erstellenden Werk.
Laut DIN 69905 umfasst das Pflichtenheft die ?vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts?.
Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes
Pflichtenheft genannt) sind nun präzisiert, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.
Das Pflichtenheft wird vom Auftragnehmer (Entwicklungsabteilung/-firma) formuliert und auf dessen Wunsch vom Auftraggeber bestätigt. Idealerweise sollten erst nach dieser Bestätigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen. Der Auftragnehmer hat einen durch den Vertrag bestimmten Anspruch auf eine solche Bestätigung (Mitwirkungspflicht nach §643 BGB).
Im Gegensatz zum technischen Design (auch technische Spezifikation ? wie wird es umgesetzt?) beschreibt das Pflichtenheft die geplante technische Lösung ? in unserem Beispiel die Software ? als Black Box (was wird umgesetzt?). Entsprechend enthält es in der Regel nicht die betriebliche Lösung der Aufgabenstellungen des Auftraggebers. Schon gar nicht beschreibt es die (hier beim Softwarebeispiel) Implementierungsprobleme, sondern allenfalls die Schnittstellen, deren sorgfältige Beschreibung solche Probleme
vermeiden soll.
Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Fälle explizit ein- oder auszuschließen.
Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausführung des Werkvertrages oder auch des Kaufvertrages beschließt. Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Software die Forderungen des Pflichtenheftes in dem Verständnis des Bestellers erfüllt.
Ein Pflichtenheft sollte wie folgt gegliedert sein:
- Zielbestimmung
- Musskriterien: unabdingbare Leistungen, in jedem Fall zu erfüllen
- Sollkriterien: die Erfüllung dieser Kriterien wird angestrebt
- Kannkriterien: die Erfüllung ist nicht unbedingt notwendig und sollte nur angestrebt
- werden, falls noch ausreichend Kapazitäten vorhanden sind
- Abgrenzungskriterien: diese Kriterien sollen bewusst nicht erreicht werden
- Produkteinsatz
- Anwendungsbereiche
- Zielgruppen
- Betriebsbedingungen: physikalische Umgebung des Systems, tägliche Be-triebs-
- zeit, ständige Beobachtung des Systems durch Bediener oder unbeaufsichtigter Betrieb
- Produktübersicht: kurze Übersicht über das Produkt
- genaue und detaillierte Beschreibung der einzelnen Produktfunktionen
- Produktdaten: langfristig zu speichernde Daten aus Benutzersicht
- Produktleistungen: Anforderungen bezüglich Zeit und Genauigkeit
- Qualitätsanforderungen
- Benutzeroberfläche: grundlegende Anforderungen, Zugriffsrechte
- nichtfunktionale Anforderungen: einzuhaltende Gesetze und Normen, Sicherheitsanforderungen, Plattformabhängigkeiten
- technische Produktumgebung
- Software: für Server und Client, falls vorhanden
- Hardware: für Server und Client getrennt
- Orgware: organisatorische Rahmenbedingungen
- Produktschnittstellen
- spezielle Anforderungen an die Entwicklungsumgebung
- Entwicklungsschnittstellen
- Gliederung in Teilprodukte
- Ergänzungen
- Glossar: eventuelle Fachausdrücke werden für Laien erläutert.
Planungsphase
Die Planungsphase ist die logische Aufarbeitung des Sollkonzeptes. Der im Sollkonzept beschriebene Lösungsansatz wird jetzt in seine Teilschritte zerlegt und für eine sinnvolle Abarbeitung vorbereitet.
- Projekt-Strukturplan
- Ablauf und Zeitplanung
- Qualitätsplan mit Definition der Meilensteine
- Schnittstellen und Einflussfaktoren
- Netzplan
- Verkabelungsplan
- Gebäudeplan
- Kosten-Nutzen-Analyse
- Übersicht über die Datenorganisation und Berechtigungen
- Datenschutzkonzept
- Datensicherungskonzept
- etc.
Projekt-Strukturplan
Ein erster Schritt der Planung wird meist mit einer Mind-Map begonnen und endet mit einer To-Do-Liste. Die so ermittelten Arbeitsschritte müssen nun geordnet werden. Die Auflistung bzw. Zuordnung der Arbeitsschritte zu Überbegriffen nennt man Strukturplan, er schafft eine erste Übersicht über den Umfang des Projektes. Innerhalb einer Firma ist ein solcher Strukturplan notwendig, um die einzelnen Elemente eines Projektes den jeweiligen
Kostenstellen zuzuordnen.
Ablauf und Zeitplan
Ausgehend vom Strukturplan wird jedem Arbeitsschritt eine Zeitkomponente zugeordnet.
Anhand der Eigenschaften der Arbeitsschritte (nacheinander oder gleichzeitig) und ihrer Zeitdauer wird nun ein Projektablaufplan erstellt, aus dem eine genaue Zeitplanung
resultiert.
Qualitätsplan mit Definition der Meilensteine
Im Ablaufplan ergeben sich einige ?kritische Engstellen?, sogenannte ?single points of failure?, von denen der Fortgang des Projektes abhängt. Diese Engstellen sind natürliche Meilensteine des Projektes. Je genauer der erwartete Projektzustand an diesen Meilensteinen im Vorfeld definiert wurde, desto besser lässt sich auch die Qualität bzw. der Zustand des Projektes zu diesem Zeitpunkt beurteilen.
Schnittstellen und Einflussfaktoren
Personen, Abteilungen, Hardware oder Software stehen in Abhängigkeit zum Projekt und bestimmen den erfolgreichen Verlauf mit. Diese Schnittstellen und Einflussfaktoren müssen genau beschrieben werden.
Netzplan
Im Netzplan wird skizzenhaft aber genau gezeigt, welche aktiven Geräte auf welche Weise miteinander vernetzt sind. Aus dem Netzplan muss der Standort des jeweiligen Gerätes hervorgehen.
Verkabelungsplan
Ein Verkabelungsplan gibt genaue Auskunft über die verwendeten Kabel, deren Verlauf und ihren Anfangs- und Endpunkt. Meist werden sie nach Ausgangs- und Endpunkt benannt bzw. gekennzeichnet. Die abschließende Dokumentation der Verkabelung muss Lagepläne einschließen, welche die Identifikation und Lage von Verteilern, Kabelwegen, Kabeln, Kabelverbindungen, Anschlusspunkten, Gestellen, Rangierfeldern und Schutzeinrichtungen sowie Einzelheiten über Erdung und Potentialausgleich umfassen.
(siehe Planungsrichtlinien für Kommunikationsnetze in Bayern (KomNet))
Gebäudeplan
Bei kleinen Netzen lassen sich der Netzplan und der Verkabelungsplan in den Gebäudeplan integrieren. Bei großen Netzen sind es drei miteinander verknüpfte aber eigenständige Pläne.
Im Gebäudeplan müssen auch die im Verkabelungsplan angesprochenen Kabelschächte und der Ort der Anschlussdosen erkennbar sein.
Kosten-Nutzen-Analyse
Stehen die Kosten oder eine perfekte Lösung im Vordergrund? Auftraggeber müssen den Nutzen eines Systems zu einem Zeitpunkt beurteilen, zu dem er größtenteils noch nicht quantifizierbar ist. Während das System bzw. seine Umsetzung reift, stiftet es sowohl quantifizierbaren als auch nicht quantifizierbaren Nutzen, wie z.B. höhere Arbeitsplatzzufriedenheit, verbesserte Abläufe, höhere Kundenzufriedenheit und ein besseres Unternehmensimage. Eine Kosten-Nutzen-Analyse soll zumindest im Nachhinein die Entscheidung für ein Projekt rechtfertigen.
Zum Einen muss also eine Aufstellung der Arbeitszeit erstellt und finanziell ausgewertet werden, zum Anderen werden die verwendeten Ressourcen aufgelistet und der Gesamtpreis ermittelt (Anschaffungskosten, Betriebskosten, Fixkosten, variable Kosten, Gemeinkosten, etc.).
Der Nutzen resultiert aus einer Gegenüberstellung von ?Vorher? und ?Nachher?!
Übersicht über Rechte- und Datenorganisation
Alle Systemeinstellungen (abhängig von ihrer Bedeutung für das Projekt) müssen dokumentiert werden, damit ein fachkundiger Dritter das Projekt wiederholen kann.
Datenschutzkonzept
Bei Bedarf wird hier die Umsetzung der 10 Gebote des Datenschutzes geplant bzw. die Datenschutzvorgaben des Bundes und der Länder auf das Projekt (Netzwerk, Webseite, etc.) angewendet.
Datensicherungskonzept
Bei Bedarf wird hier die Umsetzung von Sicherungsverfahren und Sicherungsarten geplant (Ursicherung, Datensicherung, Systemsicherung; inkrementell, differentiell, Vollsicherung, Generationenprinzip, etc.).
Umsetzungsphase
Die Umsetzungsphase wird von vielen mit dem eigentlichen Projekt gleichgesetzt, tatsächlich ist sie nur noch die konsequente Abarbeitung der geplanten Arbeiten.
- Durchführung der geplanten Arbeiten
- Controlling (nach Qualitätsplan mit Meilensteinen)
- Tests (Systemtests)
Während der Durchführung müssen oftmals Hardwareeinstellungen oder Ergebnisse dokumentiert werden. Der Zeitbedarf für diese Dokumentation soll dem Projekt angemessen geplant und in der Dokumentation als eigener Posten angegeben werden. Als Faustregel gelten zehn Prozent der gesamten Projektzeit.
Abschlussphase
In der Abschlussphase werden die Projektnotizen ausgewertet und die Ergebnisse
beschrieben. Sie teilt sich in folgende Unterpunkte:
- Projektverlaufsdokumentation
- Fazit
- Präsentation
- Übergabe des Projektes
Projektverlaufsdokumentation
Innerhalb der Dokumentation findet nun ein Soll?Ist?Vergleich statt. Die Zeitplanung wird der real benötigten Zeit gegenübergestellt und sämtliche Abweichungen werden benannt, erklärt, und begründet.
Fazit
Zuallererst werden im Fazit die Kernpunkte (Probleme und Ziele) des Projektes noch einmal aufgegriffen und mit wenigen Worten der Erfolg der Arbeit bewertet. Probleme während der Umsetzung und eventuell nicht erreichte Ziele lassen sich hier noch einmal erläutern. Zum Schluss sollte ein Verweis auf das Kosten- und Nutzenverhältnis der vorliegenden Arbeit sowie ein Ausblick in die Zukunft gegeben werden. Hier ist die eigene Meinung gefragt.
Präsentation
Die Präsentation und die Übergabe des Projektes sind in der Regel nicht mehr Gegenstand der Dokumentation.
Ausbildung gesucht?
Du willst Dein Hobby zum Beruf machen? Dann bewerbe Dich bei uns als Fachinformatiker für Anwendungsentwicklung / Systemintegration.
