Kann die Erstellung eines Software-Design-Dokuments nach der Entwicklung gerechtfertigt sein?

Derzeit arbeite ich an meinem Abschluss für mein "Software Development" -Studium, in dem ich komplexe Software individuell in einem externen Unternehmen entwickeln muss. Dies alles muss strukturiert erfolgen und alle entsprechenden Dokumente erstellen.

Für dieses Projekt habe ich mich entschieden, mit den IEEE-Standarddokumenten zu arbeiten: Software Requirements Document (SRS), Software Architecture Documents (SAD) und Software Design Document (SDD). Obwohl in der Schule anders unterrichtet, habe ich mich für dieses Projekt entschieden, die SDD nach der Entwicklung (statt vorher) zu erstellen . Meine Argumentation ist:

Das Unternehmen, in dem ich mein Praktikum mache, hat mir die Anweisung gegeben, auf experimentelle Weise eine komplexe Software zu erstellen, die bestimmte Anforderungen erfüllt. Aufgrund der Freiheit, die sie mir in der Projektdefinition gegeben haben, ist im Voraus fast nichts sicher und kann am besten beim Experimentieren im Entwicklungsprozess angetroffen werden. Außerdem erstelle ich die Software auf individuelle Weise . Es hätte für niemanden im Unternehmen von Vorteil, wenn ich dieses Software-Design im Voraus erstellen würde. Wenn ich es vorher mache, kostet es mich nur viel Zeit, es später zu ändern, da ich sicher sein kann, dass angesichts der Unsicherheiten im Projekt das Design, das ich vorher mache, viel geändert werden muss . Das fühlt sich für mich kontraproduktiv an.

Ist dies eine gute Rechtfertigung, um die SDD nach der Entwicklung zu erstellen? Wenn nicht, gibt es dafür eine gute Rechtfertigung?

Bearbeiten: Der Grund, die SDD anschließend zu erstellen, besteht darin, dass zukünftige Entwickler das Projekt fortsetzen. Ich werde nicht in der Lage sein, das gesamte Projekt in meiner Abschlussphase abzuschließen, daher müssen andere Entwickler die aktuelle Codebasis beibehalten.

In IEEE Std 1016 Abschnitt 3.1 Software-Design im Kontext finden Sie diesen Absatz:

Eine SDD kann in einer Vielzahl von Entwurfssituationen erstellt und verwendet werden. In der Regel ist eine SDD bereit, die Entwicklung eines Softwareelements zur Lösung eines Problems zu unterstützen, wobei dieses Problem in Form einer Reihe von Anforderungen ausgedrückt wurde. Der Inhalt der SDD kann dann auf diese Anforderungen zurückgeführt werden. In anderen Fällen ist eine SDD bereit, ein vorhandenes System ohne Konstruktionsdokumentation zu verstehen. In solchen Fällen wird eine SDD so erstellt, dass interessierende Informationen erfasst, organisiert, präsentiert und an alle interessierten Parteien weitergegeben werden. Diese Informationen von Interesse können für die Planung, Analyse, Implementierung und Weiterentwicklung des Softwaresystems verwendet werden, indem wesentliche Designprobleme identifiziert und angegangen werden.

Die Autoren von IEEE Std 1016 erkennen an, dass eine SDD möglicherweise nicht im Voraus erstellt wird. Eine kann erstellt werden, nachdem das Softwaresystem vorhanden ist, um Informationen für interessierte Parteien zu erfassen.

Abschnitt 1.1 Umfang enthält auch einige interessante Informationen:

Dieser Standard schreibt keine spezifischen Methoden für Design, Konfigurationsmanagement oder Qualitätssicherung vor.

Im Zusammenhang mit diesen Fragen lauten die Schlüsselwörter "Konfigurationsmanagement". Das Konfigurationsmanagement gilt nicht nur für das zu erstellende Softwaresystem, sondern auch für die zugehörige Dokumentation.

In Ihrer persönlichen Situation und in vielen Situationen ist das Erstellen einer SDD im Voraus eine Verschwendung. Die Antwort von David Arno ist fast das, was ich für die richtige Antwort halten würde. Das wahre Design Ihres Softwaresystems ist der Code. Sie sind jedoch "SDD vor erstellen" oder "SDD nach erstellen" nicht Ihre einzigen Optionen. Sie haben eine dritte Option: Entwickeln Sie die SDD mit dem Softwaresystem.

Wenn Sie einem Standard wie IEEE Std 1016 folgen, müssen Sie eine SDD verwenden. Insbesondere definiert Abschnitt 4 dieses Standards den Inhalt, über den Sie verfügen. Beginnen Sie beim Durcharbeiten von Entwurfsentscheidungen mit dem Erstellen der verschiedenen Ansichtspunkte, Ansichten und Überlagerungen. Erfassen Sie beim Treffen von Entscheidungen die Entwurfsgründe für diese.

Auf diese Weise können interessierte Parteien die Entwicklung des Software-Designs verfolgen, ohne sich mit dem Code befassen zu müssen. Natürlich können Leute Kommentare oder Vorschläge haben. Wenn Sie die SDD aktualisieren, können sie Ihren Fortschritt verfolgen und frühzeitig Feedback zum Ansatz geben, das Sie dann sowohl in das Produkt als auch in die SDD integrieren können. Wenn Sie beim Verlassen des Projekts den Software-Code und die SDD synchronisieren, sollte jemand in der Lage sein, die Arbeit problemlos zu integrieren und aufzunehmen.

Wenn Sie von der SDD nur das Design mit anderen kommunizieren möchten, können Sie es nach der Entwicklung erstellen. Das einzige ist, es heißt dann Dokumentation.

Ich möchte jedoch darauf hinweisen, dass eine SDD auch einem anderen Zweck dienen kann. Es kann Ihnen auch helfen, über Design nachzudenken und sicherzustellen, dass Sie "schnell versagen". Dies ist eine gute Sache, insbesondere wenn viele Dinge im Voraus ungewiss sind, da Sie Ansätze verwerfen können, die während der gesamten Implementierung nicht frühzeitig funktionieren würden. Es kann auch verhindern, dass Sie sich zu früh auf technische Details konzentrieren, indem Sie nichts codieren, bis Sie das Design herausgefunden haben.

Ich würde Ihnen raten, zumindest vorher einen Versuch bei der SDD zu unternehmen. Wenn Sie auf Dinge stoßen, bei denen Sie sich nicht sicher sind, wie die Dinge funktionieren würden, können Sie kleine Prototypen der Probleme erstellen, die Sie lösen möchten. Auf diese Weise erhalten Sie Erfahrung bei der Lösung der spezifischen Probleme für Ihr Projekt, die langfristig der Qualität der vollständigen Lösung zugute kommen.

Das einzig wahre detaillierte Designdokument, das Sie erstellen, ist der Code. Es teilt dem Compiler genau mit, wie Ihre Anwendung erstellt werden soll. Daher kann Ihr Entwurf bis zu diesem letzten Build vor dem Versand nicht vollständig sein.

Alle anderen von Ihnen erstellten Designdokumente, z. B. eine SDD, müssen aktualisiert werden, nachdem Sie Ihr Design (Code) fertiggestellt haben. Daher gibt es einen zwingenden Grund, die SDD anschließend zu schreiben: Sie müssen sie nur einmal ausführen.

Der offensichtliche Gegenpol dazu ist: "Wie oft schreiben Sie wirklich eine SDD nach dem Ereignis"? Die App wird ausgeliefert, sodass Sie zu diesem Zeitpunkt wahrscheinlich keine Zeit mit Dokumentieren verbringen möchten. Dies gilt jedoch auch für die Aktualisierung eines vorhandenen. Was ist schlimmer, keine SDD oder eine SDD, die falsch ist und der nicht vertraut werden kann?

Es gibt jedoch zwei Gründe, es im Voraus zu schreiben. Erstens kann es eine obligatorische Anforderung an Sie sein, dies zu tun (nicht schön; aber es passiert). Zweitens kann das Erstellen eines solchen Dokuments Ihnen helfen, eine Gesamtstrategie für das Design zu formulieren. Dies kann jedoch genauso gut erreicht werden, indem Bilder auf informelle Weise gezeichnet, Notizen usw. gekritzelt werden. Und da es später neu geschrieben werden muss, bietet der "schnelle und schmutzige" Ansatz für diesen Vorab-Makro-Designprozess viele Vorteile.

Für mich wäre es keine gute Argumentation.

Wenn es wirklich nötig ist, würde ich mich mit einem starken Fokus auf die Prototypenentwicklung für ein besseres Verständnis einer unbekannten Problemdomäne aussprechen. Selbst in diesen Fällen wären einige Designelemente zuvor nützlich.

Es gibt sowieso einen Grund, dies im Vorfeld zu tun . Weil Sie dies tun, um zu lernen , wie Sie solche Dokumente schreiben. Wenn Sie diese Arbeit überspringen, weil sie hier möglicherweise nicht zu 100% benötigt wird, überspringen Sie Ihr Lernen.

Ein Kompromiss könnte darin bestehen, es während der Implementierung zu schreiben . Vor jeder Komponente / jedem Modul / Bildschirm oder jeder anderen Unterteilung Ihres Programms müssen Sie darüber nachdenken, wie Sie es erstellen möchten. Anschließend fügen Sie Ihre Entscheidungen Ihrem Designdokument hinzu und implementieren sie.

Wenn sich später etwas ändert, aktualisieren Sie das Dokument.

Dies hat mehrere Vorteile gegenüber dem nachträglichen Schreiben:

• Sie werden lernen, Konstruktionsdokumente auf dem neuesten Stand zu halten, wenn sich Anforderungen ändern. Dies ist eine nützliche Angewohnheit

• Sie werden lernen, vor der Implementierung über Design nachzudenken

• Es ist nicht so nervenaufreibend langweilig wie das Schreiben von Designdokumenten nachträglich

• Wenn Ihnen die Zeit ausgeht, erhalten Sie ein Designdokument, in dem beschrieben wird, was Sie bisher haben, damit andere Ihre Arbeit fortsetzen können

• Auf diese Weise ist es nicht viel zusätzliche Arbeit

• Während Ihr Projekt weitergeht, sind Sie sich möglicherweise nicht ganz sicher, warum Sie vor zwei Monaten selbst so etwas getan haben, und Sie werden Ihre Notizen haben, die Sie Ihnen mitteilen können.

System Design Document, eine Aufzeichnung der grundlegenden Anforderungen sowie (neue Funktionen) Aktualisierungen, wenn das Projekt mit neuen Design- und Lösungsattributen fortschreitet. Wird beibehalten, bis das Projekt / die Lösung geliefert wurde. Nützlich, es kommuniziert mit allen Beteiligten.