Shortcuts - Softwaredesigndokumente - Sinnvoller Einsatz im Projektalltag


Preis: k.A.

Erhältlich ab:  November 2013

Autoren / Autorinnen: Shortcut Autorenteam

1.1 Ziel des Buchs

Software Design Descriptions/Documents (SDD) [1] sind für die erfolgreiche Entwicklung und Wartung von Software unentbehrlich. Wirklich?

Die Designdokumentation beschreibt das Softwaredesign aus technischer Sicht und bildet die Schnittstelle zwischen den Anforderungen an die Software und deren Realisierung in Form von Quelltext. Und landet dann, einmal gelesen, in der Schublade?

Wer oder was hat eigentlich Einfluss auf den Sinn und Einsatz der Designbeschreibungen im Projekt? Und was ist zu beachten, damit sie nicht schon während des Projekts zum Papiertiger werden und einen Nutzen darstellen können?

Selbst gut strukturierte und archivierte SDDs werden langfristig oft zu einer Bürde, wenn sie aus dem Fokus geraten und nicht aktiv mit ihnen gearbeitet wird. Sie verlieren ihre Aktualität und Relevanz – wenn diese überhaupt jemals gegeben war – und damit die Motivation, sie zu nutzen oder sie sogar zu pflegen. Ein kleiner Teufelskreis entsteht, der die Degeneration der Dokumentation schließlich forciert.

In diesem Buch möchte ich Ihnen daher nicht Schritt für Schritt erläutern, wie ein Softwaredesign und dessen Dokumentation erstellt werden. Vielmehr möchte ich Ihnen einen Überblick geben, welche Position ein SDD in einem Softwareentwicklungsprojekt einnehmen kann, welchen Einflüssen es im Laufe seines Lebens ausgesetzt seien wird, und Ihnen Anregungen geben, wie sich der Alltag im Projekt mit dem SDD gestalten lässt.

1.2 Softwaredesignprozess

Der Begriff Design umfasst als Ausdruck einer Tätigkeit, je nach Auffassung, sowohl ein kreatives Vorgehen und Gestalten als auch ein technisch exaktes Spezifizieren. Während der Erstellung eines Softwaredesigns wird dabei versucht, abstrakte Anforderungen an eine Software in ein Konzept zu übersetzen, das als Plan zur technischen Umsetzung der Anforderungen dienen kann.

Dieser Plan, das Design (der Begriff Design soll im Folgenden auch architektonische Aspekte beinhalten), kann beispielsweise als „Big Design Up Front“ komplett vor der Implementierung spezifiziert werden oder im Gegensatz dazu erst während der Entwicklung agil [2] entstehen.

Je nach persönlichen Vorlieben und Interessen eines Softwareentwicklers wird der Prozess des Designens während der Softwareentwicklung zuweilen eher als kreativ und dankbar empfunden oder auch schon mal als lästiger und unnützer Aufwand vor der Kodierung verschmäht. Insbesondere unter dem im Projektalltag nicht seltenen Zeitdruck besteht, neben den persönlichen Präferenzen während der Ausarbeitung des Designs und der Niederschrift der Dokumentation, ein ständig abzuwägender Trade-off (Abb. 1.1) zwischen: „Ist alles Wichtige berücksichtigt und ausreichend notiert?“ und „Liegt man noch im Zeitplan und kann man sich überhaupt um das Design und dessen Dokumentation bemühen?“.

Einerseits besteht die Gefahr, dass ein Stück Software zu Over-Engineered und Gold-Plating betrieben wird. Die Anwendung wird technisch komplexer als nötig, kann sogar mehr als sie soll. Andererseits ist ein Schnellstart hin zur Entwicklung der Software ebenso wenig hilfreich, da eventuell technisch elementare Bedingungen nicht berücksichtigt wurden und Anforderungen später nicht realisierbar sind.

Das Vorgehensmodell sowie die Stakeholder geben neben den Anforderungen an die Software dabei einen Rahmen und Bedingungen vor, die den Designprozess sowie die Ausprägung und Wartung des SDD maßgeblich beeinflussen.

Abbildung1_1.png

Abbildung 1.1: Trade-off zwischen Schnellstart und Gold-Plating: Was ist zu wenig, was ist zu viel designt und dokumentiert?

1.3 Dokumentation

Die Dokumentation bzw. ein Dokument dient der Vermittlung von Information und Wissen zwischen Menschen. Softwaredesigndokumente beinhalten im Speziellen das Wissen über eine abstrakte Lösung zum Aufbau eines Stücks Software. Die darin dargestellte Information ist allerdings nur einer sehr kleinen Leserschaft zugänglich – da Wissen aus dem Bereich der Softwareentwicklung noch nicht zum Allgemeinwissen gehört, technisch komplex ist und eine eigene Sprache besitzt.

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang