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


17

Supponiamo di aver ricevuto le specifiche di un progetto da un cliente e ora è il momento di iniziare a svilupparlo. Normalmente, ho appena iniziato con il primo modulo (di solito la registrazione dell'utente) e poi vado da un modulo al successivo. Ho in mente solo poco prima che sto per iniziare un modulo su come funzionerà, ma prima non c'è alcuna pianificazione.

Tuttavia, penso che sarebbe meglio se andassi oltre le specifiche e pianificassi come funzionava il sistema prima di codificarlo, ad esempio quali sono i componenti principali, come interagiranno, ecc. Sono solo non sono sicuro di cosa dovrei pianificare.

Per dare un'idea migliore di ciò che sto chiedendo, come dovrei ...

a) Dividere il progetto in componenti,

b) Pianificare le loro interazioni, ad esempio dovrei fare diagrammi di classe, scrivere test unitari, ecc.?

Qualche idea?


"Non sono proprio sicuro di cosa dovrei pianificare"? Perchè no? Hai elencato argomenti specifici. Cosa c'è che non va negli argomenti che elenchi. Cosa c'è di sbagliato in "quali sono i componenti principali, come interagiranno"? Dal momento che quelle sono le cose di cui ti preoccupi, perché non iniziare da lì?
S.Lott

4
Il tuo cliente prima o poi cambierà le specifiche. Pianifica le interazioni dei moduli in modo tale che le modifiche non rovinino l'intera base di codice.
Reno,

Risposte:


23

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

  • Inizia con gli obiettivi del progetto. Gli obiettivi sono necessariamente i più vaghi, ma ti aiutano a concentrarti su ciò che il cliente o l'utente intende fare con il software. Alla fine della giornata, vuoi soddisfare questi obiettivi, anche se ciò significa lasciare alcune funzioni davvero interessanti.
  • Quindi inizio a suddividere l'applicazione nei suoi sottodomini. Probabilmente ci sono centinaia di modi diversi per farlo, motivo per cui iniziamo con gli obiettivi del progetto. Vogliamo suddividere l'applicazione in alcuni sottosistemi correlati che supportano tali obiettivi. Questo ci aiuta a concentrarci sul prossimo compito.
  • Identificare 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 da poter 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 deve 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 interrompere il sistema nel suo insieme.
  • Rivedi come vengono implementate le cose nel mio sottosistema attuale rispetto a come viene implementato in altri sottosistemi. Ogni approccio non coerente è qualcosa che l'utente deve imparare. Va bene se stiamo parlando di un nuovo concetto. Per motivi di usabilità, non vogliamo 5 modi diversi per eliminare le informazioni presenti semplicemente perché eravamo pigri. Riutilizzare gli stessi elementi dell'interfaccia utente è il modo più rapido per rendere l'applicazione più intuitiva. L'apprendimento di tre concetti è molto più semplice dell'apprendimento 20.

Fondamentalmente, questo approccio alla definizione progressiva di un progetto da un livello molto alto a una progettazione più dettagliata mi è servito bene. Anche le interazioni tra i sottosistemi vengono perfezionate quando si tenta effettivamente di implementarle. È una buona cosa.


"Probabilmente ci sono centinaia di modi diversi per farlo, motivo per cui iniziamo con gli obiettivi del progetto". Penso che molto probabilmente inizi con modelli di progettazione applicabili che si adattano agli obiettivi. Non penso che tu pensi agli "obiettivi".
S.Lott

1
La maggior parte dei clienti che ho incontrato possono articolare i loro obiettivi piuttosto bene, ma hanno difficoltà a tutto il resto. In sostanza, voglio assicurarmi che il mio design soddisfi ciò di cui hanno bisogno. Quando gli obiettivi del progetto e quelli del cliente sono allineati, aiuta davvero le cose. Quindi, per essere più concreti, sì, sto perfezionando il mio design e scegliendo il modo in cui abbasso il problema in modo che tutto sia allineato.
Berin Loritsch,

8

Penso che sarebbe meglio se andassi oltre le specifiche

Giusto. Buona idea.

pianificato come funzionava il sistema prima che lo codificassi.

Buona. Fai di più.

quali sono i componenti principali,

Eccellente.

come interagiranno,

Corretta.

Non sono proprio sicuro di cosa dovrei pianificare.

Come puoi non essere 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 il modello di visualizzazione 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Leggi sul framework Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

Questo è ciò che devi pianificare.

come dovrei a) Dividere il progetto in componenti,

Usa modelli di design ampiamente adottati per altri progetti simili.

In caso di dubbi, leggere i progetti J2EE per idee.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

come devo b) Pianificare le loro interazioni, ad esempio dovrei fare diagrammi di classe, scrivere unit test, ecc.?

Sì. Buone idee, tutte.


4

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

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

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

Sviluppa casi di test / utilizzo e verifica con il cliente Se un requisito non è verificabile, eliminalo.

Sviluppa il design e assicurati che se tutti i pezzi funzionano correttamente, in teoria farebbe quello che ti serve.

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


3

Volete sicuramente avere qualche progetto in atto prima di iniziare a scrivere codice.

Una volta che lo hai, di solito preferisco fare prima una fase di architettura iniziale per definire come i livelli delle tue app si incastrano. Ciò include elementi di backbone come sicurezza e registrazione.

Quindi creo 1 funzione dall'alto verso il basso in modo che tu abbia implementato qualcosa completamente.

Quindi vai da lì.


0

Qualunque cosa

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


3
-1 Non credo che la risposta sia utile e nella maggior parte dei casi "tutto" non è sicuramente la strada da percorrere.
KeesDijk,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.