In che modo gli sviluppatori verificano che le modifiche ai requisiti software in un sistema non violano un requisito dei sistemi software a valle?

Question

In che modo gli sviluppatori verificano che le modifiche ai requisiti software in un sistema non violano un requisito dei sistemi software a valle?

#1 da (2 voti)
#2 da (0 voti)

1

Nel mio lavoro, eseguo la raccolta dei requisiti, l'analisi e la progettazione di soluzioni aziendali oltre alla codifica. Ci sono più sistemi e pacchetti software e ci si aspetta che gli sviluppatori lavorino su ognuno di essi, invece di essere assegnati ad apportare modifiche solo a 1 sistema oa pochi sistemi.

In che modo gli sviluppatori assicurano di aver acquisito tutti i requisiti necessari e risolto eventuali requisiti in conflitto?

Un esempio di questo tipo di scenario:

Bob lo sviluppatore è invitato a modificare il sistema di ticket dei problemi per un'ipotetica attività di riparazione di utilità. Si contraggono con una società di servizi pubblici per fornire questo servizio. Il vecchio sistema fornisce un meccanismo per un cliente esterno per creare un ticket che indica un problema con il servizio di utilità in un particolare indirizzo. Esiste un sistema di pianificazione e un sistema di fatturazione che dipende da questi dati. Il nuovo progetto di Bob è quello di modificare il sistema di posizionamento dei biglietti per consentire l'inserimento di più indirizzi da parte di un proprietario o di un altro cliente finale con proprietà multiple. Le fatture del sistema di fatturazione per biglietto, ma dovrebbero essere modificate in bolletta per indirizzo. Quali pratiche potrebbero aiutare Bob a scoprire che anche il sistema di fatturazione deve essere cambiato? In che modo Bob potrebbe scoprire quali altri sistemi della sua azienda potrebbero dover essere modificati per supportare le nuove modifiche \ modello di business? Diciamo che c'è una specifica documentata per ogni sistema coinvolto, ma ci sono molti sistemi e Bob non ha familiarità con tutti loro.

Fine dell'esempio.

Spesso ci troviamo in questo scenario e disponiamo di revisioni del design, ma la direzione attribuisce la responsabilità finale per qualsiasi difetto (processo aziendale o processo software) allo sviluppatore che sta facendo il disegno e il lavoro.

Alcune organizzazioni sembrano essere più brave di altre. In che modo riescono a rilevare e risolvere requisiti in conflitto o incompleti tra sistemi software?

Attualmente disponiamo di molte conoscenze tribali e solo pochi sviluppatori che comprendono l'intera catena aziendale e del software. Questo sembra altamente inefficace e porta a problemi a livello di requisiti.

requirements requirements-management

posta Peter Smith 23.08.2014 - 18:35

fonte

2 risposte

Leggi altre domande sui tag requirements requirements-management

Memorizzazione e presentazione di dati di tabelle personalizzate Come scrivere una storia utente specifica per le attività in questo caso [duplicato]

score 2 · Answer 1

Due modi:

Usando interfacce ben definite tra i sistemi connessi che hanno comportamenti chiari, non ambigui e documentati, e
Scrivendo test unitari che codificano il comportamento a livello di classe e metodo, test di integrazione che verificano la funzionalità su più sistemi e test di accettazione che convalidano il soddisfacimento soddisfacente dei requisiti del software.

Il processo per scoprire e identificare le capacità di un sistema interno, in modo da poter scrivere software contro di esso, non è diverso da quello di valutare qualsiasi altro sistema esterno. La documentazione ti porterà a una certa distanza, ma l'unico modo per essere sicuri è quello di colpire il sistema estraneo e vedere come si comporta.

Nel tuo esempio, sai già che il tuo sistema di fatturazione deve essere in grado di supportare la fatturazione per indirizzo. Quindi, verifichi il sistema per vedere se lo fa. Nella tua mano c'è l'elenco delle funzionalità e delle funzionalità che il sistema estero deve supportare il tuo nuovo software, perché le hai già identificate attraverso una serie di riunioni per la raccolta dei requisiti e la pianificazione del software.

Avere una suite di test completa per ogni sistema aiuta questo processo, perché i test sono una forma di documentazione. Se sono scritti bene, puoi dire quali sono le capacità del sistema (dovrebbe), perché i test specificano i comportamenti desiderati.

score 0 · Answer 2

Nella mia esperienza due cose aiutano con questo tipo di sfida, che esiste praticamente per ogni sistema:

Conoscenza approfondita del sistema nel team. Sì, suona spaventoso e in realtà è quando la conoscenza è concentrata in pochissime persone. Vuoi diffondere quella conoscenza tra gli sviluppatori. Associare la programmazione e garantire che più persone lavorino su ogni singolo pezzo del software è fondamentale
test di integrazione. Ogni interfaccia dovrebbe avere i suoi test di integrazione, che dovrebbero crollare sul loro volto quando avviene un cambiamento incompatibile. I buoni test di integrazione automatizzati sono difficili da creare e mantenere, quindi sono spesso manuali, sebbene siano preferibili i test automatici.

Cose che non aiutano:

Documentazione. Ok, aiuta, ma solo un po ', perché il più delle volte è scaduto o viene ignorato, o entrambi.
Test unitari. Per definizione, non testano questo tipo di comportamento tra i sistemi.