Quanto disegno accade nella vostra fase di attuazione?

Question

Per quelli di voi che lavorano nel big-disegno-up-front / cascata gruppi: quanto il pensiero critico e la progettazione viene saltato nella fase di progettazione e sinistra per la fase di implementazione? Come completi e dettagliati sono le vostre specifiche funzionali e tecniche consegnati al termine della fase di progettazione?

Mi sembra che ci sia un sacco di spazio per l'interpretazione del livello di dettaglio che deve essere fornita al termine della fase di progettazione, e la cosa mi infastidisce quando la fase di progettazione è affrettata e poi manager si arrabbiano che il fase di costruzione non progredisce come se stessimo a sfornare i widget su una catena di montaggio. D'altra parte, una fase di progettazione che è abbastanza completa per rendere la fase di costruzione operare come una catena di montaggio include praticamente la fase di realizzazione con esso - tutto ciò che sarebbe rimasto in "costruzione" è quello di digitare roba nell'editor. Naturalmente, ciò significa anche la vostra fase di progettazione è gigantesco.

Mi rendo conto che questa è una lacuna del modello a cascata , ma se c'è qualcuno là fuori che può fornire qualche consigli costruttivi: Dove si disegna la linea? Quali dovrebbero essere le aspettative per le fasi di progettazione e di build essere, e quali tipi di difetti di progettazione o errori dovrebbero / non dovrebbero essere tollerati nella fase di costruzione?

Answer 1

Sono un grande fan di prototipazione rapida, rapida Incremento, e la rapida iterazione. evoluzione piuttosto che "disegno intelligente". si scrive software per risolvere i problemi per le persone e le persone tendono a cambiare le loro menti e le esigenze nel corso del tempo, anche brevi periodi di tempo.

E 'bello ottenere i requisiti, una vista a volo d'uccello, e "firmare", come quadrato-lontano possibile prima di codifica, ma non ha molto senso essere dogmatici, è tutto fluido. essere pronti a modificare, emendare, e buttare via il codice, come si va. la cosa divertente è che si non arriva ad un punto di completamento in ogni caso ... la maggior parte del codice sembra cambiare mentre le persone si preoccupano di esso, e poi una volta nessuno si preoccupa, appena viene eliminato.

ora per essere certi che non si applica a pezzi must-lavoro-la-prima volta di software come i sistemi di controllo aereo, controlli dei reattori nucleari, ecc, ma la mia ipotesi è che non è il tuo caso.

Answer 2

C'è sempre qualcosa perso in fase di progettazione. Le persone sono imperfetti, e anche con una gestione perfetta che permette un sacco di tempo fase di progettazione, senza la pressione di passare alla realizzazione, ci saranno cose che hai perso.

Allo stesso modo, nel design, si entra in un punto dei rendimenti decrescenti. Ad esempio, se la progettazione di un'interfaccia utente e la scrittura che in una specifica, si può rapidamente raggiungere il punto in cui la specifica contiene il layout, formattazione e tutta la logica di una forma. Nel qual caso la sua praticamente identica alla realizzazione, con forse solo i bit disordinato di colla codice essere diversi.

Si ha bisogno di interrogare il valore di spingere il disegno troppo: quando si trasforma. Progettuali nella scrittura del codice, perché questo è il modo più chiaro per trasmettere il vostro intento, il suo tempo di chiedere se è troppo è troppo

Implementazione, poi, inizierà a cose Scoprire dimenticate o perse, così come altri dettagli di implementazione che potevano sembrare facile, ma perché non risultano essere. (Forse i servizi che ho pensato che potrebbe ottenere da qualche libreria, o il vostro sistema operativo, risultano essere non del tutto come previsto ... e avete bisogno di fare un po 'di scavo o di scrivere un sacco di nuovo codice come un work-around, shim o patch.)

Cascata è un modello semplice incantevole, ottimo per spiegare alla gestione. E 'anche abbastanza lontana dalla iterativo e mescolato ad alto livello / basso pensiero livello che accade nella realtà.

---

Un po 'commento più interessante di questo può essere trovato in un vecchio libro:. "Declino e la caduta del programmatore americano" da Ed Yourdon

So che questa non è una risposta perfetta, ma poi, di programmazione e di progettazione di metodologie non sono macchine perfette. L'approccio migliore per loro è di trattarli come un sistema utile per ottenere le cose fatte. Le regole sono lì per aiutarti, e per essere rotti quando ottengono nel senso. La rottura delle regole dovrebbe essere fatto in modo intelligente, non solo perché qualcuno si sentiva come tagliare il codice dal giorno 1.