Artefatto: Richiesta di modifica (CR - Change Request)
Questi artefatti vengono utilizzati per documentare e seguire le richiese di una modifica al prodotto. Questo fornisce una registrazione delle decisioni ed assicura, con un appropriato processo di valutazione, che venga preso in considerazione l'impatto di modifica della richiesta.
Domini: Gestione modifiche e configurazione
Tipi di prodotto di lavoro: Dati del progetto
Scopo
  • Formulazione e traccia delle modifiche e dei difetti
Relazioni
RuoliResponsabile: Modificato da:
OperazioniInput in:
Output di:
Utilizzo del processo
Descrizione
Descrizione principale

La necessità di cambiare è prerogativa dello sviluppo di un sistema software poiché si evolve durante la sua creazione iniziale e viene quindi utilizzato e gestito nelle operazioni giorno per giorno in un ambiente vivo. Le richieste di modifica forniscono una registrazione delle decisioni e, con un appropriato processo di valutazione, assicurano che venga considerato il loro impatto di modifica.

 La Richiesta di modifica è nota anche con altri nomi, ad esempio CR, difetto, bug, incidente, richieste di miglioramento. L'acquisizione e la gestione di queste richieste assicura in modo appropriato che le modifiche ad un sistema vengano eseguite in maniera controllata, in modo da poter prevedere il loro effetto sul sistema. Alcuni tipi di importazione di Richiesta di modifica includono:

Le richieste di miglioramento, utilizzate da vari stakeholder per richiedere future funzioni che loro desiderano incluse nel prodotto. Si tratta di un tipo di richiesta dello stakeholder che cattura ed articola una comprensione delle esigenze dello stakeholder.

I difetti sono delle segnalazioni di anomalie o errori contenuti in un prodotto di lavoro distribuito. I difetti comprendono le omissioni e le imperfezioni rilevate durante le prime fasi del ciclo di vita, o i sintomi di errore (malfunzionamenti) che devono essere isolati e corretti nel software. I difetti possono anche includere le deviazioni da quello che ci si può essere ragionevolmente attendere dal comportamento del software (ad esempio problematiche di utilizzabilità).

Lo scopo di un difetto è di comunicare i dettagli della problematica, abilitando l'azione correttiva, la risoluzione e traccia. Le seguenti persone fanno uso delle CR:

  • Insieme di ruoli: Analisti utilizzano le CR per definire delle modifiche significative per requisiti ad alto livello e per determinare i requisiti, specialmente dalle CR identificate come Richieste di miglioramento.
  • Insieme di ruoli: Responsabili utilizzano le CR per gestire controllare l'assegnazione del lavoro.
  • Insieme di ruoli: Tester utilizzano le CR per descrivere i malfunzionamenti (difetti), le omissioni e le problematiche relative alla qualità rilevati durante la verifica del software.
  • Insieme di ruoli: Sviluppatori utilizzano le CR dei difetti per analizzare i malfunzionamenti e individuare gli errori sottostanti o le cause del malfunzionamento per risolvere la CR.
  • Ruolo: Analista di test utilizza le CR per pianificare i test che verificheranno le CR risolte e per valutare l'impegno del test analizzando serie di difetti per misurare i trend nella qualità del software e del processo di progettazione software.
Breve profilo

Esempio di modulo di richiesta di modifica

  1. Identificazione

  • Progetto:
  • Numero di richiesta di modifica:
  • Tipo di richiesta di modifica: (problema o miglioramento)
  • Titolo:
  • Data invio:
  • Originatore:
  • Priorità della richiesta di modifica:
  1. Problema corrente

  • Descrizione del problema corrente:
  • Errore critico:
  • Danno:
  • Miglioramento:
  • Nuovo requisito:
  • Condizioni in cui si è osservato il problema:
  • Ambiente corrente: Hardware
  • Compilatore del sistema operativo:
  • Origine del problema corrente:
  • Impatto sui costi o sui risparmi del problema corrente:
  1. Modifica proposta (originatore)

  • Descrizione della modifica proposta:
  • Costo stimato per implementare la modifica proposta:
  1. Modifica proposta (team di revisione modifica)

  • Azione:
  • Approvata:
  • Non approvata:
  • Rinviata:
  • Descrizione della modifica proposta:
  • Elementi della configurazione implicati:
  • Categoria:
  • Correzione errore:
  • Miglioramento:
  • Nuova funzione:
  • Altro:

  1. Risoluzione

  • Costo stimato per implementare la modifica proposta:
  • Implementatore:
  • Tempo effettivo per implementare la modifica:
  • Analisi:
  • Implementazione:
  • Test:
  • Documentazione:
  • Numero di righe di codice implicate:
  1. Valutazione

  • Metodi di test
  • Ispezione
  • Analisi
  • Dimostrazione
  • Test
  • Piattaforme di test
  • Scenari di test
  1. Disposizione del team di revisione modifica

  • Modifiche approvate ed accettate
Personalizzazione
Opzioni di rappresentazione

I campi effettivi ed i dati necessari per identificare in modo accurato, descrivere e tracciare i difetti variano e dipendono dagli standard, dalle linee guida e dal sistema di controllo modifiche implementato.

In genere è più efficace memorizzare le richieste di modifica in un database o in un sistema di gestione delle richieste di modifica, in modo da poterle gestire più facilmente (ad esempio, ordinandole in base alla priorità, seguendone l'assegnazione e lo stato di completamento). In un progetto piccolo è sufficiente un foglio elettronico.

In un progetto piccolo è possibile gestire i difetti con un semplice elenco. Si può anche utilizzare un foglio elettronico con una colonna separata per ogni attributo della richiesta di modifica. Questo è possibile solo con sistemi piccoli. Quando il numero di persone coinvolte e la quantità di difetti va oltre un determinato limite è necessario utilizzare un sistema più flessibile di traccia dei difetti.



Ulteriori informazioni