Criteri per la conduzione della
revisione di accettazione

Precondizioni

  1. Ciascun gruppo di progetto sara' ammesso alla revisione di accettazione (RA) solo dopo aver superato con successo la revisione di qualifica (RQ), ovvero avendo in essa riportato un esito con giudizio uguale o superiore a "sufficiente".
  2. Condizione necessaria per superare con successo la RQ sara' aver emendato, completato ed emesso ciascun documento di progetto in osservanza ai commenti emessi dal cliente nelle revisioni tenutesi nell'ambito del corso.
  3. Condizione sufficiente sara' aver fornito il materiale atteso in ingresso alla RQ con forma e contenuto adeguati ai fini della revisione, secondo i criteri adottati per le revisioni precedenti.

Conduzione della revisione

  1. Per i gruppi che abbiano soddisfatto le precondizioni di cui sopra nel rispetto del calendario del corso affisso all'indirizzo http://www.math.unipd.it/~tullio/IS_modB/calendario.html , la RA si terra' in data 3 giugno 2002 a partire dalle ore 14:00 in aula P50.
  2. Ogni altro gruppo dovra' produrre un piano di contingenza indicante il calendario con il quale il gruppo si impegna formalmente a soddisfare le precondizioni di cui sopra, e concordarne il contenuto con il cliente entro e non oltre il 3 giugno 2002.
  3. L'ammissione alla RA nella data concordata avra' luogo mediante fornitura da parte del gruppo candidato di tutto il materiale costituente il prodotto finale entro e non oltre le ore 18:00 del giorno precedente la revisione . Una lettera di accompagnamento dovra' indicare con precisione ogni eventuale modifica apposta al materiale approvato con la RQ.
  4. La RA constera' della esecuzione delle seguenti azioni:

Installazione

  1. Il materiale d'installazione dovra' essere fornito sotto forma di archivio compresso (*.zip) entro e non oltre la scadenza di ammissione alla RA.
  2. Il materiale dovra' essere comprensivo dell'intero insieme dei sorgenti e delle librerie richiesti per la costruzione degli eseguibili necessari. L'assenza dei sorgenti non sara' pregiudizievole se prevista da espliciti accordi o clausole contrattuali.
  3. Il cliente indichera' la piattaforma sulla quale l'installazione dovra' aver luogo, scegliendo tra Linux Red Hat 7.2, Linux SuSE 7.2, Windows ME, Windows 98.
  4. Il manuale di installazione (incluso nel manuale d'uso) dovra' indicare i requisiti minimi necessari per consentire la corretta installazione del prodotto su ciascuna delle piattaforme sopra indicate.
  5. Il cliente od un suo incaricato (l'operatore) eseguira' le azioni di installazione del prodotto come indicate nel manuale d'uso, verificandone l'esito. In presenza dei sorgenti, l'installazione dovra' includere la creazione degli eseguibili necessari all'esecuzione del sistema.

Collaudo di esecuzione nominale

  1. Utilizzando il programma gia' installato e con l'aiuto del manuale d'uso, l'operatore costruira' due (2) droni raccoglitori provvisti di logica di controllo, salvandoli poi in archivio.
  2. L'operatore verifichera' la realizzazione di almeno una (1) logica di controllo da parte dell'utente e la associera' ad uno dei due droni.
  3. Il primo drone sara' semplice e leggero, utilizzando il minimo di componenti ed i meno pesanti tra essi.
  4. Per la realizzazione del secondo, l'operatore effettuera' un assemblaggio col massimo dei componenti possibili, verificando il controllo dei vincoli di peso.
  5. L'ambiente di collaudo sara' il simulatore con una mappa creata in precedenza (una di default ovvero una caricata tra quelle disponibili), nella quale dovranno essere presenti almeno due vermi.
  6. La durata della simulazione sara' fissata in non meno di tre (3) minuti.
  7. La simulazione continuera' fintantoche' i due droni, prelevati da archivio, avranno caricato tutta la spezia possibile, ovvero quando essi saranno distrutti od impossibilitati a fare qualsiasi movimento (stallo), ovvvero quando avra' termine il tempo stabilito per la simulazione.
  8. L'operatore verifichera' inoltre l'eventuale chiamata degli ornicotteri.

Collaudo di comportamento a seguito di malfunzionamento

  1. L'operatore effettuera' una sequenza di operazioni deliberatamente intese a causare il malfunzionamento del sistema, anche qualora alcune di esse fossero esplicitamente deprecate dal manuale d'uso.
  2. Qualora l'esecuzione produca malfunzionamento, l'operatore provera' a mettere in relazione lo stato del sistema a quel punto e l'eventuale diagnostica prodotta dal sistema con le informazioni fornite al riguardo dal manuale d'uso, verificando la qualita' del supporto fornito dal prodotto (inteso sia come eseguibile che come documentazione) per il ripristino di uno stato nominale.

Verifica della documentazione del codice

  1. Il cliente prendera' in esame la parte di codice sorgente relativa alla logica di controllo e ne effettuera' una verifica di qualita' strutturale.
  2. La documentazione richiesta dovra' essere inclusa nel materiale consegnato in ingresso alla revisione.
  3. Costituira' titolo preferenziale la fornitura di documentazione in formato PDF od HTML generata con l'ausilio di JavaDoc.