Controllo di configurazione release rilasciare le manette!

La natura sempre più complessa e globale di tutte le attività nei settori industriali e verticali, unita ai modelli di business “Internet Time” a fuoco rapido, sta dando nuova enfasi alla gestione del cambiamento. La capacità di gestire efficacemente il cambiamento sta emergendo come una chiave di differenziazione tra i concorrenti-consentendo alle organizzazioni di evolvere modelli di business e linee di prodotto e cambiare marcia abbastanza rapidamente da soddisfare le opportunità dell’economia attuale – prima della concorrenza.

Mentre le organizzazioni faticano a gestire i progetti in questo ambiente, Configuration Management (CM) è diventato un componente sempre più critico, offrendo un framework per la gestione del cambiamento.

La disciplina di CM si compone di sei aree di competenza, come definito dalla EIA-649 (ANSI, 2004))

• CM di Pianificazione e di Gestione (CMPM),
• Configurazione di Identificazione (CI),
• Configurazione di Change Management (CCM),
• Configurazione di Contabilità di Stato (CSA),
• Configurazione > Verifica & Audit (CVA), e
• CM di Dati Digitali.

Tuttavia, ISO 10007 (ISO, 2003) raggruppa CM in quattro classificazioni:

• CI,
• Controllo di configurazione (CC),
• CSA e
• Revisioni e verifiche di configurazione (R & A).

(CCM e CC sono per tutti gli scopi pratici identici, come lo sono CVA e R & A.)

Si noti che il controllo della configurazione è discusso in questo articolo. Anche la gestione delle modifiche di configurazione e il controllo delle modifiche sono termini utilizzati per descrivere lo stesso processo.

Molti project manager percepiscono il controllo della configurazione come sistemi di contenimento e confinamento progettati per contrastare lo sviluppo del prodotto e che di solito influiscono negativamente sulla pianificazione del progetto. Sfortunatamente, troppo spesso processi CC generici progettati per programmi grandi e complessi come lo sviluppo di armi o sistemi medici, sono imposti ad altri tipi di progetti. Questi processi non sono adattati per soddisfare le esigenze, ad esempio, di uno sforzo di sviluppo Web o di un nuovo prodotto. Questo alla fine porta ad un’intensa frustrazione con il processo CC e l’effetto “manette” – dove processi non progettati per soddisfare le esigenze del programma hanno un impatto negativo sul progresso.

I project manager implementano il controllo di configurazione per controllare e tenere traccia delle modifiche. I processi sono progettati per garantire che venga utilizzato il livello appropriato per approvare le modifiche e che tali modifiche siano basate sulle migliori informazioni disponibili. I processi forniscono un quadro per la revisione del cambiamento. Ciò consente al team di valutare se l’implementazione del cambiamento è accettabile e di identificare i potenziali problemi in modo tempestivo. Questi processi consentono la calibrazione e, se necessario, un’ulteriore revisione.

La vera domanda non è se implementare il controllo di configurazione, ma quale livello di controllo di configurazione implementare. Un’organizzazione può richiedere un pacchetto di controllo della configurazione “standard aziendale” su tutti i progetti. Questo tipo di sistema è spesso imposto ai team di progetto a causa di una storia di mancanza di controllo della configurazione e del conseguente impatto finanziario. I project manager, che riconoscono che un approccio “one-size-fits-all” non funzionerà, devono dimostrare che i controlli appropriati sono in atto per evitare di ripetere gli errori del passato.

Controllo della configurazione in azione

Il tipico progetto di sviluppo non richiede un processo di controllo della configurazione a livello di un sistema di armi principale. È importante dotare il team di un adeguato livello di flessibilità, garantendo nel contempo l’esistenza di un sistema di controlli ed equilibri. La chiave per qualsiasi sistema è lo sforzo richiesto nel documentare il processo, insieme alla documentazione richiesta dal processo. Il processo CC di esempio descritto di seguito è progettato per soddisfare i requisiti di un progetto di sviluppo di applicazioni di piccole e medie dimensioni.

Il team di progetto deve prima analizzare il ruolo appropriato del controllo di configurazione sul progetto. Questo, come minimo su un progetto software, comporterebbe un tema di documentare tutti i file di codice internamente e qualche tipo di documentazione esterna. Altre aree da coprire includono l’approvazione delle modifiche e i processi di documentazione delle modifiche. Il semplice consenso dei partecipanti dovrebbe essere sufficiente. Naturalmente, un consiglio strutturato convocato regolarmente è meglio.

Ora entriamo nei diversi aspetti del semplice processo di controllo della configurazione.

Documenti

Il piano di gestione della configurazione (CMP) definirà il processo CC. In alcune applicazioni in cui il processo CC è abbastanza dettagliato, viene sviluppato un piano di controllo della configurazione (CCP). In entrambi i casi, tutti i processi e le procedure sono coperti per eseguire il controllo della configurazione.

La documentazione di modifica stessa (dettagliata in seguito) deve fornire informazioni sufficienti che siano autoesplicative al punto da non richiedere ulteriori informazioni dall’originatore. Ciò è necessario a causa della possibilità che l’originatore potrebbe non essere disponibile al momento dell’implementazione della modifica.

Processo

Il processo CC è semplice (Allegato 1). Un individuo ha un’idea o trova un errore nel sistema corrente. Questo individuo dovrebbe documentare i risultati su una richiesta di modifica aziendale (ECR), un modulo utilizzato per registrare tutti i bug, le modifiche o i miglioramenti per il progetto specificato. La richiesta di modifica viene instradata a peer e supervisori per la revisione e quindi approvata e implementata.

Allegato 1 – Processo di controllo della configurazione semplice

Documentazione delle modifiche

Documentare le modifiche è la parte più critica di un sistema di controllo della configurazione. Il dettaglio della documentazione non è importante quanto le informazioni documentate. Tuttavia, le informazioni documentate devono descrivere la modifica e includere, come minimo, le seguenti informazioni. I requisiti minimi per la documentazione sono:

naturalmente, le ulteriori informazioni contenute nella documentazione, il più semplice è quello di ricreare, recuperare, analizzare e correggere. Inoltre, questo aiuterà nella documentazione finale per la consegna del prodotto.

Quando un individuo scopre un errore o un requisito nel progetto corrente, documenta la modifica richiesta. Una richiesta di modifica contiene informazioni sulla richiesta e descrive lo scenario in cui è stato rilevato l’errore, chi l’ha rilevato, quando è stato rilevato e le correzioni consigliate. La richiesta dovrebbe anche identificare gli elementi di configurazione interessati, se possibile, e inserire una sorta di codice di gravità o priorità per identificare quando questa modifica, se approvata, dovrebbe verificarsi.

Approvazione del cambiamento

L’approvazione del cambiamento dovrebbe provenire da un supervisore di progetto designato con la vista “big picture” dell’impatto del cambiamento. Una revisione inter pares è un mezzo altamente efficace per verificare tutti gli aspetti del cambiamento e garantire che tutte le aree interessate dal cambiamento siano affrontate. Avere il cliente d’accordo con il cambiamento sarebbe utile per i miglioramenti. Tuttavia, nei piccoli progetti di sviluppo, la maggior parte delle modifiche è di tipo “bug fix” e il cliente non vedrebbe l’impatto della modifica.

Raccolta dati

La raccolta dei dati è vitale per recuperare informazioni su articoli simili e scoprire tendenze e tendenze. Queste informazioni dovrebbero risiedere elettronicamente, il che consente un facile recupero dei dati e la manipolazione dei dati per la contabilità e le metriche dello stato. Le informazioni possono essere utilizzate per compilare un rapporto “lezioni apprese”, che viene distribuito in tutta un’organizzazione per il miglioramento tecnico.

Modifica implementazione.

Una volta ricevute tutte le approvazioni appropriate, inizia il compito di implementazione. Il test in ogni fase dell’implementazione verifica che gli impatti su altri aspetti del programma siano minimi. Tutti i test sono completati e la modifica viene implementata nell’intero programma.

Processo a ciclo chiuso

Un processo a ciclo chiuso in cui l’originatore del cambiamento conoscerà il risultato finale del cambiamento prima che venga visualizzato nel prodotto finale è un componente chiave per il successo. Questo vale per tutti i tipi di industrie, dalla costruzione alla produzione al software.

Questo processo a circuito chiuso imposta le schede di controllo con ruoli diversi nel processo di modifica (Allegato 2). Ogni consiglio ha l’obbligo di rivedere un cambiamento nel contesto completo della sua carta e di giungere a una decisione definitiva per ogni cambiamento. Naturalmente, il consiglio potrebbe richiedere ulteriori informazioni prima di poter prendere tale decisione, ma questo dovrebbe essere minimo.

L’Istituto per la gestione della configurazione (ICMHQ) insegna la metodologia CMII (CMIIU) per la gestione della configurazione e ha sviluppato questa visione di un processo di cambiamento a ciclo chiuso. Questo processo inizia e termina con l’elemento finale. Si noti che l’amministrazione delle modifiche alla configurazione viene visualizzata a tre diversi livelli all’interno del ciclo. Ogni area è definita in modo diverso e ha ruoli e responsabilità specifici.

• Revisione tecnica Ensures assicura che tutte le valutazioni di dettaglio e l’analisi di fattibilità siano complete.
• Il Change Review Board (CRB) – Valuta l’impatto sul business del cambiamento. Questo cambiamento è valido per il nostro ambiente aziendale? Soddisfa uno dei nostri obiettivi strategici? Si inserisce nella nostra dichiarazione di visione? Con una modifica approvata, la CRB può indicare o meno un periodo di tempo per la modifica, dipendente dalla previsione competitiva e dal rischio aziendale.
• Il Change Implementation Board (CIB) – Assegna i finanziamenti necessari e determina i tempi di attuazione del cambiamento. Ciò include anche l’assegnazione di efficacia per la modifica, che specifica quando la modifica è effettiva. L’efficacia potrebbe riguardare una data, una build, un numero di serie o un numero di lotto. Questo dipende dall’elemento finale.

L’opzione Fast Track del ciclo è dove tutto il dolore di CC viene rilasciato e i proprietari possono ottenere una modifica approvata in pochi minuti rispetto ai giorni. La chiave di questo ovviamente è un albero di documentazione adeguato per ogni prodotto. Ogni documento deve avere un creatore e un utente assegnati a loro. Se le modifiche hanno un impatto solo sulla documentazione di basso livello, allora Fast Track è in ordine e il cambiamento urla attraverso il processo CC.

Sommario

La chiave per qualsiasi processo di controllo della configurazione di successo è il buy-in da tutto il team di progetto. I membri del team non dovrebbero essere invitati a rinunciare a un buon giudizio e controllo per il bene di un’infrastruttura di gestione che non è progettata per soddisfare i requisiti del progetto in questione. I processi di controllo della configurazione sono progettati per ridurre il rischio di guasti e garantire che i risultati siano soddisfatti nei tempi e nel budget. Se il team di progetto partecipa alla creazione del framework di controllo della configurazione iniziale, la partecipazione e l’accettazione in tutto il team di progetto vengono accelerate e l’infrastruttura stabilita supporterà gli obiettivi aziendali.