documento SRS e controllo versione

Sì e no. Il controllo della versione riguarda proprio questo: controllo delle revisioni degli asset, siano essi file di testo del codice sorgente, immagini o persino documentazione. Mentre gli ingegneri del software di solito inseriscono il codice sorgente e le risorse grafiche (una volta ricevute) sotto il controllo della versione, le risorse grafiche e i documenti degli standard vengono spesso preparati dai non ingegneri. Nella mia esperienza, queste persone lavorano raramente sotto il controllo della versione (anche se si potrebbe sostenere che dovrebbero).

Un altro motivo per cui le specifiche dei requisiti non sono spesso sotto controllo di versione è che spesso non sono file di testo (documenti Word, fogli di calcolo o documenti di Google sono comuni) e quindi le versioni non possono essere confrontate facilmente da molti sistemi di controllo versione. Sì, i word processor moderni possono confrontare in modo intelligente diverse revisioni, ma a volte tale funzione non può essere invocata dal sistema di controllo della versione.

Nonostante ciò, c'è una naturale tendenza per le persone a capire l'importanza di preservare le vecchie versioni, e ho visto vari metodi ad hoc usati dai non-ingegneri, come aggiungere numeri di revisione o date ai nomi dei file, ad esempio .

Chiedete degli standard e non conosco standard ufficiali comunemente applicati che richiedano quali risorse debbano essere sotto controllo di versione e quali no. Questa è una scelta gestionale e organizzativa e varia da luogo a luogo. Alcune aziende hanno una politica chiara su questo, usando linee guida interne o definite dall'esterno, o strumenti software speciali, altri no.

Anche se sono d'accordo con la maggior parte della risposta di Randall Cook , vorrei aggiungere alcune cose aggiuntive.

I tuoi requisiti dovrebbero essere in gestione della configurazione ed essere controllati in qualche modo. Cioè, dovresti essere in grado di associare un determinato insieme di requisiti (magari acquisiti in un documento SRS o in una raccolta di user story o in un database o in un altro formato) a una determinata versione del software. Per qualsiasi versione del software, probabilmente vorrai sapere quali sono i requisiti, la progettazione, l'implementazione (codice sorgente), i casi di test (codice di test, script, procedure manuali) e forse anche i risultati dei test. Questo aspetto della gestione della configurazione è chiamato "identificazione della configurazione".

Un aspetto della gestione della configurazione è controllo della versione . Tuttavia, il modo in cui implementate il controllo della versione potrebbe essere diverso a seconda del tipo di artefatto. Il codice sorgente può essere tenuto in strumenti che sono adatti alla gestione del software (che di solito è un file di testo) - strumenti come Subversion o git. Tuttavia, potrebbero essere necessari strumenti diversi per la versione corretta di altri artefatti. Gli strumenti di gestione dei requisiti, come DOORS, hanno spesso flussi di lavoro di gestione delle modifiche e supportano il controllo delle versioni dei requisiti. Per i documenti, un sistema di gestione dei contenuti può consentire di tenere traccia delle versioni.

Per quanto riguarda gli standard, ci sono degli standard per la gestione della configurazione, ce ne sono molti , alcuni attivi e alcuni ritirato o sostituito - ANSI, ISO, IEEE, Dipartimento della Difesa degli Stati Uniti, pratiche industriali specifiche per una serie di industrie diverse, e così via. Quanto sono applicabili a voi dipende da vari fattori: obblighi contrattuali o normativi, dimensioni e tipo del progetto, industria, per citarne alcuni grandi. Possono fornire indicazioni e un punto di partenza per la sartoria. In definitiva, tuttavia, spetta all'organizzazione di sviluppo definire un processo adatto alle loro esigenze.