Fragt man eine Softwareentwicklerin bzw. einen Softwareentwickler nach der Entwicklungsdokumentation, wird es dazu je nach Stellung im Projekt unterschiedliche Meinungen geben. Stößt die Person gerade zum Projektteam dazu, wird sie händeringend nach einer aussagekräftigen Dokumentation Ausschau halten. Gibt es keine, wird sie sich fragen, wie sie es schaffen soll, sich in den vorhandenen Quellcode einzuarbeiten. Ist die betreffende Person bereits Mitglied des Teams, dann sieht die Sache bekanntermaßen anders aus. Die Entwicklerin bzw. der Entwickler kennt sich im Projekt aus und sieht eine Dokumentation üblicherweise nicht als dringlich an. Mit anderen Worten: Es gibt immer wichtigere und vor allem auch spannendere Tätigkeiten als die Beschreibung bereits implementierter Funktionen.

Für das Anfertigen einer Dokumentation müssen verschiedene Fragen geklärt werden, darunter die Folgenden:

• Was soll dokumentiert werden?

• In welchem Umfang soll das geschehen?

• Wie gestaltet man die Dokumentation so, dass sie für die Zielgruppe verständlich ist?

• In welcher Form (formal, Wiki, Texte, Grafiken usw.) soll die Dokumentation erstellt werden?

• Wo wird die Dokumentation gespeichert?

• Wer hat Zugriff auf die Dokumentation?

• Welche Personen sind für ihre Pflege verantwortlich?

Es gibt nicht die eine Form der Softwaredokumentation. Typische Varianten sind die Programm-, die Prozess- und die Entwicklerdokumentation (Abb. 1). Was darunter genau zu verstehen ist, klären wir in den nächsten Abschnitten.

Programmdokumentation

Die Programmdokumentation bezieht sich auf die Installation, Bedienung und Administration der Software. Die Zielgruppe können Endanwender oder Systemverantwortliche in Unternehmen sein, die die Software einsetzen. So trivial, wie diese Form der Dokumentation auf den ersten Blick wirkt, ist sie nicht. Selbstverständlich sollte Software heute so gestaltet sein, dass die Anwender sie direkt einsetzen können. Andererseits erfordern komplexe Softwaresysteme die umfassende Beachtung und Bereitstellung von Hard- und Softwarevoraussetzungen. Umfangreiche Konfigurationsschritte können eine größere Hürde darstellen, wenn es um die Nutzung eines neuen Softwareprodukts geht. Die Programmdokumentation beschäftigt sich also mit der Frage des Einsatzes und der Verwendung der Software und nicht mit ihrer internen Funktionsweise. Daher ist diese Form der Dokumentation i. d. R. auch eine essenzielle Voraussetzung für den Verkauf eines Softwareprodukts. Gelegentlich sind Entwickler auch in der Position des Anwenders. Denken Sie dabei zum Beispiel an den Fall, dass Sie die Softwarekomponente eines Drittanbieters in Ihrer Applikation verwenden möchten. Diese Komponente setzen Sie dabei in Form einer Blackbox ein, d. h., Sie müssen über die Schnittstellen genau Bescheid wissen:

• Welche Daten sollen als Parameter übergeben werden?

• Welche Daten liefert die Komponente als Ergebnis?

• Welche Beschränkungen gibt es in Bezug auf die Verwendung?

Wie die Komponente intern im Detail funktioniert, ist nicht unwichtig und schon gar nicht uninteressant, aber für einen ersten Einsatz nicht entscheidend. Wir suchen in diesem Fall also nach einer Produktdokumentation, die die Verwendung der Komponente beschreibt. Gut ist es, wenn es nicht nur eine Beschreibung der Schnittstellen gibt, sondern auch Beispiele für die typischen Einsatzszenarien der Komponente existieren. Idealerweise gibt es Quellcodebeispiele in der Dokumentation, sodass man diese direkt in den eigenen Programmcode übernehmen und anpassen kann. Sie sehen: Programmdokumentationen sind ein wichtiges Merkmal einer Software und unter keinen Umständen nur ein Nice-to-have. Sie sollten i. d. R. als Onlineversion auf der Webseite präsentiert werden, damit Anwender stets darauf zugreifen können. Gleichermaßen ist eine gute Produktdokumentation ein Aushängeschild eines Produkts, in diesem Fall unserer Software. Sie verdeutlicht die Einsatzmöglichkeiten, zeigt Problemlösungen auf und ist damit ein hervorragendes Werbeinstrument.

Softwareentwicklungsdokumentation

Darunter verstehen wir die Prozessdokumentation und die Entwicklerdokumentation. Die Prozessdokumentation beinhaltet Informationen, die den Entwicklungsprozess der Software betreffen. Darunter:

• Welche Vorgehensweise wird gewählt?

• Wie sind die Zuständigkeiten verteilt?

• Wer ist Ansprechpartner?

• Darf man bei unklaren Anforderungen den Kunden direkt kontaktieren oder ist der Ansprechpartner der Product Owner?

• In welcher Form finden Abstimmungen im Projekt statt?

• Wie wird eine Remotezusammenarbeit organisiert?

Die Prozessdokumentation beschreibt in groben Schritten die Organisation des Entwicklungsprozesses. Sie könnten nun argumentieren, dass diese den Teammitgliedern von allein klar werden wird. Das ist zwar nicht falsch, doch spricht auch manches dagegen: Wie sieht das bei größeren und verteilt arbeitenden Teams mit einer regelmäßigen Fluktuation der Mitglieder aus? Wie werden neue Mitarbeiter instruiert? Eine Basisdokumentation, die Grundzüge der Abläufe und der organisatorischen Festlegungen enthält, ist hier sehr hilfreich. Beispielsweise kann man eine allgemein anerkannte Organisationstruktur der agilen Projektarbeit konkretisieren und mit Namen, Zuständigkeiten, Erreichbarkeiten usw. versehen. Ein echtes Hilfsmittel.

Die eigentliche Entwicklerdokumentation ist als Unterstützung für die Softwareentwicklung gedacht. Hier geht es tatsächlich um technische Fragen, beispielsweise um die Architektur des Softwaresystems und die Implementierung (Quellcode). Die Entwicklerdokumentation soll Entwicklerinnen und Entwickler in ihrer Tätigkeit unterstützen und hat dabei eine determinierende und eine deskriptive Funktion. Die determinierende Funktion besteht darin, konkrete Vorgaben zu machen. Es werden verbindliche Konventionen zu Bezeichnungen von Quelltextelementen festgelegt. Es finden sich Klassen- und Datendiagramme, Architektur- und Designpläne und andere Vorgaben zur Erstellung der Software. Die Vorgaben und Richtlinien werden dabei üblicherweise in den Styleguides zusammengefasst und geben unter anderem folgende Hinweise:

• Ist eine Entwicklungsumgebung vorgegeben oder kann jede Entwicklerin/jeder Entwickler das Werkzeug aussuchen?

• Wie sollte man den Quellcode formatieren?

• An welcher Stelle werden Leerzeichen und Tabulatoren gesetzt?

• Wie wird mit Einrückungen umgegangen?

• Welche Vorgaben bestehen für die Vergabe von Namen für Variablen, Klassen, Objekte usw.?

Wird die Camel-Case- oder die ungarische Notation verwendet (Kasten „Camel-Case- und die ungarische Notation“)?

• Wie, in welcher Form und in welchem Umfang werden Quelltextkommentare aufgeführt?

Auch wenn sich über die Zeit allgemein anerkannte Konventionen zur Gestaltung des Quelltextes herauskristallisiert haben, ist es sehr sinnvoll, dass ein Entwicklungsteam eigene Styleguides definiert. Ausgangspunkt können zentral verfügbare Styleguides sein. Solche werden zum Beispiel von Google für die Quellcodeverwaltungsplattform GitHub bereitgestellt. Dort finden sich Hinweise zur Quelltextformatierung für die unterschiedlichsten Programmiersprachen. Es gibt auch eine Empfehlung für Java (Abb. 2).

Abb. 2: Styleguides von Google für Java [5]

Nicht immer werden alle Vorgaben als sinnvoll empfunden. Es empfiehlt sich daher, die allgemeinen Empfehlungen an die individuellen Ziele des Teams anzupassen. Die Praxis zeigt, dass man mit einem Zuviel an Vorgaben eher das Gegenteil dessen erreicht, was man möchte. Wenige, dafür wichtige und entscheidende Vorgaben festzulegen und auf deren Einhaltung dann auch zu achten ist zielführender. Kleinere und weniger kritische Abweichungen sind dagegen zu tolerieren bzw. sind dafür keine Vorgaben zu machen. Der „Fluss“ des Entwicklers wird dadurch nicht gebremst. Das gilt gerade dann, wenn Entwickler in unterschiedlichen Teams eingebunden sind. Sie müssen sich in diesem Fall nicht grundsätzlich umgewöhnen und brauchen nur die Vorgaben zu wenigen zentralen Punkten zu beachten.

Kommen wir zur deskriptiven (beschreibenden) Aufgabe der Dokumentation. Damit sollen die wesentlichen Entscheidungen der Implementierung festgehalten werden. Das betrifft zum Beispiel einzelne Funktionen, Module, Datenbankfelder usw. Diese Dokumentation wird für die unterschiedlichsten Aufgaben benötigt, etwa bei der Erweiterung, der Fehlersuche, der Fehlerbereinigung und der Wartung des Systems.

Formen der Entwicklungsdokumentation

Je nach Zielgruppe, Nutzungskontext und Änderungshäufigkeit wird zwischen folgenden Formen der Dokumentation für den eigentlichen Entwicklungsprozess unterschieden [1], [2]:

• Architekturdokumentation: Eine stabile Architektur ist eine notwendige Voraussetzung zur Erstellung leistungsfähiger Software. Diese Form der Dokumentation bezieht sich auf den Aufbau des Systems. Folgende Themen werden dabei behandelt: Überblick, Zielsetzung der Software, Bestimmung der Qualitätsmerkmale und Rahmenbedingungen, Definition der Stakeholder, Überblick über die Risiken, Vorstellung übergreifender technischer Konzepte, Information zu Deployment und Betrieb, Zusammenfassung zentraler Begriffe (Glossar). Im Netz gibt es zahlreiche Vorlagen für eine Architekturdokumentation.

• Developer-Guides/API-Guides: Diese Dokumentation zielt auf die Beschreibung von typischen Anwendungsfällen, die Nutzung von Modulen usw. Dabei kann mit Hilfe von Beispielen gezeigt werden, wie bestimmte Module des Softwaresystems genutzt werden. Entwickler können bei einer Erweiterung des Systems auf diese Informationen zurückgreifen.

• Schnittstellendokumentation: Schnittstellen werden zur Interaktion zwischen einzelnen Komponenten eingesetzt. Die Dokumentation von Schnittstellen ist wichtig, damit die Entwickler wissen, wie ein Modul zu nutzen ist.

• Klassen- und Methodenreferenz: In dieser Dokumentation werden die Klassen und die zugehörigen Eigenschaften und Methoden der Software beschrieben.

• Testfälle: In der Regel wird jedes Softwaresystem zahlreichen Tests unterzogen. Ein Test beinhaltet eine detaillierte Vorgehensanweisung, eine Beschreibung des Gegenstandes und des Ergebnisses. Um den Überblick zu behalten, sollen die Tests entsprechend dokumentiert werden.

Die o. g. Dokumentationsformen sind eng miteinander verbunden. Die genannten Punkte sind Beispiele für Inhalte einer solchen Dokumentation. Diese müssen je nach Projekt ergänzt und angepasst werden.

Verantwortlichkeiten und Prozess

In vielen Entwicklungsprojekten gibt es schon bestimmte Elemente zur Dokumentation. Entwickler haben ggf. schon das eine oder andere UML-Diagramm erstellt, um den Überblick während der Entwicklung zu behalten. Typisch sind automatisch generierte Klassendiagramme. Auch werden bei der Programmierung oft schon Quelltextkommentare hinzugefügt, um beispielsweise die Bedeutung einzelner Klassen, Methoden oder Eigenschaften zu beschreiben. Diese Einzelelemente sind wichtig und können eine Ausgangsbasis für eine aussagekräftige Dokumentation darstellen. Sie ergeben jedoch noch kein zusammenhängendes Bild. Die entscheidende Frage ist: Wie schnell kann sich ein außenstehender Entwickler mit Hilfe der Dokumentation in das Projekt einarbeiten? Um das zu gewährleisten, braucht es einen geplanten Prozess für die Dokumentation. Sie kann nicht nebenher, als „Abfallprodukt“ entstehen. Wichtig ist auch, wer an der Erstellung beteiligt ist. Eine gute Dokumentation entsteht in der Zusammenarbeit der Mitglieder eines Teams. Je nach Projektgröße sind neben den Entwicklern auch die Softwarearchitekten und weitere Personen daran beteiligt. In umfangreichen Projekten kann die Strukturierung der Dokumentation durch technische Redakteure vorgenommen werden.

Die agile Dokumentation

Sind eine Dokumentation und agile Projektarbeit kein Widerspruch in sich? Nein, ganz und gar nicht! Die agile Entwicklung hat die Art und Weise, Software zu bauen, maßgeblich verändert. Statt starrer Prozesse ist Flexibilität angesagt. Änderungen in den Anforderungen sind willkommen und werden so schnell wie möglich eingearbeitet. Das Vorgehen hat auch Auswirkungen auf die Art der Entwicklungsdokumentation. Statt umfassender Lasten- und Pflichtenhefte arbeiten wir mit elektronischen Boards, definieren Tasks und legen den Inhalt des nächsten Sprints fest. Bei der Teamarbeit wird mit Kanban-Bords, Klebezetteln usw. hantiert. Dennoch gilt auch hier: Der Quellcode als Ergebnis zeigt nur das Wie der Lösung, aber nicht das Warum. Ebenso werden Zusammenhänge nicht erklärt. Eine Dokumentation ist daher auch in agilen Projekten notwendig. Die Art und Weise der Dokumentation kann jedoch an die Prozesse angepasst werden. Dazu einige Beispiele bzw. Best Practices:

• Die Dokumentation als Teil des Entwicklungsprozesses: Die Aufgaben der Softwaredokumentation müssen integraler Bestandteil des Entwicklungsprozesses werden. Man könnte die Dokumentation als separaten Punkt in die Definition of Done aufnehmen. Bevor ein Task als „done“ markiert wird, ist zu prüfen, ob die Dokumentation eines Features oder einer User Story ausreichend ist.

• Kompakte und aktuelle Informationen: Dokumentieren Sie alle notwendigen Sachverhalte in einer kompakten Form. Denke Sie daran, dass die Dokumentation bei Änderungen am betreffenden Modul gepflegt werden muss.

• Ebenen der Dokumentation: Entwickler können im laufenden Prozess beispielsweise die einzelnen Softwarekomponenten dokumentieren. Dennoch sollte es auch eine minimale Dokumentation des Gesamtsystems, der Architektur und des Systemkontexts geben. Man kann dabei auf gut etablierte Standards zurückgreifen, zum Beispiel das Template Arc42 [12].

• Dokumentation wie Quellcode behandeln: Die Dokumentation sollte mit rein textbasierten Werkzeugen erstellt (siehe nächster Abschnitt) und sie sollte versioniert werden.

• Komplexes Visualisieren: Getreu dem Motto: „Ein Bild sagt mehr als tausend Worte“ ist es oft hilfreich, komplexe Sachverhalte mit Hilfe einer Grafik zu veranschaulichen. Dabei muss es sich nicht immer um das perfekte UML-Diagramm handeln. Eine Infografik verdeutlicht Zusammenhänge und hält diese für Nachbetrachtungen fest. Eine solche Infografik kann – entsprechend groß ausgedruckt – während der Entwicklung an der Wand befestigt werden. Später wandert die Darstellung dann in die Dokumentation.

Fassen wir zusammen: Die Dokumentation ist zwar nicht der Fokus der agilen Entwicklung. Sie gehört jedoch auch hier zu den Aufgaben. Im nächsten Abschnitt geht es um die Werkzeuge für eine gute Softwaredokumentation.

Werkzeuge und Anwendung in der Java-Praxis

Für die Anfertigung der Dokumentation stehen unterschiedliche Tools zur Verfügung. Sehr häufig wird mit Visualisierungen gearbeitet. Grafische Modelle – zum Beispiel ein Entwurf der Architektur – können dabei mit einem spezialisierten Zeichenprogramm erstellt werden. Man ist gut beraten, sich an allgemeine Standards zu halten. Um die Struktur zu dokumentieren, kann man zum Beispiel Paket-, Verteilungs- und Komponentendiagramme erstellen, wie diese in der UML definiert werden. Oft werden solche Diagramme als zu komplex empfunden. Sie bilden jedoch einen brauchbaren Standard, und die Syntax und die Verwendung der Symbole ist genormt. Selbst wenn man in der Praxis die Vorgaben der UML an dieser Stelle nicht zu 100 Prozent einhält, dürfte das Ergebnis nutzbar sein. Um UML-Diagramme zu erstellen, gibt es mehrere Varianten: Onlinezeichenwerkzeuge, Zeichentools als eigenständige Applikationen oder Plug-ins, die man in die Entwicklungsumgebung integrieren kann. Weitere UML-Diagramme, insbesondere Klassendiagramme, können automatisiert aus dem Quellcode generiert und in die Dokumentation übernommen werden.

Üblich ist es heute, den Quelltext direkt zu kommentieren. Folgende Hinweise aus der Praxis haben sich bewährt:

• Sprache: Einigen Sie sich zwingend auf eine Sprache. Variablen, Klassennamen und andere Quelltextelemente werden üblicherweise in englischer Sprache bezeichnet. Bei den Quelltextkommentaren findet man innerhalb eines Projekts oft ein Durcheinander vor. Die Erfahrung zeigt, dass Entwicklerteams immer häufiger international und damit mehrsprachig zusammengesetzt sind. In diesem Fall ist eine englischsprachige Dokumentation oft die bessere Wahl. Dafür spricht auch, dass die Tools zur automatischen Quelltextdokumentation Informationen aus den Namen der Quelltextelemente ableiten. Wenn diese in englischer Sprache verfasst werden, dann sollte auch der Rest der Dokumentation auf Englisch sein.

• Textinhalte: Es sollte dokumentiert werden, was nicht unmittelbar aus dem Quelltext ersichtlich ist. Warum wurde der Sonderfall hier nicht berücksichtigt? Welcher Algorithmus liegt der Berechnung zugrunde? Wozu dient diese Klasse? Welche Aufgabe wird durch die Methode gelöst? Besonders wichtig ist die Dokumentation der Schnittstellen und Parameter. Wozu dient diese Eigenschaft? Welche Werte werden in der globalen Variablen gespeichert? Jede Quelltextdatei sollte mit einem standardisierten Header (Autor, Datum der Erstellung, Version usw.) versehen werden.

• Umfang: Lieber einen Kommentar zu viel als einen zu wenig. Über einen Hinweis kann man bei einer kommentierten Selbstverständlichkeit schnell hinweglesen. Eine fehlende Information muss man sich dagegen im Zweifelsfall sehr mühsam durch eine aufwendige Quelltextanalyse selbst erarbeiten.

Welche Tools gibt es, um Quelltextkommentare zu verarbeiten? Bekannt ist das Tool Javadoc [6], das gefühlt schon immer Bestandteil des Java Development Kits war. Ein weiteres Tool ist Doxygen [7]. Doxygen ist ein Standardtool zum Generieren von Dokumentationen aus annotierten C++-Quellen, unterstützt aber auch andere gängige Programmiersprachen, u. a. C, Objective-C, C#, PHP, Java, Python. Doxygen kann man auf unterschiedliche Arten einsetzen: Es kann einen Onlinedokumentationsbrowser in HTML und/oder ein Offlinereferenzhandbuch in LaTeX aus einer Reihe von dokumentierten Quelldateien generieren. Es gibt auch eine Unterstützung für die Generierung von Ausgaben in den Formaten RTF-, PostScript-, Hyperlink-PDF, komprimiertem HTML und Unix-Manpages. Man kann Doxygen so konfigurieren, dass es die Codestruktur aus Quelldateien extrahiert. Das ist sehr nützlich, um sich in großen Source-Distributionen schnell zurechtzufinden. Doxygen kann auch die Beziehungen zwischen den verschiedenen Elementen mit Hilfe von Include-Abhängigkeitsdiagrammen, Vererbungsdiagrammen und Kollaborationsdiagrammen visualisieren, die alle automatisch generiert werden. Man kann das Tool auch zum Erstellen normaler Dokumentationen verwenden. Doxygen wurde unter macOS und Linux entwickelt. Darüber hinaus sind ausführbare Dateien für Windows verfügbar. Das Tool steht unter der GNU General Public License zur Verfügung. Als drittes Tool zur Generierung von Dokumentationen aus dem Quellcode erwähnen wir noch Natural Docs [8]. Es kann aus dem Quelltext unterschiedlicher Programmiersprachen automatisch eine HTML-basierte Dokumentation generieren.

Wo und in welchem Format sollte man eine Softwareentwicklungsdokumentation publizieren? Die genannten Tools zur Verarbeitung von Quelltextkommentaren erzeugen als Standardformat meist HTML. Eine webbasierte Dokumentation ist dabei heute üblich und auch oft praktisch. Organisiert in Form eines Wikis ist die Bearbeitung der Dokumentation einfach und auch die Pflege jederzeit durch alle Beteiligten möglich. Ein solches Wiki kann man auf einem privaten Bereich des Servers hosten, der aber von überall zugänglich ist; es kann im unternehmensweiten Intranet abgelegt werden oder noch einfacher direkt im Quelltextrepository. Verwenden Sie beispielsweise GitHub zum Hosten Ihrer Versionsverwaltungsdateien, dann können Sie dort auch die Wiki-Funktion nutzen. Für öffentliche Projekte (public) steht diese Funktion sogar kostenfrei zur Verfügung. Der Vorteil dieser Variante ist, dass die Dokumentation direkt dort landet, wo sie am meisten benötigt wird – beim Quellcode. Alternativ kann man ein einfaches Wiki-System verwenden und es auf einen Webserver aufsetzen. Das Wiki kann entweder mit Hilfe von Text und einem rudimentären Editor zur Formatierung gefüllt werden. Oft geht es schneller und einfacher, wenn eine Auszeichnungssprache wie Markdown oder AsciiDoc (Kasten: „Markdown und AsciiDoc“) verwendet wird, um mit einer simplen Syntax validen HTML-Code zu generieren.

Umfassende Entwicklungsprojekte weisen eine komplexe Struktur auf, in der sich die Quelltextdateien der einzelnen Komponenten verbergen. Eine Dokumentation könnte dem Aufbau folgen und diesen entsprechend spiegeln. Das sollte nach Möglichkeit automatisch geschehen und idealerweise in den Build-Prozess eingebunden werden. Das Ziel ist es, die Inhalte der Dokumentation, vorliegend als Markdown-Dateien, auf der Basis dieser Struktur zusammenzufassen. Das kann man mit Hilfe eines statischen Seitengenerators erledigen. Ein solches Tool ist JBake [9]. Der Verarbeitungsprozess ist in Abbildung 3 dargestellt.

Abb. 3: Automatische Hilfestruktur mit einem Static-Site-Generator erstellen

Mit diesen Tools haben wir schon einen gut gefüllten Werkzeugkasten, um unmittelbar aus dem Quellcode eine vernünftige Entwicklerdokumentation zu erstellen.

Weitere Tools

Der Dokumentationsprozess endet nicht bei der Entwicklerdokumentation. Der Übergang zur Produktdokumentation ist fließend. Diese Dokumentationen müssen auch in Fragen der Gestaltung, Sprache usw. an die Zielgruppe angepasst werden. Dafür verwendet man dann weitere Tools. Neben den klassischen Office-Programmen, wie der Textverarbeitung, können auch Satz- und Layoutprogramme wie Adobe FrameMarker zum Einsatz kommen. Um den Prozess der Textstrukturierung zu vereinfachen, kann man automatische Satzsysteme wie LaTeX verwenden. Es gibt auch Spezialprogramme für technische Dokumentationen. Ein sehr umfassendes Softwaretool ist RoboHelp von Adobe [10]. Es handelt sich um ein umfassendes Authoring-Werkzeug für Hilfesysteme, Richtlinien und Wissensdatenbanken. Inhalte können aus den unterschiedlichsten Quellen übernommen werden. Die Ausgabe der Dokumentation kann in diversen Formaten erfolgen, u. a. auch in responsivem HTML5.

Fazit

Eine aktuelle und aussagekräftige Entwicklungsdokumentation ist notwendig, wenn ein Softwaresystem eine gewisse Größe und Komplexität erreicht hat. Der Aufwand dafür wird häufig gescheut und die Ressourcen sind meist nicht wirklich eingeplant. Es ist aber nicht sinnvoll, die Dokumentation zu vernachlässigen. Da Software meist über längere Zeiträume gewartet wird, zahlt sich eine vernünftige Dokumentation i. d. R. schnell aus. Voraussetzungen sind ein geplantes Vorgehen, eine Struktur und Festlegungen darüber, welche Elemente in welchem Detailgrad beschrieben werden.

Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://larinet.com. Folgen Sie uns auch auf Instagram unter www.instagram.com/larinetcommunication