Da dove inizia la progettazione: codice, interfaccia utente, flusso di lavoro o altro?

Question

Stavo discutendo di questo sul lavoro, e mi stavo chiedendo dove la gente inizia i loro progetti? Tendiamo a iniziare a progettare il codice per risolvere il problema presentato a noi, ma probabilmente siamo tutti programmatori (o erano).

Mi stavo chiedendo dove altre persone e organizzazioni iniziano il loro progetto. Cominciano a risolvere il problema come un problema di codifica, a sedersi e a progettare quale interfaccia utente utilizzare o a mappare i dati o il flusso di lavoro?

Grazie

Answer 1

Perché non iniziare con i test di accettazione?

Una delle cose che ho spinto in progetti recenti è di garantire che il team di test sia coinvolto nel progetto di molti produttori. Se non è possibile concordare un criterio di accettazione con il cliente, è necessario porsi la domanda, alcuni dei requisiti del progetto sono davvero necessari?

A tal fine sono ora molto interessato a framework di test che cercano di catturare i requisiti in modo verificabile, ad esempio:

• easyb
• concordian
• ..

Forse un sistema di test automatizzato e di gestione dei requisiti di accettazione anticipata consentirebbe di provare più di una soluzione.

Answer 2

Inizio sempre con flusso di lavoro/processo. Ho scoperto che quando si inizia con la modellazione del processo di business/flusso di lavoro in genere si tende a ottenere più informazioni che rendono l'interfaccia utente più utilizzabile e il codice/i requisiti tendono ad essere più adatti alle esigenze degli utenti.

Le persone in genere commettono l'errore di iniziare a progettare codice/interfaccia utente prima di capire veramente il flusso di lavoro. Detto questo, se capisci il quadro generale, puoi iniziare a progettare su uno qualsiasi dei 3 workflow, codice, ui (e questo è il mio ordine preferito).

Answer 3

Personalmente, se l'applicazione ha un'interfaccia utente, è da lì che comincio, in quanto ciò normalmente spinge i processi e i flussi di lavoro.

Paper prototyping dove ha senso e reiterando il design mentre lavoro.

Se si tratta di un'applicazione a riga di comando, penso molto attentamente alle opzioni della riga di comando, ai valori predefiniti e ai normali schemi di utilizzo prima di iniziare a lavorare.

Answer 4

Inizio con il design dai requisiti. Se i requisiti richiedono un'interfaccia utente, tenderei a progettarlo come attività secondaria e progettare il motore di calcolo (o qualsiasi altra cosa tu lo chiami) come un'altra sottoprocesso; questa è una sorta di MVC con separazione netta tra M e V, con C che fornisce il collegamento tra loro. Quindi progettare C diventa un altro sotto-compito.

Ma raramente ho il lusso di progettare qualcosa da zero in questi giorni, sono molto più propenso ad aggiungere nuovi moduli e nuove funzionalità ai sistemi esistenti. In questi casi la maggior parte del design dell'interfaccia utente è già stata eseguita, quindi ha un sacco di design M.

E ho sentito che Test Driven Design è un movimento popolare in questi giorni, quindi i test potrebbero essere un altro punto di partenza da prendere in considerazione.

Answer 5

mio schema generale tende ad andare lungo queste linee:

1. requisiti di cattura (definire ingressi e uscite previsti).
2. Progettare qualcosa che potrebbe funzionare (struttura del programma principale/idee del flusso di dati per spiegare come passare dagli input alle uscite nei requisiti).
3. Prototipo di qualsiasi algoritmo e verifica con dati reali (generalmente in Excel e/o Python per dimostrare che possiamo ottenere dall'input all'output).
4. Implementare una soluzione (aumentare il risultato in C++/.net).
5. Test per la morte/correggere eventuali bug che vengono portati alla luce (convalidare contro i modelli precedenti e altri test che sembrano importanti).
6. Optomise eventuali colli di bottiglia o problemi di usabilità.

Generalmente creo soluzioni software e/o GUI incorporate per connettersi a tali sistemi e manipolarli/visualizzare i dati di output.

Answer 6

Inizio sempre con i requisiti, quindi progettare il database, quindi progettare l'app. Un'app progettata prima del database è una ricetta per i problemi. Penso che sia interessante il fatto che nessun altro sia sembrato pensare che progettare il database fosse abbastanza importante da menzionare. Non c'è da stupirsi che ci siano così tante applicazioni commerciali deisgnizzate là fuori.

Answer 7

Penso che le risposte a questa domanda (così com'è) rifletteranno principalmente i tipi di applicazioni progettate/create dalle persone che scrivono le risposte. Ad esempio, se stai progettando un programma che otterrà dati da un database (o qualche fonte in ogni caso), massaggialo come necessario, e poi inserirai il risultato in un altro, è probabile che inizierai a pensare a schemi di database, flusso di dati e codifica/formattazione dei dati (probabilmente in merito a tale ordine).

D'altra parte, se si stava scrivendo un tipico programma desktop del tipo che apre un file, consente all'utente di modificarne il contenuto e quindi di salvarlo (che si tratti di una fotografia, un documento di elaborazione testi, un foglio di calcolo o qualunque sia) è probabile che gli schemi di database non salgano in primo piano rispetto al tuo pensiero. Qualcuno che ha guardato (per esempio) le specifiche per i formati di file di Microsoft Office probabilmente avrebbe spazio per argomentare che in alcuni casi, il design sarebbe meglio se fosse stato inserito più pensiero iniziale nel formato, ma di solito non sarà comunque

Per ottenere una risposta più significativa, penso che sia necessario fare un passo indietro rispetto a "qual è il tuo approccio alla risoluzione del problema?" a qualcosa di più simile: "Qual è la relazione tra il tipo di problema e il tuo approccio per risolverlo?" Altrimenti, la maggior parte di ciò che otterrete sarà di solito poco più di una dichiarazione indiretta su quali tipi di problemi ha lavorato quella persona.

Answer 8

Inizio con il flusso di lavoro e i requisiti funzionali. Il funzionamento è indipendente dall'interfaccia utente (solitamente con gli strumenti e gli script della riga di comando), quasi sempre con tre framework di test (test funzionale/unitario completo, controllo dello stato rapido "attivo e in esecuzione" e test dello stress delle prestazioni). L'ultimo passo è l'interfaccia utente.

Answer 9

Inizio con dati non elaborati. Nemmeno con strutture dati, ma con numeri interi, float, array di stringhe, matrici di interi e così via. Non ci sono diagrammi uml o requisiti utente, nessuna gerarchia di classi o ereditarietà, nessuna interfaccia di classe o funzione, nessun flusso di lavoro o processo. Solo un singolo algoritmo che produce un singolo set di dati.

Answer 10

Ho poca esperienza in programmazione e progettazione, ma quello che faccio è principalmente l'interfaccia con i database, quindi è da lì che inizio. Quando mi viene dato un problema, mi siedo per un'ora e disegno lo schema del database, lo creo, quindi aggiungo i miei SP e le mie viste.

Successivamente, scrivere le query e i moduli, l'HTML effettivo e il JS e il CSS che rendono tutto così bello (o meno, che è generalmente il caso con i miei "disegni").

Quindi, nel modello MVC, immagino che sia M prima, poi V? Non ho molta esperienza con MVC.

È un modo relativamente naturale?