Beacon Strips (C2)
Presentazione: 25 Giudizio complessivo sui documenti: 24
Consegna e considerazioni generali
Consegna: include un documento spurio con nome “Analisi dei req.pdf”.
Lettera di Presentazione: niente da segnalare. Registro delle modifiche: bene.
Attenzione al formato tipografico: le intestazioni e i piè di pagina (che acquisiscono testo dal corpo del documento) devono evitare le sovrapposizioni che si verificano invece nel PdQ.
Presentazione Buona modalità di erogazione. Ingenuità ed errori nei contenuti tecnici.
Apprezzabile demo.
Norme di Progetto v3 Il documento resta difettoso per insufficiente copertura dei processi istanziati dal progetto e per scarsa profondità del contenuto.
Analisi dei Requisiti v3
Figg. 15, 17: è presente un’azione con più di un flusso entrante. Il documento è migliorato e l’errore sull’estensione nei diagrammi dei casi d’uso è stato in gran parte corretto. Con l’introduzione dei diagrammi di attività sono stati però introdotti gli errori sopra segnalati, che sono da correggere nella versione da consegnare in ingresso alla RA.
Specifica Tecnica v2
Il documento non fornisce visione complessiva dell’architettura con le sue macro-caratteristiche. Il pattern MVC non è contestualizzato. Fig. 30: il diagramma delle classi del pattern Singleton è errato. Il documento ha buona struttura, ma continua a mancare di una descrizione chiara dell’integrazione dei framework e librerie utilizzate all’interno dell’architettura.
Definizione di Prodotto
La formattazione scelta per la descrizione delle componenti risulta caotica.
Alcune componenti hanno attributi di tipo void (ad esempio Building). È corretto che classi come LinearScoringAlgorithm stiano all’interno dei package “data”? Inoltre, questa tipologia di classi andrebbe descritta in maggiore dettaglio. Nella parte client, sono presenti molti oggetti di tipo JSONObject. È opportuno fornire uno schema preciso per questi oggetti.
L’utilizzo diretto del pattern Singleton, come in LoginManager, è sconsigliato. Meglio l’uso di un dependency injector che garantisca le caratteristiche singleton per una componente. Non è chiaro come la componente server acceda e gestisca i dati all’interno del database. Quale pattern è stato utilizzato per l’accesso ai dati? I diagrammi di sequenza vanno aumentati in numerosità. Il tracciamento nel documento di DP deve essere relativo alle coomponenti fisiche dell’applicazione, ossia alle classi o ai metodi in esse contenuti. Non è accettabile limitarsi ai package.
Il documento ha struttura discreta. Il livello di dettaglio delle descrizioni è da documentazione pubblica, inadeguato quindi a svolgere il suo compito ai fini di progetto: i contenuti devono quindi essere aumentati almeno per le componenti di business. Il tracciamento è da correggere. Documento da ripresentare prima dell’ingresso in RA.
Manuali
Manuale utente: come fa l’utente a ottenere copia dell’applicazione? Qual’è il processo da seguire per la segnalazione di errori? Non è presente una lista dei messaggi di errore che possono essere incontrati nell’applicazione. Nella descrizione del “Gioco” deve essere fornito un esempio per ogni possibile tipologia di domanda. Il documento ha buona struttura. Deve però essere completato con la descrizione di tutte le funzionalità dell’applicazione e inserendo quando sopra indicato.
Piano di Progetto v3 Nessun miglioramento percepibile è stato attuato nella direzione delle richieste ricevute in sede di RP.
Piano di Qualifica v3
La revisione non cura l’indesiderabile sovrapposizione di contenuti con il documento Norme di Progetto. Buoni i contenuti della sezione 5, che sarebbe però meglio collocata in appendice. Lo stato di avanzamento dei test è insufficiente rispetto ai prerequisiti di ingresso in RQ. Buone le appendici.
Glossario v3 Bene.
