Operazione: Establish Change Control Process
Questa attività definisce come creare un processo di controllo delle modifiche.
Scopo

L'obiettivo di avere processi di controllo delle modifiche standard e documentati è quello di assicurare che le modifiche vengano fatte all'interno di un progetto in modo coerente e che gli stakeholder appropriati vengano informati sullo stato del prodotto, delle modifiche apportate e dell'impatto di tali modifiche sui costi e sulla pianificazione.

Relazioni
Passi
Determinazione del processo di richiesta modifica

Una tipica procedura per lagestione delle richieste di modifica è quella di mostrare il seguente diagramma di attività. (Fare clic su qualsiasi parte del diagramma per avere una descrizione completa del Concetto: Gestione della richiesta di modifica)

Attività di esempio per la gestione delle richieste di modifica inizio pagina

Concetti: Gestione delle richieste di modifica Flusso del processo di richieste di modifica tra il proponente, il CCB, un lavoratore assegnato e un tester.

Completamento del modulo di richiesta di modifica inizio pagina

Il modulo della richiesta di modifica Š una risorsa inoltrata formalmente utilizzata per tenere traccia di tutte le richieste (che include nuove funzioni, richieste di potenziamento, difetti, requisiti modificati, ecc.). Dovrebbe includere le relative informazioni di stato per tutto il ciclo di vita del progetto. Tutta la cronologia della modifica sarà contenuta nella CR, comprese le modifiche di stato assieme alle date ed ai motivi della modifica. Queste informazioni saranno disponibili per qualsiasi analisi ripetuta e per la chiusura finale. Un esempio di richiesta di modifica Š riportata in Prodotto di lavoro: Richieste di modifica.

Gli stati tipici che una richiesta di modifica potrebbe attraversare sono descritti nel seguente diagramma di stato. (Fare clic su qualsiasi parte del diagramma per avere una descrizione completa del Concetto: Gestione della richiesta di modifica)

Stati e transizioni di esempio per una richiesta di modifica inizio pagina

Concetti: Gestione delle richieste di modifica Flusso di processo per una nuova richiesta di modifica. Gli stati possibili sono Inoltrata, Rinviata, Respinta, Assegnata, Risolta e Verificata.

Analisi della richiesta di modifica inizio pagina

Dopo essere stata inoltrata, una richiesta di modifica viene analizzata per assicurare che sia effettivamente valida e che il personale tecnico e di gestione appropriato la riesamini per valutarne la validità. Le richieste di modifica devono essere valutate a vari livelli all'interno del team di sviluppo. Un responsabile del team spesso revisiona e approva le richieste di modifica inoltrate da qualcuno del suo personale. Se, tuttavia, lo scopo di una modifica va oltre le responsabilità del team, viene portata al successivo livello di revisione. Se l'impatto della modifica si estende su parecchi team di sviluppo differenti, viene revisionata dal Quadro controllo modifica. Nel Rational Unified Process, il ruolo di responsabile del controllo della modifica viene utilizzato per rappresentare il ruolo di CCB (Change Control Board, Quadro controllo modifica).

Occasionalmente, il malfunzionamento di un sistema può essere dovuto più al suo utilizzo che alla sua implementazione. Potrebbe anche essere il caso in cui il problema sia stato già segnalato e indirizzato.

Il risultato della fase di analisi è di accettare o rifiutare la richiesta di modifica sulla base che non è valida, è duplicata oppure esterna allo scopo del progetto corrente.

Valutazione dei costi della richiesta di modifica inizio pagina

Per le modifiche valide, la fase successiva è quella di valutare i costi della modifica in base all'impatto sull'intero sistema e la facilità di implementazione.

Le informazioni provenienti dalla fase di determinazione dei costi vengono fornite al CCB per la valutazione. Il CCB esamina la richiesta di modifica e il relativo impatto da un punto di vista strategico, organizzativo e tecnico. Il CCB deve decidere se una richiesta di modifica può essere economicamente giustificata.

Applicazione della richiesta di modifica inizio pagina

Dopo essere stata approvata, la richiesta di modifica può essere applicata al software. Il software modificato viene quindi sottoposto a controlli di qualità per assicurare che le modifiche apportate siano in armonia con le norme del progetto adottate e che non abbiano effetti indesiderati sulle altre parti di software esistente.

Dopo aver eseguito le modifiche, la nuova versione del software viene verificata in un build di prova del prodotto e quindi incorporata in una versione di rilascio verificata del software completo.

Manutenzione della cronologia delle modifiche inizio pagina

Poiché si apportano modifiche al software, è importante che venga mantenuto un record di tutte le modifiche.

Un modo efficiente per mantenere una cronologia delle modifiche è all'inizio di ogni componente software e all'interno delle richieste di modifica.

Un esempio del tipo di modifica di dati da conservare in una intestazione di componente potrebbe essere la seguente:

Cronologia delle modifiche

Versione Modificatore Data Modifica Ragione

1.1 Bruce Bogtrotter 98.05.01 Intervalli di test CR#232

1.2 Maria Mussolini 98.06.02 Requisiti CR#454

Determinazione del Quadro controllo modifica
Scopo Determinare un CCB (Change Control Board, Quadro controllo modifica) che approverà tutte le modifiche degli elementi di configurazione definiti. L'obiettivo del team è quello di assicurare che tutte le modifiche proposte ricevano analisi e revisione tecnica appropriate e siano documentate a fini di tracciamento e controllo. 
Fasi secondarie

Il CCB si riunisce su base regolare e quando richiesto.

Le attività di base del CCB sono quelle di dichiarare le linee base del prodotto, esaminare le modifiche a tali linee e approvare, disapprovare o rimandare la loro implementazione.

Selezione membri inizio pagina

L'obiettivo di questa fase è di creare un CCB composto da "persone giuste" con autorità effettiva e sufficiente esperienza nel prevenire proposte di modifica imprudenti e costose. Il CCB deve essere composta da rappresentanti di tutte le organizzazioni interessare o da stakeholder quali:

  • Utenti
  • Sviluppatori
  • Gruppo di test
  • Gestione progetto

Designazione della presidenza di CCB inizio pagina

Il presidente del CCB deve provenire dall'ufficio di gestione del progetto. La presidenza deve essere in grado di risolvere i conflitti senza ambiguità all'interno del team e far osservare le decisioni del team sul progetto.

Le decisioni del CCB dovrebbero essere prese all'unanimità ogni volta che è possibile. La dinamica di gruppo riflette la natura cooperativa del progetto di sviluppo. Il ruolo del presidente è di alimentare questa visione cooperativa e svolgere azioni unilaterali se necessario.

Incontro per la valutazione delle proposte di modifica inizio pagina

Il CCB deve riunirsi su base regolare e quando richiesto, per assicurare che le proposte di modifica vengano esaminate e disposte in tempi ragionevoli. Il team di sviluppo deve vedere questo gruppo come un gruppo affidabile per la risoluzione dei problemi che potrebbero altrimenti bloccare l'avanzamento del progetto.

Definizione dei protocolli di notifica di revisione di modifica
Scopo L'obiettivo dei protocolli di notifica di revisione di modifica è quello di assicurare che i membri appropriati del personale siano avvisati quando vengono inoltrate richieste di modifica.
Decidere chi dovrebbe revisionare i vari prodotti di lavoro. 
Guida al tool:  Definizione delle notifiche di modifica e revisione utilizzando Rational ClearQuest

L'input in questa fase è dato dall'elenco di prodotti di lavoro da sviluppare durante il corso del progetto.

I membri del personale devono esaminare il prodotto relativo ai prodotti di lavoro per decidere se soddisfa gli standard definiti di qualità del progetto per essere passato alla fase successiva dello sviluppo. Se un prodotto non supera un esame, viene sottoposto a rilavorazione, modifica e riesame.

Affinché un esame sia efficace, il prodotto deve essere verificato dal personale appropriato che conosce lo scopo e l'impatto di una modifica o miglioramento proposti. Inoltre, le revisioni devono essere efficaci, in modo che il tempo lavorativo di implementatori e integratori fondamentali non venga sprecato su difetti dal minimo impatto.

I membri del personale che devono essere coinvolti in una revisione, sono rappresentanti del produttore, del destinatario e della gestione del prodotto. Ciò per assicurare che tutti gli stakeholder con un interesse legittimo nel la qualità del prodotto possano decidere se il prodotto può avanzare al successivo livello di sviluppo.

Nell'ambiente del team, l'intero progetto viene suddiviso in attività. Le attività vengono assegnate a singoli responsabili per l'implementazione e l'integrazione. Ad esempio, l'intero sistema viene suddiviso in sottosistemi e quindi in singoli pacchetti. I membri del team responsabili dell'implementazione di un pacchetto devono essere sicuri che le loro modifiche siano state revisionate dai pari livello all'interno del sottosistema e qualsiasi altra persona negli altri sistemi può ricevere gli effetti delle modifiche.

Il principio di notifica di revisione e modifica è quello di comunicare ai pari livello e ai responsabili del team e ai destinatari delle modifiche proposte, in modo da offrire l'opportunità di esaminare e commentare le proposte.

Una guida supplementare a questo argomento viene fornita inConcetto: Gestione delle richieste di modifica.


 

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni