Comprensione degli obiettivi dell'iterazione
Scopo:
|
Acquisire una conoscenza iniziale dello scopo e degli obiettivi del piano di iterazione.
|
Esaminare il piano di iterazione e identificarne lo scopo e gli obiettivi.
È utile integrare tale esame con discussioni informali con i membri principali del progetto, come il responsabile di
progetto, l'architetto del software e il garante del cliente; questi incontri spesso evidenziano preoccupazioni in modo
più esplicito di quanto documentato nel piano. Si ottengono utili informazioni anche dalla frequentazione delle
riunioni di inizio iterazione.
|
Esaminare le opzioni nell'ambito dell'impegno di valutazione
Scopo:
|
Comprendere le aspettative degli stakeholder nell'ambito dell'impegno di valutazione.
|
La missione è quella di controllare il committente che dirige l'impegno di test in un determinato periodo di tempo. Le
risorse di verifica sono di solito limitate, per cui è necessario bilanciare quelli che sono i vincoli dovuti alla
mancanza di risorse con le esigenze di convalida di qualità dell'impegno per lo sviluppo del software.
Acquisire una conoscenza iniziale a livello strategico delle aspettative del team di sviluppo del software. È
necessario occuparsi principalmente delle aspettative del responsabile di progetto, dell'architetto del software e dei
principali analisti di sistema.
|
Prospettare le opzioni agli stakeholder
Scopo:
|
Acquisire informazioni e riscontri dagli stakeholder per gli obiettivi e lo scopo dell'impegno di test.
|
Non è una pratica estremamente utile considerare gli obiettivi e lo scopo isolati dal resto del team del progetto. Il
RUP sostiene la proprietà da parte del team della qualità del prodotto, pertanto è necessario includere gli stakeholder
principali al resto del team del progetto quando si decide quale verifica è importante. Si devono considerare i membri
del team che rivestono i seguenti ruoli come importanti stakeholder: responsabile di progetto, architetto, analista di
sistema, integratore.
In alcuni casi, il formato della presentazione sarà formale, con gli stakeholder che si riuniscono come consiglio di
revisione, richiedendo un'importante preparazione in anticipo. In altri casi, sono appropriati brevi incontri o singoli
colloqui con ogni stakeholder. Ogni approccio ha i suoi lati positivi e negativi: scegliere il formato che si adatta
meglio alle esigenze nel contesto dell'attuale ambiente del progetto.
|
Formulare il manifesto della missione
Scopo:
|
Identificare in modo chiaro l'essenza della focalizzazione sulla verifica per l'iterazione corrente.
|
Le asserzioni di missione sono utili per fornire il punto di attenzione a un team, soprattutto in quelle situazioni
dove il team dispone di molte scelte possibili. I team di test, senza una missione di valutazione, ritengono spesso di
dover semplicemente "verificare": ciò fornisce una piccola indicazione quando è necessario eseguire scelte difficili
riguardanti le migliori soluzioni di verifica all'interno dei vincoli di tempo e di risorse. Un'asserzione di missione
infonde l'essenza dell'obiettivo di lavoro attuale e fornisce un "mantra" per mantenere l'attenzione del team sui
giusti dettagli.
Formulare un'asserzione di missione che può essere utilizzata dal team di test. Non renderla troppo complessa né
includere troppe proposte in conflitto: le migliori asserzioni di missione sono semplici, concise e pertinenti; nella
maggior parte delle situazioni dove occorre prendere una decisione tra diverse opzioni possibili, la missione renderà
ovvia la scelta che il team dovrà fare.
Ecco alcune proposte di asserzioni di missione che si possono adottare per una determinata iterazione:
-
trovare più errori possibili
-
trovare rapidamente i problemi importanti
-
valutare i rischi di qualità percepiti
-
informare sui rischi di progetto percepiti
-
informare sulla qualità percepita
-
certificare uno standard
-
verificare una specifica (requisiti, progettazione o richieste di prodotto)
-
soddisfare gli stakeholder
-
adempiere ai mandati di processo
Osservando l'elenco, si nota che molte missioni sono mutualmente esclusive. Ad esempio se la missione è quella di
cercare velocemente i problemi importanti, non sarà possibile la missione relativa alla verifica di una specifica:
conseguire con successo una missione, spesso porta a negare la possibilità di altre missioni e richiede un diverso
approccio di supporto per il test.
I team di test che cercano di soddisfare troppe missioni di valutazione spesso si imbattono in problemi, incontrando
conflitti durante il loro lavoro. Si consiglia di scegliere o riconsiderare la missione di valutazione in ogni
iterazione: è normale che la missione si alteri nel corso del tempo in base al contesto del corrente impegno di lavoro.
|
Identificazione dei componenti distribuibili del test
Scopo:
|
Annunciare il valore che si riceverà dall'impegno di lavoro di verifica.
|
Determinati prodotti di lavoro sono componenti distribuibili importanti per uno o più stakeholder: altri prodotti di
lavoro sono parti necessarie dell'impegno di test e mentre sono importanti per il team di test, sono di poco interesse
per quegli stessi stakeholder .
Pensare all'insieme minimo di componenti distribuibili utili per l'impegno di test. Non elencare tutti i prodotti di
lavoro ma solo quelli che offrono un vantaggio diretto e tangibile a uno stakeholder e quelli con cui si desidera
misurare il successo dell'impegno di test. Potrebbe essere necessario regolare l'elenco iniziale affinché si adatti
alle esigenze degli stakeholder, ma si dovrà essere intraprendenti per incoraggiare a considerare i componenti
distribuibili utili e pratici.
|
Ottenere il consenso dello stakeholder
Scopo:
|
Negoziare con tutti gli stakeholder per accordarsi insieme sulla missione più appropriata per
l'iterazione.
|
In un modo simile alla fase precedente Prospettare le opzioni agli stakeholder; è
necessario ottenere il consenso dagli stessi stakeholder della missione di valutazione e i relativi aspetti di supporto
associati sono appropriati per l'iterazione.
Soffermarsi nuovamente sul formato appropriato per la presentazione della missione e per l'acquisizione delle
approvazioni richieste. Scegliere il formato che si adatta meglio alle esigenze nel contesto dell'attuale ambiente del
progetto.
|
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.
|
|