Welche wesentlichen Design-Artefakte erstellen Sie im Laufe Ihres Softwareentwicklungszyklus? Was macht sie für Ihre Praxis so wichtig?
Das Projekt, an dem ich gerade arbeite, ist seit über 8 Jahren in Produktion. Diese Webanwendung wurde in dieser Zeit aktiv verbessert und gepflegt. Während wir über CMMI-basierte Richtlinien und Prozesse verfügen und Teile unserer Praxis gut definiert sind, wurde die Entwurfsphase weitgehend vernachlässigt. Kennt jemand bewährte Verfahren?
Da ich in der Vergangenheit an vielen Wasserfallprojekten und in letzter Zeit an vielen Ad-hoc- und agilen Projekten gearbeitet habe, gibt es eine Reihe von Design-Artefakten, die ich gerne erstelle, obwohl ich nicht oft genug betonen kann, dass dies wirklich von den Details des Projekts abhängt (Methodik/Teamstruktur/Zeitskala/Werkzeuge usw.).
Für eine allgemeine, serverbasierte "Unternehmensanwendung" würde ich mir ein Minimum in dieser Richtung wünschen:
Wenn ich von einem Dokument spreche, kann jedes der oben genannten Dokumente in mehrere Dokumente aufgeteilt oder vielleicht in einem Wiki oder einem anderen Tool gespeichert werden.
Was ihre Nützlichkeit angeht, so war es immer meine Philosophie, dass ein Entwicklungsteam in der Lage sein sollte, eine Anwendung an ein Supportteam zu übergeben, ohne seine Telefonnummern weitergeben zu müssen. Wenn aus den Design-Artefakten nicht klar hervorgeht, was die Anwendung tut, wie sie es tut und wo sie es tut, dann wissen Sie, dass das Support-Team der Anwendung die gleiche Sorgfalt und Aufmerksamkeit schenken wird wie einem tollwütigen Hund.
Ich sollte erwähnen, dass ich nicht die Praxis rechtfertige, Software von einem Entwicklerteam an ein Supportteam zu übergeben, sobald sie fertig ist. fertig Ich will damit nur sagen, dass es möglich sein sollte, wenn die Unternehmensleitung dies wünscht.
Die Entwürfe ändern sich während der Entwicklung und danach so stark, dass die meisten meiner sorgfältig erstellten Dokumente in der Versionsverwaltung verrotten und eher hinderlich als hilfreich sind, sobald der Code in Produktion ist. Ich betrachte Designdokumente als notwendig für eine gute Kommunikation und zur Klärung Ihrer Gedanken während der Entwicklung, aber danach ist es eine Herkulesaufgabe, sie richtig zu pflegen.
Ich mache Fotos von Whiteboards und speichere die JPEGs in der Versionsverwaltung. Das sind einige meiner besten Design-Dokumente!
In unserem Modell (das ziemlich spezifisch für Geschäftsprozessanwendungen ist) umfassen die Design-Artefakte:
Aber zählen diese wirklich als Design-Artefakte? Unser Rahmen ist so gestaltet, dass diese Definitionen verwendet werden, um den eigentlichen Code des Systems zu generieren, also gehen sie vielleicht über das Design hinaus.
Aber die Tatsache, dass sie eine doppelte Funktion haben, ist sehr wirkungsvoll, da sie per Definition immer auf dem neuesten Stand und mit dem Code synchronisiert sind.
Dies ist kein Entwurfsdokument im eigentlichen Sinne, sondern unser Einheitstests 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 bestehen müssen, damit unser Build erfolgreich ist.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
