Esame dell'approccio di test rispetto all'architettura software
Scopo:
|
Aggiornare la conoscenza dell'approccio per la verifica e del modo in cui verrà forzato dall'architettura
software.
|
Riesaminando l'approccio di test, dettagliare e caratterizzare gli aspetti fondamentali di tale approccio. Utilizzando
tali informazioni, riesaminare l'architettura software e iniziare a formulare una interpretazione delle necessità
generali dell'ambiente per l'impegno della verifica.
|
Identificazione di ogni ambiente di sviluppo specifico
Scopo:
|
Conoscere il numero dei diversi ambienti di sviluppo e acquisire familiarità con le caratteristiche
principali di ognuno di essi.
|
Utilizzando l'architettura software come punto di partenza, individuare e rivedere il modello di sviluppo e le
informazioni associate. Identificare ogni ambiente di destinazione specifico in cui verrà sviluppato il software e
acquisire familiarità con le distinte caratteristiche di ognuno di essi.
|
Consolidamento dell'elenco degli ambienti necessari
Scopo:
|
Formulare un elenco consolidato di un piccolo numero di ambienti che forniscono un'ampia gamma di
esperienza ambientale.
|
Di solito, non è pratico installare e gestire un grande numero di ambienti di test. Le economie di scala obbligano di
solito ad accettare un limitato sottoinsieme dei possibili ambienti di destinazione. Creare un elenco di tutti gli
ambienti di destinazione identificati e cercare i modi per consolidare e ridurre l'elenco a un sottoinsieme gestibile.
È tipico sia per l'hardware che per il software del sistema operativo essere condivisi attraverso più ambienti di test.
|
Per ogni configurazione di ambiente di test
Scopo:
|
Definire gli elementi essenziali di ogni configurazione di ambiente di test che consentiranno l'esecuzione
della verifica richiesta.
|
Per ogni configurazione di ambiente di test identificata, in cui si desiderano eseguire le verifiche, identificare ed
eseguire i seguenti dettagli.
utilizzando il piano di test, identificare ogni tecnica che farà parte dell'approccio di test. Per ogni tecnica,
elencare i requisiti ambientali specifici che dovranno essere soddisfatti per consentire l'esecuzione della verifica.
Utilizzando i requisiti identificati, iniziare a confrontare un elenco di hardware e software che sarà necessario per
eseguire la verifica. Prestare attenzione nella ricerca delle opportunità di consolidamento.
A questo punto raccogliere le informazioni dettagliate per ogni configurazione. Cercare di essere più precisi
possibile. Ciò può richiedere l'aiuto del supporto tecnico o le risorse di amministrazione di sistema. Provare a
cercare gli estremi minimo e massimo dei possibili ambienti. Spesso, tali estremi sono sufficienti nel fornire
un'adeguata grandezza di esperienza ambientale.
Installare, conservare e gestire un ambiente di test è spesso un'impresa difficile e impegnativa. Puntare l'attenzione
sulle procedure di gestione che si adotteranno per mantenere l'ambiente di test in buone condizioni.
|
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.
|
|