Quali artefatti di design essenziali produci?[Chiuso]

Question

Nel corso del ciclo di vita dello sviluppo del software, quali artefatti di progettazione essenziali produci?Cosa li rende essenziali per la tua pratica?

Il progetto a cui sto attualmente lavorando è in produzione da più di 8 anni.Questa applicazione web è stata attivamente migliorata e mantenuta nel corso del tempo.Sebbene disponiamo di politiche e processi basati su CMMI, con parti della nostra pratica ben definite, la fase di progettazione è stata ampiamente trascurata.Le migliori pratiche, qualcuno?

Answer 1

Avendo lavorato su molti progetti a cascata in passato e su molti progetti ad hoc e agili più recentemente, ci sono una serie di artefatti di progettazione che mi piace creare anche se non posso affermare abbastanza che dipenda davvero dai dettagli del progetto ( metodologia/struttura del team/tempistica/strumenti, ecc.).

Per una "applicazione aziendale" generica basata su server vorrei che il minimo indispensabile fosse qualcosa del genere:

• Un documento di progettazione funzionale dettagliato (aka spec).Generalmente qualcosa sulla falsariga di Joel s' Specifica di esempio di WhatsTimeIsIt, anche se probabilmente con alcuni diagrammi dei casi d'uso UML.
• Un documento di progettazione tecnica del software.Non necessariamente dettagliato per una copertura del sistema al 100%, ma dettagliato in tutte le aree chiave e contenente tutte le decisioni di progettazione.Essendo un po' un fanatico di UML, sarebbe bello vedere molte immagini sulla falsariga di diagrammi di pacchetto, diagrammi di componenti, diagrammi di classi di funzionalità chiave e probabilmente alcuni diagrammi di sequenza inseriti per buona misura.
• Un documento di progettazione dell'infrastruttura.Probabilmente con un diagramma di distribuzione UML per la progettazione concettuale e forse un diagramma di rete per qualcosa di più fisico.

Quando dico documento, tutto quanto sopra potrebbe essere suddiviso in più documenti o magari archiviato su un wiki/qualche altro strumento.

Per quanto riguarda la loro utilità, la mia filosofia è sempre stata che un team di sviluppo dovrebbe sempre essere in grado di consegnare un'applicazione a un team di supporto senza dover fornire i propri numeri di telefono.Se gli elementi di progettazione non indicano chiaramente cosa fa l'applicazione, come lo fa e dove lo fa, allora sai che il team di supporto presterà all'app la stessa cura e attenzione che darebbe a un cane rabbioso.

Dovrei menzionare che non sto rivendicando la pratica di consegnare il software da un team di sviluppo a un team di supporto una volta che è finito, che solleva tutta una serie di questioni interessanti, dico solo che dovrebbe essere possibile se la direzione lo desiderasse.

Answer 2

Codice funzionante... e disegni su lavagna.

:P

Answer 3

I progetti cambiano così tanto durante lo sviluppo e successivamente che la maggior parte dei miei documenti accuratamente realizzati marciscono nel controllo del codice sorgente e diventano quasi più un ostacolo che un aiuto, una volta che il codice è in produzione.Considero i documenti di progettazione necessari per una buona comunicazione e per chiarire il tuo pensiero mentre sviluppi qualcosa, ma dopo ciò ci vuole uno sforzo erculeo per mantenerli adeguatamente mantenuti.

Scatto foto di lavagne e salvo i JPEG nel controllo del codice sorgente.Questi sono alcuni dei miei migliori documenti di progettazione!

Answer 4

Nel nostro modello (che è abbastanza specifico per le applicazioni dei processi aziendali) gli artefatti di progettazione includono:

• un modello di dati di dominio, con commenti su ciascuna entità e attributo
• un file delle proprietà che elenca tutti i trigger di modifica e creazione su ciascuna entità, attributi calcolati, validatori e altra logica aziendale
• una serie di definizioni dello schermo (visualizza modello)

Ma questi contano davvero come artefatti di design?La nostra struttura è tale che queste definizioni vengono utilizzate per generare il codice effettivo del sistema, quindi forse vanno oltre la progettazione.

Ma il fatto che svolgano il doppio compito è potente perché sono, per definizione, aggiornati e sincronizzati con il codice in ogni momento.

Answer 5

Questo non è un documento di progettazione, di per sé, ma il nostro test unitari hanno il duplice scopo di "descrivere" come dovrebbe funzionare il codice che testano.La parte bella di questo è che loro non diventare mai obsoleto, poiché i nostri test unitari devono superare affinché la nostra build abbia successo.

Answer 6

Non penso che nulla possa sostituire le buone specifiche di progettazione vecchio stile per i seguenti motivi:

• Serve come mezzo per comunicare agli altri come costruirai un'applicazione.
• Ti consente di toglierti le idee dalla testa in modo da non preoccuparti di tenere traccia di un milione di cose contemporaneamente.
• Se devi mettere in pausa un progetto e riprenderlo in un secondo momento, non stai ricominciando il tuo processo di pensiero da capo.

Mi piace vedere varie informazioni in una specifica di progettazione:

• Spiegazione generale del tuo approccio alla sfida in questione
• Come monitorerai la tua candidatura?
• Quali sono i problemi di sicurezza e come vengono affrontati?
• Diagrammi di flusso/diagrammi di sequenza
• Questioni aperte
• Limitazioni note

I test unitari, sebbene siano un elemento fantastico e probabilmente fondamentale da includere nello sviluppo dell'applicazione, non coprono tutti questi argomenti.