Definizione delle norme di identificazione di configurazione
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.
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.
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
|
|