LateButSafe (C4)
Presentazione: 25 Giudizio complessivo sui documenti: 20
Consegna e considerazioni generali
I dettagli forniti per identificare le fonti dei riferimenti informativi continuano a essere insufficienti nonostante le ripetute segnalazioni in sede di revisione.
Migliorata invece l'accuratezza informatica del registro delle modifiche.
L'uso della convenzione “voce di glossario” andrà evitata nei titoli di paragrafo visto che la g in pedice corrompe i bookmark, ma anche perché ridondante.
Alcuni documenti presentano ancora un certo numero di errori tipografici o di formattazione, segno di insufficiente verifica, per metodo, attenzione ed efficacia.
Presentazione
Buoni il ritmo e il flusso di erogazione, migliorati rispetto alla revisione precedente. La notazione usata per mostrare diagrammi è sovente non standard, con scelta editoriale inopportuna per una presentazione tecnica.
Nessuna dimostrazione di prototipo, per scelta intenzionale, ma solo una sequenza di catture di schermo che delineano il funzionamento desiderato del prodotto.
Norme di Progetto v3
Il documento è stato modificato nella direzione delle raccomandazioni ricevute in sede di RP, talvolta però in modo poco ragionato (per esempio, I contenuti di §4.6.1 sono in realtà parte di §5.1, mentre quelli di §4.7 sono da collocare all'interno di §4.6). Una volta effettuate queste correzioni, il documento avrà raggiunto sufficiente e soddisfacente maturità.
Analisi dei Requisiti v3
Persiste l’errore sul caso d’uso UC0.9.2. RQ13 è ancora riportato come requisito di qualità, anche se in sede di RP è stato) segnalato che la sua classificazione è errata.
Il documento ha corretto alcuni degli errori segnalati in RP, ma altri ne permangono. Se ciò fosse intenzionale, andrà giustificato esplicitamente. In caso contrario, ciò denoterebbe scarsa attenzione.
Specifica Tecnica v3
Per quale motivo individuate vantaggi/svantaggi solo per la tecnolgia HTML (5) ? Come già segnalato in sede di RP, la presentazione dei DP utilizzati dovrebbe essere portata al termine del documento, come appendice. Fig. 1 è troppo informale per descrivere il pattern e come questo sia utilizzato nell’architettura del prodotto. Fig. 2: le classi astratte devono essere riportate come tali. Inoltre non sono presenti gli oggetti receiver per i singoli comandi.
Qual è il vantaggio dell’utilizzo di un Invoker unico? Non è chiaro.
L’applicazione ha necessità di una componente server, non è quindi possibile individuare unicamente una struttura MVC, poiché il prodotto dovrà essere necessariamente distinto in due componenti distinte e indipendenti. Nel diagramma fornito in fig. 6 non è presente la componente InsertEditRemove.
Fig. 7: è ancora presente un package di nome “Presenter”. Ragionare sulla reale necessità del tipo Invoker. AbstractCommand viene definita come
“interfaccia astratta”. È corretto? Model::serverRelations: la suddivisione fra le componenti server e client non è per niente chiara. Esplicitare. Fig. 13:
alcuni rami non hanno guardie associate, come già segnalato in sede di RP (e questo è problema comune a molti dei diagrammi di attività riportati). Il tracciamento è ancora incompleto: come osservato in sede di RP, molte componenti non hanno alcun requisito associato e viceversa, e ciò invalida l'architettura proposta.
Il documento purtroppo presenta un’architettura ancora incompleta. È necessario distinguere in modo netto la componente server da quella client e adattare il documento di conseguenza. Persistono inoltre errori già segnalati in sede di RP. Documento da rivedere.
Definizione di Prodotto
Pag. 10: “obbiettivo”. I contenuti di §2 non sono adatti a un documento di Definizione di Prodotto. §4.1: i tracciati JSON devono essere forniti, altrimenti un programmatore non ha idea di quale siano le informazioni da inserirvi. La politica di gestione degli errori per quanto riguarda l’API REST fornita va specificata. Pag. 19: alla riga 4 riga ci si riferisce a una classe astratta, ma non è chiaro quale essa sia (Premi::Model è definito come
package). La notazione scelta (elenco puntato) per riportare le informazioni di dettaglio delle singole classi è prolissa e dispersiva. Pag. 25: l’attributo Presentazione ha la prima lettera maiuscola. “setta” → imposta.
InsertEditRemove è definita come “classe statica”: cosa vuol dire? Una classe con solo metodi e attributi statici? Non è chiaro l’utilizzo dell’attributo “id”.
Perché la classe fornisce sia metodi per ritornare oggetti, che attributi di questi oggetti? In questo modo si violano i principi dell’OOP. Il tipo di ritorno dei metodi non può essere sempre Object o Array generico. Nei metodi
“remove*” non è chiara l’operazione di copia preventiva. Classe Invoker: non è chiaro il motivo per il quale la classe sia un Singleton. Nel design pattern Command, infatti, l’invoker è il tipo che ha la necessità di eseguire un’operazione delegandola al comando e pertanto non è unico. §5.3.2:
AbstractCommand ha come descrizione “classe concreta”. Non è chiaro il motivo per il quale questa classe possieda metodi per recuperare posizione, rotazione e dimensione di altri oggetti. Nelle descrizioni dei comandi concreti, cosa significa la frase: “Classe concreta, è interfaccia del Design Pattern Command”? Nei comandi concreti sono citati tipi, ad esempio “Inseter”,
“Editor”. §6.2: “i servizi sono degli oggetti che incapsulano del Codice”, definizione troppo generica. Se i services individuati sono quelli di Angular, allora essi fanno parte del modello e non della componente controller. Non è chiaro quali siano le informazioni e le operazioni che sono disponibili all’interno degli oggetti $scope. Pag. 88: “edipage”. Pag. 105: Execution, per i suoi metodi viene utilizzata una notazione mai altrimenti utilizzata all’interno del documento.
Il tracciamento bidirezionale tra requisiti e componenti di dettaglio è del tutto assente.
Il documento raggiunge un grado di dettaglio appena sufficiente, ma da migliorare per esposizione e presentazione. In particolare, è necessario andare in maggior dettaglio nei metodi più complessi del sistema, aiutandosi con l’utilizzo di diagrammi di sequenza o attività. Assente il tracciamento componenti – requisiti e viceversa. Le componenti di View e Controller vanno maggiormente specializzate sulla tecnologia scelta (Angular).
Documento da rivedere.
Manuali
Manuale amministratore: Il glossario dei manuali è rivolto a utilizzatori esterni al fornitore, pertanto non può essere quello di progetto. È necessario inserire un glossario direttamente come appendice al documento. Pag. 7:
attenzione alla grammatica: “deve essere installato sul PC ospitante il Server le tecnologie MongoDB e nodeJs”. Quali versioni dei due applicativi devono essere installate? §3: non è chiaro se i comandi debbano essere eseguiti dopo aver recuperato una particolare configurazione o pacchetto. Inoltre, le indicazioni fornite non sono applicabili a sistemi Windows (il comando sudo, ad esempio).
Il documento è in uno stato ancora molto embrionale. Le indicazioni fornite per l’installazione sono incomplete: mancano prerequisiti software e indicazioni delle configurazioni iniziali.
Manuale utente: §1.3: l’utilità del Glossario riportato non è chiara. Come viene acceduto Premi? Esistono requisiti minimi di sistema? Quali browser sono supportati? Pag. 8: “Premibisogna”. Perché fornite due workflow differenti per l’autenticazione? §3.4: è ragionevole che il salvataggio di una presentazione avvenga al di fuori della modalità di editing? §4.5.1: le funzionalità di spostamento di un frame all’interno del percorso principale, o la sua eliminazione, vanno descritti in maniera più approfondita.
Utilizzando una modalità visuale di presentazione, il documento ha buona fruibilità e struttura. Non tutte le funzionalità sono però descritte in modo approfondito.
Piano di Progetto v3
Il documento è stato modificato nella direzione delle raccomandazioni ricevute in sede di RP.
Talune di tali modifiche sono state evidentemente apportate “in velocità”, senza sufficiente ragionamento, e quindi con esito infelice, sia per qualità di presentazione (per errori tipografici e grammaticali) che per contenuto (dove l'analisi degli scostamenti non si traduce, in §8.3.2, in una pianificazione credibile, che pure sarebbe importante vista la delicatezza delle scadenze a
venire). Il resto è buono. Curiosamente, in tabella 26 manca il “totale dei totali”.
Piano di Qualifica v3
I contenuti attuali di §2 non sono conformi alle attese; essi riportano conoscenze bibliografiche (che sono materia da appendice) ma,
contrariamente alle attese, non presentano specifici obiettivi, quantitativi, di qualità fissati per il progetto. Incidentalmente, l'assenza di obiettivi
quantitativi rende vacuo il riferimento al ciclo PDCA, che di essi ha bisogno per ogni sua parte. Alcune metriche di prodotto, che servirebbero come base per la determinazione di obiettivi quantitativi di qualità, appaiono in §3.6.
Nessuna metrica di processo viene invece considerata: coerentemente con tale lacuna, i contenuti delle appendici non segnalano alcuna attività di verifica sulla qualità dei processi.
Nel complesso, il documento non assolve pienamente alla sua funzione.
Glossario v3 Apprezzabile.
