Dokumentationsanforderungen im IT-Projektmanagement
Aus Winfwiki
| Name der Autoren: | Emanouel Tachtsoglou, Rafael Arndt |
| Titel der Arbeit: | "Dokumentationsanforderungen im IT-Projektmanagement" |
| Hochschule und Studienort: | FOM Neuss |
Inhaltsverzeichnis
Inhaltsverzeichnis
|
1 Einleitung
Der Begriff der Dokumentation bezeichnet allgemein das detaillierte und strukturierte Festhalten von Informationen über Dinge und Vorgänge, um diese einem bestimmten Personenkreis zur Kenntnis zu bringen. Die vorliegende Fallstudie befasst sich mit den Dokumentationsanforderungen im IT-Projektmanagement.
Es ist schon seltsam: Zum Thema Projektmanagement existiert eine riesige Literaturvielfalt und in den entsprechenden Nachschlagewerken ist alles Mögliche dazu von A-Z definiert. Jedoch zum Thema Dokumentationsanforderungen im Projektmanagement ist dieses gar nicht oder nur selten der Fall. Dabei ist die Projektdokumentation in der DIN 69901 ganz klar definiert als "Zusammenstellung ausgewählter, wesentlicher Daten über Konfiguration, Organisation, Mitteleinsatz, Lösungswege, Ablauf und erreichte Ziele des Projektes".
Eine würdige Bedeutung hat die Projektdokumentation offensichtlich nur für Architekten und Ingenieure, denn für diese Ingenieurdisziplinen gibt es die Honorarordnung(HOAI), in der die Projektdokumentation als eigene, und nicht schlecht dotierte, Phase definiert ist. Das ist auch verständlich, denn wer mit dem Architekten ein Gebäude erstellt hat oder mit einem Maschinenbauer eine komplexe Maschine entwickelt und zum Laufen gebracht hat, der möchte am Ende selbstverständlich auch klar die Entwicklungs- / Entwurfsphase, die Ausführungszeichnungen, die gesamten Kosten sowie die Wartungs- und Bedienungsanleitungen strukturiert dokumentiert haben, um im Laufe der Nutzungsdauer jederzeit darauf zugreifen zu können. Das gilt für Architekten und Ingenieure.
Doch warum gilt dieses nicht für Projektmanager? In der Praxis ist es oftmals der Fall, dass Projekte abgeschlossen, ihr Ergebnis zwar noch ordentlich präsentiert, aber es gibt keine saubere, nachvollziehbare Zusammenfassung der Projekt-Ergebnisse im Stile einer klassischen Dokumentation. Dazu reicht oft die Energie des Projektleiters oder das Projekt-Budget nicht mehr. Häufig wird es auch nicht im Projektmanagement-Handbuch (PM-Buch) eines Unternehmens beschrieben und eingefordert oder es wird einfach vergessen. Dabei ist die Erstellung der Dokumentation sehr wichtig und im Grunde genommen auch so einfach, wenn man im Laufe des Projektes permanent auf dieses Ziel hingearbeitet hat.
1.1 Zielgruppe
Die Fallstudie richtet sich an unerfahrene Mitarbeiter von Unternehmen, die in IT-Projekten eingesetzt sind und sich einen ersten Überblick über die vorhandenen Dokumente und Basiskonzepte verschaffen möchten.
1.2 Abgrenzung
Die Fallstudie bietet einen allgemeinen Einstieg in das Themengebiet der Dokumentationsanforderungen in IT-Projekten. Kapitel 5 der Fallstudie beinhaltet die relevanten Basiskonzepte eines IT-Projektes. Hierbei muss klar betont werden, dass aufgrund des begrenzten Potenzials an zu erstellenden Seitenzahlen, sowohl die Themengebiete IT-Projektmanagement, Dokumentation aber vor allem die Basiskonzepte auf die wesentlichen Informationen komprimiert wurden.
2 IT-Projektmanagement
Im folgenden werden die Grundlagen zum Thema IT-Projektmanagement erläutert.
2.1 Definition IT-Projektmanagement
Projektmanagement definiert sich nach DIN 69901 als Gesamtheit von Führungsaufgaben, -organisation, -techniken, und -mitteln für die Abwicklung eines Projektes. Da es sich beim IT-Projektmanagement nicht um gewöhnliche Projekte handelt sondern um IT-Projekte, geht es beim IT-Projektmanagement hauptsächlich um die Abwicklung von Softwareentwicklungs-Projekten.
In der Geschichte der Menschheit wurden eine Reihe von großen Projekten durchgeführt, wie z.B. der Bau der Pyramiden im alten Ägypten und der chinesischen Mauer. Alle diese Projekte wurden geplant und in ihrer Durchführung gesteuert. Als wissenschaftliche Disziplin der Managementlehre wurde Projektmanagement erst nach dem zweiten Weltkrieg entwickelt. Anerkannt und umfassend entwickelt worden ist sie erst in den letzten zehn bis zwanzig Jahren.
Die Notwendigkeit von Projektmanagement resultiert aus den im Laufe der Zeit veränderten wirtschaftlichen Rahmenbedingungen. In Folge von Globalisierung, gestiegenem Konkurrenzdruck, technischem Fortschritt und gewachsenen Kundenansprüchen bietet Projektmanagement ein effizientes Instrument, um diesen Herausforderungen gerecht zu werden. Jedoch bietet ein systematisches Projektmanagement wesentliche Vorteile, unter anderem Rückgängige von Terminverzögerungen, Reduktion von Kosten sowie eine Steigerung der Kundenzufriedenheit.
2.2 Definition IT-Projekt
Unternehmen führen Arbeiten aus. Arbeit gliedert sich in der Regel entweder in Tätigkeiten oder in Projekte, wenngleich sich Tätigkeiten und Projekte manchmal überschneiden. Tätigkeiten und Projekte besitzen viele gemeinsame Charakteristika:
- werden von Menschen verrichtet
- sind beschränkt durch limitierte Ressourcen
- werden geplant, ausgeführt und kontrolliert.
Projekte werden oft implementiert als Mittel zur Erreichung von strategischen Unternehmenszielen. Primär differieren Tätigkeiten und Projekte in der Tatsache, dass Tätigkeiten permanent und repetitiv sind, während Projekte temporär und einmalig sind. Hinsichtlich dieser Eigenschaften lässt sich folgende Definition für ein Projekt ableiten: Ein Projekt ist ein temporäre Anstrengung, welche zur Erstellung eines unikaten Produkts oder Dienstleistung durchgeführt wird. Eine weitere Definition liefert das Deutsche Institut für Normung(DIN). Nach DIN 69901 definiert sich ein Projekt als ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in Ihrer Gesamtheit gekennzeichnet ist wie z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.
Folgt man der ersten Definition meint temporär, dass jedes Projekt einen definierten Beginn sowie ein definiertes Ende besitzt. Unikat bedeutet in diesem Zusammenhang, dass sich jedes Produkt oder Dienstleistung in einer bestimmten Art und Weise auszeichnet und sich dadurch von allen anderen Produkten oder Dienstleistungen unterscheidet.
Projekte sind für viele Unternehmen ein Mittel um auf jene Anforderungen zu reagieren, welche durch operationale Tätigkeiten nicht mehr zum gewünschten Ergebnis führen. Sie werden in allen Hierarchiebereichen im Unternehmen verwendet. Dabei können eine Person oder auch tausende Personen in ein Projekt involviert sein. Die Dauer eines Projekts erstreckt sich in einem Zeitraum von einigen Wochen bis hin zu mehr als fünf Jahren.
Beispiele für Projekte beinhalten:
- Entwicklung eines neuen Produkts oder Dienstleistung
- Herbeiführung einer Struktur-, Personal-, Stilveränderung eines Unternehmens
- Konstruktion eines Gebäudes oder Anlage
- Aufbau eines Wasserversorgungssystem in einem Entwicklungsland
Basierend auf IT-Projekte geht es vielmehr um die Entwicklung oder Anschaffung von neuen oder modifizierten Informationssystemen.
2.2.1 Temporär
Temporär meint, dass jedes Projekt einen definierten Beginn sowie ein definiertes Ende besitzt. Das Ende ist erreicht wenn im trivialsten Fall die Zielvorgaben des Projekts erreicht wurden. Es kann aber auch sein, dass man während des Projekts zu der Erkenntnis gelangt, die Zielvorgaben des Projekts werden nicht erreicht oder können nicht erreicht werden. Auch dann ist das Projekt zu Ende. Des Weiteren könnte die Notwendigkeit des Projekts nicht mehr bestehen und somit ebenfalls zu Terminierung des Projekts führen. Temporär bedeutet nicht zwangsweise, dass das Projekt von kurzer Dauer ist. Viele Projekte halten über mehrere Jahre. Wie dem auch sei, Fakt ist jedoch, dass die Dauer des Projekts endlich ist und somit kein fortlaufendes Unterfangen ist.
Fundamentale Unterschiede zwischen Projekten und Tätigkeiten bestehen hinsichtlich ihrer Ziele. Projekte streben nach der Erreichung des Projektziels um das Projekt anschließend wieder zu beenden während die Ziele einer fortlaufenden nicht-projektbezogenen Tätigkeit in der Aufrechterhaltung des Betriebs bestehen.
Temporär ist ebenfalls das Projekt Team. Dieses wird ausschließlich zur Durchführung des Projekts gegründet und nach seiner Vollendung wieder aufgelöst.
2.2.2 Einzigartiges Produkt, Dienstleistung oder Ergebnis
Projekte implizieren etwas, was noch nie zuvor gemacht wurde und besitzen somit eine Unikate Eigenschaft. Ein Produkt oder eine Dienstleistung kann sogar einzigartig sein, wenn die Kategorie zu der sie gehören sehr umfangreich ist.
Zum Beispiel wurden unzählige Software Produkte im Laufe der Zeit entwickelt, doch jede Software an sich ist einzigartig - unterschiedliches Design, Funktionalität, Architektur, Benutzerfreundlichkeit usw.
2.2.3 Progressive Ausarbeitung
Progressive Ausarbeitung ist ein Charakteristikum von Projekten, welche die Eigenschaften von temporär und Unikat integriert. Aufgrund der Tatsache, dass jedes Produkt eines jeden Projektes einzigartig ist, müssen die Charakteristika, die das Produkt oder Dienstleistung kennzeichnen, im Vorhinein progressiv ausgearbeitet werden. Nur eine progressive Ausarbeitung des Projekts führt in der Regel dazu, dass jedes Produkt eines jeden Projektes ein Unikat ist.
Progressiv meint hier eine schrittweise Verrichtung während Ausarbeitung die sorgfältige und detaillierte Planung des Projekts inkludiert. Diese Charakteristika des Produkts werden relativ früh im Projekt allgemein definiert, bis sie im weiteren Verlauf expliziter und detaillierter werden im Zuge des durch das Projekt Team immer besser und umfangreicher entwickelten Verständnisses zum Produkt. Die progressive Ausarbeitung der Produkt Charakteristika muss sorgfältig mit Hilfe eines angemessenen Definitionsumfangs koordiniert werden, ganz besonders wenn das Produkt auf Basis eines Vertrags entwickelt werden soll.
2.3 Ziel Projektmanagement
Ein Projekt unterliegt der Einhaltung der Bestimmungsgrößen Zeit, Qualität und Kosten. Ziel des Projektmanagements ist es, ein Projekt so zu planen, dass es in kürzester Zeit, in der bestmöglichen Qualität und zu möglichst geringen Kosten abgewickelt wird. Dabei ist es Aufgabe der Projektleitung Überraschungen im Projektverlauf zu vermeiden, Probleme frühzeitig zu erkennen, Maßnahmen gegen Verzögerungen und Kostensteigerungen im laufenden Projekt einleiten zu können, sowie Aufgaben und Ressourcen delegieren zu können.
2.3.1 Zeit
Zu Beginn des Projekts existieren eine Startzeit und eine geplante Endzeit, bis zu der das Produkt oder Dienstleistung erstellt werden muss. Die Zeit zwischen diesen beiden Zeitpunkten ist die Dauer des Projekts, welche vom Projektleiter zu Beginn des Projekts geschätzt oder vorgegeben wird.
2.3.2 Qualität
Die Leistung bzw. Qualität meint das sachliche Ergebnis eines Projektes[1]. Wie in Kapitel 2.2.3 bereits erläutert, müssen dazu die Charakteristika des Produkts vom Auftraggeber und Projektleiter definiert werden, so dass beide Parteien einer Meinung hinsichtlich des zu erstellenden Produkts oder Dienstleistung sind.
2.3.3 Kosten
Die Durchführung von Projekten erfordert die Bereitstellung eines Budgets. Zum Projektstart werden die Kosten geschätzt und zwischen Auftraggeber und Projektleiter fixiert. Sie beziehen sich hauptsächlich auf Personal(intern und extern) sowie die Nutzung bestimmter Ressourcen (Geräte, Materialien, Räume, usw.). Da die Kosten nicht exakt vorhersehbar sind, müssen sie regelmäßig kontrolliert werden, um bei Abweichungen reagieren zu können[2].
2.4 Projekt Stakeholders
Projekt Stakeholder sind Einzelpersonen oder eine Organisation, die aktiv an einem Projekt beteiligt sind, oder deren Interesse als Folge der Projektdurchführung oder des Projektabschlusses positiv oder negativ beeinflusst werden können²(PMBOK-Definition). Basierend auf IT-Projekte insbesondere Software-Projekte kommen folgende Stakeholder in Frage:
2.4.1 IT-Projektleiter/ IT-Projektmanager
Der IT-Projektleiter ist die Hauptverantwortliche Person eines IT-Projekts. Er besitzt unterschiedliche Aufgabenbereiche innerhalb des Projekts. Hierzu gehören unter anderem:
- Entwicklung von Zielvorgaben und Methoden
- Planung und Organisation von Kapital und Personal
- Einhaltung von Zeitplänen und Budget
- Strukturierung der einzelnen Projektphasen und Arbeitsschritte
- Überblick über den Entwicklungsstand des Projekts
- Steuerung des Projekts
- Kalkulation von Risiken
- Sicherung der Qualität
- Funktionierende Kommunikation innerhalb des Projektteams gewährleisten
Neben den Aufgabenbereichen sollte ein IT-Projektleiter auch über bestimmte Soft-Skills verfügen:
- Motivationsfähigkeit
- Führungsqualitäten(zusammenhalten des Teams)
- Frei reden und präsentieren können
- Andere kritisieren können
- Selber kritikfähig sein
2.4.2 Kunde
Grundsätzlich ist ein Kunde eine natürliche oder juristische Person, welcher sich für die Produkte oder Dienstleistungen eines Unternehmens interessiert. Dabei wird zwischen Laufkundschaft und Stammkundschaft, aber auch zwischen Altkunden und Neukunden differenziert.
Bezüglich des Projektmanagements ist eine gedankliche als auch praktische Unterscheidung dieser Kundenkategorien durchzuführen, um den Bedürfnissen der Kunden gerecht zu werden. Von essentieller Bedeutung ist auch hier eine Kunden Datenbank, die die Kontaktdaten, eine Kurzbeschreibung des Kunden und eine Übersicht über die bisher stattgefundene Zusammenarbeit bzw. die in Aussicht stehende Zusammenarbeit beinhaltet.
2.4.3 Anwendungsspezialist
Anwendungsspezialisten fungieren als Bindeglied zwischen dem Unternehmen und den Programmierern. Ihr Tätigkeitsprofil umfassen die Beratung des Kunden, die Installation, Konfiguration und Betreuung von Anwendungen sowie die Unterstützung der Programmierer bei der Neuentwicklung von Software.
2.4.4 Systemanalytiker
Systemanalytiker modellieren Geschäftsprozesse eines Unternehmens². Das Resultat einer Geschäftsprozessanalyse durch den Systemanalytiker unterstützt bei der Identifikation der spezifischen Anforderungen, die das Unternehmen an die Software hat. Mit Hilfe des neu zu entwickelnden Informationssystems soll somit die Basis für eine effizientere Abwicklung des Arbeitsalltages geschaffen werden. Die Anforderungen werden in einem Anforderungsmodell zusammengefasst und in Zusammenarbeit mit den Softwareentwicklern umgesetzt.
2.4.5 Entwerfer/ Software-Architekt
Entwerfer / Software-Architekt sorgen für die Umsetzung der gegebenen Anforderungen, in eine software-technische Lösung im Sinne einer Softwarearchitektur.
2.4.6 Software-Ergonom
Der Software-Ergonom ist für die Konzeptionierung der grafischen Benutzeroberfläche verantwortlich.
2.4.7 Technischer Redakteur
Der Technische Redakteur erstellt eine ausführliche Dokumentation in Form von Benutzerhandbüchern und Online-Hilfen.
2.4.8 Programmierer/ Implementierer
Die Aufgabe des Programmierers besteht in der Programmierung bzw. Code-Erstellung der vorgegebenen Spezifikationen für eine Systemkomponente.
2.4.9 Tester
Ein Tester übernimmt die Rolle des zukünftigen Benutzers und ist eine möglichst wenig mit dem Produkt betraute Person. Durch Testen der Produktfunktionalitäten überprüft der Tester das Produkt auf mögliche Fehler. Der Tester übernimmt somit eine Präventionsmaßnahme, damit keine Fehler beim Auftraggeber auftreten.
2.4.10 Installationsentwickler
Installationsentwickler sorgen für die Installation und Einführung eines Software-Produkts beim Auftraggeber.
2.5 Projektphasen
IT-Projekte durchlaufen mehrere Phasen, deren Inhalte im Folgenden erläutert werden.
2.5.1 Vorbereitung
Bevor mit der eigentlichen Entwicklung eines Produktes begonnen werden kann, muss durch eine Voruntersuchung oder Durchführbarkeitsuntersuchung die fachliche, ökonomische und personelle Durchführbarkeit gezeigt werden. Am Ende der Vorbereitungsphase steht die Entscheidung über die weitere Vorgehensweise: weitermachen oder beenden.[3]
2.5.2 Konzeption
Eine wichtige Tätigkeit innerhalb des Projekts stellt das Definieren der Produkt-Anforderungen dar. Jedes Produkt soll bestimmte Anforderungen erfüllen. Anforderungen(requirements) legen die qualitativen und quantitativen Eigenschaften eines Produkts aus der Sicht des Auftraggebers fest. Die systematische Vorgehensweise, um die Anforderungen in einem iterativen Prozess zu ermitteln, bezeichnet man als Systemanalyse[4].
Prinzipiell sind Anforderungen an ein neues Produkt verschwommen und nicht klar formuliert. Hinsichtlich dieser Tatsache ist es das Ziel der Konzeptionsphase ein vollständiges, konsistentes und eindeutiges Anforderungsdokument, das so genannte Pflichtenheft zu erstellen. Dieses ist deshalb so relevant, weil das Pflichtenheft die Basis für die Abnahme des fertigen Produkts ist. Ohne das Pflichtenheft kann keine Produkt-Abnahme stattfinden.
2.5.3 Spezifikation
Ziel der Spezifikation in IT-Projekten ist die Umsetzung der gegebenen Anforderungen im Sinne der Entwicklung einer Systemarchitektur. Somit soll die Basis für die Phase Realisierung geschaffen werden.
2.5.4 Realisierung
Aufgabe der Realisierung in IT-Projekten ist es, die Leistungserstellung mit Hilfe der vorgegebenen Spezifikationen zu implementieren. Dabei werden die Konzepte aus der Spezifikationsphase mit Hilfe einer entsprechenden Programmiersprache umgesetzt.
Auch die Dokumentation der Problemlösung und der Implementierungsentscheidungen durch geeignete Verbalisierung und Kommentierung ist eine Aufgabe der Realisierungsphase. Basierend auf einem entwickelten Testplan mit entsprechenden Testfällen, wird das fertige Produkt des Weiteren auf Fehler getestet werden.
2.5.5 Inbetriebnahme
Bei der Inbetriebnahme wird das fertig gestellte Produkt inklusive der gesamten Dokumentation abgenommen und beim Anwender eingeführt. Das Produkt wird beim Kunden installiert, d.h. es wird in die Zielumgebung des Betriebes eingerichtet. Nach erfolgreicher Installation müssen die Benutzer und das Betriebspersonal unter Umständen geschult werden.
2.5.6 Wartung
Software veraltet in dem Maße, wie sie mit der Wirklichkeit nicht Schritt hält[5]. Mit der erfolgreichen Abnahme und Einführung eines IT-Produkts beginnt die Wartung und Pflege. Nach erfolgreicher Inbetriebnahme können im täglichen Betrieb folgende Fälle auftreten:
- Fehler im täglichen Betrieb
- Änderung der Umweltbedingungen (neue Systemsoftware, neue Hardware, neue organisatorische Einbettung)
- Neue Wünsche und Anforderungen des Kunden (z.B. neue Funktionalitäten)
Damit das Produkt nicht veraltet, ist es also das Ziel der Wartung und Pflege diesen Fällen entgegenzuwirken, d.h. Fehler zu beheben und Anpassungen sowohl an die Umwelt als auch an neue Anforderungen vornehmen zu können.
2.6 Abgrenzung
Das IT-Projektmanagement unterscheidet sich vom Management anderer Ingenieurbereiche aus folgenden Gründen:
2.6.1 Immaterielles Produkt
Man sieht es nicht. Man kann es nicht berühren. Der Projektleiter ist abhängig von der Dokumentation, um den Entwicklungsfortschritt zu überprüfen[6].
2.6.2 Entwicklungsfortschritt objektiv nicht zu ermitteln
Es ist schwer festzustellen, ob ein Teilprodukt fertig gestellt ist oder nicht. Ein Software-Entwickler kann fast jederzeit behaupten, er sei mit einem Teilprodukt fertig, d.h. es existiert ein Dokument oder ein Quellprogramm. Um festzustellen, ob dieses Dokument oder Quellprogramm überhaupt verwendbar ist. Ist eine genaue Untersuchung durch einen Experten erforderlich. Um die Qualität zu überprüfen, muss man fast denselben Aufwand betreiben wie bei der Entwicklung. Der Projektleiter ist also voll auf die Aussagen seines Teams angewiesen.
Es fehlen in der Regel einfache und billige Kontrollmittel. Sogar gute Entwickler glauben oft, fertig zu sein und sind es nicht, da die Aufgabe nicht eindeutig definiert wurde. Natürlich gib es auch genug Entwickler, die den wahren Stand ihrer Arbeit verdecken, um Zeit zu gewinnen. Bei Großprojekten wird die Verschleierung des Projektzustandes oft von den Managern der mittleren Ebene geschickt fortgesetzt, so dass es noch schwieriger wird, den wahren Zustand zu ermitteln[7].
2.6.3 Kein deterministischer Verlauf
Neue Erkenntnisse während der Entwicklung haben Auswirkungen auf die bisherigen Ergebnisse. Deshalb ist ein bestimmtes Teilprodukt immer nur bedingt fertig. Diese entwicklungsinternen Zyklen müssen bei der Projektplanung mitberücksichtigt werden. Oft wird die Hälfte der Arbeit zur Überarbeitung bereits erstellter Teilprodukte benötigt[8].
2.6.4 Kein klares Verständnis vom Entwicklungsprozess
Andere Ingenieurdisziplinen haben eine lange Historie. Die Entwicklungsstufen dort sind verstanden und vorhersagbar[9].
2.6.5 Unteilbarkeit der Arbeit
Um ein Software-Problem zu lösen, muss sich der Entwickler intensiv mit dem Problem beschäftigen. Dadurch wird die Übertragung von Aufgaben an einen anderen Mitarbeiter teuer, da der neue Mitarbeiter die Einarbeitungszeit des alten Mitarbeiters wiederholen muss. Aufgaben sind also nicht voll austauschbar.
Nicht jeder Mitarbeiter kann die Aufgaben eines anderen übernehmen, denn dafür sind die Aufgaben oft viel zu spezialisiert. Fällt ein Experte aus, dann kann man ihn nur noch durch vergleichbaren Experten ersetzen. In Netzplänen wird jedoch von der vollen Austauschbarkeit der Mitarbeiter ausgegangen
2.6.6 Keine Naturwissenschaft
Als ein künstliches Produkt des menschlichen Erfindungsgeistes basiert Software nicht auf physikalischen Prinzipien und wird daher auch nicht durch diese begrenzt[10].
2.6.7 Hoher Grad an Abstraktion
Diese Unterschiede gegenüber Entwicklungen anderer Disziplinen sind für einen Außenstehenden nur schwer zu erkennen. Daher scheitern viele Manager aus anderen Branchen, wenn sie das Management von Software-Entwicklungen versuchen. Viele Software-Manager sind von Managementideen geprägt, die aus typischen Produktionsprozessen stammen. Wegen der Besonderheiten einer Software-Entwicklung ist mehr Management als bei Produktionsprozessen erforderlich, nicht weniger.
Viele Softwareentwicklungen werden zu spät fertig gestellt, die Kosten und die Termine werden überschritten. Jede Entwicklung eines großen Software-Systems ist ein neues und technisch innovatives Projekt. Viele Ingenieurprojekte, die ebenfalls innovativ sind, z.B. neue Transportsysteme, neue Brücken, neue Tunnel, neue Stadien, haben ebenfalls Zeit- und Kostenprobleme[11].
3 Dokumentation
Im folgenden werden die Grundlagen zum Thema Dokumenation dargestellt.
3.1 Definition
Der Begriff Dokumentation definiert sich nach DIN 69901 als die Zusammenstellung ausgewählter, wesentlicher Daten über Konfiguration, Organisation, Mitteleinsatz, Lösungswege, Ablauf und erreichte Ziele des Projekts.
Die Projektdokumentation ist ein Bestandteil der Qualitätssicherung. Mit der Dokumentation wird sichergestellt, dass zu jedem späteren Zeitpunkt nachvollzogen werden kann, wie das Projekt entstanden ist, was dabei zu beachten ist, was die Voraussetzungen waren. Sie wird laufend nachgeführt, somit ist gewährleistet, dass auch bei länger andauernden Projekten keine Informationen verloren gehen.
3.2 Aufgaben
Dokumentation hat die folgenden drei Hauptaufgaben.
3.2.1 Wissenssicherung
Das Wissen (Know-How) über ein System macht einen beträchtlichen Teil des Werts eines Systems aus. Die Produktdokumentation hat die Aufgabe, dieses Wissen schriftlich oder auf Datenträgern festzuhalten, damit es nicht verloren geht. Die Prozessdokumentation sichert die Erfahrungen in der Abwicklung von Projekten.
3.2.2 Kommunikation
Eine geordnete Systementwicklung und -pflege ist ohne Kommunikation nicht möglich. Dies gilt sogar für Ein-Personen-Projekte, wenn das Produkt länger als ein paar Wochen leben soll. Mündliche Kommunikation ist bei Arbeiten in einem kleinen Personenkreis sehr effizient. Ausschließlich mündliche Kommunikation verursacht jedoch erhöhte Kosten (und wird letztlich ineffizient), wenn der Personenkreis sich ändert oder die Systembetreuung auf einen anderen Personenkreis übergeht. Letzteres ist typisch der Fall beim Übergang von der Entwicklung zur Nutzung. Daher müssen auch in Kleinprojekten alle für ein System wichtigen mündlichen Informationen und Absprachen in Dokumenten festgehalten werden. Mündliche Kommunikation genügt nicht, da Erzeugung und Benutzung von Informationen unter Umständen um Jahre auseinander liegen können.
3.2.3 Sichtbarmachen des Projektfortschritts
Der Abschluss jeder Phase der Entwicklung wird nachprüfbar, markiert durch die Fertigstellung von Dokumenten. Das Erstellen von Zwischendokumenten nur mit dem Zweck des Nachweises abgeschlossener Tätigkeiten ist zu vermeiden.
3.3 Notwendigkeit
In vielen Projekten besitzt Dokumentation nicht die Akzeptanz, welche ihr eigentlich zustehen müsste. Dieses resultiert zum einen aus der Tatsache, dass in Projekten immer ein immenser Zeitdruck herrscht, welche die Erstellung der Dokumentation das Projekt in Verzug bringen könnte aber auch ein limitiertes Projekt-Budget, welches eine ausführliche Dokumentation nicht zulässt. Der Grundsatz des Managements ist hierbei "Hauptsache es läuft und der Kunde ist zufrieden".
Gerade bei den Entwicklern ist die Erstellung der Dokumentation sehr unbeliebt, da sie neben ihrer primären Aufgabe, der Implementierung der Systemkomponenten ebenfalls für die mühselige Erstellung der Dokumentation verantwortlich sind. Dabei ist die Erstellung der Dokumentation ein wesentlicher Bestandteil der Qualitätssicherung. Ein übersichtliches und systematisch angelegtes Dokumentationssystem vereinfacht die interne und externe Dokumentation, erleichtert die Stellvertretung der Projektleitung bei vorübergehender Abwesenheit oder Krankheit. Des Weiteren muss Dokumentation aus folgenden Gründen integraler Bestandteil von IT-Projekten und ganz besonders von Software-Projekten sein:
- Bei einer Nachdokumentation am Ende der Codeerstellung sind wichtige Informationen, die während der Entwicklung angefallen sind, oft nicht mehr vorhanden.
- Entwicklungsentscheidungen (z.B.: Warum wurde welche Alternative gewählt?) müssen dokumentiert werden, um bei Modifikationen und Neuentwicklungen bereits gemacht Erfahrungen auswerten zu können.
Der Aufwand für die Dokumentation wird reduziert, wenn zu dem Zeitpunkt, an dem die Information anfällt von demjenigen, der sie erzeugt oder verarbeitet, auch dokumentiert wird.
Dieses Prinzip der integrierten Dokumentation beinhaltet folgende Vorteile[12]:
- Reduziert den Aufwand der Dokumentationserstellung
- Stell sicher, dass keine Informationen verloren gehen.
- Garantiert die rechtzeitige Verfügbarkeit der Dokumentation
Somit bildet eine gut ausgearbeitete Dokumentation die Voraussetzung für eine leichte Einarbeitung in ein Produkt bei Personalwechsel oder durch neue Mitarbeiter. Des Weiteren besteht eine sehr gute Wartbarkeit des Produkts.
3.4 Wirtschaftlichkeit
Dokumentation kostet Entwicklungszeit und -geld, darum wird sie - vor allem unter Termindruck
- oft nicht oder nur fragmentarisch erstellt. Außer bei sehr kurzlebigen Systemen geht die
Rechnung mit der Kosteneinsparung jedoch nicht auf (siehe Abbildung). Wird in einem Unternehmen, das seine IT-Projekte bisher nicht oder nur rudimentär dokumentiert hat, sorgfältiges Dokumentieren eingeführt, so ist folglich zu erwarten, dass die Produktivität in den frühen Phasen der Entwicklung absinkt und dafür in den späten Phasen sowie in der Nutzung steigt. Ferner darf eine Verbesserung der Produktqualität erwartet werden.
3.5 Verfasser
Die gesamte Dokumentation des Projekts wird nicht von einer einzelnen Person erstellt. Vielmehr ist es in der Praxis so, dass die partizipierenden Teilnehmer entsprechend ihrer Rolle im Projekt für die Dokumentation einzelner Dokumente und Basiskonzepte verantwortlich sind. Der Auftraggeber erstellt beispielsweise das Lastenheft und das Pflichtenheft wird in Zusammenarbeit von Auftraggeber und Projektleiter fixiert. Der Systemanalytiker ist für die Dokumentation des Anforderungsmodells zuständig und der IT-Architekt für die Dokumentation der Systemarchitektur.
Während der Realisierungsphase muss der Quellcode vom Programmierer dokumentiert bzw. kommentiert werden. In der gleichen Phase wird das fertige Produkt vom Testverantwortlichen auf Basis des von ihm erstellten Testplans und Testprotokolls getestet. Besprechungsprotokolle, die während Team Sitzungen eingesetzt werden, werden vom Protokollführer verfasst. Somit ist der Dokumentationsprozess auf mehrere Schultern verteilt. Der wesentliche Vorteil hierbei ist, das alle relevanten Informationen dokumentiert werden, da jedes Projekt-Mitglied genau die Informationen dokumentiert mit denen er sich auch auseinander gesetzt hat.
3.6 Inhalt
Ein IT-Projekt unterliegt einer Dokumentation, die sich aus folgenden Dokumentationskonzepten zusammensetzt:
- Prozessdokumentation
Die Prozessdokumentation oder auch Vorgehensdokumentation genannt, dient primär der Dokumentation des Projektverlaufs und fördert somit die Transparenz des Projektgeschehens. Die Inhalte dieser Dokumente sind Projektphasenübergreifend und unter anderem eine sehr große Hilfe für den Projektleiter, da er beispielsweise unter der Zuhilfenahme von Statusberichten einen Überblick über den Projektentwicklungsstand erhält. Des Weiteren ermöglicht die Prozessdokumentation eine Soll-Ist-Analyse und ruft den Projektmitgliedern vielleicht in Vergessenheit geratene Besprechungsergebnisse wieder in Erinnerung.
- Produktdokumentation
Die Produktdokumentation oder auch Systemdokumentation genannt dokumentiert das materielle Projektergebnis. Die Dokumente der Produktdokumentation sind phasenspezifisch und befassen sich nicht mit dem Projektentwicklungsstand, sondern ausschließlich mit dem zu entwickelnden Produkt. Die Produktdokumentation enthält somit alle Unterlagen, die zur Fertigung, Einsatz und ggf. zur Betreuung des zu erstellenden Produktes notwendig sind.
4 Dokumentationsanforderung
Dokumentationsanforderungen sowie ergänzende Arbeitsanweisungen sind in der DIN EN ISO 9001:2000 geregelt. Im folgenden werden wesentliche Dokumente und Basiskonzepte des IT-Projektmanagements erläutert.
4.1 Anforderungen und Qualitätsaspekte einer Dokumentation
In einer Dokumentation müssen gewisse Grundvoraussetzungen erfüllt sein.
- Aktualität: Es muss sichergestellt sein, dass alle Dokumente auf den neusten Stand gehalten werden.
- Einheitlichkeit: Erfüllung der für die Erstellung von Dokumenten geltenden Vorschriften und Normen. Festlegung der verschiedenen Dokumentenarten.
- Nachvollziehbarkeit: Eignung von Dokumenten zur unmissverständlichen Vermittlung von Informationen an jeden Leser.
- Verfügbarkeit: Jederzeit eine rasche Verfügbarkeit der richtigen Dokumente, zum richtigen Zeitpunkt von dem richtigen Empfänger.
- Schutz vor Verlust: Ständiges sichern der Dokumente durch Datensicherung.
- Systematik: Eine auf bestimmte Ordnungsprinzipien basierende Einteilung.
- Vollständigkeit: Vorhandensein der für den Zweck der Dokumentation notwendige und hinreichende Informationen.
4.2 Festlegung von Dokumentationsanforderungen
Die Festlegung der Dokumentationsarten ist der erste Schritt für eine notwendigen Projektdokumentation. Sie stellt eine Grobgliederung dar und dient als Orientierungshilfe. In Zusammenarbeit mit dem jeweiligen Verantwortlichen für ein Projektstrukturplan-Element oder ein Arbeitspaket ist festzulegen, welche Spezifikationen, Pläne, Zeichnungen, usw. für seine Arbeit erforderlich sind. Spezifikationen, Pläne, Prozeduren, Zeichnungen, usw. sind eine wichtige Voraussetzung für den erfolgreichen Abschluss eines Projektvorhabens. Für Forschungs- und Entwicklungsprojekte trifft dies in ganz besonderem Maße zu. Sind an dem Projekt außerdem mehrere Abteilungen oder Firmen beteiligt, so ist die Präzisierung der Dokumentationsanforderungen von besonderer Bedeutung. Zur Dokumentationserfassung ist die Dokumentations-Anforderungsliste ein praktisches Instrument. Die Dokumentations-Anforderungsliste sollte folgende Informationen enthalten:
- Dokumentationsbezeichnung (Titel),
- Dokumentationsnummer,
- Ersteller des Dokuments (Firma/ Abteilung),
- geplante Ausgabedatum (ggf. Meilenstein),
- geplanter Verteiler.
Die Dokumentations-Anforderungsliste, die nicht mit der später zu erstellenden Dokumentationsüberwachungsliste zu verwechseln ist, stellt ein wichtiges Projekt-Planungsinstrument dar und hat die gleiche Bedeutung wie die Hardware-Lieferliste eines Projektes. Die Erstellung von Dokumentations-Anforderungsbeschreibungen ist für die Projektleitung von außerordentlicher Bedeutung. Durch sie wird sichergestellt, dass der Dokumentationsinhalt dem entspricht, worauf es der Projektleitung ankommt.
4.3 Dokumente der Produktdokumentation
Die Produktdokumentation oder auch Systemdokumentation genannt, dokumentiert die Projektergebnisse. Im folgenden werden die Dokumente und Basiskonzepte der Produktdokumentation, gegliedert nach Projekt-Phasen vorgestellt.
4.3.1 Vorbereitung
Im folgenden wird die Phase Vorbereitung und die dazugehörigen Dokumenten erläutert.
4.3.1.1 Lastenheft
Gemäß DIN 69905 (Begriffe der Projektabwicklung), beschreibt das Lastenheft die "vom Auftraggeber festgelegte Gesamtheit der Forderungen an Lieferung und Leistung eines Auftragnehmers innerhalb eines Auftrags."
Das Lastenheft beschreibt die Spezifizierung und Problembeschreibung des Projektauftrages. Es wird festgehalten wann das Projekt gestartet wird und wann es zu Ende ist. Es werden verbindliche Ziele, Kostenlimit, konkrete Mindestanforderungen, Qualität und Funktionalität im Lastenheft vereinbart. Basierend auf dem Lastenheft wird überprüft ob das Erreichen des Ziels umgesetzt werden kann.
4.3.1.2 Ist-Analyse
In der Ist-Analyse werden zunächst die Ermittlung und Darstellung der Informationen für Termine und Kosten behandelt, anschließend die Ermittlung und Darstellung des Fertigungswertes unter Berücksichtigung der Schnittstelle zur Leistungsbewertung und Projektfortschritts. Gewisse Hürden für eine verlässliche Analyse sind zu überwinden:
- in Arbeit befindliche Vorgänge sind hinsichtlich des Ergebnisses schlecht abzuschätzen,
- die Fertig/Beendet -Meldungen (90%-Syndrom),
- eine verbindliche Aussage über den Stand einer Aufgabe erfordert mehrere Personen,
- die Projektrealisierung wird von Änderungen an Ergebnis, Termin und Kosten begleitet,
- die Bestimmung des bis "Heute" zu erreichende Ergebnisses ist schwierig,
- das Reporting der Projektbeteiligten zum Projektstand hält diese von der Projektarbeit ab[13].
4.3.2 Konzeption & Spezifikation
In dieser Phase werden klar die Anforderungen definiert und die Anforderungen entsprechend umgesetzt. Die dazugehörigen Dokumente werden nun erläutert.
4.3.2.1 Pflichtenheft
Ein Pflichtenheft beinhaltet die quantitativ und konsistent formulierten Ziele eines Projektes (überprüfbare Sollvorgaben).
Im Projektmanagement versteht man unter dem Pflichtenheft das i.d.R. vom Auftragnehmer oder von einer speziellen hierfür eingesetzten Arbeitsgruppe erarbeitete Detailkonzept eines Vorhabens aufgrund der Anforderungen des Kunden, Nutzers oder sonstigen Nachfragers. Der Begriff ist insbesondere in der Softwareentwicklung üblich. Im Gegensatz zum Lastenheft muss das Pflichtenheft detailliert und vollständig die Anforderungen des beabsichtigten Projektes enthalten. Es dient dann als verbindliche Grundlage des zu schließenden Vertrages. Der Begriff des Pflichtenheftes ist wie auch der des Lastenheftes nicht gesetzlich oder sonst verbindlich geregelt; es besteht jedoch ebenfalls eine Regelung in DIN 69905.
Demnach sind im Pflichtenheft die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" niedergelegt. Die beschreiben die "Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes". Während im Lastenheft also steht, was der Auftraggeber will, enthält das Pflichtenheft die Details, wie der Auftragnehmer die Vorgaben des Auftraggebers umsetzen will. Das Lastenheft kann also mit der Nachfrage und das Pflichtenheft mit dem Angebot verglichen werden.
Die einfachste Form eines Pflichtenheftes wäre die Benennung eines tatsächlich möglichen Preises und Liefertermins. Da das Pflichtenheft vom Auftraggeber geschrieben wird, folgt es i.d.R. auch seinen Denkmustern. Es ergibt sich daher das kommunikationstheoretische Problem, die angebotene Art und Weise der Erfüllung der Anforderungen des Lastenheftes so zu beschreiben, dass es der Auftraggeber, der seinen eigenen Denkmustern folgt, auch versteht. Es ist daher von großer Bedeutung, die Abfassung des Pflichtenheftes so vorzunehmen, dass der Auftraggeber transparent sehen kann, wie seine Anforderungen umgesetzt werden sollen. Die Sprache der Anwender und die produkt- oder theoriebezogene Sprache der Techniker ("Fachchinesisch") müssen aufeinander abgestimmt sein. Dies ist insbesondere in der Softwareentwicklung der Fall, wo die Anforderungen der Anwender oft vage, unzusammenhängend, unvollständig und widersprüchlich sind.
Die Definition des Leistungsumfanges ist dann besonders problematisch und kann umfassen:
- Muss Kriterien: unabdingbare Leistungen,
- Wunsch Kriterien: erstrebenswerte Leistungen,
- Kann Kriterien: Leistungen, die enthalten sein können, denen der Auftraggeber aber neutral gegenübersteht und
- Negativ Kriterien: Leistungen, die nicht enthalten sein dürfen.
Bei großen Projekten mit viel Abstimmungsbedarf zwischen Auftragnehmer und Auftraggeber wird daher oft eine besondere Arbeitsgruppe zur Erarbeitung des Lastenheftes eingesetzt, die dann auch für die Erstellung des Pflichtenheftes verantwortlich ist. Die Anforderungen des Pflichtenheftes können sich in der Anwenderdokumentation oder dem Anwenderhandbuch niederschlagen.
4.3.2.2 Fachkonzept
Ein Fachkonzept ist das auf einen spezifischen Themenbereich eingeschränkte Konzept. Der Themenbereich kann dabei formell/methodisch gewählt sein oder objektbezogen.
Anforderungen an IT-Fachkonzepte
Das IT-Fachkonzept/die IT-Fachspezifikation beschreibt die Leistungsmerkmale die der Auftraggeber an die Software stellt aus fachlicher Sicht. Dieses IT-Fachkonzept sollte aber auch die Grundlage sein für die:
- Test-Cases
- Qualitätsprüfung
- Anwenderdokumentation
Wenn die fachlichen Anforderungen und Vorgaben bereits im Hinblick auf diese spätere Verwendung dokumentiert werden, hilft das Zeit und Kosten zu sparen. Dieser Anspruch hat von vornherein Einfluss auf die Gestaltung:
- der Dokumentstruktur,
- des Layouts,
- der Formulierungen
- und der Abbildungen.
Von Anfang an sollte eine gleichermaßen verständliche Sprache für den Auftraggeber und Entwickler verwendet werden. Bei einer sinnvollen Gliederung Sie des Pflichtenhefts, können die Vorgaben an die Software-Entwicklung sich nahtlos einfügen lassen. In die Beschreibung des Dokumentaufbaus gehört ein Verweis auf bereits bestehende Unterlagen.
4.3.2.3 DV-Konzept
Bei großen, komplexen IT-Projekten erstellt man aus dem Fachkonzept das DV-Konzept. Das DV-Konzept beinhaltet die DV-technische Umsetzung des Pflichtenheftes. Das Fachkonzept ist so eine Art Kreuzungspunkt zwischen Nicht-EDV (Auftraggeber) und EDV (Anwendungsentwickler, System-Integrator ...).
Im DV-Konzept wird beschrieben, wie die einzelnen fachlichen Funktionen und Anforderungen des Fachkonzeptes in die DV umgesetzt werden. Dazu gehören u.a.:
- Analyse der Produktumgebung
- Wahl der Programmiersprache und des Datenbanksystems
- Entwicklung des Daten[bank]modells (Datenflussplan)
- Entwurf der Benutzerschnittstellen (Kommandos)
- Modul- oder Klassenentwurf (PAP/Struktogramm, UML)
Wichtig ist nur, dass in dieser Phase noch nichts programmiert oder sonstwie implementiert wird. Es geht lediglich darum, eine dv-technische Lösung für die funktionalen Anforderungen (Fachkonzept) zu entwickeln.
Es wird nach und nach die Inhalte des Fachkonzepts analysiert und auf dieser Grundlage entwickelt. Die Darstellungsmethoden (ERD, PAP, UML, ET etc.) dienen zur Visualisierung der Ergebnisse.
4.3.2.4 Datenflussdiagramm
Oder auch der Datenflussplan genannt, stellt eine Art der Netzwerkartigen Darstellung eines Systems dar. Der Kontrollfluss im Datenflussdiagramm ist leider nicht gegeben. Die Darstellung ist sowohl von Hardware und Softwaresystemen als auch von sozio-ökonomischen Systemen möglich. Es zeigt Arbeitsabläufe als Abfolge einzelner Tätigkeiten, die als Prozess bezeichnet werden. Ein Datenflussdiagramm enthält mindestens eine Schnittstelle. Jede Schnittstelle ist nur ein Mal vorhanden sie kann jedoch mehrfach gezeichnet werden. Zwischen diesen Schnittstellen gibt es keine Datenflüsse. Jeder Datenfluss hat einen Namen. Ausnahme: Datenflüsse, die zu Speichern führen oder dort beginnen und die keinen Namen haben, transportieren die gesamten gespeicherten Daten. Zwischen Schnittstellen und Speichern dürfen keine direkten Datenflüsse bestehen. Ein DFD beschreibt den Datenfluss. Daher enthält ein DFD keine Entscheidungen, Wiederholungen, Initiierungen und Terminierungen. Funktionsnamen repräsentieren eine Aktion.
Vorteile:
- Datenflussdiagramme sind relativ leicht zu erstellen und gut lesbar.
- Mehr Funktionen zu beschreiben als mit einem Funktionsbaum.
Nachteile:
- Die Größe der grafischen Repräsentation, da die Darstellung schnell unübersichtlich wird.
- Bezeichnung der Daten und Funktionen auf einem einheitlichen Abstraktionsniveau ist zum Teil schwierig.
- Fehler sind nur schwer zu finden, da der Datenaufbau der Datenflüsse bekannt sein muss.
4.3.2.5 Entity-Relationship-Modell
Das Entity-Relationsship-Modell (ERM) ist wohl die bekannteste und auch in der Praxis am häufigsten verwendete Methode zur Datenmodellierung. Das ER-Modell wurde 1976 von P. Chen entwickelt und die permanent gespeicherten Daten und ihre Beziehungen untereinander zu beschreiben[14].
- Entities (Entität): sind reale oder abstrakte Dinge, die für ein Unternehmen von Interesse sind (Kunden, Artikel, Aufträge).
- Relationsship (Beziehung): ist eine logische Verknüpfung zwischen zwei oder mehreren Entitytypen. Während Entities bereits für sich existieren können, bestehen Beziehungen nur in Verbindung mit den betreffenden Entitytypen z.B. Eine Beziehung zwischen Kunde und Adresse könnte "wohnen" sein.
- Property (Attribute, Eigenschaft): Attribute sind Eigenschaften von Entities z.B. Kundennummer, Name und Anschrift des Entitytyps Kunde.
Das ER- Modell dient Anwendern und Entwicklern, wo nur die Sachlogik und nicht die Technik behandelt werden.
4.3.2.6 Klassendiagramm
Eine Klasse ist eine Menge von Objekten, in der die Eigenschaften (Attribute), Operationen und die Semantik der Objekte definiert werden. Alle Objekte einer Klasse entsprechen dieser Festlegung. In der Informatik ist sie eine grafische Darstellung von Klassen und deren Beziehungen.
Eine Klasse ist eine Zusammenfassung gleichartiger Objekte. Sie sind die agierenden Grundelemente einer Anwendung. Die Gleichartigkeit bezieht sich auf Eigenschaften (Attribute) und/oder auf Fähigkeiten (Operationen/Methoden) der Objekte einer Klasse. Eine Klasse enthält gewissermaßen die Konstruktionsbeschreibung für Objekte die mit ihr erzeugt werden. Die Möglichkeit eines Objektes wird durch das Verhalten der Objekte, Nachrichten zu empfangen und zu verstehen beschrieben. Es werden bestimmte Operationen dafür benötigt. Die Begriffe Nachricht und Operation sollten nicht synonym verwendet werden. Zusätzlich zu Eigenschaften und Fähigkeiten kann eine Klasse auch Definitionen von Zusicherungen, Merkmalen und Stereotypen enthalten.
4.3.3 Realisierung
Im folgenden werden die Dokumente der Phase Realisierung näher erläutert.
4.3.3.1 Struktogramm
Durch ein Nassi-Shneideman-Diagramm wird ein Diagrammtyp von Programmwürfeln einer Strukturierten Programmierung dargestellt. Es ermöglicht eine optimale grafische Darstellung von linearen Kontrollstruktur. Der verfügbare Platz ermöglicht außerdem die Wahl aussagekräftiger Namen[15]. Diese Methode zeigt das Gesamtproblem, dann gegliedert in Teilproblemen, bis schließlich die Grundstruktur eines Problems dargestellt wird. Ein Struktogramm ist im ganzen Rechteckig und genauso breit wie ein Strukturblock. Der Vereinbarungsteil kann am Anfang in einem eigenen Kasten beschrieben werden[16]. Struktogramme dürfen keine komplizierten Programmiersprachen beinhalten, gerade so, dass sie auch hier durch dritte logisch zu verstehen sind.
4.3.3.2 Pseudocode
Eine höhere Programmiersprache aus mathematischen Notationen. Dieses Sprache kann von Menschen aber nicht von Computer gelesen werden. Es ist die Bezeichnung für einen Ablaufplan eines Programms und Darstellung eines bereits vorliegenden Struktogramms. Bei Pseudocode handelt es sich also nicht um eine Programmiersprache. Der nächste Schritt wäre die Umsetzung des Pseudocode in eine Programmiersprache die es in ein lauffähiges Programm umsetzten kann.
4.3.3.3 PAP
Ein Programmablaufplan ist eine grafische Darstellung durch Symbole die durch Linien miteinander verbunden sind, um Kontrollstrukturen zu beschreiben. Benutzt werden genormte Formen, die allerdings in der Softwareerstellung nur noch selten genutzt wird. Der Projektablaufplan bietet eine Übersichtliche Darstellung des Programms und Intuitives Verständnis von Programmstrukturen. Es entstehen aus der Kombination weniger Darstellungsformen. Die Symbole dafür sind in der DIN 66001 genormt.
4.3.3.4 Entscheidungstabelle
Entscheidungssituationen erfolgen im allgemeinen als Aktionen unter bestimmten Bedingungen. Je unüberschaubarer die Bedingungen sind, desto ungenügender sind verbale Beschreibungen und schematische Darstellungen von Ablaufplänen. Entscheidungstabellen fassen derartige Entscheidungssituationen übersichtlich und in konzentrierter Form zusammen.
Voraussetzung dabei ist, dass dem gegebenen Ausgangsbedingungen die Aktionen klar zugeordnet werden können, d.h. sog. Entscheidungsregeln gebildet werden können.
Bei der Entwicklung einer Entscheidungstabelle sollten die Entscheidungsregeln
- alle Entscheidungssituationen erfassen,
- sich nicht gegenseitig ausschließen oder widersprechen,
- keine überflüssigen Angaben enthalten und
- eingehalten werden können.
Bei komplexen Entscheidungssituationen können die Entscheidungstabellen sehr groß und unübersichtlich werden. In solchen Fällen empfiehlt sich eine Teilung in mehrere Einzelentscheidungen, die danach ineinander überführt werden.
Entscheidungstabellen finden Anwendung z.B. in der Rechentechnik bei der Programmerstellung, wenn komplizierte logische Zusammenhänge geprüft werden müssen, oder in der Materialwirtschaft, wenn logische Problemstellungen gelöst werden müssen.
4.3.3.5 Benutzerhandbuch
Für den Anwender ist ein Benutzerhandbuch vorgesehen. Das Benutzerhandbuch enthält allgemeine Daten zur Software, Angaben über die Installation, Hinweise zur Bedienung und eine ausführliche Beschreibung der einzelnen Funktionen. In der Praxis hat sich die Unterstützung des Führungskonzepts "Projektmanagement" in zwei Handlungsebenen bewährt: Unternehmen und Projekte. Dementsprechend ist es angeraten, für beide Handlungsebenen die wichtigen Arbeitsgrundlagen effektiver Projektarbeit zu dokumentieren. Es handelt ich um das Projektmanagement-Handbuch und das Projekt-Handbuch.
Das Benutzerhandbuch enthält allgemeine Daten zur Software, Angaben über die Installation, Hinweise zur Bedienung und eine ausführliche Beschreibung der einzelnen Funktionen. Schließlich kann ein Kapitel, welches sich mit Besonderheiten des Programms und eventuell eintretenden Schwierigkeiten sowie der Beseitigung von Fehlern beschäftigt, im Benutzerhandbuch enthalten sein. Sinnvoll ist ebenfalls eine Beschreibung der von der Software benutzten Dateien und Dateiformate.
4.3.4 Inbetriebnahme
Die Phase "Inbetriebnahme" ist sozusagen das Ende das Projekts. Der Abschlussbericht steht an und die Projektstrukturen werden nun aufgelöst. Die Dokumente dieser Phase werden nun erläutert.
4.3.4.1 Abnahme
Die Abnahme ist ein entscheidender Meilenstein im Projektablauf. Bei vertragsgerechter Erstellung des Werks hat der Auftraggeber die Pflicht und der Auftragnehmer das Recht zur Abnahme. Das Abnahmeprotokoll, das dazu dient, die Abnahme der Projektlösung durch den Auftraggeber bzw. den zuständigen Fachbereich oder die betreffenden Fachabteilung zu dokumentieren. Es kann aber auch ausweisen:
- noch gegebene Mängel
- erforderliche Nachbesserungen
- sich dadurch ergebende Minderungen[17]
Der genaue Zeitpunkt der Abnahme ist wegen der daran anknüpfenden Rechtsfolgen von besonderer Bedeutung. Auch er sollte in dem gemeinsamen Abnahmeprotokoll der Parteien festgehalten werden.
An die Abnahme schließen sich entscheidende Rechtsfolgen an. Diese sind:
- Gefahrenübergang
- Beginn der Gewährleistungsfristen
- Fälligkeit der Zahlungen
- Übergang der Beweislast auf den Auftraggeber
Die Abnahme ist ein entscheidender Meilenstein im Projektablauf. Bei vertragsgerechter Erstellung des Werks hat der Auftraggeber die Pflicht und der Auftragnehmer das Recht zur Abnahme.
4.3.4.2 Abschlussbericht
Ein Projektabschlussbericht ist nach DIN 69901 wie folgt definiert: "Zusammenfassende abschließende Darstellung von Aufgaben und erzielten Ergebnissen, von Zeit-, Kosten- und Personalaufwand sowie gegebenenfalls von Hinweisen auf mögliche Anschlussprojekte."
Der Projektabschlussbericht beschreibt das Ergebnis des gesamten Projekts aus fachlicher und organisatorischer Sicht. Er beschreibt aber auch da raus gewonnenen Erkenntnisse für Zukünftigen Projekte. Das bewusste Analysenieren von Stärken und Schwächen der Organisation wird mit dem langfristigen Ziel, die Leistungsfähigkeit des Unternehmens verbessert.
Sein Inhalt dient der Projektabwicklung und den Projektinhalt.
- Die Ziele und Anforderungen lt. Projektauftrag und wesentliche Änderungen im Projektverlauf,
- Die Vorgehenswiese zur Realisierung, ggf. fachliche Besonderheiten,
- Die erzielten Ergebnisse und
- Empfehlungen für die künftige Facharbeit
Der Projektabschlussbericht ist durch den Projektleiter zu veranlassen und muss allen (leitenden) Projektbeteiligten zukommen. Dies können beispielweise Auftraggeber, Auftragnehmer, Projektkaufmann/Controlling, Lenkungsausschuss und Geschäftsleitung sein.
4.3.5 Wartung
Nach erfolgreicher Abnahme beginnt nun die Pflege und Wartung des IT-Produkts. Es werden nun Dokumente der Wartung erläutert.
4.3.5.1 Änderungsanforderung
Im Laufe eines Projektes können neue Anforderungen, Änderungen an den Annahmen der Planung und neue Ziele oder Ergebnisse identifiziert werden. Eine effektive Änderungssteuerung setzt voraus, dass der ursprüngliche Projektumfang dokumentiert und abgestimmt ist. Zu viele Änderungsanforderungen sorgen mit Sicherheit dafür, dass das Projekt seine definierten Ziele verfehlt. Manchmal wird eine Lösung erst mit bestimmten Änderungen wirklich gut.
Ursachen für Änderungsanforderung:
Interne:
- Workshops zur Diskussion der Projektergebnisse (z.B. Fehler im Fachkonzept)
- Nutzung zusätzlicher Vorteile
- Risikominimierung
Externe:
- Gesetzesänderungen
- Marktentwicklungen
Es empfiehlt sich zu Anfang des Projekts ein sog. Änderungsbudget zu vereinbaren. Hiermit können im Laufe des Projektes kleine Änderungen schnell und unbürokratisch umgesetzt werden. Eine Budgeterweiterung für das laufende Projekt ist möglich.
4.3.5.2 Übergabeprotokoll
Mit dem Übergabeprotokoll werden die Inhalte (Programme, Bauteile, Konzepte, Beschreibungen,...) und Modalitäten (Form, Verantwortlichkeit, Abnahmefristen, Abnahmeunterstützung) der Produktübergabe dokumentiert. Im Übergabeprotokoll werden auch die Leistungsmerkmale (Funktionsumfang und Qualitätsmerkmale) und Dokumentationen (Benutzerhandbücher oder Wartungsunterlagen) protokolliert und übergeben.
4.4 Dokumente der Prozessdokumentation
Die Prozessdokumentation oder auch Vorgehensdokumentation genannt, dokumentiert den Projektverlauf. Folgende Dokumente sind Bestandteil der Prozessdokumentation.
4.4.1 Checklisten
Checklisten beschreiben schrittweise einen bestimmten Prozess und dienen zu seiner Durchführung und gleichzeitigen Dokumentation. Sie sind die Schnittstellen zwischen Fachwissen und Management.
Der Umfang einer Checkliste kann von einem nur wenige Punkte enthaltenden Formular bis zu einem mehrere hundert Seiten umfassenden Buch reichen. Dies hängt vom Umfang eines Prozess oder Projekts ab.
Im Projektmanagement helfen Checklisten bei der Einhaltung von Methoden und erlauben dadurch die Verwendung von einheitlichen Vorgehensmodellen. Sie dienen damit als wichtiges Werkzeug des Qualitätsmanagements. Projektspezifische Checklisten sind Bestandteil des Projekthandbuches.
4.4.2 Besprechungsprotokoll
Grundsätzlich sollte bei jeder Besprechung ein Protokoll erstellt werden. Damit wird das Besprochene und Vereinbarte festgehalten. Nicht anwesende Personen sollten mit Hilfe des Besprechungsprotokolls über das Wesentliche informiert werden.
Für die Besprechung sind vorab folgende Punkte zu klären:
- Besprechungsziel
- Wer muss Anwesend sein
- Besprechungspunkte
- Zeit und Ort
- Zeit für jeden Besprechungspunkt
- Protokollführer
Es muss geklärt werden, welche Art von Besprechungsprotokoll geführt wird. Da gibt es das Verlaufsprotokoll, welches über den chronologischen Ablauf der Besprechung informiert. Bei der Durchführung sollten folgende Vorgangsweise berücksichtigt werden:
- Pünktlich beginnen
- Diskussionen kontrollieren und darauf achten, dass nicht vom Thema abgewichen wird
- Wiederholen Sie Entscheidungen und Ergebnisse
- Festlegung, wer was bis wann zu erledigen hat
- Zeitmanagement, darauf achten, dass die Zeit für die einzelnen Punkte nicht überschritten wird
Dann gibt es das Diskussions- oder Ergebnisprotokoll. In diesem wird der sachbezogene Zusammenhang der Diskussion zusammengefasst. Ein Protokoll wird generell sachlich geschrieben. Persönliche Stellungnahmen haben darin nichts verloren.
Eine sinnvolle Gliederung im Besprechungsprotokoll sollte nicht fehlen. Wenn es in einer Besprechung recht "chaotisch" zugeht, ist ein Verlaufsprotokoll nicht empfehlenswert. Hier wird das Protokoll am besten nach Inhalten strukturiert (falls gegeben nach Tagesordnungspunkten). Protokollierte Aufgaben werden mit Erledigungstermin und Zuständigkeit (in eigener Spalte) versehen. Falls bekannt, wird der Termin für die nächste Besprechung im Protokoll vermerkt. Oft reicht auch ein handgeschriebenes Protokoll. Um die Verteilungsprozedur abzukürzen, wird das Protokoll gut leserlich während der Besprechung geschrieben. Am Ende der Besprechung wird es kopiert und an die Teilnehmer gleich verteilt.
4.4.3 Netzplan
Die Begriffe der Netzplantechnik und Netzplan werden laut DIN 69 900 wie folgt definiert: (DIN: DIN 69 900, Netzplantechnik, Deutscher Normenausschuss, Frankfurt 1983)
"Die Netzplantechnik umfasst Verfahren zur Projektplanung und -steuerung. Der Netzplan ist die grafische Darstellung von Ablaufstrukturen, die die logische und zeitliche Aufeinanderfolge von Vorgängen veranschaulichen."
Da in Projekten vorrangig Tätigkeiten voneinander abhängen und mit Zeitaufwand verbunden sind, ist die zweckmäßigste Art zur Darstellung solcher Verknüpfungen und zur Bestimmung von Terminen der Netzplan[18].
Der Netzplan wird aus dem Projektstrukturplan entwickelt, in dem die Arbeitspakete der untersten Strukturplanebene in ihre einzelnen Vorgänge zerlegt werden. Anschließend werden die Aufgaben, die zeitlich nacheinander oder parallel verlaufen, in ihren Beziehungen zueinander so dargestellt, dass für jedes Aufgabenpaket sogenannte Teilnetze entstehen. Nach dieser analytischen Phase werden die einzelnen Teilnetze zu einem Gesamtnetzplan zusammengeführt.
Die Basiseinheit der Netzplantechnik, der Vorgang, ist durch jeweils zwei Ereignisse begrenzt:
- Beginn des Vorganges als Vorereignis
- Ende des Vorganges als Nachereignis
Das Nachereignis eines Vorganges ist identisch mit dem Vorereignis des nachfolgenden Vorganges[19].
4.4.4 Gantt-Diagramm
Eine einfache Form der Darstellung von -zusammenhängen in Projekten bietet das Balkendiagramm. Die Form ist jedoch nur für kleine, überschaubare Projekte nützlich, da das Balkendiagramm sehr schnell an die Grenzen seiner Aussagekraft stößt. Ein Balkendiagramm ist, einfach ausgedrückt, der Vorläufer eines Netzplanes, jedoch wesentlich einfacher zu lesen. In einem Diagramm werden die verschiedenen Vorgänge, Tätigkeiten usw. als Balken symbolisiert dargestellt. Diese Balken werden mit einer Zeitachse verknüpft, so dass eine Übersicht über die Art und den Zeitraum der Tätigkeit gegeben ist. Jedoch können Verknüpfungen, d.h. Abhängigkeiten von verschiedenen Tätigkeiten untereinander, nicht deutlich gemacht werden.
Zur grafischen Darstellung mittels Balkendiagramm muss eine Definition von Vorgängen (Tätigkeiten) erfolgen und eine Zeitschätzung jedes Vorgangs unter Berücksichtigung der zur Verfügung stehenden Ressourcen vorgenommen werden. Ist dies geschehen, erfolgt die grafische Umsetzung unter Berücksichtigung der zeitlichen Reihenfolge. Balkendiagramme haben den Vorteil, dass sie sehr anschaulich sind. Die logischen Abhängigkeiten einzelner Vorgänge sind jedoch nicht direkt und eindeutig ersichtlich. Balkendiagramme eignen sich lediglich bei kleineren Projekten zur Terminüberwachung.
Nachteile:
- Unübersichtlich bei vielen Vorgängen
- Kein Ausweis der Vorgangsabhängigkeiten
- Keine Erkennbarkeit von Pufferzeiten[20]
5 Schlussbetrachtung / Fazit
Unternehmen unterliegen hinsichtlich der im Laufe der Zeit veränderten wirtschaftlichen Rahmenbedingungen im Sinne von Globalisierung einem immer stärker werdenden Wettbewerbsdruck. Um auf dem Markt nachhaltig bestehen zu können sind Unternehmen gezwungen, den eigenen Zeit- und Leistungsaufwand möglichst effizient zu gestalten. Es gilt die eigene Rentabilität zu optimieren, um auf diese Weise die eigene Wettbewerbsfähigkeit zu erhalten bzw. zu steigern.
Hinsichtlich dieser Herausforderungen bietet Projektmanagement eine effektive Methode zur Verschaffung eines Wettbewerbsvorteils. Ein gutes Projektmanagement impliziert jedoch nicht nur die termingerechte und kostengünstige Leistungserstellung, sondern auch die Einhaltung von Qualitätsmaßstäben. Hier gehört auch die Erstellung der Dokumentation.
Unglücklicherweise wird in vielen IT-Projekten die Dokumentation aus unterschiedlichsten Gründen vernachlässigt und die Risiken unter dem Motto "Hauptsache es läuft" in Kauf genommen. Eine Möglichkeit diesem Problem entgegenzutreten wäre die Einführung einer eigenen Projektphase nur für die Erstellung der Dokumentation, so wie es bei Architekten und Ingenieuren der Fall ist. Eine andere Möglichkeit ist die Änderung der Zielvorgabe durch das Management, bei dem nicht mehr der Grundsatz "Hauptsache es läuft" propagiert wird, sondern die Einhaltung gesetzter Qualitätsmaßstäbe für alle Projektbeteiligten absoluten Vorrang hat.
IT-Projekte bieten ein breites Spektrum an Dokumenten und Basiskonzepten. Hier muss klärend betont werden, dass nicht alle Dokumente in einem IT-Projekt verwendet werden bzw. können. Der Einsatz der Dokumente ist vielmehr abhängig vom zu erstellenden Produkt.
Somit lautet das Fazit dieser Fallstudie, Qualität nicht nur produzieren, sondern auch dokumentieren.
6 Fußnoten
- ↑ Bendisch, R., Kern, U. (2006), S.4
- ↑ Vgl. Jenny (2001), S.163 f.
- ↑ Vgl. Balzert, Helmut (1996), S.56
- ↑ Vgl. Balzert, Helmut (1996), S.91
- ↑ Vgl. Sneed, Harry M. (1987), S.83
- ↑ Vgl. Balzert, Helmut (1998), S. 4
- ↑ Vgl. Sneed, Harry M. (1987), S. 203
- ↑ Vgl. Sneed, Harry M. (1987), S. 203f.
- ↑ Vgl. Balzert, Helmut (1998), S. 5
- ↑ Vgl. Balzert, Helmut (1998), S. 5
- ↑ Vgl. Balzert, Helmut (1998), S. 5f.
- ↑ Vgl. Balzert, Helmut (1996), S. 936
- ↑ Vgl. Autoren-Team (2008), S. 739
- ↑ Vgl. Balzert, Helmut (1998), S. 138
- ↑ Vgl. Balzert, Helmut (1998), S. 209
- ↑ Vgl. Balzert, Helmut (1998), S. 209
- ↑ Vgl. Olfert, Klaus; Steinbruch Pitter (2004), S. 203
- ↑ Vgl. Litke, Hans-D. (2004), S. 77
- ↑ Vgl. Olfert, Klaus; Steinbruch, Pitter (2004), S. 101
- ↑ Vgl. Olfert, Klaus; Steinbruch, Pitter (2004), S. 99
7 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | Wirtschaftlichkeit eines IT-Produkts mit und ohne Dokumentation[1] |
| 2 | Anforderungen und Qualitätsaspekte einer Dokumentation |
| 3 | Beispiel: Datenflussdiagramm |
| 4 | Beispiel: Struktogramm |
| 5 | Beispiel: Pseudocode |
| 6 | Beispiel: Programmablaufplan |
| 7 | Beispiel: Entscheidungstabelle |
| 8 | Beispiel: Abnahmeprotokoll |
| 9 | Beispiel: Checkliste |
| 10 | Beispiel: Netzplan |
| 11 | Beispiel: Gantt-Diagramm |
8 Literatur- und Quellenverzeichnis
| Autoren-Team (2008) | Autoren-Team: Projektmanagement, Fachmann, RKW Edition, Verlag Wissenschaft & Praxis |
| Balzert, Helmut (1998) | Balzert, Helmut: Lehrbuch der Software-Technik/Software Management,Software Qualitätssicherung, Spektrum Akademischer Verlag |
| Balzert, Helmut (1996) | Balzert, Helmut: Lehrbuch der Software-Technik/Software Entwicklung, Spektrum Akademischer Verlag |
| Bendisch, R., Kern, U. (2006) | Bendisch, Roman; Kern, Uwe: Projekte managen, MA Akademie Verlag |
| Brücher, Heide (2004) | Brücher, Heide: Leitfaden Wissensmanagement
Von der Anforderungsanalyse bis zur Einführung, Vdf Hochschulverlag |
| Burghardt, Manfred (2007) | Burghardt, Manfred: Einführung in Projektmanagement, SIEMENS |
| Cronenbroeck, Wolfgang (2004) | Cronenbroeck, Wolfgang: Handbuch Internationales Projektmanagement, Cornelsen-Verlag |
| Dörrenberg/ Möller (2003) | Dörrenberg/ Möller: Projektmanagement, Verlag Oldenbourg |
| Glinz, Martin (2002) | Glinz, Martin: Software Engineering I Vorlesungsskript, http://www2.staff.fh-vorarlberg.ac.at/~hv//Semester4/OOAD/glinz.pdf, zugegriffen am 17. Januar 2009 |
| Hesseler, Michael (2007) | Hesseler, Michael: Projektmanagement, Verlag Franz Vahlen |
| Jenny (2001) | Jenny, B. : Projektmanagement in der Wirtschaftsinformatik, vdf Hochschulverlag, Zürich 2001 |
| Kessler, Heinrich; Winkelhofer, Georg (2004) | Kessler, Heinrich; Winkelhofer, Georg: Projektmanagement
Leitfaden zur Steuerung und Führung on Projekten 4. Auflage, Springer Verlag |
| Litke, Hans-D. (2004) | Litke, Hans-D.: Projektmanagement
Methoden, Techniken, Verhaltensweisen, Carl Hanser Verlag München Wien |
| Madauss, Bernd J. (2000) | Madauss, Bernd J.: Handbuch Projektmanagement, Schäffer Poeschel Verlag |
| Mehrmann, Elisabeth; Wirtz, Thomas (1992) | Mehrmann, Elisabeth; Wirtz, Thomas: Effektives Projektmanagement, ECON Taschenbuch Verlag |
| Nausner, Peter (2006) | Nausner, Peter: Projektmanagement, Utb Verlag |
| Olfert, Klaus; Steinbuch, Pitter A. (2004) | Prof. Dipl.-Kfm. Olfert, Klaus; Prof. Dipl.-Ing. Steinbuch, Pitter A.: Projektmanagement Kompakt Training 3. Auflage, Kiehl Verlag |
| Rinza, Peter (1976) | Rinza, Peter: Projektmanagement, Springer-Verlag |
| Sneed, Harry M. (1987) | Sneed, Harry M.: Software-Management, Verlagsgesellschaft Rudolf Müller GmbH (1987) |
| Wischnewski, Erik (2000) | Wischnewski, Erik: Modernes Projektmanagement, Vieweg Friedr. + Sohn Verlag |
| Wolf, Max L.J.; Mlekusch, Rudolf; Hab, Gerhard (1997) | Wolf, Max L.J.; Mlekusch, Rudolf; Hab, Gerhard: Projektmanagement live, Expert-Verlag GmbH |
| Zielasek, Gotthold (1995) | Zielasek, Gotthold: Projektmanagement
Erfolgreich durch Aktivierung aller Unternehmensebenen, Springer-Verlag |
