È possibile giustificare la creazione di un documento di progettazione software dopo lo sviluppo?

In IEEE Std 1016 Sezione 3.1 Progettazione software nel contesto, puoi trovare questo paragrafo:

An SDD can be prepared and used in a variety of design situations. Typically, an SDD is prepared to support the development of a software item to solve a problem, where this problem has been expressed in terms of a set of requirements. The contents of the SDD can then be traced to these requirements. In other cases, an SDD is prepared to understand an existing system lacking design documentation. In such cases, an SDD is prepared such that information of interest is captured, organized, presented and disseminated to all interested parties. This information of interest can be used for planning, analysis, implementation and evolution of the software system, by identifying and addressing essential design concerns.

Gli autori di IEEE Std 1016 riconoscono che un SDD non può essere creato in anticipo. Uno può essere creato dopo che il sistema software esiste al fine di acquisire informazioni per le parti interessate.

Sezione 1.1 Scope fornisce anche alcune informazioni interessanti:

This standard does not prescribe specific methodologies for design, configuration management, or quality assurance.

Nel contesto di queste domande, le parole chiave sono "gestione della configurazione". La gestione della configurazione non si applica solo al sistema software in fase di creazione, ma a qualsiasi documentazione associata.

Nella tua situazione personale e in molte situazioni, la creazione di un SDD in primo piano è uno spreco. La risposta di David Arno è vicina a quella che considererei la risposta giusta. Il vero design del tuo sistema software è il codice. Tuttavia, "creare SDD prima" o "creare SDD dopo" non sono le uniche opzioni. Hai una terza opzione: evoluci l'SDD con il sistema software.

Se stai seguendo uno standard come IEEE Std 1016, hai i requisiti per un SDD. Nello specifico, la Sezione 4 di questo standard definisce il contenuto che hai. Mentre lavori attraverso le decisioni di progettazione, inizia a creare i diversi punti di vista, viste e sovrapposizioni. Mentre prendi le decisioni, acquisisci le motivazioni progettuali per loro.

Ciò consentirà alle parti interessate di seguire l'evoluzione del design del software senza dover scavare nel codice. Naturalmente, le persone possono avere commenti o suggerimenti. Se si aggiorna l'SDD, possono tenere traccia dei propri progressi e fornire un feedback sull'approccio in anticipo, che è quindi possibile incorporare nel prodotto e nell'SDD. Quando si esegue la transizione dal progetto, se il codice del software e l'SDD sono sincronizzati, qualcuno dovrebbe essere in grado di collegarsi facilmente e riprendere il lavoro.

Se tutto ciò che stai cercando dall'SDD è comunicare il design con gli altri, allora sì, puoi crearlo dopo lo sviluppo. L'unica cosa è che viene chiamata documentazione.

Tuttavia, vorrei sottolineare che un SDD può servire anche a un altro scopo. Può anche aiutarti a ragionare sul design e assicurarti di "fallire velocemente". Questa è una buona cosa, soprattutto se un sacco di cose sono incerte in anticipo perché è possibile scartare approcci che non avrebbero funzionato durante l'intera implementazione in anticipo. Può anche impedirti di concentrarti sui dettagli tecnici a breve, non codificando nulla finché non hai capito il design.

Ti consiglio di fare almeno un tentativo all'SDD in anticipo. Se ti imbatti in cose in cui non sei sicuro di come funzionerebbero le cose, puoi creare piccoli prototipi dei problemi che stai cercando di risolvere. Questo ti darà esperienza nel risolvere i problemi specifici del tuo progetto che andranno a beneficio della qualità della soluzione completa nel lungo periodo.

L'unico vero documento di progettazione dettagliata che verrà creato è il codice. Indica esattamente al compilatore come costruire la tua applicazione. Di conseguenza, il tuo progetto non può essere completato fino a quella creazione finale prima della spedizione.

Qualsiasi altro documento di progettazione che crei, come un SDD, dovrà essere aggiornato dopo aver completato il disegno (codice). Pertanto, c'è una ragione convincente per scrivere l'SDD in seguito: devi solo farlo una volta.

L'ovvio contro è "quanto spesso scrivi un SDD dopo l'evento"? L'app viene spedita, quindi non è probabile che tu voglia dedicare tempo a documentare in quella fase. Ma questo vale anche per l'aggiornamento di uno esistente. Quale è peggio, nessun SDD o SDD è sbagliato e non può essere considerato attendibile?

Ci sono due ragioni per scriverlo in anticipo però. In primo luogo potrebbe essere un obbligo obbligatorio per farlo (non bello, ma succede). In secondo luogo, la creazione di un documento di questo tipo può aiutarti a formulare una strategia generale per la progettazione. Ma ciò può essere fatto altrettanto bene disegnando immagini, scarabocchiando note, ecc. In modo informale. E poiché sarà necessario riscriverlo in un secondo momento, l'approccio "rapido e sporco" a questo processo di progettazione macro in anticipo offre molti vantaggi.

Per me, non sarebbe una buona argomentazione.

Se davvero necessario, vorrei discutere con una strong attenzione allo sviluppo di prototipi per una migliore comprensione di un dominio problematico sconosciuto. Tuttavia, anche in questi casi, alcuni pezzi di design potrebbero essere utili prima.

C'è un caso da fare per farlo comunque in anticipo . Perché lo stai facendo per imparare sulla scrittura di documenti come questo. Saltare questo lavoro perché potrebbe non essere necessario al 100% qui significa saltare l'apprendimento.

Un compromesso potrebbe essere quello di scriverlo durante l'implementazione . Prima di ogni componente / modulo / schermo o altra suddivisione del tuo programma, devi pensare a come lo farai. Quindi aggiungi le tue decisioni al documento di progettazione e poi le implementa.

Se qualcosa cambia in seguito, aggiorni il documento.

Questo ha diversi vantaggi rispetto alla scrittura dopo il fatto:

• Imparerai a mantenere aggiornati i documenti di progettazione quando cambiano i requisiti, un'abitudine utile

• Imparerai a pensare al design prima dell'implementazione

• Non è noiosamente noioso come scrivere documenti di design dopo che il fatto è

• Se si esaurisce il tempo, si avrà un documento di progettazione che descrive ciò che si è fatto finora in modo che altri possano continuare il proprio lavoro

• Non è molto più lavoro in questo modo

• Mentre il tuo progetto continua, potresti non essere del tutto sicuro del motivo per cui tu stesso hai fatto qualcosa in quel modo due mesi fa, e avrai le tue note da dirti.

Documento di progettazione del sistema, un record di requisiti di base più (nuove funzionalità) aggiornamenti man mano che il progetto avanza con nuovi attributi di progettazione e soluzione. Mantenuto fino alla consegna del progetto / soluzione. Utile, comunica a tutti gli interessati.