Concetto: Gestione delle richieste di modifica
La gestione delle richieste di modifica è un processo atto a garantire l'utilizzo di metodi e procedure standard per una gestione pronta ed efficiente di tutti i cambiamenti, per ridurre al minimo l'impatto di incidenti relativi alle modifiche.
Relazioni
Descrizione principale

Definizioni

Richiesta di modifica (CR) - Un prodotto di lavoro inoltrato formalmente, utilizzato per tenere traccia di tutte le richieste degli stakeholder (i portatori d'interesse), ad esempio nuove funzioni, richieste di miglioramenti, difetti, requisiti cambiati ed informazioni relative allo stato, durante tutto il ciclo di vita del progetto. La cronologia completa della modifica viene conservata con la Richiesta di modifica, inclusi tutti i cambiamenti di stato con le relative date e motivazioni del cambiamento. Queste informazioni saranno disponibili per qualsiasi analisi ripetuta e per la chiusura finale.

Change (o Configuration) Control Board (CCB) - Il quadro di controllo che sovrintende il processo della modifica composto da rappresentanti di tutte le parti interessate, inclusi i clienti, gli sviluppatori e gli utenti. In un progetto di dimensioni ridotte, può assumere questo ruolo un unico membro del team di lavoro, ad esempio il responsabile di progetto o l'architetto del software. In RUP (Rational Unified Process) viene rappresentato dal ruolo di Responsabile del controllo della modifica.

Riunione di analisi CCB - La funzione di questo tipo di riunione è di esaminare le richieste di modifica Inoltrate. Nella riunione viene effettuata un'analisi iniziale del contenuto della richiesta di modifica per stabilire se si tratta di una richiesta valida. In caso affermativo, viene fatta una valutazione per determinare se la modifica faccia parte o meno dell'ambito relativo al rilascio corrente, in base alla priorità, ai tempi, alle risorse, al livello di impegno, al rischio, alla severità e ad altri importanti criteri, come stabilito dal gruppo. Di solito questo tipo di riunione si tiene una volta a settimana. Se il volume della richiesta di modifica aumenta considerevolmente o se si avvicina il termine del ciclo di un rilascio, la riunione può essere indetta anche quotidianamente. I tipici partecipanti di una riunione di analisi CCB sono il responsabile test, il responsabile sviluppo ed un membro del reparto di marketing. In base alle esigenze, i membri della riunione possono ritenere necessaria la presenza di ulteriori partecipanti.

Modulo di inoltro richiesta di modifica - Questo modulo viene visualizzato quando una richiesta di modifica viene Inoltrata per la prima volta. Sul modulo sono visualizzati solo i campi necessari alla persona che effettua l'inoltro.

Modulo richiesta di modifica combinato - Questo modulo viene visualizzato quando si sta visualizzando una richiesta di modifica già inoltrata. Contiene tutti i campi necessari per descrivere la richiesta di modifica.

La struttura del processo di richiesta di modifica riportata di seguito descrive le condizioni e gli stati delle richieste di modifica per tutta la durata del processo e chi deve essere informato durante il ciclo di vita della richiesta di modifica. Il processo generale associato alle richieste di modifica viene descritto nella sezione  Attività: Processo di controllo della modifica.

Esempi di attività per la gestione delle richieste di modifica

L'esempio che segue mostra le attività che un progetto potrebbe utilizzare per gestire una CR durante il suo ciclo di vita (selezionare le voci del diagramma per visualizzarne le descrizioni):

CR chiusa Test non riuscito Verifica modifiche nella versione rilascio CR Chiusa Conferma duplicato o respingi Inoltrata Altre informazioni Aggiorna CR Inoltrata Respingi Duplicato Verificata Verifica modifiche nella versione test Test non riuscito Apporta modifiche Risolta Respingi Duplicato Verifica modifiche nella versione test Assegnata Assegna e pianifica lavoro Inoltra CR Assegna e pianifica lavoro Aperta Esamina CR Rinviata Inoltrata Richiesta di modifica (CR) Quadro controllo modifica (CCB) Inoltra CR Diagramma descritto nella tabella precedente.

Descrizioni delle attività di esempio del processo CRM (Change Request Management, gestione della richiesta di modifica):

Attività Descrizione Responsabilità
Inoltra CR Qualunque stakeholder può inoltrare una CR (Change Request, richiesta di modifica). La richiesta di modifica viene registrata nel sistema di traccia delle richieste di modifica (ad es. Rational ClearQuest) e viene collocata nella coda di analisi CCB, impostando lo stato della richiesta di modifica su Inoltrata. Persona che ha inoltrato
Esamina CR La funzione di questa attività è di rivedere le richieste di modifica Inoltrate. Un esame iniziale del contenuto della richiesta di modifica viene effettuata durante la riunione per l'analisi del CCB, per stabilire se si tratta di una richiesta valida. In caso affermativo, viene fatta una valutazione per determinare se la modifica faccia parte o meno dell'ambito relativo al rilascio corrente, in base alla priorità, ai tempi, alle risorse, al livello di impegno, al rischio, alla severità e ad altri importanti criteri, come stabilito dal gruppo. CCB
Conferma duplicato o respingi Se si sospetta che una richiesta di modifica sia un Duplicato o sia stata Respinta come richiesta non valida (ad es., errore dell'operatore, non riproducibile, funziona come progettato, ecc.), ad un delegato del CCB viene assegnato il compito di confermare il duplicato o di respingerlo e di raccogliere ulteriori informazioni dalla persona che ha inoltrato la richiesta di modifica, se necessario. Delegato CCB
Aggiorna CR Se sono necessarie ulteriori informazioni (Altre informazioni) per valutare una richiesta di modifica o se questa viene respinta in una qualunque fase del processo (ad es., confermata come Duplicato, Respinta, ecc.), la persona che l'ha inoltrata ne viene informata e può aggiornare la richiesta di modifica con le nuove informazioni. La richiesta di modifica aggiornata viene quindi reinoltrata alla coda di analisi CCB per la valutazione dei nuovi dati. Persona che ha inoltrato
Assegna e pianifica lavoro Una volta Aperta la richiesta di modifica, il responsabile progetto assegna il lavoro al membro appropriato del team, in base al tipo di richiesta (ad es., richiesta di miglioramento, difetto, modifica alla documentazione, difetto durante il test, ecc.) ed effettua gli eventuali aggiornamenti alla pianificazione del progetto. Responsabile progetto
Apporta modifiche Il membro assegnato del team esegue la serie di attività definite nella sezione appropriata del processo, ad esempio requisiti, analisi e progettazione, implementazione, produzione di materiali di supporto per l'utente e progettazione di test per effettuare le modifiche richieste. Sono incluse tutte le usuali attività di revisione e di test descritte in un normale processo di sviluppo. La richiesta di modifica viene quindi contrassegnata come Risolta. Membro assegnato del team di lavoro
Verifica modifiche nella versione test Una volta Risolte dal membro assegnato del team di lavoro (analista, sviluppatore, tester, autore tecnico, ecc.), le modifiche vengono collocate in una coda di test da assegnare ad un tester e devono essere Verificate in una versione di prova del prodotto. Tester
Verifica modifiche nella versione rilascio Una volta che le modifiche risolte sono state Verificate in una versione di prova del prodotto, la richiesta di modifica viene collocata in una coda rilasci per essere verificata in una versione di rilascio del prodotto, note sul rilascio del prodotto, ecc. e viene Chiusa la richiesta di modifica. Delegato CCB (integratore di sistema)

Esempi di stati e transizioni di una richiesta di modifica

Il seguente diagramma mostra degli esempi di stati e chi deve essere informato durante il ciclo di vita di una CR (Change Request, richiesta di modifica) [Selezionare le voci del diagramma per visualizzarne le descrizioni]:

Riunione di analisi CCB Altre informazioni Altre informazioni Aggiorna CR Aggiorna CR Conferma duplicato o respingi Verifica modifiche nella versione rilascio Chiusa Altre informazioni Verificata Duplicato Respingi Riunione di analisi CCB Inoltra CR Inoltrata Test non riuscito Verifica modifiche nella versione test Risolta Apporta modifiche Aperta Assegna e pianifica lavoro Assegnata Rinviata Richiesta di modifica (CR) Diagramma descritto nella tabella precedente.

Descrizioni degli stati di esempio della gestione della richiesta di modifica (CRM):

Stato Definizione Controllo accesso
Inoltrata Questo stato si verifica con 1) l'invio di una nuova richiesta di modifica, 2) l'aggiornamento di una richiesta di modifica esistente o 3) la valutazione di una richiesta di modifica Rinviata per il ciclo di un nuovo rilascio. La richiesta di modifica viene collocata nella coda dell'analisi CCB. A questa azione non viene assegnato alcun proprietario. Tutti gli utenti
Rinviata La richiesta di modifica viene considerata valida ma "al di fuori dell'ambito" del rilascio corrente. Le richieste di modifica in stato Rinviata verranno conservate e riconsiderate per i rilasci futuri. Può essere assegnato un obiettivo di rilascio per indicare il lasso di tempo in cui la richiesta modifica può essere Inoltrata e rientrare nella coda dell'analisi CCB. Ammininstratore

Responsabile progetto

Duplicato Una richiesta di valutazione in questo stato è considerata il duplicato di un'altra richiesta di modifica che è stata già inoltrata. Le richieste di modifica possono essere collocate in questo stato dall'amministratore CCB Review dell'analisi CCB o dal membro del team che è stato assegnato a risolvere la richiesta. Quando la richiesta di modifica viene collocata in stato Duplicato, il numero CR che duplica verrà registrato (nella scheda Allegati in ClearQuest). Prima di inoltrare una richiesta di modifica, è necessario cercare nel database delle richieste eventuali duplicati. Questo evita di dover eseguire svariati passi nel processo di revisione e quindi porta ad un notevole risparmio di tempo. Le persone che hanno inoltrato delle richieste di modifica duplicate devono essere aggiunte all'elenco di notifiche della richiesta originale, per future informazioni relative alla risoluzione. Ammininstratore

Responsabile progetto

Responsabile QE

Sviluppo

Respinta Una richiesta di modifica viene definita in questo stato durante una riunione di analisi CCB o da un membro assegnato del team quando non è valida oppure sono necessarie ulteriori informazioni da parte della persona che l'ha inoltrata. Se è stata già assegnata (Apri), la richiesta di modifica viene rimossa dalla coda di risoluzione e viene esaminata di nuovo. Un'autorità designata del CCB le viene assegnata per la conferma. Non sono richieste azioni da parte della persona che l'ha inoltrata a meno che non sia ritenuto necessario, nel qual caso lo stato della richiesta di modifica viene modificato in Altre informazioni. La richiesta di modifica viene esaminata di nuovo nella riunione di analisi CCB valutando le eventuali nuove informazioni. Se ne viene confermata la non validità, la richiesta di modifica viene Chiusa dal CCB e viene informata la persona che l'aveva inoltrata. Ammininstratore

Responsabile progetto

Responsabile sviluppo

Responsabile test

Altre informazioni Non sono disponibili dati sufficienti a confermare la validità di una richiesta Respinta o di Duplicata. Diviene automaticamente proprietario della richiesta la persona che l'aveva inoltrata e gli viene richiesto di fornire ulteriori dati. Ammininstratore
Aperta Una richiesta di modifica in questo stato viene considerata inclusa "nell'ambito" del rilascio corrente ed è in attesa di risoluzione. E' predisposta per la risoluzione prima del successivo obiettivo cardine. Viene definita come appartenente alla "coda di assegnazione". I membri della riunione sono le uniche autorità in grado di attivare una richiesta di modifica nella coda di risoluzione. Se viene individuata una richiesta di modifica con priorità due o superiore, deve essere immediatamente portata all'attenzione del responsabile QE o di sviluppo. A quel punto possono decidere di indire una riunione di analisi CCB straordinaria oppure attivare immediatamente la richiesta di modifica nella coda di risoluzione. Ammininstratore

Responsabile progetto

Responsabile sviluppo

Reparto QE

Assegnata Una richiesta di modifica Aperta diviene quindi compito del responsabile progetto assegnare il lavoro in base al tipo di richiesta di modifica e, se necessario, aggiornare la pianificazione. Responsabile progetto
Risolta Significa che è stata portata a termine la risoluzione della richiesta di modifica e ora è pronta per la verifica. Se la persona che inoltrato la richiesta è membro del reparto QE, ne diviene automaticamente il proprietario; altrimenti, il ruolo di proprietario passa al responsabile QE che deve manualmente riassegnare la richiesta. Ammininstratore

Responsabile progetto

Responsabile sviluppo

Responsabile QE

Reparto di sviluppo

Test non riuscito Viene posta in questo stato una richiesta di modifica che ha avuto esito negativo durante la verifica nella versione di test o nella versione di rilascio. Diviene automaticamente proprietario della richiesta di modifica il membro del team che l'aveva risolta. Ammininstratore

Reparto QE

Verificata Una richiesta di modifica in questo stato è stata Verificata in una versione di prova ed è pronta per essere inclusa in un rilascio. Ammininstratore

Reparto QE

Chiusa La richiesta di modifica non richiede più interventi. Si tratta dello stato finale assegnato ad una richiesta di modifica. Solo l'amministratore dell'analisi CCB ha l'autorizzazione a chiudere una richiesta di modifica. Quando una richiesta di modifica viene Chiusa, la persona che ha inoltrato la richiesta riceve una notifica tramite email, con le ultime disposizioni relative alla richiesta. Una richiesta di modifica può essere Chiusa: 1) dopo che la sua risoluzione Verificata viene convalidata in una versione rilascio, 2) quando viene confermato il suo stato Respinta oppure 3) quando viene confermata come Duplicato di una richiesta di modifica esistente. In quest'ultimo caso, la persona che ha inoltrato la richiesta verrà informata del duplicato di richiesta di modifica e verrà aggiunta alla richiesta originaria per future notifiche (per ulteriori dettagli consultare le definizioni degli stati "Respinta" e "Duplicato"). Se la persona che ha inoltrato la richiesta desidera contestarne la chiusura, la richiesta di modifica deve essere aggiornata ed Inoltrata di nuovo per l'analisi CCB. Ammininstratore

I 'tag' dello stato forniscono le basi per riportare le statistiche relative alla richiesta di modifica (epoca, distribuzione o trend).

Diagramma descritto nella tabella precedente.

Stati della richiesta di modifica nel contesto del cubo CM.