Scopo: modificare le procedure di controllo per assicurare che le modifiche proposte a un
sistema vengano valutate e applicate in modo coerente e controllato.
|
Fasi secondarie
|
Guida al tool
|
Per ulteriori informazioni: Concetto: Gestione delle richieste di 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)
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)
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.
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.
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.
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
|