La volontà di ingegnerizzare e automatizzare la produzione del software e la sempre crescente quantità di progetti di ampio respiro, spesso a sviluppo distribuito, incentivati in particolar modo dalla comunità Open Source, ha fatto sì che si sviluppasse sempre di più il Software Configuration Management (SCM) ovvero l’insieme di attività, pratiche e strumenti atti alla gestione e al controllo di tutte quelle attività legate a tale produzione.

Entriamo nell’ottica

Quando viene sviluppato un progetto software vi sono molteplici attività che ruotano attorno alla sua realizzazione, queste sono di molti tipi ma hanno l’esigenza comune di essere gestite, controllate e tracciate.

Le operazioni fatte sulle varie attività possono essere svolte in svariati modi e avvalendosi di molteplici strumenti, il SCM prevede una loro gestione formale ovvero un insieme di prassi ben definite che devono essere rispettate.

Il vantaggio che si ha rispettando le indicazioni del SCM è quello di avere una gestione del ciclo di vita del software molto agevole e controllata, inoltre permette a progetti con team di sviluppo distribuito di uniformare le proprie produzioni rendendo più facile l’aspetto collaborativo.

I vantaggi sono accentuati quando al software si può applicare un modello di ciclo di vita di tipo evolutivo, in quanto il maggior coinvolgimento del committente e le frequenti versioni parziali che vengono rilasciate e modificate a seconda delle esigenze richieste [1], rendono la produzione del software più caotica e aumentano la necessità di gestione controllata delle attività.

Seppure l’utilizzo formale di prassi e di strumenti possa sembrare in disaccordo con una prototipazione e uno sviluppo rapido del software, bisogna però considerare che i livelli di applicazione delle procedure possono essere variabili a seconda dell’entità del progetto e a seconda delle metodologie scelte per lo sviluppo, infatti le attività controllate potranno essere in numero adeguato o gestite in maniera meno rigorosa e approfondita.

Le attività

Quando ci si riferisce al SCM spesso si pensa erroneamente che le attività da gestire si riducano in termini pratici al semplice versionamento del software, tuttavia seppur questo rimanga un aspetto fondamentale non è l’unico che deve essere preso in esame.

Non solo le attività possono essere gestite e controllate ma più in generale qualsiasi artefatto che da esse venga prodotto può subire un processo di gestione. Di seguito vengono riportati i principali elementi sottoposti al SCM:

• Specifiche dei requisiti
• Specifiche funzionali
• Project plan
• Quality plan
• Task plan
• Manuale utente
• Documentazione di sviluppo
• Specifiche di progetto
• Codice sorgente
• Test Case
• Test Results
• Bug report
• Manuali di installazione e gestione del prodotto
• Programmi eseguibili
• Schemi dei database
• Schemi di configurazione
• Documenti relativi alla manutenzione del prodotto
• Standard e procedure adottate

[2]. Non tutte queste componenti devono necessariamente essere gestite anche perché in alcuni progetti alcune di esse potrebbero non esistere, tuttavia è buona norma cercare di prenderne in considerazione il più possibile.

Affinché il processo di configurazione del software risulti efficace si deve avere una distribuzione e condivisione delle informazioni: con questi termini si intende che tutti i dati riferiti agli elementi precedentemente elencati devono essere sviluppati e tracciati e condivisi fra di loro in modo tale che venga creato un legame stretto fra componenti che ne consenta il tracciamento.

Immaginiamo che il nostro progetto sia in fase di testing, un uso del SCM potrebbe essere quello di tracciare l’attività di testing , associargli il test relativo, tracciare l’eventuale bug riferendolo al test che lo ha prodotto, tracciare l’attività di correzione, risolvere il bug, versionare il software corretto, rieseguire il test, e così via. Come si può immaginare queste attività sono strettamente interdipendenti fra loro e coinvolgono gran parte delle componenti elencate prima.

Se tutte le informazioni relative alle attività svolte sono tracciate e condivise sarà facilmente reperibile in un secondo momento un qualsiasi riferimento allo sforzo prodotto, consentendo un notevole risparmio di risorse per eventuali altre attività correlate, inoltre sarà molto più facile la gestione del progetto in ambito di un team distribuito perché i tracciamenti effettuati potranno essere acceduti da tutti i membri.

Come è facile immaginare tutte le informazioni sulle attività devono essere registrate in modo tale che chiunque operi sul progetto sia in grado di accedervi, per tale scopo sono nati diversi sistemi che integrano innumerevoli funzionalità atte al SCM.

Gli strumenti

Esistono svariate decine di software in grado in grado di gestire a 360 gradi la vita di un progetto software ed in particolare i suoi aspetti di configurazione: ne sono stati prodotti sia dalla comunità open source (google code) sia dalle più importanti aziende software (sourceforge).

Non è intenzione di questo articolo soffermarsi sui tool per il tracciamento delle specifiche attività, tuttavia è necessario affrontare un aspetto centrale nelle funzionalità previste dall’SCM ovvero il versionamento.

Per tale scopo la stragrande maggioranza degli strumenti ricorre a CVS (Concurrent Version System) o all’SVN (Subversion).

Il CVS utilizza un’architettura client-server: un server immagazzina la versione corrente di un progetto e la sua storia; il client si connette al server per verificare l’ultima versione disponibile del software ed utilizzare quest’ultima. Molti client possono simultaneamente pubblicare le copie dei progetti. Quando essi registrano poi i cambiamenti, il server tenta di fonderli. Se questo sistema fallisce, per esempio perché due client hanno cercato di cambiare la stessa linea in un certo file, il server nega la seconda operazione di registrazione e informa il client sul conflitto, il quale sarà risolto a mano dall’utente. Se l’operazione di registrazione riesce, allora i numeri di versioni di tutti i file coinvolti si incrementano automaticamente, e il server CVS scrive una linea di descrizione fornita dall’utente, la data ed il nome dell’autore nel relativo file di log.

I client possono anche confrontare le differenti versioni dei file, richiedere una completa storia di cambiamenti, o la verifica di una fotografia storica del progetto da una certa data e da un certo numero di revisione[3].

L’SVN [4] è una evoluzione del CVS con le seguenti caratteristiche principali:

• Comprende gran parte delle caratteristiche di CVS.
• Le directory, i cambi di nome, e i metadati dei file sono sotto controllo versione.
• I commit sono vere transazioni.
• Il branching e il tagging sono operazioni veloci, che richiedono un tempo indipendente dalla dimensione dei dati.
• Il protocollo client/server invia solo le differenze in entrambe le direzioni, e quindi i costi di comunicazione sono proporzionali alla dimensione delle modifiche, non alla dimensione dei dati.
• I file binari sono gestiti efficientemente.
• La licenza è Open Source, simile a quella di Apache.

Si nota che potendo gestire il versionamento di qualsiasi file binario e delle directory l’SVN è uno strumento potenzialmente completo per una gestione integrata del SCM, in quando le varie attività e le loro cooperazioni possono essere registrate su documenti organizzati e mantenute con il versionamento.

Conclusioni

Come visto le pratiche di SCM rendono flessibile e ordinati lo sviluppo e la manutenzione di un progetto. Il prezzo da pagare per avere i risultati sperati non è tuttavia trascurabile, se il tempo impiegato per il semplice versionamento (meglio se sempre correlato da commenti) del software è trascurabile, non altrettanto si possono definire i tempi per la compilazione dei moduli relativi alle varie altre attività. E’ quindi necessaria un’analisi preventiva per cercare il giusto compromesso fra il materiale prodotto e lo sforzo che questo richiede. Anche i tempi di startup per l’installazione, la configurazione e l’apprendimento dell’uso degli strumenti non sono trascurabili e possono incidere significativamente su progetti di stretto respiro, tuttavia i benefici che ne derivano risultano spesso essere maggiori del prezzo pagato. Come in molte attività un investimento iniziale (in questo caso più di tempo che di denaro), porta a una resa molto proficua sul lungo periodo. In particolar modo nel mondo dello sviluppo sotftware dove l’attività artigianale spesso predomina quella organizzata è necessario cercare di adottare metodologie, prassi e strumenti che consentano una ingegnerizzazione dei vari processi del ciclo di vita.

Riferimenti

[1] Autori Vari, “Ciclo di vita del software, i modelli incrementali“, Wikipedia, 2007

[2] Autori Vari, “Gestione della configurazione“, Wikipedia, 2007

[3] Autori Vari, “Concurrent Version System“, Wikipedia, 2007

[4] Autori Vari, “Subversion“, Wikipedia, 2007