Operazione: Analisi comportamento in runtime
Questa attività descrive in che modo analizzare la funzionalità di un componente durante l'esecuzione al fine di identificare i miglioramenti che si possono apportare.
Scopo
  • Per comprendere la funzionalità di un componente durante l'esecuzione.
  • Per individuare comportamenti anomali ed eventuali azioni di correzione richieste.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Passi
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.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni