Acquisizione dello stato del lavoro
Scopo:
|
Per ottenere un obiettivo, aggiornare la conoscenza dello stato generale del lavoro di verifica rispetto al
programma.
|
Ci sono diversi modi per affrontare questa fase e molto dipende dalla propria istruzione sul progetto. Dove possibile,
ottenere ed esaminare i resoconti sullo stato di avanzamento preparati da singoli membri di team o team secondari. I
time sheet (fogli di tempificazione) del progetto rappresentano un'altra possibile fonte da considerare. Un'altra utile
fonte di informazioni è costituita dai sistemi di pianificazione di progetto come Microsoft Project, lì dove sono stati
utilizzati e aggiornati con lo stato di avanzamento attuale. Nei punti in cui sono disponibili e utilizzati
attivamente, si potrebbe anche ricavare lo stato oggettivo o la metrica di avanzamento dalla configurazione e
modificare i sistemi di gestione.
In questa fase e in quelle successive riguardanti la raccolta di informazioni e la valutazione dell'impegno di test,
provare a ottenere un punto di vista bilanciato che includa sia le stime oggettive che quelle soggettive. È importante
ricordare che i numeri oggettivi costituiscono solo una parte del contesto e devono essere supportati e descritti in
base al "clima" del progetto corrente. Contrariamente, non affidarsi semplicemente alle supposizioni soggettive
sull'impegno di test: ricercare le prove oggettive di supporto. Si consiglia di integrare i propri dati oggettivi
mediante discussioni con i responsabili dei team oppure, quando possibile, con i singoli membri del team per
raccogliere valutazioni soggettive e misurare il livello di confidenza che è possibile attribuire ai dati oggettivi.
|
Raccolta della metrica di produttività ed efficacia dell'impegno di test
Scopo:
|
Raccogliere ed esaminare i dati obiettivi che permettono la valutazione della verifica eseguita dal team di
test.
|
Indagare su quanto impegno è stato speso per l'identificazione, la definizione, la progettazione, l'implementazione e
l'esecuzione dei test. Cercare gli eccessi di impegno dedicati a un aspetto dell'impegno di test a svantaggio di altri
aspetti. Cercare anche le aree dove l'impegno può essere improduttivo o dove si dimostra non particolarmente
vantaggioso per il livello impiegato.
Osservare anche l'efficacia della verifica. Cercare i dati che supportano le osservazioni iniziali di efficacia.
Considerare gli aspetti come la frequenza di rilevazione di difetti, il conteggio di severità dei difetti, le
statistiche duplicate di difetti e i difetti rilevati come errori del test.
|
Raccolta della metrica di distribuzione, di trend e di epoca delle richieste di modifica
Scopo:
|
Raccogliere ed esaminare i dati obiettivi che permettono la valutazione dei problemi e dei difetti
registrati dal team di test.
|
Identificare i trend importanti evidenti nei dati di richiesta di modifica. In generale, è meno importante per tale
attività impiegare tempo ad analizzare volumi di dati e più importante identificare cosa indicano i relativi trend di
dati Ricercare i segni positivi come il tasso costante e fisso della rilevazione dei difetti oppure l'incremento
graduale in corso e la susseguente diminuzione del tasso di rilevazione nel tempo. Prestare attenzione ai picchi
improvvisi e alle riduzioni del tasso di rilevazione che indicano che il team di test potrebbe aver incontrato problemi
con il processo, ambientali, politici o altri che ne riducono la produttività.
Guardare i trend di chiusura dei difetti. Ricercare aumenti significativi di chiusure con la dicitura "non
riproducibile" da parte del personale di sviluppo; identificare i casi dove ciò è conseguenza di un'analisi
insufficiente dell'errore da parte del team di test e quantificare l'estensione di questo problema. Osservare i trend
dei difetti chiusi dal personale di sviluppo con la dicitura "funzionante come da progetto"; identificare i casi dove
ciò è il risultato di un'analisi insufficiente della specifica che è stata eseguita dal team di test e quantificare
l'estensione di questo problema. Prestare attenzione nel confermare tali indicazioni che non siano false e dovute
invece a sviluppatori sovraccaricati di lavoro. Sarebbero necessarie delle analisi anche sui trend di verifica dei
difetti quando vengono rilasciate le correzioni agli errori al team di test nei successivi build: ricercare i trend che
indicano che i difetti in attesa di verifica da parte del team di test sono datati e stanno aumentando
considerevolmente.
Ricercare altri trend che indicano problemi. Rivedere il modo in cui i difetti e altre richieste di modifica sono stati
registrati o gestiti dal team di test: le informazioni ambigue e insufficienti sono frustranti per uno sviluppatore che
deve prendere provvedimenti. Il team dovrebbe avere cura di monitorare che la qualità delle informazioni registrate per
i difetti sia in media relativamente elevata. Cogliere l'opportunità di migliorare la chiarezza delle richieste di
modifica associate, eliminando l'ambiguità e il linguaggio e i ragionamenti emotivi. Collaborare con le persone che
hanno creato questi prodotti di lavoro per accertare che l'essenza del problema venga dichiarata in modo chiaro e
incoraggiarle a trovare modi effettivi e accurati per la discussione dei problemi.
Inoltre, osservare dall'esterno gli squilibri nella distribuzione dei difetti su un numero di dimensioni differenti.
Ricercare le aree funzionali dell'applicazione o della specifica che hanno fornito pochi difetti: ciò può indicare che
in quell'area funzionale è stata eseguita una verifica insufficiente. Osservare anche la distribuzione per membro di
team di test: possono esserci indicazioni che singoli membri del team sono sovraccarichi di lavoro e che la loro
produttività ne risente.
|
Raccolta della metrica di tracciabilità, copertura e dipendenza
Scopo:
|
Raccogliere ed esaminare i dati oggettivi che permettono la tracciabilità della risorsa di
valutazione.
|
Analizzare lo stato delle relazioni di tracciabilità tra le proposte di risorse-test di verifica, scenari di test,
script di test, suite di test e richieste di modifica, e le risorse a monte e a valle a cui si riferiscono. Ricercare
segnali che indichino che l'impegno di test è puntato sulle aree corrette e una serie di motivazioni utili. Ricercare
anche le indicazioni negative che suggeriscono che determinati aspetti della verifica sono assenti o non hanno più
importanza: se i team di requisiti o di sviluppo lavorano su aree non rappresentate dall'impegno di test corrente, ciò
dovrebbe suscitare preoccupazioni.
|
Valutazione della metrica e formulazione della stima iniziale
Scopo:
|
Valutare e stimare i dati di metrica e formulare una stima iniziale dell'efficacia dell'impegno di test per
il programma.
|
Esaminare tutte le informazioni raccolte e valutarle nel complesso. Ricordarsi che ogni gruppo di dati raccolto
riguarda solo un aspetto della valutazione totale ed è necessario formulare la valutazione dell'impegno di test
basandosi su una visione bilanciata e contemplata di tutti i dati.
registrare la valutazione iniziale in un formato adeguato affinché gli stakeholder possano effettuare commenti e
fornire riscontri.
|
Risultati di registrazioni
Scopo:
|
Documentare i risultati riepilogativi da includere nella creazione di report di gestione di progetto e
abilitare l'analisi della valutazione successiva di stato in confronto alle valutazioni precedenti.
|
Questa attività produce informazioni di stato riepilogative importanti per il responsabile del progetto e per gli altri
ruoli nel team di gestione. Tali ruoli utilizzeranno i risultati riepilogativi per prendere decisioni sul progetto.
Si consiglia di registrare alcuni aspetti della valutazione dell'impegno di test in un formato che consenta alle
successive valutazioni di essere confrontate e contrapposte alle precedenti. Ciò permetterà di analizzare nel tempo il
trend relativo nei miglioramenti di impegno di test.
|
Presentazione di valutazione e acquisizione di riscontro
Scopo:
|
Avvalersi dell'opera degli stakeholder e ottenere il loro riscontro sull'utilità dell'impegno di test
attuale per le loro necessità.
|
Presentare la valutazione per il commento e il riscontro da parte degli stakeholder. La forma o il metodo di tale
presentazione differirà da progetto a progetto: in alcuni casi si tratterà di una serie di conversazioni informali, in
altri di un semplice invio di messaggi su un sito web intranet del progetto e in altri di una presentazione formale
(scegliere una forma che sia adatta alla propria cultura).
Anche con i documenti di specifica e di progettazione migliori possibili, ci saranno solitamente differenze fra
l'aspettativa originale e l'intenzione di quei documenti e del prodotto finale risultante. Ciò è vero per il software
di verifica e di valutazione come lo è per lo stesso sviluppo del software. Il valore di questa fase è quello di
cogliere l'opportunità di ricevere riscontri da parte degli stakeholder e identificare dove l'accurata pianificazione e
la documentazione non hanno raggiunto le attese e le intenzioni previste.
|
Pianificazione e implementazione delle iniziative di miglioramento
Scopo:
|
Identificare le aree da migliorare e formulare le strategie iniziali per ottenere i relativi
miglioramenti.
|
In base alle analisi e ai riscontri ricevuti dai vari stakeholder, identificare le opportunità di miglioramento.
Cercare i modi per rendere la verifica più efficace, produttiva ed efficiente. Ciò potrebbe coinvolgere: la
riassegnazione del personale, includendo il personale in coppia, per una migliore efficienza lavorativa oppure
l'assunzione di consulenti specializzati; l'utilizzo di strumenti di produttività per aumentare l'efficienza; la
ricerca di metodi e tecniche alternativi, più produttivi in termini di ricerca di difetti.
Nella maggior parte dei casi è meglio apportare piccoli miglioramenti incrementali all'impegno di test ed evitare il
rischio di far deragliare il progetto con grandi cambiamenti sconvolgenti: in alcuni casi un grande cambiamento è
giustificato e utile. Formulare un metodo di miglioramento appropriato secondo il proprio giudizio e discutere delle
proprie idee con altro personale di gestione per ricevere consigli, prima di impegnare il team in grandi cambiamenti.
|
Monitoraggio e supporto delle iniziative di miglioramento
Scopo:
|
Assicurare che le necessarie iniziative di miglioramento vengano raggiunte in modo soddisfacente e in tempi
adeguati.
|
Affinché i miglioramenti siano efficaci, sarà necessario gestirne la riuscita. Identificare i modi in cui sarà
possibile monitorare le iniziative di miglioramento, preferibilmente in anticipo rispetto alla loro adozione, per
verificare la rispettiva efficacia. Monitorare attivamente, in prima persona o nominando qualche altra persona del
team, l'avanzamento nell'adozione dei cambiamenti.
La maggior parte dei cambiamenti presenta resistenza o problem da superare affinché abbiano successo. Concedere il
tempo necessario e prepararsi a risolvere rapidamente qualsiasi problema che si presenta e impedisce il successo
dell'iniziativa. Avere sensibilità di fronte alla naturale riluttanza del personale al cambiamento e trovare i modi per
per placare le loro preoccupazioni in modo appropriato.
|
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.
|
|