La creazione di un documento di progettazione software dopo lo sviluppo può essere giustificata?

Attualmente sto lavorando alla mia laurea per i miei studi di "Sviluppo software", in cui devo sviluppare software complessi individualmente in una società esterna. Tutto ciò deve essere fatto in modo strutturato, creando tutti i documenti corrispondenti.

Per questo progetto ho scelto di lavorare con i documenti standard IEEE: Documento sui requisiti software (SRS), Documenti sull'architettura software (SAD) e Documento di progettazione software (SDD). Sebbene insegnato diversamente a scuola, per questo progetto ho scelto di creare l'SDD dopo lo sviluppo (anziché prima). Il mio ragionamento è:

La società presso la quale svolgo il mio tirocinio mi ha dato le istruzioni per creare un complesso software, soddisfacendo in modo sperimentale un determinato insieme di requisiti. A causa della quantità di libertà che mi hanno dato nella definizione del progetto, quasi nulla è certo in anticipo e può essere meglio incontrato durante la sperimentazione del processo di sviluppo. Inoltre, sto creando il software in modo individuale , per me non sarebbe utile per nessun altro nella società realizzare questo Software Design in anticipo. Farlo in anticipo mi costerà molto tempo per cambiarlo in seguito, poiché posso essere certo che con le incertezze nel progetto, il design che realizzo in anticipo dovrà essere cambiato molto . Mi sembra controproducente.

È una buona giustificazione per creare l'SDD dopo lo sviluppo? In caso contrario, ci sarebbe una buona giustificazione per questo?

Modifica: il motivo per creare successivamente l'SDD sarebbe per i futuri sviluppatori di continuare il progetto. Non sarò in grado di completare l'intero progetto nel mio periodo di laurea, quindi altri sviluppatori dovranno continuare sull'attuale base di codice.

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

Un SDD può essere preparato e utilizzato in una varietà di situazioni di progettazione. In genere, un SDD è pronto a supportare lo sviluppo di un elemento software per risolvere un problema, in cui questo problema è stato espresso in termini di una serie di requisiti. Il contenuto dell'SDD può quindi essere ricondotto a questi requisiti. In altri casi, un SDD è pronto a comprendere un sistema esistente privo di documentazione di progettazione. In tali casi, un SDD viene preparato in modo tale che le informazioni di interesse vengano acquisite, organizzate, presentate e diffuse a tutte le parti interessate. Queste informazioni di interesse possono essere utilizzate per la pianificazione, l'analisi, l'implementazione e l'evoluzione del sistema software, identificando e affrontando i problemi di progettazione essenziali.

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

La sezione 1.1 Scope fornisce anche alcune informazioni interessanti:

Questo standard non prescrive metodologie specifiche per la progettazione, la gestione della configurazione o la garanzia della qualità.

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, creare un SDD in anticipo è 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 l'SDD prima" o "creare l'SDD dopo" non sono le uniche opzioni. Hai una terza opzione: fai evolvere l'SDD con il sistema software.

Se stai seguendo uno standard come IEEE Std 1016, hai i requisiti per un SDD. In particolare, la Sezione 4 di questo standard definisce il contenuto che hai. Mentre lavori nelle decisioni di progettazione, inizia a creare diversi punti di vista, viste e sovrapposizioni. Mentre prendi le decisioni, cattura la logica progettuale per loro.

Ciò consentirà alle parti interessate di seguire l'evoluzione della progettazione del software senza dover scavare nel codice. Naturalmente, le persone possono avere commenti o suggerimenti. Se si aggiorna l'SDD, possono tenere traccia dei 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 software e l'SDD sono sincronizzati, qualcuno dovrebbe essere in grado di accedere facilmente e riprendere il lavoro.

Se tutto ciò che stai cercando da SDD è comunicare il progetto con gli altri, quindi sì, puoi crearlo dopo lo sviluppo. L'unica cosa è che si chiama 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, specialmente se molte cose sono incerte in anticipo perché è possibile scartare approcci che non funzionerebbero presto nell'intera implementazione. Può anche impedirti di concentrarti sui dettagli tecnici a breve, non codificando nulla fino a quando non hai capito il design.

Ti consiglierei di fare almeno un tentativo prima in SDD. Se ti imbatti in cose in cui non sei sicuro di come funzionerebbero, puoi creare piccoli prototipi dei problemi che stai cercando di risolvere. Questo ti darà esperienza nel risolvere i problemi specifici per il tuo progetto che andranno a beneficio della qualità della soluzione completa a lungo termine.

L'unico vero documento di progettazione dettagliata che creerai è il codice. Indica esattamente al compilatore come creare l'applicazione. Pertanto, il tuo design non può essere completo fino a quell'ultima build prima della spedizione.

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

L'ovvio contrario a questo è "quanto spesso scrivi un SDD dopo l'evento"? L'app viene spedita, quindi non è probabile che tu voglia passare il tempo a documentare in quella fase. Questo vale anche per l'aggiornamento di uno esistente. Che è peggio, nessun SDD o un SDD che è sbagliato e di cui non ci si può fidare?

Tuttavia, ci sono due motivi per scriverlo in anticipo. In primo luogo potrebbe essere un requisito obbligatorio per te farlo (non è carino; ma succede). In secondo luogo, la creazione di un documento del genere può aiutarti a formulare una strategia globale per la progettazione. Ma ciò può essere fatto altrettanto bene disegnando immagini, scrivendo appunti ecc. In modo informale. E dal momento che dovrà essere riscritto in seguito, ci sono molti vantaggi nell'approccio "rapido e sporco" a quel processo di progettazione macro iniziale.

Per me, non sarebbe una buona argomentazione.

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

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

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

Se qualcosa cambia in seguito, aggiorni il documento.

Ciò ha diversi vantaggi rispetto alla scrittura dopo il fatto:

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

• Imparerai a pensare al design prima dell'implementazione

• Non è così noiosamente noioso come scrivere documenti di progettazione dopo il fatto

• Se esaurisci il tempo, avrai un documento di progettazione che descrive ciò che hai finora in modo che altri possano continuare il tuo lavoro

• Non è molto lavoro extra in questo modo

• Man mano che 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 i tuoi appunti da dirti.

System Design Document, un registro dei requisiti di base più aggiornamenti (nuove funzionalità) mentre il progetto avanza con nuovi design e attributi di soluzione. Mantenuto fino alla consegna del progetto / soluzione. Utile, comunica a tutti gli interessati.