Operazione: Verify Changes in Build
In questa attività viene definito come verificare il completamento di una richiesta di modifica.
Scopo
  • Tale attività conferma che una richiesta di modifica è stata completata, di solito, attraverso l'esecuzione di un sottoinsieme di test su uno o più build.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Passi
Risoluzione della richiesta di modifica

Il ruolo assegnato esegue la serie di attività definite all'interno della sezione appropriata del processo di distribuzione come i requisiti, l'analisi & la progettazione, l'implementazione, la produzione di materiali di supporto per l'utente e la progettazione di test. Tali attività comprenderanno tutte le usuali attività di revisione e di test come descritte nel normale processo di sviluppo. La richiesta di modifica viene quindi contrassegnata come Risolta. Ciò significa che è stata portata a termine la risoluzione della richiesta di modifica e ora è pronta per la verifica.

Verifica modifiche nella versione test

Dopo che le modifiche sono state Risolte da un ruolo assegnato (analista, sviluppatore, tester, autore tecnico e così via), vengono collocate in una coda di test da assegnare ad un tester e devono essere Verificate in una versione di prova del prodotto. Una richiesta di modifica che è stata Verificata in una versione prova è pronta per essere inclusa in un rilascio. Una richiesta di modifica che ha avuto esito negativo durante la verifica nella versione di test o nella versione di rilascio verrà posta nello stato Test non riuscito. Diviene automaticamente proprietario della richiesta la persona che l'aveva inoltrata.

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, per produrre le note sul rilascio, ecc. e la richiesta di modifica viene Chiusa.

Una richiesta di modifica Chiusa CR 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 e-mail, 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 Respinto 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 e Inoltrata di nuovo per l'analisi CCB.

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

Valutazione e verifica dei risultati
Scopo:  Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti siano accettabili. 

Una volta completato il lavoro è bene verificare che questo sia stato di buona qualità, e che non si siano consumate unicamente grosse quantità di carta. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.

Richiedere ai componenti del team di concentrarsi sul flusso di operazioni che hanno come input il vostro lavoro e partecipare all'analisi effettuata durante il suo corso. Procedere in questo modo mentre si ha ancora tempo a disposizione per prendere decisioni e discutere delle loro considerazioni. È inoltre necessario considerare il proprio lavoro nei confronti dei prodotti di lavoro di input chiave, per assicurarsi che siano stati rappresentati in modo accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il vostro lavoro su queste basi.

Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel tempo. Su questa base è spesso non necessario o addirittura controproducente, definire in modo completo un prodotto di lavoro che verrà utilizzato solo parzialmente o affatto, nel lavoro immediatamente successivo. Questo perché vi è un'alta probabilità che il contesto che circonda il prodotto di lavoro possa cambiare e che i presupposti definiti, quando questo è stato creato, possano dimostrarsi errati prima del suo utilizzo, portando così al dispendio inutile di sforzi ed ad ulteriori costi di rilavorazione. Non effettuare inoltre troppi cicli sulla presentazione per evitare il detrimento del valore del contenuto. Negli ambienti di progetto dove la presentazione ha la medesima importanza e valore economico di un componente distribuibile, è bene considerare la possibilità di utilizzare una risorsa amministrativa per il compito di presentazione.



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