MIL-HDBK-61A: Controllo della configurazione

< Precedente |Contenuto |Successivo >

6.1 Attività di controllo della configurazione

Il controllo della configurazione è forse l’elemento più visibile della gestione della configurazione. È il processo utilizzato dagli appaltatori e dagli uffici del programma governativo per gestire la preparazione, la giustificazione, la valutazione, il coordinamento, la disposizione e l’implementazione delle modifiche ingegneristiche proposte e delle deviazioni agli elementi di configurazione effettuati (CIs) e alla documentazione di configurazione di base.

L’obiettivo primario del controllo della configurazione è stabilire e mantenere un processo sistematico di gestione del cambiamento che regola i costi del ciclo di vita, e:

• Consente la progettazione e lo sviluppo ottimale latitudine con il grado appropriato, e la profondità delle procedure di controllo del cambiamento di configurazione durante il ciclo di vita di un sistema/CI.

• garantisce l’elaborazione e l’attuazione di modifiche di configurazione che mantenere o migliorare la capacità operativa, di supporto, l’intercambiabilità e l’interoperabilità

• Assicura complete, accurate e tempestive modifiche alla documentazione di configurazione e mantenuto sotto la configurazione appropriata autorità di controllo

• Elimina inutili cambiare la proliferazione

L’intervallo di controllo della Configurazione inizia, per il Governo, una volta che la prima configurazione documento è approvato e baselined. Ciò si verifica normalmente quando viene stabilita la linea di base della configurazione funzionale (indicata come linea di base dei requisiti in EIA/IS-649) per un sistema o un elemento di configurazione. A quel punto, le procedure complementari di gestione del cambiamento del governo e del contraente sono impiegate per valutare sistematicamente ogni modifica ingegneristica proposta o deviazione richiesta alla documentazione di base, per valutare l’impatto totale del cambiamento (inclusi i costi) attraverso il coordinamento con le attività funzionali interessate, per disporre il cambiamento o la deviazione e fornire approvazione o disapprovazione tempestive e Il controllo della configurazione è una disciplina essenziale per tutto il ciclo di vita del programma. La figura 6-1 illustra un modello di attività di primo livello del processo di controllo della configurazione. Mostra il processo di controllo della configurazione diviso in tre segmenti, che sono dettagliati nelle figure 6-2, 6-3 e 6-4, rispettivamente.

Il primo segmento, Government Configuration Control-Initiation, riflette la parte del processo precedente alla richiesta governativa di un contractor Engineering Change Proposal (ECP). Questa attività si verifica:

• Quando la necessità di un cambiamento è originata dall’attività di Governo (tra campo e le operazioni di attività)

• Come risultato di input da parte dell’imprenditore, che una Classe per un Governo controllato basale è necessaria

• Dopo la configurazione documentazione che sarà interessato dalla proposta di modifica è stata approvata ed è inserita nella corrente di base controllata dal Governo

le Modifiche possono essere necessarie per una varietà di motivi, come ad esempio per contrastare la nuova minaccia, inserire la nuova tecnologia, e rispondere a prove e valutazioni tecniche e operative o correggere problemi. Come illustrato nella figura 6-2, l’attività governativa responsabile del controllo della configurazione conferma la necessità di modificare, stabilisce soglie per le prestazioni, i costi e il calendario per la modifica proposta, stabilisce che la modifica è tecnicamente realizzabile e conveniente (sulla base delle informazioni correnti e dell’interfaccia del contraente, se del caso) e prepara una richiesta per il contraente(s) di preparare un ECP. Uno dei contributi più significativi all’efficienza e all’efficacia del controllo della configurazione è la comunicazione chiara e concisa tra il governo e il contraente prima della richiesta formale di ECP. Idealmente questo si verifica in un ambiente di team di prodotto integrato.

Figura 6-3, che riflette il secondo segmento della Figura 6-1, modella il processo di controllo della configurazione dell’appaltatore. Il controllo di configurazione del contraente viene richiamato quando il contraente rilascia ogni elemento della documentazione di configurazione. In definitiva, il controllo della configurazione dell’appaltatore viene applicato al set completo di documentazione di configurazione, inclusa la documentazione di configurazione basata sul governo a livello di prestazioni o specifiche dettagliate, a seconda dei casi, e la soluzione di progettazione incorporata nei modelli e nei disegni ingegneristici. L’appaltatore risponde alle richieste ECP governative e alle richieste generate internamente per modifiche o deviazioni di progettazione (RFD). Il contraente valuta ogni proposta di modifica o richiesta di deviazione e ne documenta l’impatto sullo sviluppo e sulla sostenibilità dell’IC, determina il livello di revisione e approvazione richiesti e garantisce che una decisione specifica sulla fattibilità della modifica sia presa dall’autorità di controllo della configurazione applicabile prima della sua attuazione. ECP e RFD che richiedono revisione e/o approvazione del governo vengono inoltrati in conformità con i requisiti contrattuali. La decisione di approvazione del cambiamento è presa dal governo quando:

• Il cambiamento è un requisito di un baselined livello di prestazioni il documento di configurazione, controllati dal Governo, o

• Una modifica di un documento di configurazione controllata dal contraente, ha un impatto sulle prestazioni specificate, sostenibilità e altri contrattualmente specificato obblighi in materia di CI e la documentazione controllata dal Governo.

Il contraente prende la decisione quando la modifica riguarda gli elementi / la documentazione di configurazione per i quali è l’autorità di controllo della configurazione, a condizione che tali modifiche non influiscano sulle linee di base del governo.

Figura 6-4 modelli il terzo segmento della Figura 6-1, che copre la parte del processo in questione con la revisione del governo e la disposizione del contraente presentato ECPs e RFDs. Illustra la revisione dei rappresentanti del governo locale e la concomitanza con le modifiche di classe II e le deviazioni minori (dove tale azione è richiesta contrattualmente) e la sua approvazione (o non approvazione) delle modifiche di classe I e delle deviazioni principali/critiche. L’attività di controllo della configurazione del governo (in genere un segretariato) prepara la scheda di controllo della configurazione coordinando la modifica proposta con tutte le parti interessate, ricevendo impegni tecnici di concorrenza e di costi e orari e posizionando la modifica/deviazione sul calendario CCB (di concerto con la sua prontezza e l’urgenza della modifica). La CCB esamina quindi la proposta e gli impegni di attuazione e li approva o li disapprova in conformità con la politica dell’attività appaltante. Come risultato della decisione CCB, viene data la direzione di attuazione, in genere sotto forma di direttiva CCB. Le azioni dirette dalla CCB comprendono sia le azioni contrattuali che gli ordini di tasking per le attività governative, a seconda dei casi. In risposta a una direttiva CCB, l’ufficio appaltatore del governo prepara e negozia una modifica del contratto per autorizzare il contraente a procedere con l’implementazione dell’ECP di classe I approvato o dello scostamento maggiore/critico.

Un processo di controllo della configurazione efficace e ben definito assicura all’ufficio del programma governativo che tutte le modifiche alle linee di base controllate dal governo, non importa quanto piccole o apparentemente insignificanti, siano esaminate dall’autorità di controllo della configurazione applicabile. Senza un efficace processo di controllo della configurazione l’ufficio programma corre il rischio di fornire CIs con configurazioni che:

• Sono tecnicamente inadeguati e non riescono a soddisfare specifici requisiti di prestazione

• non Sono logisticamente supportabile

• Può essere pericoloso

• conseguenti sprechi di risorse, e

• non fornire un’accurata documentazione storica come base per il futuro cambiamento.

Come descritto in 6.1, il controllo della configurazione della documentazione di configurazione di base è un processo di gestione delle modifiche integrato che include sia l’attività di esecuzione (generalmente un appaltatore) che l’attività di tasking (generalmente il governo) responsabilità per la preparazione, la giustificazione, la valutazione, il coordinamento, la disposizione e l’implementazione del cambiamento. Attraverso il processo di controllo della configurazione, l’impatto completo delle modifiche e delle deviazioni ingegneristiche proposte viene identificato e tenuto conto nella loro implementazione.

Il processo di controllo della configurazione si evolve da un processo meno formale nelle prime fasi di un programma a un processo molto disciplinato e formale durante le fasi di sviluppo e dimostrazione del sistema, produzione e distribuzione e funzionamento e supporto . Nella fase di esplorazione del concetto il processo di controllo della configurazione è impiegato a supporto dell’ingegneria dei sistemi per assicurarsi che la corretta versione dei documenti, che comunicano decisioni tecniche o la definizione di parametri di studio pertinenti, siano diffusi e utilizzati da tutto il personale. Inoltre, il processo rende le parti interessate consapevoli che un cambiamento è in fase di sviluppo e consente loro di fornire input pertinenti.

Nella fase di sviluppo del concetto e della tecnologia (se applicabile), quando vengono sviluppati i documenti di definizione del programma, anche il processo di controllo della configurazione è meno formale. Come parte del processo di controllo di ingegneria dei sistemi in questa fase, ci possono essere diverse linee di base definizione requisiti stabiliti per comodità nel garantire che tutti i partecipanti al programma sono ” sulla stessa pagina.”Una procedura di controllo della configurazione è utile in questa fase per la revisione e il coordinamento delle modifiche alle specifiche a livello di sistema in evoluzione. Può anche servire a mantenere lo scambio di informazioni governo/Appaltatore efficiente e gestibile fornendo:

• l’identificazione, La documentazione, la diffusione e la revisione delle modifiche

• Appropriato il controllo delle versioni dei file e la revisione di documenti

• Un processo di rilascio per assicurare che ogni revisione/versione riflette le modifiche applicabili

Durante il Sistema di Sviluppo e di Dimostrazione, di Produzione e di Distribuzione, gestione e Supporto delle fasi, una configurazione formale del processo di controllo è essenziale. Il controllo informale del cambiamento del documento che è stato praticato durante le esplorazioni del concetto è insufficiente per l’acquisizione e il mantenimento dei sistemi. Mentre il prodotto è in fase di sviluppo e produzione, il controllo di configurazione si concentra sulla documentazione che definisce le prestazioni, le caratteristiche fisiche e funzionali e la configurazione del prodotto. Il controllo di configurazione è un processo di gestione che utilizza linee di base di configurazione contrattuali (governative) e interne (appaltatrici) come riferimenti per la gestione delle modifiche. In questo contesto, tuttavia, esistono diversi livelli di complessità del controllo della configurazione. Se osservate a livello macro, descritto dall’attività modelli (Figura 6-1 attraverso 6-4), il processo:

• gli Indirizzi baseline documentazione

• Determina in quali documenti sono interessate

• Propone un cambiamento che copre le conseguenze a tutti gli interessati che gli elementi, e

• Uniti, quando, dove, e da chi la documentazione verrà aggiornato e il cambiamento sarà parte integrante del prodotto e in tutti gli elementi di sostegno.

Mentre questa vista macro di primo livello appare semplice e diretta, una vista a livello micro del processo di controllo della configurazione può essere notevolmente più complessa. La vista micro rivela il livello di processo che si occupa di ciò che deve essere fatto per modificare ogni elemento interessato, e quindi con un’ampia varietà di considerazioni come i diritti dei dati; autorità di approvazione, custodi dei documenti; organizzazioni di progettazione, rilascio, produzione, installazione e test; relazioni contrattuali e di interfaccia.

Per modificare un prodotto, il primo passo è la revisione dei documenti che definiscono il prodotto. I concetti discussi di seguito facilitano la realizzazione di questo passaggio, utilizzando strumenti automatizzati come un AIS CM. Questo manuale visualizza questi concetti sia dal punto di vista della gestione dei programmi (macro) che dal punto di vista del controllo dei documenti (micro).

6.1.1.1 Autorità corrente.

A livello micro, se un ECP che propone una modifica a un prodotto ha un impatto su diversi documenti, la proposta di modifica, la valutazione e l’implementazione devono considerare:

• Chi è l’autorità contrattuale per approvare un ECP? Questa è l’autorità di controllo della configurazione del prodotto

• Chi ha il diritto di approvare la revisione di ogni documento interessato da un ECP? Questa è l’autorità di modifica del documento corrente.

• È necessario un ECP correlato a un’organizzazione dell’autorità di modifica dei documenti prima che l’autorità di controllo della configurazione per il prodotto possa approvare un ECP per il prodotto?

• Ci sono altre attività governative o industriali coinvolte perché il prodotto ha più utenti? Queste sono attività applicative. Uno è designato l’attività dell’applicazione principale?

a. Autorità di controllo della configurazione.

L’autorità di controllo della configurazione contrattuale che approva l’implementazione di una modifica di un prodotto (sistema/CI) può inizialmente risiedere presso un contraente o presso il governo. Può trasferire dal contraente al governo, o può continuare a risiedere con il contraente per tutto il ciclo di vita dell’IC. Questa autorità è tecnicamente responsabile delle prestazioni del prodotto e fiscalmente responsabile del finanziamento delle modifiche al prodotto.

Il livello di controllo della configurazione del governo è generalmente determinato come parte della selezione CI. Durante un programma di acquisizione, sono i livelli a cui il governo specifica, contrae, accetta e prevede di supportare logisticamente i singoli componenti di un sistema o di un CIs. Il controllo di configurazione del governo affronta sempre la linea di base funzionale e le linee di base allocate stabilite per i CIS di livello inferiore le cui specifiche sono state emesse o approvate dal governo . Pratiche di controllo della configurazione del contraente simili e correlate si applicano anche a CIS e componenti al di sotto del livello di controllo della configurazione del governo.

L’autorità di controllo della configurazione contrattuale indirizza l’insieme totale di documenti che sono baselined per il prodotto controllato da tale autorità per un contratto specifico. Questa autorità può essere l’attuale Document Change Authority (CDCA), descritta in b. di seguito, per i singoli documenti che richiedono modifiche (ad esempio, una specifica di prestazioni di sistema o CI). Se non è il CDCA per un determinato documento, non ha l’autorità di approvare una modifica proposta a tale documento e, pertanto, deve richiedere l’approvazione ECP dal CDCA applicabile o selezionare un progetto alternativo.

b. Autorità di modifica del documento corrente.

Il concetto di current document change authority (CDCA è espressione di una relazione che è sempre esistita. Prima della necessità di gestire la documentazione di configurazione con un sistema informativo automatizzato questo concetto non era chiaramente articolato, ma era incarnato nei termini “Attività di progettazione originaria” e “Attività di progettazione corrente.”Tuttavia, la definizione di tali termini si riferisce specificamente ai documenti di progettazione, ad esempio i disegni di ingegneria, al contrario di tutta la documentazione, e includono anche la responsabilità di custodia e di progettazione.

Il CDCA d’altra parte, si riferisce a specifiche o qualsiasi altro tipo di documento ed è indipendente dall’organizzazione che mantiene fisicamente e memorizza il documento. Il CDCA è l’organizzazione che ha l’autorità decisionale sul contenuto del documento, che riflette i diritti di proprietà o di dati sulle informazioni che il documento contiene. Il CDCA può essere un’attività governativa o un appaltatore e l’autorità può essere trasferita. Tuttavia c’è solo un CDCA per un documento alla volta.

Gli scenari nel riquadro illustrano la logica della designazione CDCA:

c. Attività applicativa.

Possono esserci più autorità di controllo della configurazione per un prodotto con più di un utente; ciascuna è un’autorità di controllo della configurazione per un determinato contratto. Se l’autorità di controllo della configurazione per un contratto è il CDCA per la specifica di prestazioni del sistema/CI per il prodotto, le altre autorità di controllo della configurazione sono considerate attività applicative perché la loro autorità si estende solo all’uso del prodotto e della relativa documentazione. Non possono autorizzare la modifica a nessuno dei due, ma possono partecipare al processo di controllo delle modifiche se richiesto dall’autorità di controllo della configurazione che è il CDCA o dall’attività dell’applicazione principale del governo.

È sempre stato auspicabile che il contraente trattasse un elemento attraverso un unico punto focale governativo per il coordinamento delle modifiche. Spesso questo non è stato il caso. Ogni attività governativa in genere considerava la loro autorità fondamentale e non sempre riconosceva che esistevano più autorità applicative. Poiché l’uso multiplo di elementi continua a proliferare, deve esistere un metodo logico semplice per distinguere l’autorità di controllo dall’autorità di utilizzo e per comunicare e coordinare i cambiamenti che possono avere un impatto sull’uso multiplo. A tale scopo vengono utilizzate le seguenti denominazioni di attività applicative:

• Application activity (AA) – un utente di un documento che non è il suo CDCA

• Government Lead Application authority (GLAA) – l’attività di acquisizione del governo che è stato designato come il piombo per l’acquisizione della voce. Quando assume questo ruolo, il GLAA consolida le raccomandazioni di tutte le attività di applicazione del governo ed è l’unico punto di contatto all’interno del governo per il coordinamento con il governo/Appaltatore CDCA.

6.1.1.2. Cambia classificazione.

La classificazione delle modifiche è un metodo stenografico per indicare il metodo di elaborazione e/o approvazione delle modifiche. Gli ECP che devono essere presentati al governo sono classificati come classe I o classe II. Un ECP di classe I è approvato dalla scheda di controllo della configurazione del governo e autorizzato con una modifica del contratto. Una modifica di classe II, d’altra parte, è in genere esaminata per la concorrenza nella classificazione dal rappresentante del governo locale, se non diversamente specificato nel contratto. A meno che un rappresentante del governo non sia identificato nel contratto (normalmente una persona dell’attività appaltante), il Contraente (o il cedente ECP) è responsabile dell’assegnazione della classificazione delle modifiche. Criteri simili per la classificazione delle modifiche sono contenuti in ANSI/EIA-649 dove le classificazioni delle modifiche sono indicate come modifiche “maggiori” e “minori”..

Nell’acquisizione basata sulle prestazioni, la definizione delle modifiche di classe I e di classe II è stata modificata per riflettere l’applicazione solo alle modifiche che influiscono sulla documentazione di configurazione approvata dal governo. Le modifiche alla documentazione di base del contraente devono essere esaminate dal contraente per determinare se incidono anche sui requisiti di prestazione del governo e sulle attività di supporto.

I fattori di classificazione si applicano solo alle modifiche ingegneristiche proposte alla documentazione di configurazione approvata. Sebbene l’aggiunta di una dichiarazione di attività di lavoro (come un’analisi di impatto ambientale) possa richiedere una modifica del contratto e potrebbe comportare un aumento dei costi per il governo, non è considerata una modifica ingegneristica di classe I perché né la progettazione né la documentazione di configurazione sono interessate.

Nella classificazione di un cambiamento, si deve tener conto di più della forma, dell’adattamento, della funzione o dell’interfaccia dell’IC stesso. Tutti i fattori di classificazione ECP devono essere considerati prima di classificare un ECP. I fattori includono molte considerazioni di supporto, operative e di formazione. Ad esempio, se l’appaltatore è CDCA per la documentazione della scheda, una modifica di progettazione proposta a una scheda a circuito elettronico non sarebbe una modifica di classe I da sola.. Ma se la riprogettazione richiede un cambiamento di apparecchiature di prova automatica o software di supporto per il quale il governo è responsabile, il cambiamento deve essere classificato come una classe I ECP ed elaborati di conseguenza. Va notato che cambiamenti di classe I di questo tipo che sono erroneamente classificati come classe II o considerati nella responsabilità CDCA del contraente, potrebbero comportare significativi problemi di utilizzo operativo e/o di supporto logistico e maggiori costi per il governo.

Tutte le applicazioni dell’IC interessato devono essere prese in considerazione al momento di classificare un cambiamento, ad esempio, ECPS avviato rispetto a un IC prodotto da più di un contraente, un IC che ha più applicazioni o è utilizzato da più di un’attività di tasking (applicazione). I criteri di classificazione devono essere applicati a tutte le applicazioni IC tramite il coordinamento tra le attività interessate.

6.1.1.3 Scheda di controllo di configurazione (CCB).

Le CCB governative sono istituite per i principali programmi di acquisizione. (Gli appaltatori impiegano anche un processo simile per il loro controllo della configurazione interna.) Le CCB sono generalmente costituite dal comando congiunto o dall’organismo di agenzia incaricato di agire sulle ECP di classe I e sulle richieste di deviazioni importanti o critiche. Il program manager è normalmente il presidente del CCB e prende le decisioni relative a tutte le modifiche apportate al CCB. Il CCB è un processo di gestione del programma utilizzato dal program manager per accertare tutti i vantaggi e gli impatti del cambiamento prima che la decisione sia presa. Quando viene emessa una decisione, il presidente della CCB approva una direttiva CCB, o una lettera/memorandum equivalente, che indirizza le azioni di attuazione appropriate da completare.

a. Autorità CCB.

Ogni CCB ha un’autorità limitata per approvare le modifiche in base ai seguenti fattori:

• L’autorità può essere limitata da un CCB di livello superiore, dove esiste una gerarchia di CCB su un progetto complesso

• Un CCB, all’interno di un’organizzazione che non è il CDCA per un documento, non ha l’autorità per approvare una modifica a tale documento.

• Se il CDCA è l’organizzazione che ha proposto la modifica al CCB, il CCB approva il finanziamento e l’incorporazione della modifica al prodotto, mentre il CDCA approva la modifica al documento. • Se un’organizzazione che non è il CDCA per un documento propone una modifica a un’organizzazione CCB che non è anche il CDCA per il documento (cioè, un CCB AA), il CCB AA non ha l’autorità per approvare la modifica.

• Le BCC AA possono riesaminare le modifiche proposte e formulare raccomandazioni al CDCA. Il CCB AA può decidere solo di adottare (o non adottare) una modifica approvata dal CDCA.

• L’approvazione CCB di un ECP deve talvolta essere trattenuta in attesa dell’approvazione di specifiche modifiche di documenti da parte del CDCA per tali documenti

• A volte l’approvazione CCB può essere trattenuta in attesa della ricezione delle posizioni degli utenti da parte di tutti i governi Come indicazione che adotteranno la modifica. Come indicato al punto 6.1.1.1.c, più posizioni AA dovrebbero essere coordinate da un GLAA.

b. Adesione CCB.

I membri del CCB sono normalmente composti dai principali esperti funzionali o in materia dell’organizzazione governativa, ad es. Team di programma integrato (IPT). I membri sono responsabili della consulenza del presidente della CCB. Altro personale funzionale può essere incluso, come può essere dettato dal cambiamento e / o dai requisiti del programma, compresi i rappresentanti di altri servizi DoD (per programmi di servizi congiunti) e di altri paesi (per programmi multinazionali). L’appartenenza a CCB dovrebbe consistere, ma non limitarsi a rappresentanti di logistica, formazione, ingegneria, gestione della produzione, contrattazione, gestione della configurazione e altre discipline funzionali correlate al programma. L’appartenenza a CCB è mantenuta da CCB charter.

c. Carta CCB.

Le carte CCB sono normalmente approvate attraverso i canali amministrativi ufficiali dell’attività di approvvigionamento del governo. Tutti i membri del CCB devono essere presenti a ogni riunione del CCB e devono conoscere, dal loro punto di vista funzionale, le modifiche prese in considerazione. I membri della CCB sono obbligati a rendere nota la loro posizione al presidente e, in ultima analisi, ad approvare la direttiva/ordine della CCB (quando richiesto) notando il loro accordo o disaccordo con la decisione. Per approvare la direttiva CCB (CCBD), una persona deve essere il membro primario (o supplente) CCB designato dalla carta CCB.

d. Procedure operative CCB.

L’ufficio CM dell’attività appaltante dovrebbe pubblicare le procedure per il funzionamento di CCB in modo che tutti i membri comprendano la sua importanza per il processo di acquisizione. Un segretariato CCB pianifica le riunioni, distribuisce ordini del giorno, registra le decisioni CCB e distribuisce verbali e direttive alle parti a cui sono assegnate azioni di attuazione o che hanno bisogno di sapere. Le procedure operative della CCB dovrebbero anche definire i tempi di elaborazione degli obiettivi per gli ECP al fine di garantire la tempestività del personale, l’approvazione e l’attuazione.

6.1.1.4 Efficacia.

L’efficacia di un ECP identifica la quantità o la gamma di CIS che devono essere modificati, inclusi sia l’incorporazione della produzione che il retrofit dei CIS consegnati. L’instaurazione dell’efficacia dell’ECP richiede che l’attività appaltante tenga conto di fattori quali i seguenti:

• Urgenza – Correggere una carenza che coinvolge la sicurezza del personale può essere abbastanza significativo da ignorare tutte le altre considerazioni, anche il supporto simultaneo. Se vengono poste limitazioni operative sulle apparecchiature in attesa della risoluzione di un problema di sicurezza, l’efficacia operativa può essere fortemente limitata

• Inventario – Parti e materiali a disposizione devono essere considerati; una decisione basata su costi e compromessi operativi deve essere presa per utilizzare materiali esistenti per esaurire o per rottamare l’inventario corrente. Questo vale sia per l’inventario del contraente che per le parti di ricambio e di riparazione immagazzinate dal governo

• Configurazioni: uno degli obiettivi chiave della gestione della configurazione è ridurre al minimo il numero di diverse configurazioni CI che devono essere supportate simultaneamente, in particolare se le diverse configurazioni CI richiedono software operativo, attrezzature di supporto, software di supporto, ricambi, Poiché tutte le configurazioni CI esistenti spesso non possono essere aggiornate simultaneamente, è necessario considerare attentamente il ritardo o l’accelerazione dell’incorporazione della modifica per ridurre al minimo l’impatto. L’impostazione dell’efficacia di un futuro blocco definito del CIs può essere una soluzione. La combinazione o il confezionamento di una serie di modifiche software nella versione successiva potrebbe essere un’altra, ecc.

• Lead Time-Ci sono molti tempi di consegna da considerare quando si identifica l’efficacia di un cambiamento. I tempi di produzione/approvvigionamento necessari per completare lo sforzo di progettazione non ricorrente, procurarsi parti e materiali e incorporare il cambiamento sia nella produzione che/o nel retrofit devono essere considerati. Anche il tempo di consegna amministrativo richiesto per l’elaborazione della modifica per l’approvazione è fondamentale. Il governo e il contraente hanno la responsabilità di evitare ritardi nell’elaborazione dei cambiamenti, in particolare quando ci sono grandi quantità di IC in produzione e nell’inventario operativo che devono essere adattati. Il costo del rinvio di una decisione può comportare la consegna di ulteriori configurazioni obsolete che dovranno essere adattate. Spesso, il costo ricorrente della sostituzione dei componenti nella produzione è semplicemente la sostituzione di un insieme di costo uguale o inferiore per un altro; mentre il retrofitting dello stesso cambiamento comporta il costo di entrambi gli insiemi, nonché il costo aggiuntivo di smontaggio e sostituzione.

• Tempistica-Potrebbe essere necessario selezionare l’efficacia in modo che una determinata capacità operativa sia disponibile in un dato momento o per un evento specifico come uno spiegamento di forze pianificato o un’esercitazione.

La tabella 6-1 fornisce una guida alle attività per la valutazione di un processo di controllo della configurazione.

Tabella 6-1. Guida alle attività: Controllo della configurazione Checklist di valutazione del processo

L’autorità concorrente di classe II è stata delegata agli appaltatori in molti casi come risultato di proposte di Single Process initiative (SPI). Tuttavia, l’autorità di omologazione di classe II può essere delegata agli appaltatori solo per i documenti per i quali sono il CDCA

Per una corretta applicazione di queste informazioni, vedere la NOTA alla pagina dei contenuti