Quanto tempo dedichi al documento di progettazione (s) per il vostro software?

Question

Ovviamente le dimensioni del progetto si sta lavorando sarà un fattore enorme nel quanto tempo necessario per scrivere il documento di progettazione / specifica. Ma si fa andare attraverso tutto ciò, individuando ogni piccolo dettaglio? Oppure prendere un approccio più agile e iniziare a scrivere il software molto presto e risolvere i problemi man mano che vengono a voi?

Ho sempre trovato che c'è solo così lontano si può andare con la progettazione. Ci saranno inevitabilmente alcune cose che sono mancati, ed a quel punto quanto bene si può adattare ai mezzi situazione più rispetto alla specifica stessa.

I Am prendendo il giusto punto di vista su questo? E 'in realtà un parere, o è un disegno spec perfetta sempre la strada migliore da percorrere?

Answer 1

Dipende un po 'sul vostro target di riferimento, ma la mia esperienza (più in sviluppo piccola scala / medie di lavoro scala molto grande) è che i documenti di progettazione dettagliata sono arduo e noioso da scrivere, raramente leggere e tendono a finire fuori data per il momento in un progetto viene consegnato.

Questo non significa che essi sono inutili - se si consegnano qualcosa per qualcuno, ci deve essere una dichiarazione autorevole e deciso di quello che sarà consegnato sufficientemente dettagliato che tutti possono puntare ad esso nel caso qualcuno non è soddisfatto con l'affare e dire "questo è ciò che abbiamo promesso" e valutiamo contro ciò che è stato consegnato.

Se fossi la creazione di una società per costruire un prodotto, tuttavia, non sarebbe preoccuparsi tanto di una specifica dettagliata. Vorrei documento cosa che stavamo andando a fare, ma io non vorrei andare troppo approfondita per quanto riguarda come - che è la parte che è più probabile che cambiamento e lasciare i documenti su data e abbastanza inutile o addirittura inesatte di essere effettivamente ostruttiva. Io preferirei di documentare il "come" roba in codice utilizzando qualsiasi formato di documentazione della lingua o supporti IDE migliori, in modo che quando cambia il codice è più facile aggiornare la documentazione, allo stesso tempo. Essa non si fermerà andando fuori moda, ma si ridurrà in qualche modo.

Idealmente si vorrebbe un documento di progettazione che potrebbe raddoppiare, come il manuale quando il codice è completo, ma non so di chi ha gestito con successo.

Answer 2

Dipende sicuramente dalle dimensioni e dalla struttura del progetto.

Per i progetti dei clienti, le specifiche dettagliate sono un must. Mi piace di coinvolgere pesantemente il cliente durante la specifica di progetto. Questo aiuta a scovare le considerazioni in più e si dà al cliente una migliore comprensione di cosa aspettarsi. Di solito c'è un cambiamento positivo nel comportamento (nei confronti del tempo e dei prezzi) dopo la scoperta e le specifiche sono completi. Questo ci permette anche di tappe fondamentali stabilite - e li ha colpiti -. Che è favorevole per il cliente, e il nostro team di sviluppo

Per i progetti interni e progetti lato divertente, io in genere creare un diagramma di flusso e lista delle funzionalità, quindi avviare l'hacking insieme. In questi casi, quello che trovo più importante di una scheda tecnica caratteristica, è l'attuale interfaccia utente. Io wireframe il sito su carta e fare un semplice accumulo UI (HTML / CSS). Questo mi aiuta a pensare attraverso l'esperienza degli utenti, che stimo più di caratteristiche specifiche sui miei progetti. Posso sempre tornare indietro e mettere insieme le caratteristiche più tardi.

Answer 3

Dipende cosa si intende per documenti di progettazione.

li spendo, 1/3 a 1/2 del mio tempo a scrivere giù disegni per la scrittura del software che, in un taccuino, abbozzare le cose, cercando di capire gli algoritmi, le relazioni, storie, ecc.

Non faccio tutto questo davanti up.

Non ho un documento principale firmato e sigillato che sto lavorando da. Ho fatto in passato, e non ho mai avuto alcun lavoro fatto, perché ero sempre in attesa di qualcuno per firmare qualcosa fuori. Che era più un problema con la burocrazia della società ero con oltre il concetto di design tutto in anticipo, ma io continuo a preferire l'approccio più fluido / agile che ho adesso.