Riepilogo esito corrente delle revisioni di progetto

DAMS

RA

Resoconto

• [+] Buona l'organizzazione del materiale sottomesso per accettazione
• [-] Materiale ricevuto oltre il termine di scadenza pattuito (le ore 18:00 giorno precedente la sessione di accettazione)
• Manuale d'uso:
• [-] collegamenti erronei alle illustrazioni
• [-] eccessiva stringatezza, penalizzante per l'utente in assenza di chiari riferimenti alle informazioni rilevanti all'interno di altri documenti di progetto
• [+] buona la descrizione relativa alla struttura ed alla creazione di logiche di controllo; assai utili sarebbero stati collegamenti ipertestualialle componenti di codice riferite
• Utilita' di installazione:
• [+] compilazione senza errori
• [-] lo script manca di diagnostica interna per confermare il buon esito della compilazione o per rilevare l'eventuale occorrenza di errori
• Collaudo nominale:
• [+] esecuzione corretta; alla stringata informazione del manuale d'uso hanno sopperito l'assistenza e la presenza degli esperti del fornitore
• Collaudo di malfunzionamento:
• [+] il prodotto si e' mostrato sufficientemente robusto rispetto all'esecuzione di azioni erronee, proibite od improvvide da parte dell'utente
• Valutazione complessiva: piu' che sufficiente
  

Maelstrom

RQ

• Buona la modalita' di consegna. Nessun documento atteso omesso o mancante

• PQ (versione 1.2)
• Discutibili sia l'approccio strategico al processo di qualifica che lo stile di documentazione:
• l'omissione deliberata di verifiche statiche non e' giustificata in modo credibile (l'asserzione posta in sezione 4 suona piu' provocatoria che utile)
• manca una descrizione riassuntiva dell'intento generale delle verifiche dinamiche e della copertura dei requisiti e dei componenti da esse fornita (tale analisi di copertura non e' neppure derivabile a posteriori a partire dalla lista dei test)
• manca una sintesi dell'esito dei test, che ne riassuma l'esito, indicando le prove passate e giustificando gli eventuali fallimenti (tale informazione non e' facilmente derivabile dalle informazioni fornite inrelazione all'esecuzione dei test)
• risulta incomprensibile come possa, in sezione 4.1, la responsabilita' "di errori e malfunzionamenti della parte esaminata" essere attribuita ai verificatori piuttosto che agli autori; la prassi istituita in sezione 5.1 chiarisce le azioni formali da intraprendere da parte del verificatore e dell'autore: tale specifica tuttavia non prevede l'istituzione di una base dati nella quale collezionare tutta l'informazione al riguardo e da usare come prova di rimozione e risoluzione di ogni anomalia e discrepanza
• La sezione 4.3 afferma: "Le prove dinamiche vengono effettuate mediante l'introduzione di diversi input ...". Tale affermazione non trova conferma nelle prove effettivamente effettuate, per le quali non sono stati specificati i criteri di scelta dei valori di ingresso
• I dati forniti in sezione 6.3 mancano di una qualche forma di ingradramento e di valutazione
  
• Documento di contenuto e di concezione globalmente insufficiente
• MU (versione 1.1)
• Documento di buona leggibilita' e di buona congruenza interna, anche se privo di collegamenti ipertestuali che facilitino la navigazione tra i componenti del prodotto
• Un errore alla linea 26 del file DrSimulator.java impedisce la corretta compilazione dei sorgenti del prodotto: una volta rimosso l'errore, la compilazioneavviene correttamente utilizzando lo script fornito per l'ambiente Windows;assai piu' macchinosa la compilazione in ambiente Linux (non prevista ma non esclusa dal manuale d'uso)
• Il testo a pagina 10 indica la presenza di una funzionalita' denominata DR-LogViewer non riscontrata nel prodotto: tale omissione deve essere corretta, poiche' non viene fornita alcuna indicazione su come accedere e visualizzare i rapporti di esecuzione prodotti dalla simulazione
• La descrizione fornita sembra aderente al comportamento riscontrato del prodotto in esecuzione
• Interessante e rappresentativa la discussione dei messaggi di errore e delle relative soluzioni
• Particolarmente apprezzabile il livello di dettaglio nella descrizione della produzione di logiche di controllo
  
• Ripartizione dello sforzo
• Buona l'uniformita' nella ripartizione degli incarichi e dello sforzo relativo: risulta particolarmente apprezzabile che ciascun membro del gruppo abbia avuto parte attiva nelle attivita' essenziali dello sviluppo e qualifica del prodotto
• Valutazione complessiva: vedi tabella
  

RA

Resoconto

• [+] Buona l'organizzazione del materiale sottomesso per accettazione
• Manuale d'uso:
• [+] discreta organizzazione del materiale
• [+] buona la descrizione relativa alla struttura ed alla creazione della logica di controllo
• [-] incompleta la lista dei comandi utilizzabili per la logica
  
• Utilita' di installazione:
• [+] compilazione avvenuta senza errori
• [-] occorre configurare a mano entrambi gli script di attivazione
  
• Documentazione
• [+] compilazione Javadoc avvenuta senza errori; buona la qualita' della documentazione generata
  
• Collaudo nominale:
• [+] esecuzione corretta
• [+] ottimi gli effetti di animazione
• [+] semplice e pratica la realizzazione della logica di controllo
• Collaudo di malfunzionamento:
• [+] il prodotto si e' mostrato generalmente robusto rispetto all'esecuzione di azioni erronee, proibite od improvvide da parte dell'utente
• [-] il simulatore consente il posizionamento di droni (e, presumibilmente, anche di altre entita') ad di fuori dei confini della mappa, e ne consente l'animazione ed il successivo ingresso in mappa
  
• Valutazione complessiva: piu' che buono

Microbug

RPD [2]

• DP (versione 1.1)
• In sezione 1.2.5 l'applicativo "Rational Rose" appare due volte tra gli strumenti di lavoro
• In sezione 2, nella specifica dei componenti, mancano alcuni identificatori delle associazioni nei diagrammi delle classi
• L'indice presenta un errore
• Apprezzabili i vari diagrammi
• Qualche errore grammaticale
• Complessivamente buoni struttura e contenuto del documento
  
• DCI (versione 1.2)
• In sezione 2.1.1.5 in relazione al bottone 'aggiungi logica', il termine 'file di logica' non e' definito
• In sezione 2.2 (cosi' come nel prototipo), manca l'utilizzo di una griglia di riferimento che assista il posizionamento del drone nella mappa: l'utente non conosce ne' la posizione degli assi cartesiani ne'il fattore di scala
• La figura 2 sembra indicare che dallo stato 'NuovaConfigurazioneDrone' non si possa piu' passare a 'DroneIncompleto', il che e' chiaramente incongruo
  
• Complessivamente buoni struttura e contenuto del documento
  
• PQ (versione 1.2)
• Incongrua la nozione di 'nuovo stub', per indicare l'avvenuta cattura di un valore di uscita prodotto dall'unita' sotto test: lo stub (componente passivo artificiale del test non cambia natura all'atto di catturare valori in uscita)
• Documento di qualita' complessivamente accettabile
  
• Utilita' di installazione
• Scarsamente significativa la diagnostica fornita al termine della compilazione: assai preferibile sarebbe che essa fosse (intelligentemente) dipendente dall'esito
• Codice
• Il file DDKDrone presenta un errore di sintassi alla linea 138
• Buona la qualita' generale del codice
  
• Valutazione complessiva: vedi tabella
  

RQ

• Ottima la modalita' di consegna e l'organicita' del formato
  

• PQ (versione 1.3)
• Ottimo il livello ed il rigore della presentazione della campagna di qualifica
• Apprezzabile la sistematicita' dell'approccio
• Discutibili alcune asserzioni da parte del verificatore, in assenza di norme di progetto proposte dal fornitore ed approvate dal cliente. Per esempio:
• Quale criterio oggettivo giustifica l'assenza di commenti e di descrizioni da un modulo
• Quali considerazioni rendono giustificabile ed accettabile la presenzadi file di dimensioni superiori alle 200 righe ciascuno
• La documentazione fornita in allegato supporta l'asserzione di completamento della fase di qualifica
  
• MU (versione 2.1)
• Documento agile e leggibile
• Per quanto correttamente guidata, la compilazione di DDK produce lo stesso errore gia' rilevato in sede di RPD [2]; la compilazione ha successo dopo la correzione dell'errore
• L'attivazione di DDK avviene solo rimuovendo dal relativo script l'istruzione di verifica di esistenza del file classes/DDK/Interfaccia_DDK.class
• All'attivazione, DDK si presenta come descritto nel manuale ed opera correttamente, a meno di 2 discrepanze da rimediare prima della RA:
• Etichetta "Componeneti imperiali" nel pannello di sinistra, sia nel prodotto che nell'illustrazione nel manuale
• Bottone "REMOVE" al centro del pannello, descritto come "Remove" nel manuale
• L'attivazione del Simulatore presenta lo stesso problema rilevato per DDK, in relazione al file classes/Simulazione/Simulatore.class
• L'occorrenza di guasti di funzionamento (nella forma di eccezioni non trattate per mancanza di componenti necessarie) sembra indicare lo stato di incompletezza dell'implementazione del Simulatore o del materiale consegnato
• Guasti fatali hanno luogo al caricamento di droni tra quelli predefiniti dall'installazione, con il fallimento dell'azione alla linea 455 del file Entita.java. La ragione del fallimento pare risiedere nell'essere le classi da caricare denominate con cammini assoluti applicabili solo all'ambiente di sviluppo
  
• Tale situazione viola le precondizioni di ingresso alla RQ e contraddice le asserzioni di qualifica fornite dal PQ, il quale non rileva il problema sopra descritto
• L'interessante decisione di utilizzare la classe attiva Entita come classe unificante da specializzare in Drone e Verme rende l'intero pacchetto di simulazione densamente concorrente. A fronte di cio', tuttavia, la descrizione e la giustificazione dei meccanismi che ne sovraintendono l'esecuzione risulta largamente deficitaria. I soli luoghi idonei di tale descrizione sarebbero stati la ST ed la DP. L'assenza di tale informazione puo' essere almeno in parte emendata mediante l'inserzione di adeguati commenti, possibilmente fruibili mediante Javadoc, alle rilevanti parti del codice,particolarmente Entita.java e Simulatore.java
• Ripartizione dello sforzo
• Quasi risolto lo squilibro nella distribuzione degli impegni e dello sforzo. Due situazioni risultano particolarmente deficitarie:
• Che un membro del gruppo abbia ricevuto carichi superiori del 50% rispetto alla media del gruppo
• Che uno o piu' membri del gruppo non abbiano avuto parte attiva, nel corso del progetto, in tutti i ruoli produttivi rilevanti (analisi dei requisiti, documentazione, codifica, qualifica)
• Valutazione complessiva: vedi tabella

RA

Resoconto

• [-] Emendamento sostitutivo del materiale di accettazione consegnato fuori tempo massimo (le ore 18:00 del giorno precedente la sessione accettazione). L'emendamento corregge un difetto non precedentemente rilevato nel simulatore
• [+] Buona l'organizzazione del materiale sottomesso per accettazione
• Manuale d'uso:
• [+] buona l'organizzazione del manuale
• [+] buona la descrizione relativa alla struttura ed alla creazione di logiche di controllo
• Utilita' di installazione:
• [+] installazione e compilazione senza errori
• Collaudo nominale:
• [+] esecuzione corretta
• [+] buoni gli effetti di animazione
• [-] visualizzazione disturbata dei dati immessi da tastiera
  
• Collaudo di malfunzionamento:
• [+] il prodotto si e' mostrato sufficientemente robusto rispetto all'esecuzione di azioni erronee, proibite od improvvide da parte dell'utente
• [-] non tutte le eccezioni vengono intercettate
• Valutazione complessiva:  buono
  
  

NoPanic

RPD[2]

• Consegna avvenuta fuori tempo massimo
• Strutturazione del materiale di consegna globalmente accettabile, a meno delle seguenti incongruenze
• Denominazione dei documenti non standard (p.es.: DCInuovo.html e DefinizioneDiProdotto.htm) e priva di indicazione di versione
• Codice sorgente fornito in due versioni apparentemente non congruenti (una accessibile tramite collegamento ipertestuale dal documento DefinizioneDiProdotto.htm al documento CodiceSorgente.htm; l'altra in cartella codice/ultimaVersione.zip)
  

• DP (versione 1.1)
• Lo standard di disegno architetturale necessita di maggior cura nelle definizioni della terminologia e della simbologia UML
  
• Lo standard di programmazione descritto in sezione 4.2.4 va poco al di la' di richiedere alcuni campi nel preambolo, prescrizione che il codice sorgente non sembra rispettare (p.es.: manca l'indirizzo dell'autore; manca l'indicazione di prima versione e l'eventuale storia di modifiche). Sarebbe stato assai piu' opportuno e conveniente adottare standard di codifica riconosciuti per Java e Javadoc
• La sezione 4.3 indica l'uso di "Java 1.2" (si presume con riferimento al relativo ambiente JDK) mentre altri documenti indicano l'uso della versione 1.3. Si noti che e' prassi utile indicare nel preambolo di ciascun file la versione del compilatore con il quale esso sia stato compilato
• Il documento non fornisce alcun informazione utile per comprendere il funzionamento dinamico del sistema. Date le caratteristiche densamente concorrenti del sistema determinate dal file "DRSimulator.java", tale lacuna impedisce l'accertamento dell'adeguatezza ed accettabilita' del prodotto
• Globalmente il livello di descrizione del progetto e' insufficiente ed inadeguato allo scopo della revisione
  
• Il diagramma delle classi relativo al Costruttore DR (sezione 5.1) e' e' poco leggibile ma sicuramente non descrive il concetto espresso in chiaro piu' sotto: "La composizione identifica un assemblaggio di componenti creato"
  
• Il diagramma del Simulatore di attivita' e' incompleto
  
• L'aspetto visuale del documento e' scarno, minimale, e privo di utilita' (p.es. collegamenti ipertestuali) per la navigazione al suo interno e verso materiale esterno eventualmente rilevante
• Poco curata la correttezza grammaticale ed ortografica
  
• La descrizione della relazione tra requisiti e componenti dovrebbe essere bi-direzionale, al fine di mostrare la sufficienza (tutti i requisiti mappati su componenti) e la necessita' (tutte i componenti mappati su requisiti) dell'architettura del prodotto
  
• DCI (versione 1.1)
• Il documento limita la sua descrizione alle interfacce esterne (quelle visibili all'utente). La descrizione delle interfacce interne (quello esercitate nelle relazioni tra classi del sistema) e' completamente omesse. Cio' ostacola l'elaborazione di una strategia soddisfacente per la verifica di tali interfacce. Si noti che tale omissione non e' bilanciata dalla breve elencazione delle classi interne fornita, p.es., per DRSimulator. Tale descrizione non e' pertinente al documento
• La notazione con la quale il documento fa riferimento a cartelle rilevanti per il funzionamento del prodotto e' erronea in quanto ne denota il cammino assoluto al posto di quello relativo
  
• L'aspetto visuale del documento e' scarno, minimale, e privo di utilita' (p.es. collegamenti ipertestuali) per la navigazione al suo interno e verso materiale esterno eventualmente rilevante
• Poco curata la correttezza grammaticale ed ortografica
  
• PQ (versione 2.1)
• Le definizioni di verifica statica (2.1) e verifica dinamica (2.2) non sono corrette
• La validazione (sezione 4.1) non e' effettuata dal committente, ma dal fornitore, e dimostra il completo soddisfacimento dei requisiti posti dal committente
• Le asserzioni fatte in sezione 6.2 relative al soddisfacimento dei vincoli di uso di risorse logiche e fisiche sono quantomeno ingenue e, pertanto,inadeguate
• Buona la concezione dei casi di prova dinamica in relazione diretta con la verifica di soddisfacimento di requisiti. Manca una tabella riassuntiva (bi-direzionale, come indicato in relazione al documento DP) della mappatura tra requisiti, componenti e prove
  
• MU (V2)
• Documento di scadente formato, scarso rigore e difficile lettura
• L'indicazione di versione dovrebbe apparire sia nel nome del documento che al suo interno
• Mancano indicazioni su come installare ed eseguire il codice
• Mancano indicazioni su come costruire logiche di controllo e mappe utente
• Il prodotto sembra mancare di utilita' per la generazione e la visualizzazione di rapporti di simulazione (esecuzione)
  
• Codice
• La cartella codice/ultimaVersione.zip contiene file di codice (p.es. Skills.java) che non sembrano appartenere al progetto
• Buono il rapporto tra linee di comando e commenti
• Buona la qualita' generale e lo stile di codifica
  
• Eccessiva la taglia dei file (tutti ampiamente superiori alle 200 linee, con punte di 2367 linee (di cui 1191 di comando) per il file "DRBuilder.java". Unita' di tali dimensioni sono pressoche' incontrollabili
• Tutto il codice e' stato prodotto da un solo membro del gruppo
• Il codice sembra compilare correttamente, ma sembra anche essere funzionalmente incompleto (tale appare se lanciato ed eseguito secondo le istruzioni del manuale)
• La cartella non fornisce alcuna indicazione utile per guidare la compilazione
• Manca del tutto, ed e' desiderabile per la prossima revisione, una prima forma di documentazione del codice generata da Javadoc
  
• Ripartizione dello sforzo
• Il consuntivo per risorse sembra indicare una buona uniformita' nella ripartizione dello sforzo e degli incarichi. Tale informazione, pero', crea qualche dubbio laddove indica attivita' di codifica da parte di tutti i membri del gruppo a fronte di un solo autore di tutto il codice sorgente fornito
• Valutazione complessiva: vedi tabella

RQ

• termine di consegna: da concordare
  
• comunicazione e discussione esito:

RA

• termine di consegna:
  
• sessione di accettazione:

TrendSoft

RQ[2]

• Consegna avvenuta fuori tempo massimo
• Molto buona la strutturazione e l'organicita' del materiale di consegna, incluso il supporto per la configurazione delle varie utilita'

• DP (versione 1.1)
• Confermato il giudizio molto buono emesso nel corso della RPD: il documento e' di ottima qualita', di elevata congruenza interna, e di buona leggibilita' complessiva
  
• PQ (versione 1.3)
• Buona la presentazione e la strutturazione dell'intera strategia di qualifica
• Manca una tavola riassuntiva dell'esito delle prove di verifica
• Manca una mappatura bi-direzionale tra prove e requisiti e tra prove e componenti del disegno architetturale e di dettaglio: tale mancanza impedisce di fatto la determinazione della copertura fornita dalla campagna di qualifica nel suo complesso
• Nessun esito viene indicato rispetto alle prove di collaudo: ne deriva che la fase di qualifica del prodotto e' ancora in corso, in violazione delle precondizioni di ingresso alla RQ
• Emendamenti e/o chiarimenti (versione 1.4)
• Interessante la menzione di uso di tecniche di verifica tramite analisi. Del tutto omessa qualsiasi indicazione relativa all'esito.
• Bene il riepilogo riassuntivo delle prove di integrazione. Manca l'equivalente in relazione alle prove di collaudo
• Nota che il termine 'walktrought' non ha significato (mentre lo ha il termine 'walkthrough)
• In sezione 6 (piano di integrazione) si asserisce la necessita' di modificare temporaneamente la visibilita' di metodi privati al fine di consentirne l'invocazione dall'esterno. L'uso di tale tecnica e' da evitare in quanto sconveniente e pericoloso. Se metodi privati esistono essi risponderanno ad una qualche esigenza d'uso, esisteranno pertanto "clienti" di essi, tra i quali si troveranno, procedendo a ritroso nell'albero di chiamate, anche metodi visibili dall'esterno
• MU (versione 2.0)
• Incongruente la specifica di versione del manuale, indicata come 2.0 nella denominazione del file e come 1.1 al suo interno
• Confermata la buona impostazione e l'ottima fruibilita' del documento, finalmente bilanciato in ogni sua parte
• Ottimo il livello di dettaglio nella guida all'installazione ed ad all'uso del prodotto
• Alcune incongruenze dovrebbero essere sanate prima dell'accettazione:
• L'esecuzione del comando di compilazione si blocca indefinitamente sul comando javadoc
• La verifica di integrita' (completezza) del pacchetto di installazione pare dover essere eseguita sulla cartella *.zip senza che questo venga specificato nel manuale
• La scelta di far chiudere automaticamente l'applicazione SimulatoreMain al completamento della simulazione e' particolarmente discutibile ed assai sorprendente. Insufficiente evidenza viene data nel manuale a tale modalita' di funzionamento
• Non e' chiara la corrispondenza tra i nomi dei droni mostrati in simulazione (che sembrano predefiniti) e quelli presenti nella cartella di configurazione
• Emendamenti e/o chiarimenti (versione 2.1)
• Sanate le incongruenze piu' rilevanti
  
• Resta inadeguatamente sottolineato il fatto che un drone creato ma privo di logica resta inutilizzabile (ed irriconoscibile) ai fini della simulazione
• Laboriosa e complessa la generazione di logiche di controllo da parte dell'utente. Apprezzabile invece la descrizione a livello manuale
  
• Codice
• Per quanto la RQ segni il completamento della campagna di qualifica di un prodotto completamente implementato, nessun modulo di codice tra quelli consegna e' marcato con "Finale", mentre diversi sono marcati come "Alpha", con cio' segnalando il mancato soddisfacimento delle precondizioni di ingresso alla RQ, come anche indicato dai consuntivi in piano di progetto. Tale inconsistenza deve essere sanata prima di procedere con la revisione (e la successiva accettazione)
• Circa meta' dei file hanno dimensioni superiori alle 250 linee; alcuni di essi ampiamente superiori, fino a diverse migliaia di linee. Tale dimensione e' di grande ostacolo alla comprensione, la verifica e la manutenzione del codice
• Il preambolo di alcuni file (p.es.: assemblatoredroni/JCompDroni.java, assemblatoredroni/DroniInfoListener.java) non aderisce agli standard di codifica specificati in DP
• Buona la qualita' generale del codice e la densita' di commenti
• Dal campo 'Autore' dei file di codice risulta che due membri del gruppo su 6 non hanno avuto responsabilita' di codifica e che un membro abbia preso in carico oltre il 50% dell'intera codifica, a fronte di uno sforzo complessivo dichiarato a consuntivo superiore del 50% al preventivo
• Emendamenti e/o chiarimenti (versione assunta finale)
• Un congruo numero di moduli ha numero di versione 1.0.0, e pertanto nessuna storia di modifica registrata
• Soltanto due moduli (AssemblatoreDroniMain.java e SimulatoreMain.java) sono marcati come 'finali'
• La compilazione del codice e la generazione della documentazione avvengono correttamente, su piattaforma Windows/JDK 13.1, seguendo le istruzioni del manuale
  
• Ripartizione sforzo (a fronte di consuntivo finale)
• Grave squilibro nella distribuzione degli impegni e dello sforzo.
  Due situazioni risultano particolarmente deficitarie:
• Che un membro del gruppo abbia ricevuto carichi superiori del 50%rispetto alla media del gruppo
• Che uno o piu' membri del gruppo non abbiano avuto parte attiva, nel corso del progetto, in tutti i ruoli produttivi rilevanti (analisi deirequisiti, documentazione, codifica, qualifica)
• Valutazione complessiva: Buona la qualita' complessiva del prodotto. Inadeguato lo sforzo di pianificazione, sia rispetto al soddisfacimento delle pre-condizioni di ingresso alle revisione che rispetto alla ripartizione ed il bilanciamento degli incarichi. Scelte discutibili nell'organizzazione del codice, che ne ostacolano grandemente la comprensione a fini di manutenzione

RA

Resoconto

• [+] Buona l'organizzazione del materiale sottomesso per accettazione
• Manuale d'uso:
• [+] buona organizzazione del materiale
• [+] buona la descrizione testuale dei meccanismi di creazione di logiche di controllo
• [-] eccessivamente laboriose ed oscure le modalita' di tale creazione
• l'approccio seguito rende la specifica e la realizzazione della logica dipendenti dal linguaggio Java, senza pero' fornire alcun meccanismo ne' sintattico ne' semantico per verificare correttezza, consistenza e completezza della realizzazione della logica, cio' costituendo un serio limite d'utilizzo
• Utilita' di installazione:
• [+] compilazione avvenuta senza errori
• [+] buona la struttura e la potenza espressiva del file di configurazione
• Documentazione
• [+] compilazione Javadoc avvenuta senza errori
• Collaudo nominale:
• [+] esecuzione corretta di entrambe le utilita' (assemblatore e simulatore)
• [-] l'assemblatore non fornisce alcun supporto alla creazione della logica che abilita alla simulazione i droni correttamente creati
• [-] il simulatore non consente all'utente di posizionare i droni
• [+] buoni gli effetti di animazione
• Collaudo di malfunzionamento:
• [+] il prodotto si e' mostrato robusto rispetto all'esecuzione di azioni erronee, proibite od improvvide da parte dell'utente, molto di cio' essendo dovuto alle limitatissime liberta' d'uso e di comando lasciate all'utente
• [-] e' tuttavia possibile uscire dall'applicazione 'simulatore' a simulazione in corso senza che l'abbandono della simulazione venga rilevato e/o notificato
• Valutazione complessiva: buono