Qual è un buon modo per estrarre a livello di programmazione ciò che è necessario dalla logica aziendale? [chiuso]

Il modo in cui l'ho imparato è che un caso d'uso è una traduzione inglese di ciò che alla fine diventerà logica di programmazione. Quindi, in OOP, i nomi generalmente diventano oggetti (classi), i verbi diventano metodi, e gli aggettivi sono condizioni al contorno o invarianti.

Nell'esempio del caso d'uso:

• Ci devono essere almeno due settimane di tempo pagato tra i compiti.

I nomi sono settimane, tempo e compiti. La menzione delle settimane indica che stiamo osservando un intervallo e "almeno" imposta un valore minimo per tale intervallo (in questo caso, due settimane). Intervalli significa che hai bisogno di un valore iniziale e finale.

Poi noto che il "tempo" non sta in piedi da solo; è modificato da "pagato". Questo mi dice che ci sono almeno due tipi di tempo, "pagato" e, molto probabilmente, "non retribuito". Specificare il tipo di tempo richiederà modifiche ai calcoli dell'intervallo per tenere conto del tempo potenzialmente non sequenziale. Dobbiamo rendere conto, per esempio, di qualcuno che ha una settimana di tempo pagato, una settimana di ferie e poi una seconda settimana di tempo pagato?

Questo non è un modello rigido, dovrei sottolineare, perché non esiste un modo in cui un modello possa adattarsi a ogni singolo caso d'uso. Tuttavia, esaminare la struttura di un caso d'uso e ridurlo un po 'può essere molto utile per costruire la logica programmatica.

È davvero qualcosa che viene con l'esperienza. Molti problemi di programmazione (specialmente quelli come nel tuo esempio) si verificano comunemente. E quelli che non lo sono, possono essere suddivisi in problemi che sono. Risolvere tali problemi un numero sufficiente di volte renderà la soluzione alla tua seconda natura e non penserai nemmeno a come tradurre tali requisiti aziendali in codice. Quindi continua a programmare e abbastanza presto spezzerai la tua barriera di astrazione tra mondo reale e codice.

Questa risposta ha una visione leggermente più ampia - la mia opinione è che la chiave per capire come programmare una soluzione a un requisito è acquisire una comprensione più profonda del requisito stesso e del suo fondamento logico. Una volta raggiunto questo punto, l'implementazione dovrebbe essere molto più semplice da visualizzare.

Sento che ci sono molti modi per affrontarlo; spesso dipende dal tipo di metodologia che stai seguendo, ma l'obiettivo finale è generalmente lo stesso; cioè, fornire una soluzione di lavoro che soddisfi le aspettative del tuo "cliente" entro i tempi previsti e il budget previsto.

Suggerirei di mirare a quanto segue:

1. Assicurati che tu (e i tuoi colleghi) abbia sufficiente comprensione e chiarezza dei requisiti.
2. Assicurati che il tuo "cliente" (utenti finali / manager / parti interessate / tester del QA / ecc.) capisca i propri requisiti.
3. Assicurarsi che il cliente comprenda i costi, le implicazioni e le conseguenze dei propri requisiti
4. Garantire che tutti coloro che sono coinvolti nel processo di sviluppo del software condividano la stessa comprensione e visione delle motivazioni e degli obiettivi finali sottostanti.
5. Assicurati che i potenziali rischi siano stati esplorati e discussi.
6. Assicurati che i possibili limiti e limitazioni siano stati esplorati e discussi.
7. Assicurati che i tuoi limiti tecnici (o quello del tuo team) siano stati esplorati - il requisito suggerisce tecnologie o parti di un sistema esistente che non conosci?
8. Soprattutto - assicurati che tutti abbiano le loro aspettative gestite; assicurati che l'accordo tra te / il tuo team e il cliente includa (per quanto ragionevolmente possibile) un insieme di criteri di accettazione chiari, concisi e completi che tutti comprendano.

Ecco i punti che mi piace ricordare quando osservo un requisito:

1. Il requisito sembra risolvere un problema del mondo reale o sembra un tentativo (forse ingenuo) del cliente di risolvere parzialmente il problema? il cliente sta provando a "progettare" una parte o tutta la soluzione per te? Se è così, sii cauto perché si tratta di una tipica bandiera rossa per un "cattivo" requisito.
2. Perché il cliente ha richiesto questo requisito? Quali sono le loro motivazioni?
3. Quali problemi nel mondo reale / aziendale stanno cercando di risolvere?
4. è un vero problema? fornisce costi-benefici? elimina qualche tipo di rischio? esiste un motivo normativo / giuridico / di sicurezza? o è un problema percepito / immaginario che non ha realmente bisogno di essere risolto?
5. Quali sono i costi per l'azienda o il cliente se il problema rimane irrisolto? (A volte il modo migliore per soddisfare un requisito è abbandonarlo!)
6. Quali sono i rischi associati all'abbandono del requisito? Quanto è importante veramente ?
7. In che modo il requisito influisce su qualsiasi sistema o flusso di lavoro utente esistente?
8. Quali sono i criteri di accettazione per il requisito?
9. Una volta implementato il requisito, come posso verificare che i criteri di accettazione siano stati soddisfatti? Prima ho persino scritto una riga di codice, ho una comprensione cristallina di esattamente come sto andando a testarlo?
10. Quali sistemi esterni / di terze parti (librerie, hardware, server esterni, ecc.) o aziende / clienti / fornitori sono coinvolti, se presenti? Influenzano i requisiti (ad esempio, ci sono ulteriori lavori "nascosti" non scritti che coinvolgono terze parti che il cliente non ha preso in considerazione)?
11. Sono previsti costi aggiuntivi non di sviluppo? (hardware, strumenti aggiuntivi / software, ecc.)
12. Qual è l'impatto sul processo di installazione e distribuzione; includi le procedure di Upgrade e Downgrade, se possibile, non concentrarti solo su un'installazione nuova / pulita.
13. Cosa dovrebbe essere consegnato e quando? Con quale anticipo il cliente potrà esaminare i progressi e fornire feedback per perfezionare o evolvere il requisito con te?
14. Quanto sei fiducioso nella stima della consegna (scenari Best-Case e worst-case). Il cliente ha accettato il tuo caso peggiore?

Potrei aver deviato un po 'dalla domanda, anche se ritengo che le questioni relative ai requisiti si sovrappongono pesantemente al quadro più ampio della gestione dei progetti (gestione delle aspettative dei clienti); con tutta la buona volontà del mondo, puoi credere di avere una buona padronanza di un requisito (e della tua stima) e ancora di ottenerlo irrimediabilmente sbagliato o di interrompere la scadenza / il budget.