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.
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):
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)
|
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]:
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).
Stati della richiesta di modifica nel contesto del cubo CM.
|