Mantenere la tracciabilità up-to-date, come si evolve progetto [chiusa]

Question

Nel corso vari progetti, avevo bisogno di fare in modo che il modello dei casi d'uso che ho sviluppato durante la fase di analisi copre i requisiti del progetto. Per questo, sono stato in grado di avere un certo grado di tracciabilità tra requisiti dichiarazioni (identificate in modo univoco) e casi d'uso (anche identificato in modo univoco). In alcuni casi, consentendo la tracciabilità implicava qualche sforzo supplementare che consideravo (e poi dimostrato) per essere un buon investimento.

Ora, il problema più grande che ho dovuto affrontare è stato quello di mantenere questa la tracciabilità più tardi, quando le cose hanno cominciato a cambiare (a seguito di richieste di modifica, o in seguito a casi d'uso modifiche).

Tutte le idee di migliori pratiche per la manutenzione di tracciabilità?

(Si può applicare ad altri elementi del progetto - casi d'uso per esempio e casi di test, o esigenze e casi di test di accettazione)

modifica Successivo Strumenti potrebbe aiutare, ma non in grado di rilevare le lacune o errori nella tracciabilità. Navigazione ... forse, ma non garantisce che la tracciabilità è up-to-data o corretto dopo aver applicato le modifiche.

Answer 1

Credo che la tracciabilità è una delle cose più difficili da gestire nei requisiti, secondo per assicurarsi che i requisiti siano corrette, in primo luogo. Nella mia esperienza, il miglior strumento di tracciabilità è un essere umano .

Non ho alcun panacea; solo alcuni suggerimenti per quello che mi ha aiutato in passato.

• Mantenere i documenti in una zona centrale dove tutti possono arrivare a loro con facilità. Non mi importa se si tratta di Sharepoint, un wiki, o un'unità di rete (anche se mi piace qualcosa che fornisce il controllo di versione, se possibile). Tenerlo in un posto e commercializzare il diamine fuori di esso in modo che tutti sanno di andare lì per le risposte invece di usare vecchie copie o interrompere gli sviluppatori.
• Se si dispone di un punto centrale di contatto per la gestione dei manufatti o raggruppamenti funzionali di loro, che aiuta molto. Qualcuno che li comprende e le questioni sapranno dove andare, cosa per aggiornare e se ci sono dipendenze che hanno bisogno di essere portato avanti.
• Il custode dei manufatti deve essere impegnato a loro ea tenerli aggiornati. Un anno dopo ho creato alcuni documenti requisiti di un sito, ho ancora li teneva aggiornati. So che la maggior parte degli sviluppatori avrebbero paura di dover fare, ma un anno dopo, sto ancora beneficiando guardando indietro a quelli per vedere come un requisito funzionale è cambiato nel corso del tempo.
• Non richiesta, ma è utile per identificare rapidamente i cambiamenti nel corso del tempo: utilizzare la versione del processore documento di monitoraggio se si ha. In caso contrario, vorrei almeno includere un registro delle modifiche per il documento o semplicemente marcare il nuovo testo con un riferimento al numero di versione.
• Ho provato a mettere i riferimenti di dipendenza nei miei manufatti in passato, come ad esempio i riferimenti ad altri documenti o artefatti, ma ha trovato che o sono diventati obsoleti o erano difficili da tenere traccia e quindi non erano spesso aggiornati. La disciplina in grado di superare questo, ma la maggior parte di noi hanno troppo da fare, eh? Quindi penso che la costruzione di riferimenti incrociati tra documenti / manufatti è dove vorrei uno strumento o di qualche utilità la gestione dei requisiti liberi ancora essere rilasciato per fare il lavoro:)

Answer 2

Abbiamo usato tre anni fa uno strumento razionale per i requisiti di scrittura. In questi strumenti, molte caratteristiche riguardano la tracciabilità.

Abbiamo scoperto che l'usabilità di questi strumenti non è perfetto. Anche se hanno fatto di fornire le funzionalità di base di cui avevamo bisogno, abbiamo perso un sacco di tempo andando in giro i loro limiti.

---

Presumo che non state chiedendo circa la tracciabilità fino al codice, quindi escludo questo dalla mia risposta.

---

Come si menziona ID univoci per le sue dichiarazioni e casi d'uso, si potrebbe già utilizzare uno strumento per la loro gestione.

In sostanza, un modello relazionale semplice (possibilmente in un database) potrebbe coprire le relazioni tra i pezzi identificati in modo univoco .

vorrei cercare un semplice strumento che lo fa. Se solo una persona può modificarlo, potrebbe essere semplicemente un foglio di Excel!

---

Si noti che collega due tipi di documenti non è probabilmente sufficiente.
Lei ha parlato di 5 tipi:. Dichiarazioni, casi d'uso, casi di test, i requisiti e casi di test di accettazione
Abbiamo costantemente bisogno di transitività (nel mondo relazionale, per unire le tabelle), per avere una visione tra cui diversi passaggi.

Answer 3

Ci sono molti tipi di traceabilities per mantenere: i requisiti di sistema ai requisiti di sub-sistema, i requisiti per progettare, obbligo di verifica (più importante), obbligo di codice, i requisiti ai problemi, ecc

Word, Excel e un buon sistema di gestione dei problemi va un lungo cammino. Ma possono essere doloroso quando viene richiesto di mostrare la tracciabilità. mantenendo manualmente la tracciabilità è soggetto ad errori e manodopera. IBM Doors sistema è il miglior strumento che ho usato finora. Ma sono costosi. Recentemente abbiamo trovato un sistema di ultima traccia che funziona abbastanza bene.

Answer 4

Si desidera aggiungere una versione # per la dichiarazione esigenze e per ogni caso d'uso - il maggior numero di quelli up-to-date essere comunicati a tutti e conservati a una certa zona facilmente accessibile (fisica e / o computer / web). Sarà necessario aggiungere un documento cambiamento che comprende ciò che è stata la dichiarazione requisito preliminare e / o utilizzo caso, quando è stato cambiato, da chi e chi ha approvato.

Così, quando guardando le esigenze specifiche e utilizzare casi / tutto avere l'ultima vista e se c'è una domanda per un cambiamento, si ha il cambiamento doc per riferirsi a (non sovraccaricare i requisiti o utilizzare caso spec con informazioni storico, ma mantenere le informazioni storico in prossimità come riferimento in, forma significativa facilmente accessibile)

Answer 5

Direi che il modo migliore è quello di utilizzare un bug tracker. Ogni requisito è tracciato come un insetto, modifiche di sviluppo sono associati con esso, e cambiamenti possono essere tenuti con bugnotes.

Un sacco di bugtrackers permette di associare più bug insieme (ad esempio come duplicati) quindi questo può essere utilizzato per mantenere i requisiti discreti combinati ed ancora distinti per il monitoraggio individuale.

Se si memorizzano tutti gli altri manufatti in SCM (vale a dire i documenti di progettazione, ecc), allora è possibile rintracciare questi attraverso anche associandoli con il requisito.

Ci sono strumenti per aiutare con tutto questo, ut ho trovato questi strumenti "completa del ciclo di vita" sono davvero inutilizzabili in quanto cercano di fare troppo in un'unica applicazione, o di applicazioni come correlati che "integrano" insieme, e sono incredibilmente costoso.