Cosa pianificare prima di iniziare lo sviluppo di un progetto? [chiuso]

Quando hai il privilegio di iniziare un nuovo progetto hai una tela bianca - che è allo stesso tempo eccitante e scoraggiante. Lavoro in iterazioni, ed è così che divido il lavoro:

• Inizia con gli obiettivi per il progetto. Gli obiettivi sono necessariamente i più vaghi, ma ti aiutano a concentrarti su ciò che il cliente o l'utente intendono fare con il software. Alla fine della giornata, vuoi soddisfare questi obiettivi, anche se questo significa abbandonare alcune funzioni davvero interessanti.
• Quindi inizio a suddividere l'applicazione nei suoi sottodomini. Ci sono probabilmente un centinaio di modi per farlo, ed è per questo che iniziamo con gli obiettivi del progetto. Vogliamo suddividere l'applicazione in alcuni sottosistemi correlati che supportano tali obiettivi. Questo ci aiuta a concentrarci sull'attività successiva.
• Identifica come e quando i sottosistemi devono interagire. Non stiamo gestendo i dettagli, ma solo le informazioni di alto livello per assicurarci di avere un sistema integrato di sottosistemi. Hai bisogno di un'idea generale di questo in modo che tu possa approfondire i dettagli che supportano gli obiettivi generali del progetto.
• Fornisci solo i dettagli per il sottosistema su cui sto lavorando al momento (simile alla tua attuale strategia). So già come questo sottosistema ha bisogno di interagire con altri sottosistemi, ma potrei aver bisogno di elaborare un paio di alternative in modo che abbia più senso. Ogni sottosistema è separato da un'interfaccia, quindi posso regolare l'implementazione il più possibile senza rompere il sistema nel suo complesso.
• Rivedere come sono implementate le cose nel mio sottosistema corrente rispetto a come è implementato in altri sottosistemi. Ogni approccio che non è coerente è qualcosa che l'utente deve imparare. Va bene se stiamo parlando di un nuovo concetto. Per l'usabilità, non vogliamo 5 modi diversi per cancellare le informazioni presenti semplicemente perché eravamo pigri. Riutilizzare gli stessi elementi dell'interfaccia utente è il modo più rapido per rendere l'applicazione più intuitiva. Imparare tre concetti è molto più facile che imparare 20.

Essenzialmente, questo approccio di definire progressivamente un progetto da un livello molto alto a un progetto più dettagliato mi è servito bene. Anche le interazioni tra sottosistemi vengono affinate mentre si tenta effettivamente di implementarle. Questa è una buona cosa.

I think it would be better if I went over the specs

destro. Buona idea.

planned out how the system was going to work before I coded it.

Buona. Fai di più.

what are the main components,

eccellente.

how they're going to interact,

Una corretta.

I'm just not sure exactly what I should plan.

Come puoi non sicuro quando hai già elencato un sacco di cose? Se quelle sono le cose che ti riguardano, perché non concentrarti solo su quelle cose?

Leggi sul modello di visualizzazione 4 + 1: link

Leggi sul framework Zachman: link

Questo è ciò che devi pianificare.

how should I a) Divide the project into components,

Utilizza schemi di progettazione ampiamente adottati per altri progetti simili.

In caso di dubbi, leggi i progetti J2EE per le idee.

link

how should I b) Plan their interactions, e.g should I do class diagrams, write unit tests, etc..?

Sì. Buone idee, tutto.

La cosa più importante da fare: rivedere le specifiche, interagire con il cliente per ottenere specifiche più raffinate.

I requisiti sono indubbiamente incompleti, vaghi o errati. La più grande perdita di tempo sta facendo la cosa sbagliata. I clienti non sono ingegneri software professionali e non ci si può aspettare che siano in grado di sviluppare una buona serie di requisiti.

Quindi, dovresti rivedere le specifiche, intervistare il cliente e scoprire se questo è ciò di cui lui / lei ha realmente bisogno e vuole, e può permettersi, ecc.

Sviluppa test / casi d'uso e verifica con il cliente. Se un requisito non è verificabile, buttalo fuori.

Sviluppa il design e assicurati che tutti i pezzi funzionino correttamente e che in teoria faccia ciò di cui hai bisogno.

Sviluppa un prototipo di architettura che collauda tutta la tecnologia da utilizzare in ogni livello ma ignora le funzionalità. Stai testando l'architettura, non le specifiche funzionali. Avere l'architettura sbagliata significa che devi riscrivere tutto, quindi avere l'architettura giusta è importante. Assicurati che possa soddisfare i tuoi requisiti per velocità, efficienza, sicurezza, ecc.

Sicuramente vuoi avere un progetto in atto prima di iniziare la codifica.

Una volta ottenuto ciò, in genere preferisco fare una prima fase di architettura per definire in che modo i livelli dell'app si adattano. Ciò includerebbe elementi di backbone come sicurezza e registrazione.

Poi costruisco 1 feature dall'alto al basso in modo da implementare qualcosa completamente.

Quindi vai da lì.

Tutto

Pianifica tutto, è più facile cambiarlo sulla carta rispetto a quando una parte è già codificata, ottieni un'ottima base per la documentazione e molti altri vantaggi.