Welche wesentlichen Designartefakte produzieren Sie?[geschlossen]

Question

Welche wesentlichen Designartefakte produzieren Sie im Laufe Ihres Softwareentwicklungslebenszyklus?Was macht sie für Ihre Praxis unverzichtbar?

Das Projekt, an dem ich gerade arbeite, ist seit mehr als 8 Jahren in Produktion.Diese Webanwendung wurde im Laufe der Zeit aktiv weiterentwickelt und gepflegt.Obwohl wir über CMMI-basierte Richtlinien und Prozesse verfügen und Teile unserer Praxis klar definiert sind, wurde die Entwurfsphase weitgehend übersehen.Best Practices, jemand?

Answer 1

Nachdem ich in der Vergangenheit an vielen Wasserfallprojekten und in jüngerer Zeit an vielen Ad-hoc- und agilen Projekten gearbeitet habe, gibt es eine Reihe von Designartefakten, die ich gerne erstelle, obwohl ich nicht oft genug betonen kann, dass es wirklich auf die Details des Projekts ankommt ( Methodik/Teamstruktur/Zeitplan/Tools usw.).

Für eine generische, serverbasierte „Unternehmensanwendung“ würde ich mir als absolutes Minimum etwas in dieser Richtung wünschen:

• Ein detailliertes funktionales Designdokument (auch bekannt als Spezifikation).Im Allgemeinen etwas in der Art von Joels‘ WhatsTimeIsIt-Beispielspezifikation, allerdings wahrscheinlich mit einigen UML-Anwendungsfalldiagrammen.
• Ein technisches Software-Designdokument.Nicht unbedingt detailliert, um eine 100-prozentige Systemabdeckung zu gewährleisten, aber detailliert in allen Schlüsselbereichen und mit allen Designentscheidungen.Da ich ein kleiner UML-Freak bin, wäre es schön, viele Bilder im Sinne von Paketdiagrammen, Komponentendiagrammen, Diagrammen wichtiger Feature-Classes und wahrscheinlich auch ein paar Sequenzdiagrammen zu sehen.
• Ein Infrastrukturentwurfsdokument.Wahrscheinlich mit einem UML-Bereitstellungsdiagramm für den konzeptionellen Entwurf und vielleicht einem Netzwerkdiagramm für etwas Physischeres.

Wenn ich „Dokument“ sage, kann eines der oben genannten Dokumente in mehrere Dokumente unterteilt oder möglicherweise in einem Wiki/einem anderen Tool gespeichert sein.

Was ihren Nutzen angeht, war meine Philosophie immer, dass ein Entwicklungsteam immer in der Lage sein sollte, eine Anwendung an ein Support-Team zu übergeben, ohne seine Telefonnummern preisgeben zu müssen.Wenn die Designartefakte nicht eindeutig angeben, was die Anwendung tut, wie sie es tut und wo sie es tut, dann wissen Sie, dass das Support-Team der App die gleiche Sorgfalt und Aufmerksamkeit schenken wird, die sie einem tollwütigen Hund widmen würden.

Ich sollte erwähnen, dass ich die Praxis, Software einmal von einem Entwicklungsteam an ein Supportteam zu übergeben, nicht befürworte fertig, was alle möglichen interessanten Fragen aufwirft. Ich sage nur, dass es möglich sein sollte, wenn das Management dies wünscht.

Answer 2

Arbeitscode ... und Whiteboard-Zeichnungen.

:P

Answer 3

Designs ändern sich während der Entwicklung und danach so stark, dass die meisten meiner sorgfältig erstellten Dokumente in der Quellcodeverwaltung verrotten und fast eher zu einem Hindernis als zu einer Hilfe werden, sobald der Code in Produktion ist.Ich halte Designdokumente für notwendig, um eine gute Kommunikation zu gewährleisten und Ihre Gedanken zu klären, während Sie etwas entwickeln, aber danach ist es eine gewaltige Anstrengung, sie ordnungsgemäß zu pflegen.

Ich mache Fotos von Whiteboards und speichere die JPEGs in der Quellcodeverwaltung.Das sind einige meiner besten Designdokumente!

Answer 4

In unserem Modell (das ziemlich spezifisch für Geschäftsprozessanwendungen ist) umfassen die Designartefakte:

• ein Domänendatenmodell mit Kommentaren zu jeder Entität und jedem Attribut
• eine Eigenschaftendatei, die alle Änderungs- und Erstellungsauslöser für jede Entität, berechnete Attribute, Validatoren und andere Geschäftslogik auflistet
• eine Reihe von Bildschirmdefinitionen (Ansichtsmodell)

Aber zählen diese wirklich zu den Designartefakten?Unser Framework ist so ausgelegt, dass diese Definitionen zur Generierung des eigentlichen Codes des Systems verwendet werden, sodass sie möglicherweise über das Design hinausgehen.

Aber die Tatsache, dass sie eine doppelte Aufgabe erfüllen, ist wirkungsvoll, da sie per Definition jederzeit auf dem neuesten Stand und mit dem Code synchronisiert sind.

Answer 5

Dies ist kein Designdokument an sich, sondern unser Unit-Tests dienen dem doppelten Zweck, zu „beschreiben“, wie der von ihnen getestete Code funktionieren soll.Das Schöne daran ist, dass sie nie veraltet sein, da unsere Unit-Tests bestanden werden müssen, damit unser Build erfolgreich ist.

Answer 6

Ich glaube nicht, dass irgendetwas eine gute, altmodische Designspezifikation ersetzen kann, und zwar aus folgenden Gründen:

• Es dient dazu, anderen mitzuteilen, wie Sie eine Anwendung erstellen werden.
• Damit können Sie Ideen aus Ihrem Kopf herausholen, sodass Sie sich keine Sorgen darüber machen müssen, eine Million Dinge gleichzeitig zu verfolgen.
• Wenn Sie ein Projekt pausieren und später darauf zurückgreifen müssen, beginnen Sie Ihren Denkprozess nicht noch einmal von vorne.

Ich möchte in einer Designspezifikation verschiedene Informationen sehen:

• Allgemeine Erläuterung Ihrer Herangehensweise an die vorliegende Herausforderung
• Wie überwachen Sie Ihre Bewerbung?
• Welche Sicherheitsbedenken gibt es und wie wird ihnen begegnet?
• Flussdiagramme / Sequenzdiagramme
• Offene Punkte
• Bekannte Einschränkungen

Unit-Tests sind zwar ein fantastisches und wohl wichtiges Element, das Sie in Ihre Anwendungsentwicklung einbeziehen sollten, decken jedoch nicht alle dieser Themen ab.