Leseprobe
Inhaltsverzeichnis
II. Abbildungsverzeichnis
III. Tabellenverzeichnis
IV. Abkürzungsverzeichnis
1. Einleitung
1.1. Problemstellung
1.2. Zielsetzung und Aufbau der Arbeit
2. Theoretische Grundlagen
2.1. Dokumentation und Softwaredokumentation
2.2. Arten von Softwaredokumentationen
3. Effizienzsteigerung von Dokumentationen
3.1. Anforderungen an eine gute und verständliche Dokumentation
3.2. Maßnahmen zur Effizienzsteigerungen bei Dokumentationen
4. Schlussbetrachtung
V. Literaturverzeichnis
II. Abbildungsverzeichnis
Abbildung 1: Ursachen für den Nachbearbeitungsaufwand von Software
Abbildung 2: Vorgehensmodell zur Softwaredokumentation
III. Tabellenverzeichnis
Tabelle 1: Unterscheidung betriebswirtschaftliche und technische Dokumentation
Tabelle 2: Normen für Softwaredokumentation (Auszug)
IV. Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
Im folgenden Kapitel wird zunächst die Problemstellung der vorliegenden Ausarbeitung erläutert, darauf aufbauend werden die Ziele der Arbeit definiert sowie der Aufbau dieser beschrieben.
1.1. Problemstellung
Das Thema der Softwaredokumentation genießt in der Softwareentwicklung keinen guten Ruf und wird meist nur als notwendiges Übel betrachtet. In den meisten Entwicklungsprojekten scheint es zunächst wichtiger, das System beziehungsweise die Software fertig zu programmieren als diese aufwändig zu dokumentieren. Die Dokumentation wird nur ungern und verhältnismäßig schlecht ausgeführt. Das Problem mangelhafter Dokumentation ist allerdings bereits seit langem bekannt und wurde in der Vergangenheit auch immer wieder viel diskutiert. Eine qualitativ hochwertige Dokumentation ist insbesondere auch für die Endanwender der erstellten Produkte von großer Bedeutung. Komplizierte und unverständliche Dokumentationen führen zu Fehlern und Unlust in der Anwendung der Software. Eine gute Dokumentation verringert nicht nur die Aus- und Weiterbildungskosten des eingesetzten Personals, sondern baut darüber hinaus auch Hemmschwellen gegenüber der Anwendung ab.[1]
Da auch die Gesetzgeber, speziell in Europa und in den USA, die Dokumentation als wichtig erachten gibt es seit einigen Jahren relativ klare gesetzliche Forderungen nach guten Dokumentationen. Die Anwender-Dokumentationen haben den Zweck, den Nutzer eines Produktes in die Lage zu versetzen, das Produkt sicher und richtig zu verwenden. Die meisten Hersteller von technischen Produkten sind sich mittlerweile über ihre Instruktionspflichten im Klaren und viele haben auch schon dementsprechend gehandelt und der Softwaredokumentation einen angemessenen Stellenwert in ihrem Unternehmen eingeräumt. Doch auch in den Firmen, bei denen die Dokumentation gut aufgestellt und wohl organisiert ist, bleibt sie ein Kostenfaktor, der aus Sicht der Unternehmen oft nichts mit der eigentlichen Wertschöpfungskette zu tun hat und dem im Vergleich zu anderen Bereichen, wie Produktentwicklung oder Marketing, in der Geschäftsführung kaum Beachtung geschenkt wird.[2]
Laut einer Studie der Firma Gebert Software GmbH mit mehr als 300 Firmen mit jeweils über 100 Millionen Euro Umsatz liegt der Aufwand für die Nachbearbeitung von Software durchschnittlich bei über 20 Prozent im Vergleich zum eigentlichen Entwicklungsaufwand. Als typische Ursachen für die aufwändige Nachbearbeitung nennen zwei Drittel der Unternehmen, wie in Abbildung 1 zu sehen, vor allem eine schlechte Softwareverwaltung mit unzureichender Dokumentation.[3]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Ursachen für den Nachbearbeitungsaufwand von Software[4]
1.2. Zielsetzung und Aufbau der Arbeit
Das Ziel der vorliegenden Ausarbeitung ist es, die verschiedenen Anforderungen an eine gute und verständliche Dokumentation zu erarbeiten und daraus Maßnahmen für die Effizienzsteigerung von Dokumentation abzuleiten.
Nachdem im ersten Kapitel zunächst die Problemstellung sowie die Zielsetzung und der Aufbau der Arbeit beschrieben wurden, werden im zweiten Kapitel die theoretischen Grundlagen zu Dokumentationen und Softwaredokumentationen sowie zu den verschiedenen Arten von Dokumentationen mit deren Vor- und Nachteilen erläutert. Darauf aufbauend werden im dritten Kapitel die verschiedenen Anforderungen an eine gute und verständliche anwenderbezogene Software-Dokumentation erarbeitet. Aus diesen Anforderungen werden dann Maßnahmen für die effiziente Erstellung von Dokumentationen und die Steigerung der Effizienz von Dokumentationen abgeleitet. Zum Abschluss werden im vierten Kapitel die Ergebnisse der Arbeit zusammengefasst und kritisch gewürdigt.
2. Theoretische Grundlagen
In diesem Kapitel werden die theoretischen Grundlagen erarbeitet, die zum Verständnis der vorliegenden Ausarbeitung notwendig sind. Dazu wird zunächst der Begriff Dokumentation im Allgemeinen und danach der Begriff Softwaredokumentation im Speziellen definiert. Im Anschluss werden die verschiedenen Arten von Softwaredokumentationen vorgestellt.
2.1. Dokumentation und Softwaredokumentation
Der Begriff Dokumentation beschreibt im Allgemeinen das Sammeln, Erfassen, Ordnen und Aufschließen von Dokumenten sowie deren Aufbereitung für Informationszwecke. Der Begriff beschreibt also sowohl den Prozess des Dokumentierens als auch das Produkt, welches am Ende des Prozesses entsteht und auf elektronischen Medien oder auf Papier festgehalten wird.[5]
Der Sinn einer Dokumentation liegt zum einen in der Wissenskonservierung, es wird also Wissen gesammelt und gespeichert. Durch dieses Wissen sollen Testfälle erzeugt und Module getestet werden können, bei einem Reengineering kann ebenfalls auf dieses Wissen zugegriffen werden. Zum anderen liegt der Sinn einer Dokumentation aber auch im Wissenstransfer. Damit soll sichergestellt werden, dass die später beteiligten Personen Wissen aufbauen und anwenden können.
Eine Softwaredokumentation umfasst alle notwendigen und zweckgerichteten Informationen über das vorliegende Produkt, dazu gehören die Software selbst sowie deren Erstellung und Benutzung.[6] Die Dokumentation ist hierbei nicht statisch sondern wird vom Beginn der Planung über den gesamten Lebenszyklus des Produkts entwickelt. Somit ist es nicht sinnvoll erst zum Ende der Programmierung mit der Dokumentation anzufangen, sondern bereits ab Beginn der Planung und der Umsetzung jeden Schritt zu dokumentieren.[7] Zu den hauptsächlichen Zielgruppen einer Dokumentation gehören der Projektleiter, der den Softwareentwicklungsprozess steuert, der Endanwender, der mit der Software arbeitet sowie Entwickler oder IT-Spezialisten, die die Software erstellen oder die bestehende Software im Nachhinein anpassen, erweitern und betreuen.
2.2. Arten von Softwaredokumentationen
Je nach Inhalt, Zielsetzung und Adressat einer Softwaredokumentation lassen sich Dokumentationen in verschiedene Arten aufteilen. Grundsätzlich lassen sich hierbei, wie in Tabelle 1 zu sehen, betriebswirtschaftliche und technische Dokumentationen unterscheiden.
Tabelle 1: Unterscheidung betriebswirtschaftliche und technische Dokumentation
Abbildung in dieser Leseprobe nicht enthalten
Die technischen Dokumentationen können je nach Zielgruppe nochmals in betriebsinterne und -externe technische Dokumentationen aufgeteilt werden. Eine betriebsinterne technische Dokumentation ist ausschließlich für den Gebrauch innerhalb des Unternehmens, welches die Software entwickelt gedacht. Hierzu gehört beispielsweise das Pflichtenheft.[8] Die betriebsexternen technischen Dokumentationen gehören zum Lieferumfang des Produkts und sind für die Kunden beziehungsweise Anwender der Software bestimmt.
Da sich die vorliegende Ausarbeitung mit Software-Dokumentationen für den Software-Anwender beschäftigt, welche zu den betriebsexternen technischen Dokumentationen gehören, werden nun die verschiedenen Arten betriebsexterner technischer Dokumentationen genauer erläutert.
Systemdokumentation
Die Systemdokumentation enthält Dokumente, die für die Wartung und Weiterentwicklung der Software notwendig sind. Dazu gehören UML (Unified Modeling Language)-Diagramme oder Use-Case- und Szenario-Beschreibungen, die ursprüngliche Anforderungsspezifikation beziehungsweise das Lastenheft sowie eine Dokumentation der Systemarchitektur. Die Systemdokumentation betrachtet also übergreifend die Funktionsprinzipien der Software. Dadurch kann diese Dokumentation sehr umfangreich werden, es gilt also einen Kompromiss zwischen möglichst vollständiger Beschreibung und Umfang zu finden.[9]
Programmdokumentation
Die Programmdokumentation beschreibt die Syntax, also das Funktionsprinzip, des Programmcodes. Diese Dokumentation sollte zusätzlich zur Papierform auch als Inline Source Dokumentation zur Verfügung stehen. Darunter wird das Einfügen von erklärenden Kommentaren direkt in den Programmcode verstanden. Dies ist besonders wichtig, da für einen Programmierer, der den Code nicht geschrieben hat direkt sichtbar wird, was das Funktionsprinzip des jeweiligen Codestückes ist.[10]
Benutzungsdokumentation
Die Benutzungsdokumentation enthält Dokumente und Unterlagen für die tatsächlichen Endanwender der Software, dazu gehören Unterlagen für die Installation und den Betrieb sowie Handbücher oder Online-Hilfen für die Anwender. Oft enthalten Handbücher auch FAQs (Frequently Asked Questions), die häufig gestellte Benutzerfragen auflisten und beantworten. Das Handbuch erleichtert vor allem in der Anfangszeit den Umgang des Anwenders mit der Software. Dem Anwender wird die Software nähergebracht, das Handbuch gibt einen Überblick über die Funktionen und dient gleichzeitig im Verlauf der Softwarenutzung als Nachschlagewerk für aufkommende Fragen.[11]
[...]
[1] Vgl. o.A., ‘Unverzichtbares Instrument für Systementwickler - Die Dokumentation ist eines der Software-Qualitätsmerkmale’, Computerwoche, 25 October 1991
[2] Vgl. L. Kothes, Grundlagen der Technischen Dokumentation - Anleitungen verständlich und normgerecht erstellen, VDI-Buch (Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg, 2011), p. 1f
[3] Vgl. B. Giesel, Studie: Nachbearbeitungsaufwand von Software. http://gebertsoftware.com/node/47
[4] Vgl. ibid.
[5] Vgl. W. Haag, Dokumentation von Anwendungssystemen aus der Sicht der Benutzer (Darmstadt, 1981)
[6] Vgl. W. Hoffmann, B. Hölscher and U. Thiele, Handbuch für Technische Autoren und Redakteure: Produktinformation und Dokumentation im Multimedia-Zeitalter, 1.th edn. (Erlangen: Public Corporate Publishing, 2002)
[7] Vgl. A. Rögner, Untersuchungen zur Funktion von Benutzerinformationen für die Beeinflussung der Menschlichen Zuverlässigkeit in sozio-technischen Systemen (Cottbus, 2005), p. II-3f
[8] Vgl. International Organization for Standardization, ISO IEC IEEE 15289:2011 Software und System-Engineering - Content of life-cycle information products (documents)
[9] Vgl. H. Nowak, Dokumentation in der Software-Entwicklung (Wien: InfraSoft GmbH, 2002), p. 7f
[10] Vgl. ibid., p. 3f
[11] Vgl. o.A., ‘Softwaredokumentation - Handbuch’ in SoftGuide GmbH & Co. KG (ed.), softGuide der Softwareführer - Business Software, Branchenlösungen und Standardsoftware - Ihre aktuelle Marktübersicht