404notfound (C4)
Presentazione: 23 Giudizio complessivo sui documenti: 20
Consegna e considerazioni generali
La consegna include una cartella a contenuto piatto, senza gerarchia di separazione per tipo di documenti (interni, esterni, codice), e con materiale non pertinente alla revisione corrente, inclusi tutti i sorgenti, in clamorosa violazione delle specifiche.
Alcuni documenti hanno sezioni vuote, segno di errori nella loro generazione automatica e di insufficiente verifica prima della consegna. Alcune
segnalazioni sollevate già in sede di RP sono state ignorate senza fornire giustificazione od opportune contro-deduzioni, segno di scarsa attenzione.
I riferimenti, normativi o informativi devono essere sempre specificati e devono sempre specificare la versione del documento riferito o la data di ultimo accesso, in sua assenza: questa integrazione non è stata applicata in modo sistematico a tutti i documenti.
Presentazione
Discreta qualità grafica e di erogazione orale. Insufficiente dettaglio tecnico, nonostante la sollecitazione ricevuta già in sede di RP. Discreta dimostrazione di prototipo, cui segnatamente manca supporto per la mappa della
presentazione, elemento chiave del capitolato.
Norme di Progetto v3
Il documento è stato rivisto per organizzazione e, in minor misura, per contenuti, in risposta alle segnalazioni ricevute in sede di RP. L'esito però non è ancora soddisfacente, perché non cura i difetti già precedentemente rilevati.
Non è chiaro se tale risultato derivi da ostinazione o da insufficiente chiarezza nella formulazione dei commenti.
Il documento presenta ancora diverse criticità.
Analisi dei Requisiti v3
Non tutti i casi d’uso possiedono un flusso principale degli eventi. Ne era stato richiesto l’inserimento già in sede di RP. Le richieste sui requisiti di qualità e vincolo non sono state soddisfatte. PDe19: è presente lo stesso errore segnalato in RP: “per per”.
Il documento ha recepito le indicazioni fornite in sede di RP solo per quanto riguarda i diagrammi dei casi d’uso. Tutte le altre indicazioni sono state ignorate e persistono errori già segnalati. Tali segnalazioni vengono fornite affinché possano essere prese da voi in carico da una revisione all’altra.
Documento insoddisfacente, da rivedere.
Specifica Tecnica v2
Il documento è ancora privo di riferimenti normativi e informativi. Il riferimento al Glossario non specifica alcuna versione. La fig. 1 può deve essere aumentata di dimensioni. La componente server non è praticamente descritta. Quali scelte architetturali hanno portato a individuare unicamente due componenti? Che responsabilità hanno queste componenti? Perché la struttura del server non rispecchia per lo meno la divisione dei tipi del modello dati? Ancora non è chiaro dove le librerie esterne siano utilizzate all’interno dell’architettura. Il documento di ST ha anche lo scopo di
comprendere come l’architettura generale utilizzi librerie e framework esterni.
La descrizione dei design pattern non è calata nell’architettura del prodotto.
Documento deludente, da rivedere.
Definizione di Prodotto
Le proprietà aggiuntive di un metodo in UML vanno indicate fra parentesi { } dopo il tipo di ritorno. Pag. 8: il livello di dettaglio delle descrizioni di questi metodi è troppo scarno (“pubblica una lista...”, da dove viene recuperata la lista? Utilizzando quali strutture? Attraverso quali algoritmi?). Ad esempio, getInfographicFrames: viene fornita una nota che indica che la presentazione deve essere associata all’utente che ha effettuato la richiesta. Non è chiaro però da dove l’informazioni sull’utente venga recuperata. Pag. 11:
CurrentUser, perché il metodo ha la prima lettera maiuscola? Inoltre, non è corretto che esso acceda direttamente al database. Pag. 12: bene le note, ma non sarebbe stato più consono fornire direttamente il JSON da utilizzare come default? Le componenti descritte in §3.2.1. e §3.2.2 non sono distinguibili.
toastMessageFactory: come deve essere implementata? §3.3.1: le classi di metodi statici andrebbero evitate, poiché poco si adattano ai concetti di OOP e FP. Valutare se creare delle classi service che abbiano il compito di
interfacciarsi con le API suddividendo le chiamate per tipo di oggetto di business. Fig. 9: rivedere, non vi è dipendenza circolare fra i controller e le viste, ma la dipendenza coinvolge anche l’oggetto $scope. Le componenti sono indicate con la prima lettera minuscola nel package
premi/client/presentationManager. Nei diagrammi inoltre, non è chiara la dicitura ($scope) prima del nome delle classi dei Controller. Quali metodi e attributi di questi vengono esposti attraverso l’oggetto $scope corrispondente?
Inoltre, quando i metodi si aspettano un oggetto JSON, è necessario fornire lo schema o un esempio per documentare la struttura dell’I/O. §4: non è corretto che il tracciamento sia condiviso fra ST e DP, poiché le entità individuate sono potenzialmente diverse: componenti logiche nel primo caso; componenti di dettaglio nel secondo.
Il documento ha buona struttura e contenuto discreto, da rivedere.
Alcuni metodi sono approfonditi più di altri, ma vi sono alcune parti che devono essere completate come indicato e alcune scelte architetturali devono essere affinate.
Manuali
Manuale utente: Pag. 6: indicare esplicitamente i browser per i quali si è certi che l’applicativo funzioni (dovrebbero essere presenti nei requisiti). Dare inoltre indicazione di come è possibile accedere all’applicazione. Pag. 7: la password deve essere composta da “n” caratteri, ossia? Bene §3.6, ma per non perdere l’utente è necessario inserire più immagini screenshot.
Il manuale ha struttura e buoni contenuti. Deve essere completato inserendo un numero maggiore di screenshot ove possibile.
Piano di Progetto v3
La revisione del documento presenta qualche correzione nella direzione delle segnalazioni ricevute in sede di RP, ma non pienamente soddisfacenti.
I contenuti di tabella 7 non correlano in modo esplicito con l'attualizzazione dei rischi presentata nella parte precedente di §5, e ciò ne riduce l'utilità. I contenuti di §6 attengono alle Norme di Progetto e non al PdP. La struttura di
§9 non è convincente, perché oscura quanto già appreso dai consuntivi parziali precedenti (in termini di dati e di correzioni) e nasconde il consuntivo corrente e il preventivo a finire all'interno di §9.2, invece di trattarli a parte. I contenuti di §9.2.2 sono solo discorsivi e non forniscono alcuna informazioni di vera pianificazione di calendario e di impegno; manca quindi evidenza che il gruppo sia in grado di completare il lavoro entro le scadenze imminenti e senza sforare nell'uso di risorse.
Piano di Qualifica v3
Il documento ha subito importanti modifiche migliorative, nella direzione delle segnalazioni ricevute in sede di RP. Anche in questo caso però con esito non del tutto soddisfacente.
I contenuti di §2 descrivono attributi di qualità interessanti, ma non fissano gli obiettivi quantitativi che il gruppo si assume nel progetto: nella sua attuale forma, tale materiale è da collocare in appendice e non nel corpo del documento. I contenuti di §3.1, che per titolo assolverebbero a questa funzione, sono dunque pertinenti a §2, ma sono ancora insoddisfacenti perché privi di indicazioni misurabili. L'attenzione al ciclo PDCA in §4.3 non è congruente con la sopracitata assenza di misurabilità negli obiettivi e nei processi impegnati.
Discrete invece le appendici, cui manca però una visione di sintesi sull'andamento (e, in presenza di obiettivi quantitativi, sul loro grado di raggiungimento). Le tabelle in §A.3 hanno un problema di sovrapposizione di testo.
Glossario v3 Bene.
