Operazione: Determinazione delle politiche CM (Configuration Management)
Questa attività descrive come sviluppare le politiche CM che includano le norme di identificazione di configurazione, le norme di creazione di una linea di base, le norme per l'archiviazione e requisiti per la creazione di report della configurazione.
Discipline: Gestione modifiche e configurazione
Scopo

Lo scopo di questa attività è quello di stabilire le politiche di gestione della configurazione del progetto da utilizzare per monitorare e proteggere le risorse del progetto e per fare rispettare le norme di sviluppo del software. Le politiche del progetto dovrebbero migliorare le comunicazione tra i membri del team e ridurre i problemi incontrati durante l'integrazione del loro lavoro. 

Relazioni
Passi
Definizione delle norme di identificazione di configurazione
Scopo:  identificare e archiviare i prodotti di lavoro in un repository protetto 
Guida al tool: Creazione di linee di base utilizzando Rational ClearCase 

L'identificazione della configurazione è una parte importante della gestione della configurazione e viene definita da IEEE come "un elemento di gestione della configurazione che consiste della selezione degli elementi di configurazione per un sistema e della registrazione delle loro caratteristiche fisiche e funzionali nella documentazione tecnica". In termini di gestione di configurazione software, con identificazione della configurazione si intende la capacità di trovare e identificare la versione corretta di qualsiasi prodotto di lavoro di progetto, in modo rapido e semplice. L'impatto negativo di avere un sistema di identificazione di configurazione inefficace si misura in termini di perdita di tempo e di qualità.

Le etichette identificano le versioni specifiche dei prodotti di lavoro. L'insieme dei prodotti di lavoro che costituiscono una versione di un sottosistema, sono collettivamente e singolarmente identificabili tramite una particolare versione ed etichetta. Le etichette sono quindi utili nel riutilizzo o nel fare riferimento a insiemi originali di prodotti di lavoro dotati di versione.

La seguente è una convenzione consigliata di etichettatura di prodotto di lavoro a livello di prodotto, utilizzabile per i percorsi di etichettatura e i prodotti di lavoro nella Struttura della directory del prodotto.

<SISTEMA>[<A>]_[<SOTTOSISTEMA>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SISTEMA> identifica il sistema

<A> corrisponde a un TLA (three letter acronym, acronimo da tre lettere). Viene utilizzata per i vari tipi di prodotti di lavoro utilizzati nella creazione del sistema. Ad esempio,

PLN  Piani di progetto 
REQ  File di requisiti 
USC  Casi d'uso 
MOD  File di modello 
SRC  File di codice sorgente 
INT  Interfacce pubbliche 
TST  Script e risultati di test 
DOC  Documentazione (utente, note di rilascio) 
BIN  Eseguibili 

<SOTTOSISTEMA> identifica ogni sottosistema

<A> corrisponde a un TLA per i vari tipi di prodotti di lavoro utilizzati nella creazione del sottosistema. In accordo con la tabella precedente.

R|A|B  Corrisponde a rilascio, alfa o beta 
<X>  Numero intero, che corrisponde a un rilascio superiore (ad es.: 1) 
<Y>  Numero intero (facoltativo), che corrisponde a un rilascio inferiore 
<Z>  Numero intero (facoltativo), che corrisponde a un rilascio alternativo (patch, porte, ecc.) 
BL  Corrisponde a livello base (un rilascio interno) 
Numero intero, per i rilasci interni 

Eccone alcuni esempi:

T2K_R1.0  Rilascio 1 del sistema Thorn 2000 
T2K_GUI_R2.0.BL5  Rilascio interno del sistema GUI deliberato per la distribuzione nel rilascio 2 
T2K_B1.1  Rilascio beta 1.1 del sistema Thorn 2000 
T2K_R2.0.BL16  Linea di base #16 di sistema interna di thorn 2000 deliberata per la creazione del rilascio 2 
T2K_R1.0.5  Rilascio di manutenzione di Thorn 2000 
Definizione delle norme di creazione di linea di base

Una linea di base fornisce un punto stabile e un'istantanea dei prodotti di lavoro del progetto. Concetto: Creazione linea di base descrive quando occorre creare le linee di base nel ciclo di vita del progetto. Questa fase costituisce un'ulteriore guida per le norme.

Le linee di base identificano insiemi fissati di versioni di file e directory e vengono create in determinati punti cardine del progetto. Possono essere create per un sottosistema o per l'intero sistema. Le linee di base dovrebbero essere identificate secondo lo schema descritto nella precedente fase del processo (definizione della convenzione di etichettatura del prodotto di lavoro).

Occorre fare una distinzione durante la creazione della linea di base, cioè se si sta creando:

  • Una "linea di base di sottosistema" con TUTTE le versioni di file e directory che sono state modificate nel o nei sottosistemi.
  • Una "linea di base di sistema" con una SINGOLA versione di tutti i file e directory in tutti i sottosistemi.

Come linea guida generale, renderebbe più facile la gestione del rilascio per creare linee di base di sistema nei maggiori e minori punti cardine del progetto e linee di base di sottosistema come richiesto oppure a frequenza più elevata. Come regola empirica, è una buona idea creare una linea di base se devono essere modificati fino al 30% degli elementi di un sottosistema.

Definizione delle norme di archiviazione

L'obiettivo di questa fase è quello di assicurare che il software di progetto e le relative risorse (documenti principali) siano sottoposti a backup, catalogati e trasferiti presso siti di archiviazione designati. Gli archivi mostrano il loro valore nei momenti di riutilizzo o di perdita dovuta a disastro. In quanto tali, gli archivi devono essere creati regolarmente nei maggiori e minori punti cardine.

Le linee guida dell'etichettatura descritta in precedenza nella fase del processo "definizione della convenzione di etichettatura del prodotto di lavoro" possono essere utilizzate quando si creano le etichette di archiviazione. Comunque, è possibile richiedere ulteriori informazioni su dove i mezzi attuali devono essere archiviati. Ad esempio:

NUMERO DI SERIE  123456789 
VOLUME  1 di 3 
VAULT  B5 
DATA DI ARCHIVIAZIONE  21-Giugno-99 

Tutte le informazioni relative al prodotto devono essere conservate in un database per facilitarne il rilascio e il riutilizzo.

Definizione dei requisiti di creazione dei rapporti di stato della configurazione
Scopo La modifica dell'attività è un potente indicatore dello stato e delle tendenze del progetto. L'obiettivo di questa fase del processo è di far definire al responsabile di progetto quali dati di modifica relativi del prodotto devono essere inseriti in report, da parte di chi e a quale frequenza. 
Fasi secondarie:  
Guida al tool:  

Creazione di report di stato della configurazione , se utilizzata, descrive le varie fonti di creazione di report di stato della configurazione.

Selezione dei report basati sulla richiesta di modifica Inizio pagina

A questo punto, è necessario selezionare i report che possono derivare dall'inoltro di Richieste di modifica al progetto. Esiste un numero di report utili basati sulle richieste di modifica.

Nell categoria "epoca", la creazione di report può essere richiesta in termini di numero di richieste di modifica in una settimana o mese in base ai seguenti criteri:

  • Inoltrata
  • Assegnata
  • Risolta
  • Priorità

Elencando i problemi per stato, può aiutare a determinare quanto il progetto potrebbe essere vicino al completamento. Ad esempio, se il grosso dei problemi è stato risolto, allora il completamento del progetto è più vicino rispetto a quanto non sarebbe stato se i problemi fossero stati in fase di inoltro.

Nella categoria "distribuzione', la creazione di report può essere richiesta per rispondere ai seguenti tipi di domande:

  • Chi ha trovato i difetti, di che tipo e in che punto del progetto?
  • A chi sono stati assegnati i problemi?
  • Quanti problemi sono aperti in una data progettazione?
  • Quanto gravi sono i difetti trovati?
  • In che parte del processo sono situati i problemi che li hanno generati (causa principale)?
  • Quando vengono risolti i problemi?
  • Quanti difetti ci sono?
  • Quanto gravi sono questi difetti?

Queste metriche possono aiutare nell'analisi del carico di lavoro, di chi sta lavorando sui problemi più critici e di quanto rapidamente i problemi vengono eliminati.

Nella categoria "tendenza", è possibile richiedere report per rispondere ai seguenti tipi di domande:

  • Quanti difetti sono stati aperti in questa giornata, settimana o mese?
  • Quanti difetti sono stati chiusi in questa giornata, settimana o mese?

Questi dati sono utili nella valutazione del tasso di riparazione e potrebbero fornire indicazioni di efficienza della progettazione.

Definizione della frequenza di creazione di report Inizio pagina

Assicurarsi che i report vengano ricevuti alla giusta frequenza per fornire informazioni significative nel prendere decisioni. I report possono essere richiesti in base a quanto segue:

  • Quotidianamente: è improbabile che vengano richiesti con questa frequenza
  • Settimanalmente: tendenza, report di distribuzione e conteggio, report di build
  • Mensilmente: tendenza, report di distribuzione e conteggio, report di build
  • Per iterazione: tendenza, report di distribuzione e conteggio, report di build, descrizioni di versione
  • Per fase: tendenza, report di distribuzione e conteggio, controlli, report di build, descrizioni di versione
  • A fine progetto: tendenza, report di distribuzione e conteggio, controlli, report di build, descrizioni di versione


Ulteriori informazioni