Dokumentation im Rahmen des juristischen IT-Projektmanagements

Transkript

1 LUDWIG-MAXIMILIANS-UNIVERSITÄT MÜNCHEN Department Institut für Informatik Lehr- und Forschungseinheit Programmierung und Softwaretechnik Dr. Frank Sarre Seminararbeit Dokumentation im Rahmen des juristischen IT-Projektmanagements Daniyal Kazempour

2 Abstract Im laufe der letzten Jahrzehnte hat die Informationstechnologie in beachtlichen Dimensionen sich weiterentwickelt. Die Informationstechnologie nimmt nun breite Teile der Wirtschaft so wie der Gesellschaft ein und stellt einen Eckpfeiler der heutigen Kommunikation und Informationsverarbeitung dar. Dies hat zur Folge, dass Software bzw. IT-Projekte zunehmend komplexer werden und vom Umfang her signifikant zunehmen. Um dieser ständigen Entwicklung Schritt halten zu können, bedarf es neben Projektmanagement Modellen und der nötigen Ausbildung bzw. Expertise auch das Wissen und die Fertigkeiten die geeigneten Dokumentationen in der zu erwartenden Gründlichkeit und Qualität mit liefern zu können. Dies scheitert jedoch bislang in vielen Situationen an dem mangelnden Bewusstsein für die Bedeutsamkeit von Dokumentationen. In dieser Seminararbeit soll genau diese Signifikanz von Dokumentationen so wie die Arten von Dokumentationen als auch die zentralen Fragestellungen zu dem Thema exhaustiv behandelt werden.

3 Inhaltsverzeichnis 1 Einleitung: Definitionen 1 2 Hauptteil Soll/IstZustand und Tragweite Arten von Dokumentationen Projektmanagement Dokumentationen Dokumentationen zum Leistungsgegenstand Anwenderdokumentation Online-Hilfe Installations- und Konfigurationsanleitung Administratorhandbuch Betriebshandbuch Systemdokumentation Programmdokumentation Quellcodedokumentation Testdokumentation Schulungsdokumentation Rechtliche Aspekte Probleme Heuristiken Offene Fragen und abschließende Bemerkungen 14 I

4 1 EINLEITUNG: DEFINITIONEN 1 Einleitung: Definitionen Die fehlende allgemein anerkannte Definition des Dokumentationsbegriffs erschwert die klare Kommunikation in IT-Projekten und somit auch die Übereinkunft über den Inhalt, Dimensionen und Ansprüchen die die jeweiligen Dokumentationen erfüllen müssen. Trotz des Defizits in der Definition gibt es bestimmte Ressourcen in denen Angestrebt wurde den Dokumentationsbegriff möglichst formal und präzise zu erfassen. Von der juristischen Perspektive gibt es bislang ausschließlich im Bereich der Produktsicherheit unter dem Produktsicherheitsgesetz (ProdSG) eine Festlegung unter 3 Abs. 2 entnehmen dass Anleitungen erforderlich sind für Anlagen welche durch IT-Systeme und Software gesteuert werden. In dem Zusammenhang werden Anleitungen für die Assemblierung, Installation, Wartung, Warnhinweise, so wie einer Gebrauchs- und Bedienungsanleitung gefordert. Die Bewertung der Anleitungen, ob diese hinreichend sind, findet im Prozess der Konformitätsbewertung statt. Die Strenge der Bewertung unterliegt den Bestimmungen der prüfenden Instanzen. Zu bemängeln sei hier dass der Begriff der Anleitung anwendungsspezifisch definiert ist, nicht jedoch auf die inhaltlichen Details der Anleitungen eingeht. Anders als bei der Rechtssprechung sind im Bereich der Normierungen viele Forschritte gemacht worden, so dass Normen im Bereich der Dokumentationen in den vergangenen Jahren zugenommen haben. Jene Normen die auf Internationaler Ebene gesetzt wurden, gehen dabei weiter auf die Details ein hinsichtlich der Anforderungen an Dokumentationen. Speziell im Qualitätsmanagement haben sich Normen durchgesetzt. Hier sei genauer die Norm ISO betrachtet die für komplexe IT-Projekte besonders relevante Aspekte enthält: Spezifikationen, werden hier als Dokumente definiert die Anforderungen enthalten. Leitfäden sind als Dokumente beschrieben die Empfehlungen oder Vorschläge aufweisen. Unter Verfahren, Arbeitsanleitungen und Zeichnungen sind Dokumente zu verstehen die Informationen darstellen wie Abläufe bzw. Prozesse auszuführen sind. Zuletzt sind Aufzeichnungen jene Dokumente die wie ein Protokoll fungieren und einen objektiven Nachweis darüber geben sollen wie bei dem Projekt vorgegangen wurde bzw. wie die Ergebnisse jeweils erreicht worden sind. Das wesentliche Defizit in der Norm ISO ist dass nicht darin festgelegt wird bei welcher Projektart welche Dokumente erforderlich sind. Neben der Definition dass eine Dokumentation im Rahmen von IT-Projekten eine definierte Funktion erfüllen soll gibt es noch das Merkmal dass die Dokumente jeweils einen definierten Lebenszyklus haben (ISO9001). Laut der Norm gehören Dokumente die in einem IT-Projekt keinerlei Zweck erfüllen auch nicht zur Dokumentation dazu. Die internationale Norm ISO/IEC/IEEE ist relativ jung ziemlich umfassend. Es behandelt exhaustiv alle in einem IT-Projekt möglichen Projektanforderungen die in den Normen ISO/IEC (Softwareprojekte) so wie ISO/IEC (IT-Systeme allgemein) festgelegt sind. ISO/IEC stellt dabei ein breites Rahmenwerk für aller in einem Projekt potenziell anfallenden Prozesse dar. Eine Konkretisierung der Dokumentationsarten findet sich z.b. im IEEE Standard 829 wieder wo detaillierter auf Testdokumentationen eingegangen wird. Um die Brücke zwischen Normen und der juristischen Perspektive aufzubauen lässt sich hier an dieser Stelle erwähnen dass jegliche Norm nur als eine Empfehlung angesehen wird, außer es ist in irgend einer Form in einem Gesetz oder eine Verordnung manifestiert. Was jedoch stets möglich ist, ist eine Übernahme von Normen als Referenz in Verträgen. Auf diese Weise wird eine rechtliche Wirkung der Norm über die vertraglich geschuldete Leistung induziert. 1

5 1 EINLEITUNG: DEFINITIONEN Abbildung 1.1: Relationen einzelner Instanzen im Hinblick auf Dokumentationen Abschließend betrachtet ist zu erwähnen dass Normen eine detailliertere Struktur der Aufgaben wieder geben die in aufwändigeren IT-Projekten zum tragen kommen, doch werden diese nur selten bis gar nicht umgesetzt. Geschuldet ist dies evtl. auch der mangelnden Verbreitung und Anwendung, insbesondere wenn man berücksichtigt wie jung einige der Normen sind. Es bleibt somit abzuwarten wie sich die Normen mit der Zeit etablieren. Wobei die Verbreitung an den enormen Kosten in der Beschaffung so wie der fehlenden deutschen Übersetzung mit geschuldet sind. Neben der juristischen Perspektive und den Normen gibt es Fachliteratur zur Spezifikation von IT-Systemen die mit der Zeit ihre verbreitete Anwendung und Akzeptanz gefunden haben. Problematisch ist der Aspekt der Fachliteratur dahingehend dass sie primär den Absolventen eines Informatik oder Wirtschaftsinformatikstudiums bekannt ist, nicht jedoch zwangsläufig z.b. ausgebildeten Fachinformatikern, wo die Thematik der Dokumentation sehr knapp behandelt wird. Es bleibt auch hier abzuwarten wie das Lehrangebot in diversen Informatikausbildungen sich dahingehend verändert dass dem Thema Dokumentation in IT-Projekten im Curriculum einen höheren Stellenwert zugewiesen wird, und dass Fachliteratur auf den Markt erscheint welches die Thematik der Dokumentation hinreichend ausführlich behandelt. Auch wenn es auf der Makroebene als schwierig erweist eine allgemein anerkannte Definition des Dokumentationsbegriffs zu finden, so gibt es auf der Unternehmensebene in größeren Firmen interne Richtlinien. Die Sicherstellung der Einhaltung der Richtlinien erfolgt über das Qualitätsmanagement. Es sei noch zu vermerken dass die einzelnen Domänen mit ihren Definitionen zu Dokumentationen wie in Abbildung 1.1 in Beziehung gestellt werden können. 2

6 2 HAUPTTEIL 2 Hauptteil 2.1 Soll/IstZustand und Tragweite Die Bedeutsamkeit und Tragweiten einer Dokumentation sind beachtlich wodurch die Anfertigung von sachgerechten Dokumentationen einen hohen Stellenwert bei IT-Projekten erhalten sollte. Je nach dem wie und welche Dokumentationen umgesetzt worden sind kann es signifikante Auswirkungen haben die sich letzten Endes im Hinblick auf die Wirtschaftlichkeit bemerkbar machen. Welche Dokumente unverzichtbar sind und erstellt werden müssten hängt ganz davon ab welche Ziele zu erreichen sind und von welcher Art das Projekt ist. Es kann hierbei zwischen zwei Arten von Dokumentationen entschieden werden, jene die zum Leistungsgegenstad gehören (z.b. Spezifikationen und andere Dokumentationen die für die Nutzung und Betrieb notwendig sind) und die Projektmanagementdokumentationen. Bei Standardprojektvorgehen sind in den folgenden Phasen die jeweiligen Dokumentationen anzufertigen: Vertragsverhandlung Konzeption Realisierung Test und Abnahme Integration/Installation Betrieb Sobald IT-Systeme individuell auf die Bedürfnisse des Auftraggebers angepasst werden müssen ist im jeweiligen Fall zu ermitteln welche Dokumentationen von Nöten sind. Im Hinblick auf die Tragweite ist die Projektmanagementdokumentation essenziell um ein Projekt möglichst zielgerichtet durchführen zu können. Hier sei jedoch auch vermerkt dass es essenziell ist, allerdings keine Garantie für einen erfolgreichen Ausgang des Projekts darstellt. Eine Vernachlässigung oder geringere Dedizierung in die Projektmanagementdokumentation könnte dazu führen dass das Projekt mehr Zeit so wie Kosten in Anspruch nimmt als ursprünglich einkalkuliert was in den meisten Fällen zum Scheitern des Projekts führt. Zunächst betrachten wir die Ausgangssituation, Entscheidung und Konsequenzen seitens des Auftraggebers. Grundlage für ein Scheitern des Projekts ist auf dieser Seite das mangelnde Bewusstsein welche Tragweite eine Dokumentation haben kann. Dieser Mangel wird dann meistens erst im weiteren Verlauf des Projekts wahr genommen. Die Feststellung dass know-how über das System fehlt und keine oder nur mangelhafte Dokumentation zum Füllen dieser Wissenslücke vorliegt führt dazu dass das System nicht produktiv eingesetzt werden kann. Dies führt wiederum ggf. zu erheblichem wirtschaftlichen Schaden. Für den Auftragnehmer ist eine gründliche Dokumentation verbunden mit einem großen Mehraufwand und wird eher als kontraproduktiv wahrgenommen. Dass gerade dieser Mehraufwand im Nachhinein Zeit so wie Kosten spart wird nicht hinreichend in IT-Projekten reflektiert. 3

7 2.2 Arten von Dokumentationen 2 HAUPTTEIL Die Tragweite einer unzureichenden oder gar fehlenden Dokumentation ist abhängig von Fragestellungen wie: Um was für eine Art von Projekt handelt es sich? Wie ist der Umfang des Projekts? Wie?unverzichtbar? ist die Dokumentation? und damit verbunden: Ist eine eigenständige Weiterentwicklung geplant? Selbst wenn nicht: was passiert wenn Mitarbeiter die das System gut kennen warten das Unternehmen verlassen? (know-how Verlust) Wie hoch ist das Fehlerrisiko? Zusammenfassend kann gesagt werden dass die sinnvollste Minimierung des Risikos erreicht werden kann in dem der Auftragnehmer so genau und strukturiert wie unter den gegebenen Rahmenbedingungen möglich das Produkt zu dokumentieren. 2.2 Arten von Dokumentationen Nach den Definitionen so wie der Aufführung der Tragweiten von Dokumentationen befassen wir uns nun mit den Arten von Dokumentationen. Hier werden zwischen zwei Bereiche differenziert: Projektmanagement Dokumentationen Dokumentationen zum Leistungsgegenstand Projektmanagement Dokumentationen Die wesentlichen Ziele einer Dokumentation sind hier die Sicherstellung einer ordnungsgemäßen Planung so wie Durchführung eines Projekts. Es dient auch im Falle eines gescheiterten Projekts nachzuvollziehen welche Fehler bzw. Defizite zum Scheitern geführt haben. In diesem Zusammenhang ist noch die Bedeutsamkeit von Projektmanagement Dokumentationen im juristischen Kontext hervorzuheben. Denn in rechtlichen Auseinandersetzungen wird dann meist die Dokumentation aufgrund seiner Nachweisfunktion herangezogen. Bei der Projektplanung sind folgende Elemente in der Dokumentation festzuhalten: Projektauftrag und Projektziele Projekthintergrund Technische u. organisatorische Rahmenbedingungen Vertragliche Rahmenbedingungen Finanzielle Rahmenbedingungen 4

8 2 HAUPTTEIL 2.2 Arten von Dokumentationen Das Festhalten dieser Elemente erfolgt durch den verantwortlichen Projektleiter durch die Anfertigung eines Projektstruktur so wie eines Ressourcenplans. Handelt es sich um ein komplexes IT-Projekt, stellen sog. Profjektstrukturpläne (PSP) sicher dass eine aufgabenbezogene strukturierte Übersicht der einzelnen Projektanforderungen vorliegt. Der PSP nimmt Bezug zu den im Lastenheft definierten Anforderungsspezifikationen. Aus dem Ressourcenplan resultieren Aktivitätenund Fristenpläne (AFP). Diese beziehen anders als beim PSP auch zeitliche Verteilungen aller Arbeitsteile gekoppelt an die jew. Ressourcen mit ein. Im AFP sind auch die Mitwirkungsleistungen des Auftraggebers sichtbar. In vielen Fällen wird die AFP auch stark vereinfacht als Projektplan bezeichnet. AFPs bilden das zentrale Element der Projektsteuerung. Um den soll-zustand im AFP mit dem aktuellen ist-zustand des Projektverlaufs abzugleichen finden im Rahmen der Projektsteuerungen regelmäßige Meetings statt. Das führen von Besprechungsprotokolle stellen sicher dass der aktuelle Fortschritt nachvollziehbar bleibt und ggf. bestimmte Risiken früher erkannt werden können Dokumentationen zum Leistungsgegenstand Bei der Abnahme eines IT-Projekts sind je nach vertraglicher Vereinbarung folgende Dokumente zum Leistungsgegenstand vorzulegen: Andwenderdokumentation Online-Hilfe Installationsanleitung Konfigurationsanleitung Administratorhandbuch Betriebshandbuch Systemdokumentation Programmdokumentation Quellcodedokumentation Testdokumentation Schulungsdokumentation Anwenderdokumentation Eine Anwenderdokumentation hat den Zweck dass ein Benutzer eines Softwaresystems imstande ist basierend auf dieses Dokument alle vorliegenden Funktionen nutzen und in Problemfällen diese beheben zu können. Eine Anwendungsdokumentation hat dabei eine Perpetuierungsfunktion zu erfüllen, d.h. dem Benutzer muss über die Dokumentation die Möglichkeit gegeben sein andere Benutzer in das System einweisen zu können. Aufgrund des hohen Stellenwerts der Anwendungsdokumentation in Projekten sind sowohl umfangreiche Rechtssprechungen so wie auch Normen vorhanden, auf die jedoch in dieser Ausarbeitung nicht weiter eingegangen wird, da dies den Rahmen dieser Arbeit bei weitem überschreiten würde. Es sei hier auf die Quellen im Literaturverzeichnis verwiesen für detailliertere Aufführungen. 5

9 2.2 Arten von Dokumentationen 2 HAUPTTEIL Online-Hilfe Online-Hilfen liegen zusätzlich zur Anwendungsdokumentation in immer mehr Produkten vor. Diese sind optional sofern nicht anders im Vertrag vereinbart. Sofern die Online-Hilfe nicht auf ein separates Speichermedium vorliegt und die Texte nicht in Papierform ausgedruckt werden können und sonstige Merkmale einer Anwendungsdokumentation aufweisen, sind diese kein adäquater Ersatz von von ausgedruckten Benutzerhandbücher. Bei einer Anpassung eines Standardprodukts an den individuellen Bedürfnissen des Kunden gilt hier besondere Aufmerksamkeit, da im Falle der Änderung einer Anwendungsdokumentation auch die Online-Hilfe mit anzupassen wäre. In der Praxis bleibt diese synchronisierte Aktualisieren jedoch meistens aus Installations- und Konfigurationsanleitung Installationsanleitung erfüllen die Funktion Fachpersonal das Wissen zu vermitteln wie ein System in der Zielumgebung zu installieren ist. Die Kernelemente einer Installationsanleitung sind die Systemanforderungen (Software, Hardware so wie Betriebssystem), so wie Beschreibungen wie eine Installation und De-Installation auszuführen ist. Sind Installationen von Anwendungen in einem komplexen Umfeld zu erledigen, sind diverse Konfigurationen von Parametern mit involviert. Diese werden jedoch nicht in der Installationsanleitung sondern in Konfigurationsanleitungen (Cusomizing-Guides) aufgeführt. Die Hauptintention von diesen Anleitungen ist es Fachpersonen ein gewisses Maß an Anpassungen vornehmen zu können Administratorhandbuch Liegt ein Softwaresystem mit hoher Komplexität vor, werden die Ausführungen bestimmter kritischer Funktionen exklusiv an Administratoren dediziert. Ein Administratorhandbuch ist somit wie eine Anwendungsdokumentation, allerdings mit dem Schwerpunkt. Auch hier soll das Administratorhandbuch ermöglichen in einem gewissen Bereich das Softwaresystem individuell anzupassen bzw. zu modifizieren. Bestimmte Inhalte sind charakteristisch für diese Art von Dokumentation, so wie z.b. Verwaltung von Berechtigungsprofilen, Sperren und Freischalten von Funktionen, Protokollierungssetup so wie Konfiguration diverser Schnittstellen Betriebshandbuch Ein Betriebshandbuch ist insbesondere für die IT-Division der Auftraggeber Seite relevant damit diese einen sicheren Betrieb eines System oder Applikation gewährleisten können. Dies bedeutet dass diese Dokumentationsart den Fokus auf den technischen Betrieb hat und somit darin Inhalte wie z.b. Integration vorhandener Systemumgebungen, Sicherstellung der Verfügbarkeit, Aufrechterhaltung der Leistungsfähigkeit so wie Datenschutz Gewährleistung umfassen. Um auf das V-Modell Bezug zu nehmen, sei hier an dieser Stelle erwähnt dass in den früheren Versionen des Modells noch Betriebshandbücher enthalten waren. Im V-Modell XT ist ein solches Dokument nicht mehr explizit vorhanden. Deren konkreten Inhalte sind delokalisiert auf andere Themengebiete. Ein rechtlicher Anspruch auf ein Betriebshandbuch besteht nicht, außer es wurde vertraglich explizit festgehalten. 6

10 2 HAUPTTEIL 2.2 Arten von Dokumentationen Systemdokumentation Die genaue Definition einer Systemdokumentation bleibt im Genauen ungeklärt. Einige Quellen fassen als Systemdokumentation die Deskription der elementaren Eigenschaften eines Systems und der eingesetzten Umgebung auf, andere fassen unter diesem Begriff alle Dokumente zusammen welche die technischen und funktionalen Eigenschaften beschreiben wie z.b. Anwenderdokumentation, Administrationshandbücher, Installationsanleitungen oder Betriebshandbuch. Es sei somit Vorsicht geboten um bei einem Vertrag sofern der Begriff auftaucht, im Vorfeld explizit zu klären was die Inhalte von der Systemdokumentation sein sollen Programmdokumentation Ziel von Programm- oder Entwicklungsdokumentationen soll die Beschreibung des Aufbaus und der Struktur von der jew. Software darlegen. Es ist an IT-Fachkräfte gerichtet und soll ihnen ermöglichen sich in den Aufbau so wie Funktionsweise von Software einzuarbeiten und diese nachvollziehen zu können. Bis 1981 existierte die DIN-Norm welche jedoch ersatzlos 2006 zurückgezogen wurde und somit keine Grundlage mehr für IT-Projekte darstellt. Aktuell liefert die Norm ISO/IEC Anforderungen für diese Dokumentationsart, wenn auch nur in Ansätzen. Unter Programmer?s manual steht darin geschrieben dass in einer Art Programmdokumentation die verwendeten Algorithmen so wie die Quellcode-Struktur beschrieben sein sollen. Diese Beschreibung kann textuell oder mit Hilfe des standardisierten Unified Modelling Language (UML) erfolgen. Neben UML gibt es noch die Software Design Descriptions (SDD) die sich auf den IEEE-Standard stützen. In dieser Norm werden die technische Struktur eines System oder einer Anwendung aufgeführt. Wie viele andere Dokumentationsarten auch, wird die Programmdokumentation heutzutage weitestgehend aufgrund der Komplexität in elektronischer Form bereit gestellt Quellcodedokumentation Neben der Dokumentierung der verwendeten Algorithmen so wie der Programmstruktur ist der Dokumentation des Quellcodes der Software ebenfalls von Bedeutung. Im wesentlichen stützt sich diese Dokumentation auf die vom Entwickler eingetragenen Kommentare im Quellcode. Elemente die in einem Quellcode-Kommentar vermerkt stehen wären z.b. Programmkopf mit Programmbezeichnung, Autoren, Versionshistorie, die Signatur mit Aufrufparameter und Rückgabewert von Funktionen, die Aufgaben der Funktionen, Interface Beschreibungen usw. Primär dient diese Art der Dokumentation einer leichteren Nachvollziehbarkeit von Strukturen und Abläufen von Programmen im Detail für z.b. Analyse oder späteren Erweiterung des Programms. An dieser Stelle sei jedoch empfohlen dem Paradigma zu folgen?so wenige Kommentare wie möglich, so viele wie nötig?. Dies setzt voraus dass der Code hinreichend?sauber? geschrieben ist und die Kommentare nicht unnötig oder sogar irreführend vermerkt sind (?comment-pollution?). Ist der Programmcode?closed-source? so wäre es sinnvoll vom Auftragnehmer her sicher zu stellen dass die Schnittstellen (sofern Verfügbar bzw. vertraglich geregelt) hinreichend dokumentiert sind. Die Generierung der Dokumentationen wird mittlerweile weitestgehend automatisiert abgewickelt mittels Werkzeuge wie z.b. JavaDoc, Doxygen u.a und liegt in digitaler Form vor. 7

11 2.2 Arten von Dokumentationen 2 HAUPTTEIL Testdokumentation Die wohl umfangreichste und sehr genau in Normen festgeschriebene Art von Dokumentationen ist die Testdokumentation. Über die Norm IEEE 829 ist eine ganze Reihe an Dokumentationen spezifiziert die bei Testvorgängen anzulegen sind: Testplanung Testkonzept Testdesignspezifikation Testfallspezifikation/Testfälle Testablaufspezifikation Testprotokolle Testvorfallsbericht Testergebnisbericht Auf die Details der einzelnen Dokumentationen im Testbereich einzugehen würde den Rahmen dieser Ausarbeitung sprengen. Somit sei auf die Quellen im Literaturverzeichnis verwiesen. Die unterschiedlichen Dokumente liegen in der Verantwortung unterschiedlicher Beteiligten eines Projekts. Der Schwerpunkt der Verantwortlichkeit sollte allerdings beim Auftragnehmer liegen. Auch hier gilt als?soll-zustand? dass in komplexen IT-Projekten dass i.d.r. all diese Testdokumentationen anzufertigen sind. Der?ist-Zustand? zeigt in der Praxis wieder einmal dass solche exhaustiven Dokumentationen in dem Umfang häufig aus bleiben, sofern dies nicht im Vertrag vereinbart worden ist Schulungsdokumentation Schulungsdokumentationen sind eher dann wirksam wenn IT-Projekte vorliegen mit vielen beteiligten Personen und großen organisatorischen Tragweiten. Es sind dann sog. Anwenderschulungen von Nöten die in logistischer so wie Zeit planender Hinsicht eine Herausforderung darstellen. Als Basis der Schulungen ist eine passende Schulungsdokumentation unverzichtbar. Diese Dokumentation besteht aus einem Schulungskonzept in dem nach ISO/IEC/IEE unter ein?trainings plan? erstellt wird. Dieses Schulungskonzept deckt Themen ab wie z.b. Schulungsthemen, Zuordnung der jeweiligen Mitarbeiter, Aufteilung in Blöcke mit geeigneter Personenzahl, Festlegung der Räumlichkeiten etc. Den zweiten Teil stellen die Schulungsunterlagen selbst dar. Ziel der Schulungsunterlagen ist es den künftigen Benutzer die Fähigkeiten zu vermitteln das System je nach Aufgabenstellung passend nutzen zu können. Im juristischen Kontext sind Schulungsunterlagen geschuldet, wenn diese explizit vertraglich festgelegt worden sind. Wobei hier zu beachten ist, dass selbst wenn vertraglich geregelt ist dass der Auftraggeber eine Schulung durchzuführen hat, dies nicht impliziert dass auch Schulungsunterlagen mit zu liefern sind. Diese sollten in einem Vertrag somit explizit festgehalten werden. Es sei abschließend zu erwähnen dass die genannten Dokumentationsarten nicht zwangsläufig voneinander strikt getrennt vorliegen. Es kann dabei durchaus zu Überlappungen kommen. So kann z.b. ein Administrationshandbuch auch teile der Installation oder der Konfiguration mit beinhalten. Oder das Betriebshandbuch kann Teile vom Administrator- oder Installationshandbücher inkludieren. 8

12 2 HAUPTTEIL 2.3 Rechtliche Aspekte 2.3 Rechtliche Aspekte Nach einem BGH Urteil vom gibt es eine Rechtssprechung welches besagt dass zu jeder Software auch ein Benutzerhandbuch geliefert werden muss. Interessant in diesem Kontext ist auch die Beobachtung dass sich die Rechtssprechung mehrheitlich bislang mit dem Thema Anwenderdokumentationen bzw. Benutzerhandbücher beschäftigt hat, jedoch nicht mit anderen in IT-Projekten wichtigen Dokumentationsarten. Die Form in der die Anwendungsdokumentation vorzuliegen hat ist auch auf optischen Medien möglich, sofern dem Benutzer die Möglichkeit gegeben ist ohne Hindernisse darauf zugreifen zu können. Fehlt ein Benutzerhandbuch ist dies entsprechend einer (teilweisen) Nichterfüllung. Die Dokumentation genügt dann den Ansprüchen, wenn der Benutzer in der Lage versetzt werden kann unabhängig vom Lieferanten das Produkt/System einzusetzen und ggf. andere Anwender in den Umgang bzw Benutzung einzuweisen. Nach dem BGH Urteil vom sollen Bedienungsanleitungen allgemein folgende Kriterien erfüllen: Vermitteln aller erforderlichen Kenntnisse zur fehlerfreien Bedienung der Anlage um den mit der Anschaffung verbundenen Intention das System nutzen zu können Ergänzen oder konservieren von schon vorhandenem Wissen über den Gebrauch Dieses Urteil ist nicht nur im Kontext der Anwendungsdokumentation relevant, sondern auch für z.b. Installationsdokumentationen oder Entwicklungsdokumentationen. Es gilt hier auch dass eine Kaufsache mangelhaft ist wenn man trotz Befolgung der Anwendungsdokumentation keine fehlerfreie Funktionalität erhält und das obwohl der Kaufgegenstand frei von Makel ist. Ebenfalls in einem Beschluss festgehalten ist dass die Auflistung aller Programmfehlermeldungen mit möglichen Ursachen ein notwendiger Bestandteil der Anwendungsdokumentation ist. Fehlt eine Online-Hilfe so ist dies nach einem BGH Urteil vom ein Sachmangel. Sollte ein Benutzer nicht erfolgreich eine Software trotz Befolgung der Installationsdokumentation zu installieren oder zu deinstallieren so ist die Dokumentation ebenfalls mangelhaft. Der Fall ob eine Installationsanleitung geschuldet ist, wenn im Vertrag selbst nichts vermerkt steht ist noch nicht höchstrichterlich entschieden. Betrachtet man 434 BGB welches besagt dass eine fehlende oder mangelhafte Montageleistung ein Mangel an der Sache selbst ist, kann man eine fehlende oder mangelhafte Installationsanleitung mit dem Sachverhalt gleich setzen. Eine Konfigurationsanleitung kann auch zu den Installationsanleitungen bzw. dem Installationsprozess gezählt werden, womit auch in dem Fall eine solche Dokumentation geschuldet ist, selbst dann wenn im Vertrag nichts explizit dazu verfasst wurde. Von einer anderen Perspektive aus, kann diese Dokumentationsart auch zu Anwendungsdokumentation mit Fokus auf spezielle Nutzerkreise zugezählt werden, z.b. Administratoren. In dem Fall kann auch die Konfigurationsanleitung als Teil des Administratorhandbuchs gezählt werden. Eine genauere Auseinandersetzung der Gerichte mit dieser Frage liegt bis dato nicht vor. 9

13 2.4 Probleme 2 HAUPTTEIL Nach der aktuellen Gesetzeslage können Programmdokumentationen in schriftlicher Form durch Schulungen oder einer hinreichend verfügbaren so wie qualifizierten Hotline substituiert werden. Die Anforderungen an eine solche Dokumentation werden vom Benutzerkreis gestellt, dies inkludiert auch die Verständlichkeit der Anleitung. Hier gilt auch nach einem OLG Beschluss dass ein nicht versierter Benutzer erwarten darf dass das Dokument in deutscher Sprache vorliegt. Handelt es sich bei der Software um eine individuell angefertigte, so kann vom Auftraggeber erst dann nach einer solchen Dokumentation verlangt werden, wenn die Arbeiten an der Software fertig gestellt sind. Ein vorzeitiger Anspruch ist somit rechtlich ausgeschlossen. Interessanter Weise gilt eine Programmdokumentation auch dann schon als mangelhaft wenn auch nur das Inhaltsverzeichnis fehlt. Sofern die Übergabe eines Quellcodes vertraglich festgelegt ist, gilt ein Quellcode als mangelhaft, sofern jegliche Kommentierung fehlt. Ob eine Entwicklungsdokumentation verpflichtend geliefert werden muss ist nur über eine mittelbare Pflicht aus mehreren BGH-Urteilen zu entnehmen. Sofern nicht explizit vereinbart wurde dass eine solche Dokumentation zu erstellen ist, muss in jedem Einzelfall individuell geurteilt werden ob der Quellcode mit dazu geliefert werden muss. Nimmt man hier allerdings das Urteil des BGHs hinzu dass der Auftraggeber durch die Dokumentation vom Auftragnehmer unabhängig werden muss, so kann man darauf schließen dass eine Entwicklungsdokumentation mit hinzu geliefert werden muss, sofern der Auftraggeber beabsichtigt unabhängig vom Auftragnehmer das Programm zu modifizieren bzw. weiter zu entwickeln. 2.4 Probleme Bislang wurden in der Ausarbeitung Themen behandelt welche die Theorie betreffen (Definitionen, rechtliche Aspekte, Arten von Dokumentationen etc.). Einen kleinen Überblick was für?gängige? Probleme zwischen den Vertragspartnern auftreten können wird nun in diesem Kapitel behandelt. Der wohl häufigste in der Praxis zu beobachtende Fehler ist das Fehlen von vertraglichen Vereinbarungen zum Thema Dokumentationen. Durch die unzureichende oder ganz und gar nicht vorhandene Vereinbarung über das Thema in Verträgen entstehen Schwierigkeiten mit einer großen Tragweite. Dies resultiert daraus dass Dokumentationen nicht als unverzichtbar wahr genommen werden oder noch nicht einmal die Bedeutsamkeit zugeschrieben bekommen die sie eigentlich haben. Wie in Kapitel 2 erwähnt zieht diese Unterschätzung verheerende wirtschaftliche Folgen mit sich die mindestens eine Seite der Vertragspartner betreffen. Wird im Verlauf eines IT-Projekts doch die Bedeutsamkeit von Dokumentationen erkannt, so kommt die Erstellung solcher Dokumentationen meist zu spät. Vor allem bei für den Auftraggeber individuell angelegten Projekten ergibt sich gegen Ende ein enorm hoher Aufwand für die Dokumentation der Ergebnisse. Dies führt dazu dass der Auftragnehmer sich gegen Ende schlichtweg?verschätzt? und die ursprünglich für die Dokumentation eingeplante Zeit so wie monetäre Ressourcen für andere Aufgaben aufgebraucht werden. Hier muss allerdings erwähnt werden dass dies kein Problem der Erstellung einer Dokumentation an sich ist, sondern eher ein Problem welches einem schlechten Projektmanagement zuzuschreiben ist. Ebenfalls in dem Zusammenhang in der Praxis oft vorgefallen ist eine?deadlock? Situation wo einerseits der Auftragnehmer mehr Budget für die noch nicht erstellte Dokumentation anfordert, der Auftraggeber jedoch kein weiteres Budget zur Verfügung stellen will, so lange keine Dokumentation (oder zumindest ein Teil davon) vorliegt. 10

14 2 HAUPTTEIL 2.4 Probleme Eine weitere Problematik ergibt sich bei Fragen rund um die Art und Form von Anwendungshandbüchern. Liegt eine Standardsoftware vor, so liegt die Wahl beim Auftragnehmer ob die Anwendungshandbücher entsprechend anzupassen sind, oder ob eine Ergänzung zu den bisher vorhandenen Anwendungsdokumentationen ausreicht. Letzteres wird vom Auftragnehmer im Hinblick auf den Aufwand bevorzugt gewählt. In den Ergänzungen wird dann einfach auf die Standardhandbücher verwiesen. Laut BGH Urteil muss nur sicher gestellt sein dass der Anwender das System über die Anwendungsdokumentationen sicher und korrekt nutzen kann. Hier gibt es derzeit kein allgemein gültiges Rezept wodurch es im Einzelfall zu prüfen sei ob der Auftraggeber mit so was leben kann bzw. muss. Im Gegensatz zur Standardsoftware muss bei Individualsoftware diese Dokumentationsart vollständig neu geschrieben werden. Hier besteht Seitens des Auftraggebers die Möglichkeit auf einen Anspruch einer solchen Dokumentation. Aufgrund des erheblichen Aufwands einigen sich jedoch beide Parteien manchmal darauf aus Kostengründen keine Dokumentation zu erstellen was jedoch als Konsequenz dazu führt, dass die korrekte Bedienung nicht mehr gewährleistet ist. Bei Administrations-, Installations- oder Betriebsdokumentationen liegen häufig keine ausreichend detaillierten Beschreibungen vor. Dies führt zu den in früheren Kapiteln erwähnten?abhängigkeiten? die es erschweren dass der Auftraggeber autonom und somit ohne weiteren Einsatz von Ressourcen das Produkt nutzen kann. Geht es darum dass der Auftragnehmer später die Software weiter entwickeln oder durch Dritte weiter entwickeln lassen will, ist eine gute Programm so wie Quellcodedokumentation unerlässlich. Fehlt diese, oder ist diese nur mangelhaft, wird eine Weiterentwicklung nahezu unmöglich, oder nur unter extrem erschwerten Bedingungen zu realisieren sein. Eine häufige Fehlerquelle ist hier dass über Art so wie den Umfang der Dokumentation nichts oder nicht genau vereinbart wird. Da auch keine allgemein verbindliche Standards vorliegen, bleibt die Entscheidungsfreiheit in dem Fall bei dem Auftragnehmer. Dies führt in den meisten Fällen zum Streit weil die Lieferung nicht den Vorstellungen des Auftraggebers entsprechen. Ist doch mal eine Dokumentation vorhanden, so scheitert es auch da an einer fehlenden Verifikation ob die Dokumentation zum Programm und zum Quellcode passt. Im Hinblick auf Schulungsunterlagen ist ein gängiges Problem dass bei Individualsoftware Schulungsunterlagen für die Standardversion verwendet werden. Dies resultiert darin dass schon zu Beginn die Mitarbeiter z.b. mit einer anderen Benutzeroberfläche konfrontiert werden als jene die in den Schulungsunterlagen steht, was zu Verwirrungen führt und somit den gewünschten Lerneffekt bei der Schulung ggf. verfehlt. Rechtssprechungen in dem Bereich sind bislang noch nicht vorhanden. Es kann jedoch folgendes aus ähnlichen Fällen abgeleitet werden: Gab es keine Vereinbarung zu Schulungsunterlagen, sind auch keine geschuldet Wurde jedoch eine Erstellung und Lieferung vertraglich vereinbart, so müssen diese auch passen zu der Software geliefert werden. Vor allem im Bereich der Projektmanagementdokumentation sind viele Probleme zu beobachten die häufiger auftreten. So wird z.b. mit dem Ziel der Kostenersparnis die Projektmanagementdokumentation nicht zu formalisieren oder im Umfang zu reduzieren. Auch die mangelnde Erfahrung des Auftraggebers führt dazu dass dieser den erforderlichen Umfang einer solchen Dokumentation nicht kennt und diese auch nicht beim Vertragsabschluss mit einfordert. Dies führt je nach Fall zu unüberschaubaren Kommunikationen und diese wiederum zu Inkonsistenzen im Projektverlauf. Die Inkonsistenzen führen dann ihrerseits wiederum zu inkompatible Fragestellungen im Hinblick auf die expliziten Vereinbarungen und Verantwortlichkeiten. Durch unklare Vereinbarungen kommt es auch zu Uneinigkeiten über den Status von einer Aktivität im Projekt. 11

15 2.5 Heuristiken 2 HAUPTTEIL Und nicht zuletzt kommt es durch die Inkonsistenzen und Unklarheiten zu einer mangelnden Aktualität, sowohl unter den Beteiligten als auch in dem aktuellen Projektstand. Insbesondere wenn Teilprojekte voneinander abhängen kann diese mangelnde Aktualität verheerende Folgen für den weiteren Projektverlauf so wie für den Ausgang des Projekts haben. Bei Testdokumenten liefert der Auftraggeber häufig keine Dokumente darüber aus was in welchem Umfang und wie getestet wurde. Bei der Abnahme tauchen dann sowohl bei komplexen aber auch ggf. bei einfachsten Funktionen Fehler auf. Bei einer wiederholten Abnahme tauchen dann evtl. weitere Fehler auf, so dass von der Auftraggeberseite in Frage gestellt wird was bzw. ob überhaupt etwas getestet wurde. Bei einer Forderung eines Testdokuments erhält der Auftraggeber kein erfolgreiches Ergebnis, da nach Ansicht des Auftragnehmers dieser keinen Anspruch auf ein solches Dokument hat. Ist in einem Werkvertrag jedoch festgelegt dass der Auftragnehmer Funktionsfähigkeit nachzuweisen hat, kann die Forderung einer Testdokumentation im juristischen Kontext möglich sein, sofern der Auftragnehmer die Funktionstüchtigkeit nicht in einer anderen Art und Weise hinreichend nachweisen kann. Unabhängig von allen Problemen in den jeweiligen Dokumentationsarten liegt eine wesentliche Schwäche in der mangelnden Klärung der Verantwortlichkeiten. 2.5 Heuristiken Bei all den möglichen Problemen die in den vorigen Kapiteln erwähnt wurden sind lt. Literatur folgende Empfehlungen für die Vertragspartner aufzuführen. Diese sind nicht als ein Garant für den sicheren Erfolg eines Projekts zu verstehen, sondern viel mehr als eine Heuristik um mögliche Probleme und Konflikte so weit wie möglich zu reduzieren. Der Auftraggeber soll vor der Beauftragung sich sehr genau damit beschäftigen welche Art von Projekt vorliegt, welchen Aufwand es hat, welche Art der Nutzung so wie Weiterentwicklung geplant ist und welche Art von Dokumenten von besonders großer Bedeutung sein können. Dabei soll unbedingt bestanden werden dass die erforderlichen Dokumentationen vertraglich festgelegt werden. Es gilt wie sonst auch bei vertraglichen Regelungen dass die Definitionen der Inhalte der Dokumentationen so exakt wie nur möglich formuliert werden. Ein Beilegen von Dokumentationsmuster erleichtert das Verständnis über das geforderte und vermeidet Missverständnisse. Es ist sinnvoll stets bei Vertragsabschluss schon fest zu legen wer in den jeweiligen Parteien welche Verantwortlichkeiten hat. Auch hier gilt: je genauer dies festgelegt ist, desto weniger Missverständnisse und Unklarheiten kann es am Ende geben Für verschiedene Dokumentationen ergeben sich unterschiedliche Lieferzeitpunkte. Wann genau die Lieferzeitpunkte sein sollen, ist ebenfalls zu empfehlen bei Vertragsabschluss festzuhalten. Sollte sich der Leistungsgegenstand ändern, ist hier dringend darauf zu achten dass die Änderungen konsistent in den Dokumentationen mit angepasst werden Liegt eine Anpassung von Standardsoftware vor, so sind beide Parteien ebenfalls bestens damit bedient wenn sie im Vorfeld bei Vertragsabschluss so genau wie möglich klären in welcher Form und was von der Anpassung dokumentiert werden soll. Auch ist hier relevant welcher Vertragspartner diese Anpassung vorzunehmen hat. Sind bei der Anpassung einer vorhandenen Anwendung die Veränderungen überschaubar so können diese dann in einem?delta-anwenderhandbuch? festgehalten werden (was ebenfalls vertraglich zu regeln sei). 12

16 2 HAUPTTEIL 2.5 Heuristiken Sollten es umfangreiche Änderungen sein so sollte die Integration der Anpassungen in die Standarddokumentation vertraglich festgehalten werden. Um das Risiko eines Streits über irgendwelche Mängel so gering wie möglich zu halten empfiehlt es sich auch eine Abnahme sämtlicher Dokumentationen zu machen. Sofern ein Werkvertrag vorliegt wäre dies darin explizit festzuhalten. Dem Auftragnehmer ist zu empfehlen die Aufwände und Liefertermine für die Dokumentationen mit in die Projektplanung zu berücksichtigen und die Priorität dieser Aspekte in der Planung nicht zu reduzieren. Unabhängig von der Projektmethode ist zu empfehlen dass beide Parteien stets jederzeit uneingeschränkten Zugriff auf die Dokumentationen des Projektverlaufs haben und diese auch gemeinsam in dem notwendigem Maße pflegen. 13

17 3 OFFENE FRAGEN UND ABSCHLIESSENDE BEMERKUNGEN 3 Offene Fragen und abschließende Bemerkungen Trotz allen Definitionen und Heuristiken gibt es noch ungeklärte Fragen. Einige von denen sollen hier nun exemplarisch aufgeführt werden. So ist es z.b. ungeklärt ob eine Installationsanleitung?fool proof? sein muss, d.h. ob sie so gestaltet sein muss dass eine Installation unabhängig von der Expertise/Erfahrungsstand der anzuwendenden Person zum Erfolg führen muss. Ebenfalls noch nicht höchstrichterlich entschieden ist, ob eine Pflicht zur Dokumentation des Quellcodes besteht. Neben der Quellcodedokumentation ist ebenfalls juristisch noch nicht geklärt in welchen Fällen neben einer Anwendungsdokmentation auch weitere Dokumentationen zu liefern sind für den Fall dass vertraglich keine oder nicht eindeutige Vereinbarungen getroffen wurden. Wie auch im ersten Kapitel erwähnt sind diverse Normen vorhanden welche die Struktur, d.h. Umfang so wie Inhalte definieren, diese jedoch nicht für die unterschiedlichen Anwendungszwecke im Detail spezifizieren. Zusammenfassend ist zu erwähnen dass das Thema Dokumentationen schon allein aufgrund der nicht allgemein anerkannten Definition sich als eine Herausforderung darstellt. Es sind viele verschiedene Formen von Dokumentationen für die jeweiligen Zwecke anzufertigen, doch werden diese in der Praxis aus Zeit so wie Kostengründen reduziert oder gar drauf verzichtet, mit unter Umständen fatalen Folgen. Auch ist nicht im juristischen Kontext die Rechtslage in allen Fällen geregelt. Es bleibt somit allen Parteien zu empfehlen trotz allen Aufwands bei aller Komplexität eines Projekts, die Kriterien und Aspekte so wie Inhalte und Umfang rund um Dokumentationen so detailliert wie nur möglich vertraglich fest zu halten und den Raum für Missverständnisse oder Fehlinterpretationen auf ein Minimum zu reduzieren. Vor allem die Kommunikation und Mitwirkung so wie Transparenz bei der Einsicht der Dokumente sind wesentliche Faktoren welche Probleme reduzieren können. Dieser Mehraufwand führt längerfristig zu weniger Problemen und im Endeffekt zu weniger finanziellen so wie zeitlichen Aufwandsschäden. Eminent für das Umsetzen dieser Aspekte ist letzten Endes auch die Schärfung des Bewusstseins beider Parteien über die Wichtigkeit von Dokumentationen in IT-Projekten. Ein Ansatz hierzu wäre bei den jeweiligen Ausbildungen die Studierenden exhaustiv mit der Thematik befassen zu lassen, mit der Hoffnung dass mit der Zeit die Konflikte die aufgrund fehlender oder mangelhafter Dokumente entstehen, abnehmen werden. 14

18 LITERATUR LITERATUR Literatur [1] Reiss, Manuela; Reiss, Georg: Praxisbuch IT-Dokumentation. Addison-Wesley Verlag, München 2010 [2] D. Uhl: Technische Dokumentation? Praktische Anleitungen und Beispiele [3] U. Friedrichsen: Was muss, was kann und was geht gar nicht? Optimale Systemdokumentation mit agilen Prinzipien. OBJEKT Spectrum, SIGS-Datacom, März 2012 [4] B. Jenny: Projektmanagement in der Wirtschaftsinformatik. vdf Verlag, 5. Auflage, 2001 [5] G. Gründwied: Software Dokuementation: Grundlagen, Praxis, Lösungen. expert-verlag, 2005 [6] K. J. Oey: Moderne Softwaredokumentation: der Weg zu effizienter Entwicklerdokumentation. VDM Verlag, 2007 [7] M. Bruells: Anforderungen an Benutzer-Dokumentationen für betriebswirtschaftliche Anwendersoftware. Diplomarbeit, GRIN Verlag, 2003 [8] M. Broy, M. Kuhrmann: Projektorganisation und Management im Software Engineering. Springer Vieweg, Xpert.press-Reihe, 2013 [9] M. Werner: Anwalt Formulare, EDV- und Internetrecht, Erläuterungen und Muster. Deutscher Anwalt Verlag, 2008 [10] R.C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall, 2008 [11] S. Zörner, G. Starke: Softwarearchitekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten. Hanser Verlag, 2012 [12] BGH Urt. v ? X ZR 9/99? NJW 2001, 1718: Fälligkeit der Lieferung einer Software-Dokumentation. [13] BGH Urt. v ? X ZR 83/90? NJW 1993, 1063? Werkabnahme: Nichtlieferung der Benutzerdokumentation. [14] LG Landshut, Urt. v ? 2 HK O 2392/02? CR 2004, 19 ff.: Handbuchlieferung bei Softwarekauf. [15] OLG Köln, Urt. v U 34/97? NJW-RR 1999, 1287: Fehlen von Dokumentationsunterlagen. [16] OLG Köln, Urt. v ? 19 U 54/99: Zweisprachige Dokumentation eines zweisprachigen Computerprogramms. [17] OLG Hamm, Urt. v ? 31 U 37/89? CR 1990, 715 (716): Gewährleistungsansprüche beim Computerkauf in unzureichende Dokumentation und fehlerhafte Software. [18] BHG Urt. v ? X ZR 129/01? CR 2004, 490: Softwareentwicklungsauftrag: Anspruch des Bestellers auf Überlassung des Quellcodes. 15