Operazione: Analisi richiesta di modifica
Questo compito definisce come eseguire il triage della richiesta di modifica.
Discipline: Gestione modifiche e configurazione
Scopo
  • L'obiettivo di questo compito è determinare se la richiesta di modifica (CR) deve essere accettata o segnalata per il rifiuto. Questo compito valuta le priorità, l'impegno, i tempi e così via per le CR accettate per determinare se la modifica è nell'ambito del corrente rilascio.
Relazioni
Passi
Pianificazione della Riunione di analisi CCB

Il CCB (Change or Configuration Control Board) è il quadro di controllo che supervisiona il processo di modifica, formato da rappresentanti di tutte le parti interessate, compresi i clienti, gli sviluppatori e gli utenti. In un piccolo progetto, una singola persona, quale il responsabile del progetto o l'architetto di software, potrà avere questo ruolo. In Rational Unified Process (RUP), questo viene mostrato dal ruolo di Gestore del controllo delle modifiche.

La funzione di questa riunione è quella di analizzare le richieste di modifica inoltrate. Si effettua un'analisi iniziale dei contenuti della CR per determinare se la richiesta è valida. In caso affermativo, si determina se la modifica è interna o esterna all'ambito del rilascio corrente, in base alle priorità, tempi, risorse, livello di impegno, rischio, gravità e qualsiasi altro criterio rilevante determinato dal gruppo. Questa riunione si effettua solitamente una volta a settimana. Se il numero di CR aumenta sostanzialmente, o in prossimità del termine del ciclo di rilascio, si potrà tenere la riunione fino ad una volta al giorno. Solitamente i partecipanti alla Riunione di analisi CCB sono i gestori del test, i responsabili di sviluppo ed un membro del reparto marketing. Si potrebbe ritenere necessario l'apporto di ulteriori partecipanti a seconda delle esigenze.

Recupero della richiesta di modifica per analisi

Il modulo di richiesta di modifica è un prodotto di lavoro formalmente inoltrato utilizzato per tenere traccia di tutte le richieste, comprese nuove funzioni, miglioramenti, errori, requisiti di modifica e così via. Ciò comprende le informazioni di stato relative al ciclo 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.

Analisi delle richieste di modifica inoltrate

La funzione di questo compito è quella di analizzare le richieste di modifica inoltrate. Questa condizione si verifica quando 1) viene inoltrata una nuova CR, 2) viene aggiornata una CR esistente oppure 3) si valuta la possibilità di Rinviare la CR ad un nuovo ciclo di rilascio. Le CR vengono inserite nella coda di analisi CCB. In questa fase non avviene nessuna consegna.

Un'analisi iniziale dei contenuti della CR viene effettuata nella riunione di analisi CCB per determinare se le richieste sono valide. In caso affermativo, si determina se la modifica è interna o esterna all'ambito del rilascio corrente, in base alle priorità, tempi, risorse, livello di impegno, rischio, gravità e qualsiasi altro criterio rilevante determinato dal gruppo.

Se si determina che la CR è valida, ma "fuori dell'ambito" del rilascio corrente le si assegnerà uno stato Rinviata e la si prenderà in considerazione per rilasci futuri. Si potrà assegnare un rilascio di destinazione per indicare un periodo di tempo in cui la CR potrà essere inoltrata per accedere nuovamente alla coda dell'analisi CCB.

Se si pensa che una CR sia il duplicato di un'altra CR già inoltrata, la si deve assegnare al gestore dell'analisi CCB o al membro del team assegnato per risolverla. Quando si assegna lo stato di Duplicata ad una CR, si registra il numero della CR di cui è il duplicato (nella scheda Allegati o ClearQuest). Colui che inoltra la CR dovrebbe prima effettuare una ricerca nel DB per controllare se la sua CR è stata già inoltrata. Ciò eviterà diverse fasi del processo di analisi e di risparmiare un sacco di tempo. Coloro che hanno inoltrato una CR duplicata devono essere inseriti nell'elenco di notifica della CR originaria per future notifiche riguardanti la soluzione.

A volte nella Riunione di analisi CCB o il membro del team assegnato determinano che una CR non sia valida o che si necessità di maggiori informazioni. Se è stata già assegnata (Aperta), la CR viene rimossa dalla coda di risoluzione e viene nuovamente analizzata. Un'autorità designata del CCB dovrà confermare. Non sono richieste azioni da parte della persona che ha inoltrato la richiesta se non si ritiene esplicitamente necessario, in questo caso lo stato della CR verrà cambiato in Altre informazioni. La CR verrà nuovamente analizzata nella Riunione di analisi CCB valutando le nuove informazioni. Se si conferma non valida, la CR verrà Chiusa dal CCB e la persona che ha inoltrato la richiesta verrà notificata.

Se si determina che la CR fa parte dell'ambito del rilascio corrente le si assegna lo stato Aperta in attesa di soluzione. Significa che è stata messa in lista per essere risolta prima del successivo punto cardine di destinazione. La si definisce come parte della "coda di assegnazione". I membri della riunione sono l'unica autorità che può aprire una CR nella coda di risoluzione. Se si trova una CR con priorità due o maggiore, la si dovrà portare immediatamente all'attenzione del QE o del responsabile di progetto. A questo punto essi potranno decidere di effettuare una Riunione di analisi CCB di emergenza o semplicemente aprire la CR nella coda di risoluzione immediatamente.

Una CR Aperta richiede al responsabile di progetto di assegnare il lavoro sulla base del tipo di CR e di aggiornare la pianificazione, se necessario.

Gli stati di una richiesta di modifica (CR) possono variare come mostrato in Gestione della richiesta di modifica.



Ulteriori informazioni