Identificazione degli elementi di destinazione di iterazione
Scopo:
|
Acquisire una comprensione iniziale degli obiettivi specifici dietro al piano di iterazione.
|
Esaminare il piano e identificare gli elementi specifici che determineranno il piano e i componenti fondamentali
distribuibili attraverso cui verrà misurata l'esecuzione del piano. Gli elementi fondamentali da esaminare comprendono:
elenchi dei rischi, elenchi di richieste di modifica, insiemi di requisiti, elenchi di casi d'uso, modelli UML ecc.
È utile integrare questo esame attraverso la frequentazione delle riunioni di inizio iterazione. Se non sono già
pianificate, organizzarne una per team di test in cui si invitano i responsabili di gestione e gli addetti allo
sviluppo software principali (ad. es., responsabile di progetto, architetto di software, responsabili del team di
sviluppo).
|
Raccolta ed esame delle informazioni attinenti
Scopo:
|
Ottenere ulteriori informazioni per la comprensione dello scopo e dei componenti specifici di distribuzione
del piano di iterazione.
|
Dovendo esaminare il piano di iterazione, cercare inizialmente elementi definiti in modo chiaro e tangibile che
potrebbero essere buoni candidati per la valutazione. Esaminare i dettagli dietro al lavoro da svolgere, inclusi il
"nuovo lavoro" e le richieste di modifica ecc. Studiare i rischi che verranno risolti dal piano per capire in modo
chiaro l'impatto potenziale di rischio e le azioni da prendere per indirizzarlo (ridurlo, trasferirlo, eliminarlo
ecc.).
|
Identificazione delle motivazioni candidate
Scopo:
|
Creare un profilo delle motivazioni di test candidate per questa iterazione.
|
Utilizzando la conoscenza acquisita del piano di iterazione, identificare le fonti potenziali di ciò che motiverà
l'impegno di test. Queste potranno provenire da una o più fonti: un prodotto di lavoro singolo, un insieme di prodotti
di lavoro, da un evento o attività, o dall'assenza di una di queste. Le fonti potrebbero includere: elenco dei rischi,
richieste di modifica, insiemi di requisiti, casi d'uso, modelli UML e così via.
Per ogni fonte, esaminare i dettagli delle motivazioni potenziali. Se non si è in grado di individuare maggiori
dettagli o non si ha dimestichezza con le fonti di motivazione, potrebbe essere utile discutere gli elementi con
l'analista e il personale di gestione, iniziando solitamente con i responsabili di progetto o di analisi di sistema.
Quando si esaminano le informazioni e si discutono con il personale relativo, fornire un elenco di motivazioni di test.
|
Determinazione dei rischi di qualità
Scopo:
|
Determinare quali rischi di qualità sono più attinenti a questa iterazione.
|
Utilizzando l'elenco di motivazioni di test candidate, considerare ciascuna di esse nei termini di potenzialità di
rischi di qualità. Ciò permetterà di capire meglio l'importanza relativa di ogni motivazione candidata e può rivelare
altre motivazioni candidate assenti nell'elenco.
Esistono molte dimensioni diverse di rischio di qualità ed è possibile che una singola motivazione possa evidenziare la
potenzialità di rischio in più categorie. Evidenziare i rischi di qualità potenziali per ognuna delle motivazioni
candidate e indicare la probabilità di incontrare il rischio e l'effetto della sua risoluzione.
|
Definizione dell'elenco di motivazioni
Scopo:
|
Definire le motivazioni di test specifiche che saranno il punto centrale per questa iterazione.
|
Utilizzando l'elenco delle motivazioni candidate e le relative informazioni di rischio di qualità, determinare la
relativa importanza delle motivazioni. Determinare le motivazioni che possono essere risolte nella corrente iterazione
(è possibile conservare l'elenco delle motivazioni rimanenti per successive iterazioni).
Definire l'elenco delle motivazioni, documentandolo in modo appropriato. Ciò può essere un componente del piano di
iterazione, in un database o foglio elettronico oppure un elenco contenuto all'interno di qualche altro prodotto di
lavoro. È utile descrivere brevemente l'importanza della motivazione e gli aspetti del rischio di qualità che aiuta a
risolvere.
|
Gestione delle relazioni di tracciabilità
Scopo:
|
Abilitare l'esecuzione della segnalazione dell'analisi d'impatto e della valutazione sugli elementi
tracciati.
|
Utilizzando i requisiti di tracciabilità evidenziati nel piano di test, aggiornare le relazioni di tracciabilità come
richiesto.
|
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.
|
|