Softwareentwicklung Dokumentation

Dokumentation zur Softwareentwicklung

Dokumentationen im Softwareentwicklungsprozess Für die Dokumentation im Softwareentwicklungsprozess gibt es sehr viele konträre Ideen. Überall (auch bei "leichten" "agilen" Prozessen) wird die Bedeutung einzelner Belege hervorgehoben. Doch im Gegensatz zu anderen Ingenieurswissenschaften gibt es in der Softwareentwicklung noch keinen Konsens darüber, welche Dokumententypen, in welchem Umfang und in welcher Struktur zumindest erforderlich sind für ein gelungenes und dauerhaft wartungsfähiges?

Dabei haben die unterschiedlichen Prozess- und Prozessmodelle für die Softwareentwicklung verschiedene Schwerpunktsetzungen und bezeichnen zum Teil über 100 zu erstellenden Dokumententypen (die durch "Tailoring" zu eingeschränkt werden können). Im Bereich des Projekt-Engineerings, des Software-Engineerings und der Software-Architekturen wird heute meist eine Dokumentation über das, was wirklich nötig ist, unter beschränken verlangt, aber dennoch wird betonten, dass eine bestimmte Dokumentation unabdingbar ist.

Nachfolgend finden Sie einige Erläuterungen und Verweise auf die als wesentlich erachtete Dokumentation aufgeführt. Die beiden Künstler Jochen Ludewig und Horst Lichter fordern in ihrem Werk folgende Punkte: Die Dokumentation ist sehr wertvoll für Gute Softwarequalität und wartungsfreundlich und muss hoch geschätzt und gewürdigt werden. Die Dokumentation ist als permanente Aufgabe zu verstehen und darf nicht am Ende der Codierung durchgeführt werden.

In den Dokumenten und Zuständigkeiten müssen müssen die Voraussetzungen eindeutig sein. Der Speicherort und die Struktur der Unterlagen müssen müssen festgelegt und vereinheitlicht sein. Den Dokumenten müssen geprüft und einem Konfigurationsmanagement kann untergeordnet werden. Dabei sind die Dokumentkategorien in vier Taxonomiekategorien unterteilt: Unterlagen zum Beispiel über den Entwicklungsprozess: Für zum Beispiel die für die Planung und Instandhaltung erforderlichen Dokumente:

Unterlagen z.B. auf der Website Qualitätssicherung Für Gewisse Dokumententypen werden zur Einhaltung von Normen wie z. B. IEEE Std 830 ("Recommended Practice for Silicon Requirements Specifications") aufbereitet. In seinem Werk erwähnt Hermann Mayr folgende Dokumentationsziele: "Laut Mayr ist die Zahl der mit einem agilen Ansatz erstellten Belege nicht signifikant niedriger als mit einem traditionellen Ansatz.

Mit dem agile Ansatz werden jedoch viele Belege unter werkzeugunterstützt oder gar automatisiert generier. Die folgenden Unterlagen werden von Mayr als wesentlich für traditionelle und agile Verfahren bezeichnet (gekürzt): Die Anlagendokumentation enthält die folgenden Komponenten: Allerdings sieht er in bestimmten Dokumentationsformen eine wesentliche Aufgabenstellung des Software-Architekten. Stark schätzt die Ausgabe für die Anordnung der Komponentenansicht am höchsten bei 60 bis 80% der Zeit für die Architekturansichten zusammen.

Adam Bien bezeichnet in seinem Werk zwei Dokumententypen als das wichtigste architektonische Ergebnis: Konkretes Projekt: Abweichung vom MAD, Sichtweise, Interessengruppen, Komponenten, Interfaces, Einsatz, Testkonzept, Bedienung, Überwachung, Fehlerbehandlung, Designentscheidungen und Definition. In seinem Werk misst Johannes Siegersleben den Interfaces und Bausteinen besondere Bedeutung bei. Bei einem Architektur-Review stellt sich zunächst die Frage: Aus welchen Bestandteilen setzt sich das Gesamtsystem zusammen?

Bauteile modellieren das gesamte System sinnvoll zu überschaubare Gerätesegmenten, haben in ihrer Funktion Stabilität und präzise Schnittstellen und können individuell getestet (oder einzeln versioniert und ausgetauscht) werden. Bezüglich Software-Architekturdokumentation verlangt von Siedersleben a für alle Projektbeteiligten einfach verfügbares Übersichtsbild verfügbares Software-Architekturdokumentation verlangt von Siedersleben a vollständig dokumentiertes Interface und definierte Ausnahmenbehandlung. Eine wichtige Qualitätsmerkmal einer funktionierenden Software-Architektur ist ihre Bauteilstruktur mit größerem Kohäsion innerhalb der Bauteile, wenig Abhängigkeiten zu anderen Bauteilen und Zyklusfreiheit.

Die Software gehört zu den agile Prozessmodellen des Softwareentwicklungsprozesses. Möglicherweise benötigt Sergeant RUP und V-Modell weniger Dokumentation als herkömmliche Prozessmodelle, aber für hat einen flexiblen Produktionsprozess, der eine überraschende Menge an Dokumentation erfordert. In seinem Werk mit dem Titel Sebastian - Successfully Using Agile Project Management stellt Roman G. C. Pichler die folgende Dokumentation vor: Der Boris Gloger schildert in seinem Werk Ecrum - Products zuverlässig und entwickelt rasch die folgenden Ergebnis-Artefakte und Dokumentationen:

Unter sw-dev-process. htm#RUP oder sw-dev-process. htm#V-Modell. htm#V-Modell sind einige wesentliche Unterlagen aufgeführt, die mit dem RUP oder V-Modell XT zu erstellen sind. Zahlreiche Anregungen für Software und Architekturdokumentationen gibt es bei Stefan Zörner: Kurzvortrag: Small 1 x 1 der Architektendokumentation. Gerade in der Anfangsphase eines Softwareprojektes wird oft ein "Profil" des Projektes angelegt.

Im Vorfeld sollte er wesentliche Punkte, die das Vorhaben kennzeichnen, in einem einzelnen Text zusammengefasst haben. Nachfolgend sind mögliche Keywords für ein Projektprofil aufgeführt. Diese können nur als Beispiel herangezogen werden und müssen für für können spezifische Vorhaben durch geeignetere abgelöst werden. Von wem stammt die Software-Architektur, führt die technologische Umsetzung durch und erfasst alles?

Rubel oder Kanal? If Scrum: Wer ist Produktverantwortlicher und wer ist es? Interfaces und Abhängigkeiten Textschnittstellen zu anderen Programmen, anderen Fachbereichen und Fremdpartnern. Die technischen Interfaces zu anderen Anlagen.

Mehr zum Thema