Operazione: Define Assessment and Traceability Needs
Questa attività descrive come definire i requisiti per la valutazione e la tracciabilità e la strategia globale che verrà seguita.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Passi
Identificare requisiti di tracciabilità e valutazione
Scopo:  Comprendere i componenti distribuibili per il processo di valutazione del software e dedurre i requisiti associati. 

Analizzare il piano d'iterazione e identificare le necessità di valutazione specifiche per questo lavoro imminente. Chiedere agli stakeholder di cosa hanno bisogno per la valutazione e la tracciabilità.

Inoltre, considerare se l'impegno del test viene formalmente controllato durante o alla fine della sua esecuzione. I requisiti di controllo formale possono aver bisogno della memorizzazione di documentazione aggiuntiva e di registrazioni come prova che è stata eseguita una verifica sufficiente.

Considerazione vincoli
Scopo:  Identificare i vincoli che influenzano l'abilità (o la necessità) di implementare i requisiti.  

Mentre esiste un elenco infinito di "desideri" che si è portati a considerare come requisiti per le strategie di valutazione e tracciabilità, è importante focalizzare l'attenzione sulle "esigenze" più importanti che a) forniscono informazioni essenziali al team di progetto e b) possono essere tracciate e misurate. È improbabile poter disporre di risorse per la strategia al fine di soddisfare più di uanto non sia necessario.

Argomenti secondari:

Livello di qualità accettabile A inizio pagina

È importante identificare quale livello di qualità possa essere considerato "sufficiente" e sviluppare un'appropriata strategia di valutazione. Spesso le dimensioni della qualità diminuiscono d'importanza e i livelli di qualità si alzano e si abbassano agli occhi degli stakeholder durante il ciclo vitale del progetto.

Analizzare il piano QA, il piano di sviluppo software e intervistare gli stessi importanti stakeholder direttamente per determinare la loro idea di livello di qualità accettabile.

Abilitazione tool e processo A inizio pagina

Se è possibile immaginare un mondo fatto di tracciabilità e valutazioni senza sforzi ad un basso livello di granularità, la realtà è che è molto difficile e solitamente non economico implementare tali approcci. Con il supporto di sofisticati tool, è difficile e dispendioso in termini di tempo gestire approcci di basso livello alla tracciabilità; senza il supporto dei tool, è addirittura quasi impossibile. Il processo di progettazione software stesso può condurre a vincoli sulla tracciabilità: ad esempio, se si desidera la tracciabilità dai test ai requisiti motivanti, ma questi ultimi non vengono gestiti con attenzione, è quasi impossibile implementarla.

Considerare vincoli e limitazioni del processo di progettazione software e dei tool e scegliere di conseguenza un approccio di valutazione e tracciabilità attuabile.

Considerare possibile strategie
Scopo:  Identificare e descrivere una o più strategie in grado di semplificare il processo di valutazione richiesto.  

Ottenuta una migliore comprensione dei requisiti di tracciabilità e valutazione e dei vincoli insiti in essi a causa del livello di qualità desiderato e del supporto disponibile di tool e processi, è necessario considerare le potenziali strategie di valutazione che possono essere implementate. Per un approfondimento sulle possibili strategie, è suggerita la lettura del documento di Cem Kaner "Misurazione del grado di esecuzione del test," Ottobre 2000. (Scaricare Adobe Reader)

Argomenti secondari:

Analisi di completamento del test A inizio pagina

Esistono molti differenti approcci al completamento del test e nessuna misura fornisce da sola tutte le informazioni sul completamento necessarie per formare una valutazione dell'estensione o della completezza dell'impegno di test. Differenti strategie di completamento richiedono più o meno impegno per la loro implementazione e con nessuna categoria di misurazione particolare si giunge necessariamente ad un punto dell'analisi in cui diviene costoso registrare informazioni più dettagliate.

Alcune categorie di misurazione del completamento del test includono: requisiti, codice d'origine, standard e affermazioni del prodotto. È consigliata caldamente l'implementazione di più categorie di completamento nella propria strategia di valutazione del test. Nella maggior parte dei casi, il completamento del test fa riferimento alla pianificazione e all'implementazione di test specifici nella prima istanza. Tuttavia, anche le metriche di completamento del test e le loro analisi si rivelano utili se considerate insieme ai risultati di test o alle analisi di difetti.

Analisi risultati del test A inizio pagina

Un approccio comune all'analisi dei risultati del test consiste nel far riferimento semplicemente alla quantità dei risultati positivi o negativi come percentuale del numero totale dei test eseguiti. Secondo la nostra opinione e quella di altri professionisti nella comunità di test, tale approccio è semplicistico ed incompleto.

È consigliata, piuttosto, l'analisi dei risultati di test in termini del relativo trend nel tempo. All'interno di ogni ciclo di test, considerare la relativa distribuzione di test con esito negativo lungo dimensioni differenti come l'area funzionale su cui è stato eseguito il test, il tipo di rischi di qualità esplorati, la relativa complessità di test e le sue risorse applicate ad ogni area funzionale.

Analisi difetti A inizio pagina

Mentre i difetti sono ovviamente collegati ai risultati dell'impegno di test, l'analisi dei loro dati non fornisce nessuna utile informazione sul suo progresso o sul relativo completamento o accuratezza. Tuttavia, un errore commesso da team di test e responsabili di progetto deve utilizzare il conteggio dei difetti corrente per misurare il progresso del test o per agire da indicatore della qualità del software sviluppato. Secondo la nostra opinione e quella di altri professionisti nella comunità di test, questo approccio è inutile.

È consigliata, piuttosto, l'analisi del relativo trend di conteggio dei difetti nel tempo per fornire una misura di stabilità relativa. Ad esempio, posto che l'impegno del test rimanga costante ci si aspetta, normalmente, di vedere la nuova frequenza di rilevazione dei difetti misurata rispetto un periodo di tempo regolare nel corso dell'iterazione; una frequenza di rilevazione crescente che raggiunge un picco e poi scende giù verso la fine dell'iterazione. Tuttavia, è necessario fornire queste informazioni insieme all'analisi di altre metriche di difetto come: le frequenze di risoluzione dei difetti, inclusa un'analisi del tipo di risoluzione; la distribuzione dei difetti per ordine di gravità da parte dell'area funzionale.

Con il supporto di tool sofisticati, è possibile eseguire un'analisi completa dei dati del difetto in modo relativamente semplice; senza tale supporto è molto più difficile.

Discutere possibili strategie con gli stakeholder
Scopo:  Raccogliere feedback attraverso la revisione dello stakeholder iniziale e ridefinire le strategie secondo necessità. 

Presentare le possibili strategie ai diversi stakeholder. Ci si aspetta di includere generalmente un gruppo costituito dai seguenti ruoli; responsabile di progetto, architetto del software, responsabile di sviluppo, analista di sistema, responsabile della modifica della & configurazione e il rappresentante del cliente. Ognuno di questi ruoli ha uno stakehold su come valutare la qualità.

In base alla cultura del progetto, scegliere il formato appropriato per presentare le possibili strategie. Si va da una o più riunioni informali ad una presentazione formale o workshop.

Definire e trovare un accordo sulla strategia di valutazione
Scopo:  Ottenere il consenso dello stakeholder sulla strategia da usare. 

Analizzare il feedback ricevuto dalle discussioni e perfezionare la strategia di valutazione al fine di ottenere una singola strategia che incontra i bisogni di tutti gli stakeholder.

Presentare la strategia di valutazione per la valutazione e l'approvazione finale.

Definire i requisiti del tool
Scopo:  Definire i requisiti di configurazione del tool di supporto che abilitano il processo di valutazione.  

Come detto in precedenza, con il supporto di tool sofisticati, è possibile eseguire un'analisi completa dei dati di misurazione in modo relativamente semplice; senza tale supporto è molto più difficile.

Per le seguenti categorie, considerare il tool più adeguato: completamento e tracciabilità, analisi del difetto.

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 buon 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. Se possibile, utilizzare gli elenchi forniti in RUP per verificare che la qualità e la completezza siano di livello "sufficiente".

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. Può 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 iterativo e che in molti casi i prodotti di lavoro vengono sviluppati 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.



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