Wie viel Design geschieht in Ihrer Implementierungsphase?

Question

Für diejenigen unter Ihnen, die in Gruppen mit großem Design/Wasserfall arbeiten: Wie viel kritisches Denken und Design werden in Ihrer Designphase übersprungen und Ihrer Implementierungsphase überlassen? Wie vollständig und detailliert sind Ihre funktionalen und technischen Spezifikationen am Ende der Entwurfsphase?

Es scheint mir, dass es viel Raum für Interpretation in der Detailebene gibt, die am Ende der Designphase bereitgestellt werden muss, und es ärgert mich, wenn die Designphase gehetzt wird und dann die Manager wütend werden, dass die Bauphase nicht Es Fortschritte, wie wir Widgets auf einer Montagelinie auswirken. Andererseits enthält eine Entwurfsphase, die vollständig genug ist, um die Build -Phase wie eine Montagelinie zu betreiben, praktisch die Implementierungsphase - alles, was in "Build" übrig bleibt, ist, Dinge in den Editor einzugeben. Natürlich bedeutet dies auch, dass Ihre Designphase gigantisch ist.

Mir ist klar, dass dies ein Mangel des Wasserfallmodells ist, Aber wenn da draußen jemanden gibt, der konstruktive Ratschläge geben kann: Wo zieht man die Grenze? Was sollten die Erwartungen an Design- und Bauphasen sein und welche Arten von Design -Mängel oder -fehlern sollten/sollten in der Bauphase nicht toleriert werden?

Answer 1

Ich bin ein großer Fan von schnellem Prototyping, schneller Inkrementierung und schneller Iteration. Evolution eher als "intelligentes Design". Sie schreiben Software, um Probleme für Menschen zu lösen, und Menschen neigen dazu, ihre Meinung und ihre Bedürfnisse im Laufe der Zeit, selbst kurze Zeiträume zu ändern.

Es ist schön, Anforderungen, eine Vogelperspektive zu erhalten und vor dem Codieren so quadratisch wie möglich abzuschriften, aber es ist kaum Punkt, dogmatisch zu sein, alles flüssig. Seien Sie bereit, den Code zu bearbeiten, zu ändern und wegzuwerfen, während Sie gehen. Das Lustige ist, dass Sie sowieso nie zu einem Fertigstellungspunkt ankommen ... die meisten Code scheint sich zu ändern, während sich die Leute darum kümmern, und wenn sich dann niemand darum kümmert, wird es nur gelöscht.

Um sicher zu sein, dass dies nicht für die Zeit mit dem Ersten Zeit von Software wie Flugzeugsteuerungssystemen, Kernreaktorkontrollen usw. gilt, aber ich vermute, dass dies nicht Ihr Fall ist.

Answer 2

In der Designphase fehlt immer etwas. Die Menschen sind unvollkommen, und selbst mit einem perfekten Management, das viel Entwurfsphase ohne den Druck zur Implementierung ermöglicht, wird es Dinge geben, die Sie verpasst haben.

Ebenso betreten Sie im Design einen Punkt der Rückgänge. Wenn Sie beispielsweise eine Benutzeroberfläche entwerfen und diese in einer Spezifikation schreiben, können Sie schnell den Punkt erreichen, an dem die Spezifikation das Layout, die Formatierung und die gesamte Logik eines Formulars enthält. In diesem Fall ist es ziemlich identisch mit der Implementierung, wobei möglicherweise nur die chaotischen Codekleber unterschiedlich sind.

Sie müssen den Wert des Drückens des Designs zu weit abfragen: Wenn das Design zum Schreiben des Codes wird, da dies der klarste Weg ist, um Ihre Absicht zu vermitteln, ist es an der Zeit zu fragen, ob genug genug ist.

Die Implementierung wird also beginnen, Dinge zu entdecken, die vergessen oder verpasst wurden, sowie andere Implementierungsdetails, die möglicherweise einfach zu sein schienen, sich aber nicht als nicht herausstellen. (Vielleicht haben sich die Dienste, von denen Sie dachten, Sie könnten aus einer Bibliothek oder Ihrem Betriebssystem erhalten, als nicht ganz wie erwartet herausgestellt ... und Sie müssen etwas graben oder viel neuer Code als Arbeit schreiben, Shim oder Patch.)

Wasserfall ist ein schönes einfaches Modell, das sich gut zum Management erklärt. Es ist auch ziemlich weit entfernt von dem iterativen und gemischten hochrangigen und niedrigen Wert, der in der Realität passiert.

---

Ein etwas interessanterer Kommentar dazu finden Sie in einem älteren Buch: "Niederlassung und Fall des amerikanischen Programmierers" von Ed Yourdon.

Ich weiß, dass dies keine perfekte Antwort ist, aber dann sind Programmier- und Designmethoden auch nicht perfekt. Der beste Ansatz für sie ist es, sie als ein hilfreiches System zu behandeln, um Dinge zu erledigen. Die Regeln sind da, um Ihnen zu helfen und kaputt zu werden, wenn sie im Weg stehen. Das Brechen der Regeln sollte intelligent erfolgen, nicht nur, weil jemand nach Tag 1 den Code schneiden wollte.