DonkeyCode (C3)
Presentazione: 27 Giudizio complessivo sui documenti: 26
Consegna Regolare nei tempi e buono per organizzazione. Codice, di discreta qualità apparente, incluso nella fornitura.
Considerazioni generali Il capitolato d'appalto è da considerare riferimento normativo. Presentazione buona per struttura ed efficace per contenuti ed erogazione.
Norme di Progetto v3.0 Modesto per quantità ma interessante per qualità il contenuto aggiuntivo incluso nella versione corrente del documento.
Specifica Tecnica v2.0
Complimenti per aver scovato anche il pattern MVPC (che effettivamente esiste)! Pag. 5: “sopratutto". Fig. 9: l'architettura del vostro modello è progettata in modo da fornire gruppi di funzionalità troppo legate con le tipologie di utenti dell’applicazione: il modello dovrebbe invece essere totalmente agnostico sulla vista. Stessa figura: non c’è alcuna classe che implementa le interfacce del package services. Fig. 12: è presente una condizione senza guardia.Il documento è migliorato e tratta ora i corretti argomenti architetturali. Sono stati introdotti piccoli errori che potrebbero essere corretti. Nel complesso discreto.
Definizione di Prodotto
Molto bene l’introduzione alle descrizioni delle componenti di dettaglio mediante diagrammi ad alto livello. Molto bene anche l’utilizzo di notazione UML standard nelle descrizioni delle operazioni e membri di classe. La trattazione delle componenti di dettaglio deve essere maggiormente divisa fra componenti server side, client side e mobile. Fig. 13: i due tipi sono troppo accoppiati, poiché Priority possiede le descrizioni dei valori
dell’enumerazione: provare a pensare una differente struttura che mantenga valore e descrizione nello stesso tipo (analogamente per il tipo Gravity, Status, ecc…). Per almeno una delle classi Converter sarebbe opportuno riportare il mapping tra le informazioni di un oggetto TO e BO. Pag. 60:
“{update…”, “{delete…”. La divisione delle operazioni definite nel package server.model.services è troppo legata all'interfaccia utente per poter essere inserita nel modello, il quale dovrebbe essere agnostico rispetto al proprio utilizzatore. Inoltre, il fatto però che questi tipi possiedano un DAO fa sì che essi non possano essere spostati nel controller senza richiedere un refactoring.
Fig. 108: la figura è tagliata rispetto all’ordinamento della pagina (sono presenti altre immagini nel documento tagliate). È necessario un diagramma di sequenza per comprendere bene il flusso dell’applicazione al momento della creazione dei presenter e delle view attraverso le factory definite:
rivedere. Pag. 215: “il metodo avvalora”, si dice “valorizza”. Bene l’utilizzo di eccezioni personalizzate. Fig. 182: non è presente la guardia di
terminazione del ciclo loop. Bene i diagrammi di sequenza. Bene anche il tracciamento. Il documento ha una buona impostazione e raggiunge un buon grado di dettaglio nella descrizione dei metodi. Correggere l’errore
architetturale riscontrato e sistemare le immagini. Nel complesso, buono.
Manuali
Non è presente un manuale in cui si descriva la procedura di installazione dell’applicazione su un application server (nel vostro caso quello di Google).
Non sono nemmeno elencati i requisiti minimi di sistema per l’utilizzo di Rescueme: provvedere.
Manuale-popolazione-1.0.0.pdf
Pag. 1: inserire le versioni supportate di browser. Pag. 3: riferirsi a un esempio di pagina in cui si indicano anche graficamente i concetti di header, corpo, ecc.., che possono non essere familiari per una persona non “addetta ai lavori”. Fig. 2: eliminare la dicitura “latitudine null / …”, poco parlante.
Come si raggiunge da fig. 2 (che è descritto essere la pagina principale dell’applicazione) la fig. 3? Per la funzionalità di logout dare un suo
riferimento posizionale all’interno della pagina. Attribuire un codice di errore univoco ai messaggi per facilitare la loro segnalazione da parte di un utente.
Manuale-autorita-1.0.0.pdf
Bene la suddivisione degli utenti fra i manuali. Converrà spostare la descrizione dell’amministratore di autorità prima di quella dell’operatore.
Contestualizzare meglio le singole funzionalità all’interno della pagina.
L’impostazione è comunque buona.
Manuale-applicazione-android-1.0.0.pdf Bene.
Piano di Progetto v3.0
Pur se confermando nel complesso la buona impostazione già rilevata in sede di RP, il documento soffre di poca chiarezza e presentazione confusa nella parte aggiuntiva relativa al preventivo a finire. Risulta particolarmente difficile capire quale distanza di tempo e di risorse il gruppo reputi esservi tra lo stato attuale e il completamento del progetto. Curiosa l'idea che il costo aggiuntivo necessario alla completamento delle attività di progetto possa
“gravare sul preventivo”. Attenzione: Gantt è un nome proprio e come tale va scritto con l'iniziale in maiuscolo.
Piano di Qualifica v3.0 Molto buono per impostazione e contenuto. Molto interessanti i rapporti sull'esito delle verifiche riportati nell'appendice B, nella quale però converrà usare uno stile più fattuale (dati, fatti, tabelle, grafici) invece che narrativo.
Glossario v3.0 Buono per impostazione e contenuto.
