Determinazione dello scenario di esecuzione richiesto
Scopo:
|
Per identificare il percorso di esecuzione che simulerà la funzionalità runtime desiderata
|
Se l'obiettivo dell'osservazione e dell'analisi della funzionalità runtime è di fornire la conoscenza richiesta della
funzionalità del software, occorre indicare quali percorsi di esecuzione nell'applicazione saranno d'importanza per
l'esplorazione e tra quelli, quale offrirà la maggiore opportunità nel comprendere la funzionalità runtime del
software.
In generale, gli scenari più utili da controllare tendono a rispecchiare tutti o parte di quelli che l'utente
tipicamente utilizzerà. Come tale, è utile quando possibile identificare gli scenari domandando o altrimenti
consultando un esperto del campo come un utente rappresentante del software che si sta sviluppando.
I casi d'uso offrono una preziosa serie di artefatti da cui è possibile identificare ed esaminare gli scenari utili.
Come sviluppatore, i più familiari di questi casi saranno probabilmente le realizzazioni del caso d'uso con cui
iniziare. In assenza di realizzazioni del caso d'uso, identificare tutti gli scenari del caso d'uso disponibili che
offrono una descrizione testuale del percorso che l'utente utilizzerà per navigare attraverso i diversi flussi di
eventi nel caso d'uso. Infine, i flussi di eventi del caso d'uso possono essere consultati per ricevere informazioni da
cui è possibile identificare gli scenari candidati. E' possibile migliorare l'esito di questo ultimo approccio
consultando un rappresentante per l'attore dei casi d'uso o altri esperti del dominio.
I tester sono un'altra risorsa vantaggiosa da consultare quando si tenta di identificare gli scenari utili per
l'analisi in runtime. I tester acquisiscono spesso una notevole conoscenza ed esperienza del dominio attraverso i loro
impegni sui test facendoli assumere il ruolo di pseudo esperti del dominio. In molti casi, il desiderio di osservazione
della funzionalità runtime del software verrà dai risultati stessi delle attività di test.
Se questa attività avviene in seguito alla notifica di un difetto, l'attenzione principale sarà di riprodurlo in un
ambiente controllato. In base alle informazioni registrate in seguito alla presenza di un problema, è necessario
identificare una serie di scenari di test come potenziali candidati per poter riprodurre con affidabilità il difetto.
Potrebbe essere necessario modificare alcuni test o crearne nuovi, tuttavia occorre tenere presente che la riproduzione
del difetto è un passo essenziale e per gli scenari più difficili potrebbe essere richiesto più tempo per riprodurlo
che per correggerlo.
|
Preparazione del componente di implementazione per l'osservazione in runtime
Scopo:
|
Per accertarsi che il componente sia pronto in uno stato appropriato per abilitare l'esecuzione in
runtime
|
Per poter ottenere risultati accurati dall'esecuzione runtime del componente, occorre prestare attenzione nel preparare
il componente soddisfacentemente in modo che non si verifichino risultati anomali come conseguenza di errori
nell'implementazione, compilazione o di collegamento.
E' spesso necessario utilizzare i componenti stub in modo che l'osservazione runtime possa essere completata
tempestivamente o che possa essere effettivamente condotta in situazioni in cui il componente si affida ad altri
componenti che non sono stati ancora implementati.
Sarà anche necessario preparare i framework o i tool di supporto richiesti per eseguire il componente. In alcuni casi
ciò potrebbe significare la creazione di codice di utilizzo o di controllo per supportare l'esecuzione del componente;
in altri casi potrebbe significare l'indirizzamento del componente in modo che i tool di supporto esterni possano
osservare e possibilmente controllare la funzionalità dei componenti.
|
Preparazione dell'ambiente per l'esecuzione
Scopo:
|
Per accertarsi che l'impostazione dei prerequisiti dell'ambiente di destinazione sia stata completata in
modo soddisfacente.
|
E' importante considerare tutti i requisiti ed i vincoli che devono essere affrontati per l'ambiente di destinazione in
cui verrà eseguita l'analisi in runtime. In molti casi sarà necessario simulare uno o più ambienti di distribuzione
progettati in cui il componente sarà infine richiesto di essere eseguito. In altri casi, sarà sufficiente osservare la
funzionalità runtime sulla macchina degli sviluppatori.
In ogni caso, è importante impostare l'ambiente di destinazione per l'osservazione del runtime in modo soddisfacente
così che quell'esercizio non sia sprecato dall'ingresso di "sostanze contaminanti" che potenzialmente renderanno non
valida l'analisi successiva.
Un'altra considerazione da fare è sull'uso dei tool che generano le condizioni di vincoli ambientali o di errore che
altrimenti sono difficili da riprodurre. Alcuni tool sono essenziali nell'isolare gli errori o le anomalie che si
verificano nella funzionalità runtime secondo queste condizioni.
|
Esecuzione del componente e cattura delle osservazioni funzionali
Scopo:
|
Per osservare e catturare la funzionalità runtime del componente.
|
In seguito alla preparazione del componente e dell'ambiente in cui sarà osservata la funzionalità. è ora possibile
eseguire il componente attraverso lo scenario scelto. A seconda delle tecniche e dei tool utilizzati, questa fase può
essere quasi interamente eseguita senza presidio oppure potrebbe richiedere un'attenzione continua mentre lo scenario
avanza.
|
Revisione delle osservazioni funzionali e isolamento dei risultati iniziali
Scopo:
|
Per identificare gli errori e le anomali nella funzionalità runtime dei componenti.
|
Durante ciascuna fase o alla conclusione dello scenario osservato, individuare gli errori o le anomalie nella
funzionalità prevista. Prendere nota di tutte le osservazioni effettuate o le impressioni raccolte che potrebbero
essere correlate con la funzionalità anomala.
|
Analisi dei risultati per comprendere le cause principali
Scopo:
|
Per individuare la causa principale di ogni errore o anomalia
|
In base ai risultati ottenuti esaminare l'errore sottostante o la causa principale di ciascun errore.
|
Identificazione e comunicazione delle azioni supplementari
Scopo:
|
Per suggerire ulteriori azioni correttive o di controllo
|
Una volta controllati tutti i risultati, è probabile che si abbia un elenco di idee o domande che richiederanno
ulteriori verifiche e specifiche azioni correttive proposte. Se non si assume un'immediata azione su questi elementi
direttamente, registrare le proprie proposte in un formato appropriato e comunicarle ai membri del team che possono
approvare o altrimenti utilizzarle.
|
Valutazione dei risultati
Scopo:
|
Per verificare che l'attività sia stata completata correttamente e che i prodotti di lavoro risultanti
siano accettabili.
|
A questo punto di completamento del lavoro, è preferibile verificare che il lavoro sia stato di livello sufficiente. È
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. Quando possibile, utilizzare gli elenchi forniti in RUP per verificare che la
qualità e la completezza siano di "sufficiente livello".
E' necessario che le persone che utilizzeranno il proprio lavoro come input per eseguire le attività a valle prendano
parte alla revisione del proprio lavoro provvisorio. Procedere in questo modo mentre si ha ancora tempo a disposizione
per prendere decisioni e discutere delle loro considerazioni. Inoltre, è necessario valutare il lavoro svolto rispetto
ai prodotti di lavoro di input chiave per accertarsi che vengano rappresentati o considerati in modo accurato e
sufficiente. Potrebbe essere utile su questa base fare revisionare il proprio lavoro all'autore del prodotto di lavoro
di input.
Tenere presente che il RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro vengono
sviluppati nel tempo. Come tale, non è di solito necessario (spesso è controproducente) formare completamente un
prodotto di lavoro che sarà solo parzialmente utilizzato o non utilizzato affatto in un immediato lavoro a valle
successivo. Ciò è dovuto all'elevata probabilità che le condizioni presenti intorno al prodotto di lavoro cambieranno -
e le supposizioni fatte quando il prodotto di lavoro è stato creato valutate non corrette - prima che il prodotto venga
utilizzato, determinando come risultato una rilavorazione e pertanto uno spreco di impegno lavorativo.
Inoltre, evitare l'inconveniente di spendere troppi cicli in presentazioni a danno del valore del contenuto. Negli
ambienti di progettazione dove la presentazione ha importanza e valore economico come componente distribuibile del
progetto, si può considerare di utilizzare una risorsa amministrativa o junior per eseguire il lavoro su un prodotto di
lavoro per migliorarne la presentazione.
|
|