Digital Sloths (C2)
Presentazione: 25 Giudizio complessivo sui documenti: 25
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di Presentazione: bene.
Verbali: distinguendoli voi stessi tra interni ed esterni, farete bene a separarli nelle rispettive cartelle. Contenuti buoni per dettaglio informativo e
leggibilità, ma ancora non tracciabili rispetto alle decisioni prese. Registro delle modifiche: bene. Correttezza tipografica: assicuratevi che le iniziali dei titoli siano consistentemente maiuscole o minuscole.
Presentazione Discreta per flusso e qualità di erogazione. Buona per leggibilità e dettaglio tecnico. Qualche ridondanza nella (lunga) presentazione dell’architettura.
Norme di Progetto v2
Apprezzabile, pur se ancora parziale e incompleta, la riorganizzazione dei contenuti. A rigore, lo studio di fattibilità è attività del processo di fornitura, e non di quello di sviluppo. Tra i processi di supporto mancano (ed è mancanza grave) verifica e validazione. I contenuti di §5 sono meglio distribuiti nella descrizione della strumentazione a supporto di specifici processi e attività.
Nel complesso, documento ancora ampiamente migliorabile.
Analisi dei Requisiti v2
Caratteristiche degli utenti: “un utenza giovane o non particolarmente matura”, non fornire giudizi sull’utenza finale. Non è più presente un utente non riconosciuto da sistema, seppure a pag. 6 si affermi che esiste almeno un caso d’uso di errore per questo attore. Come avviene il processo di
autenticazione? Non è descritto. Fig. 5: l’inclusione descrive una
precondizione di 1.4.3. Questo caso d’uso non ha il suffisso UC nel codice identificativo. “Obbiettivo” come lo intendete nel documento deve avere una
“b” sola. RQO5: “due sperimentazione pratiche”.
Il documento è migliorato. Alcuni errori sono stati corretti. Proseguire su questa strada e consolidare il tutto con la correzione degli ultimi errori.
Specifica Tecnica
Apprezzabile la numerosità dei riferimenti informativi, che devono però essere rivolti verso risorse più precise e dettagliate, soprattutto per quanto riguarda i libri. Delle tecnologie utilizzate, vanno discussi anche gli eventuali svantaggi derivanti dal loro utilizzo. REST è uno stile architetturale, non un’architettura. Attenzione: SOAP non implementa REST, sono anzi due approcci antitetici. §2.3.1: Android SDK non è un framework, è un SDK. Pag.
5: “ideato per realizzare facilmente applicazione distribuite”. §2.4.1: non è chiaro cosa utilizziate dell’infrastruttura AWS. Pag. 9: “frameworktextbfG”.
Android Studio non è un framework, ma un IDE. Nel documento, la parola framework è abusata e usata spesso a sproposito. Correggere. Pag. 10: “E’
possibile vedere un confronto tra queste tecnologie e quella Eddystone nella Figura 4.1”, ma la figura nel documento non è presente. Fig. 2: migliorare la visualizzazione dei singoli servizi offerti, ora non chiara nel diagramma. §4.1:
non descrive ciò che il suo titolo promette. Encomiabile lo sforzo di fornire un unico diagramma delle classi che rappresenti tutta la componente client, ma il risultato è illeggibile. Suggerisco ulteriore semplificazione e successivamente l’introduzione di singoli diagrammi dettagliati. Bene la descrizione delle relazioni fra le componenti logiche individuate (classi). Fig. 5: non è chiaro il perché i Presenter debbano avere riferimenti alle implementazioni concrete delle viste. Il pattern richiede che esse vengano accedute unicamente attraverso opportuna interfaccia. Rivedere. I diagrammi delle classi riportati sono spesso molto piccoli in dimensioni, anche quando il numero di classi permetterebbe l’inserimento di diagrammi di dimensioni maggiori (fig. 12 ad esempio). Non è chiaro perché spesso si inseriscano due dipendenze, una verso l’interfaccia e una verso la sua implementazione. Nei diagrammi di attività, i branch devono avere un’etichetta (guardia) associata ad ogni cammino uscente, altrimenti non è chiaro quale sia la scelta effettuata. Inoltre andrebbero descritti maggiormente. Fig. 28: eliminare il branch con un solo ramo uscente. Fig. 29: è presente un’azione con più di un flusso entrante.
Dividere il diagramma, troppo complesso. Anche le figg. 30 e 31 soffrono
dello stesso problema (problema più volte sottolineato a lezione). Bene i diagrammi di attività, in generale, ma il loro livello di dettaglio è più consono per un documento di AR che di ST. Per la descrizione dei design pattern si richiede di riportare degli esempi più atomici del loro utilizzo. Fig. 34: non è chiaro l’utilizzo del pattern Abstract Factory. Analogamente per il pattern DAO. La fig. 37 è una rappresentazione troppo informale del pattern MVP.
Il documento in generale ha buona struttura e ottimo livello di dettaglio. Sono presenti alcuni problemi architetturali che vanno risolti, ma nel complesso l’architettura individuata è buona. Manca una visione di come i framework utilizzati si integrino all’interno del prodotto (nei diagrammi). Da aggiungere.
Piano di Progetto v2
Apprezzabile il miglioramento dell’analisi dei rischi, che include la richiesta attualizzazione. Buono il dettaglio del consuntivo di periodo (questa sarebbe la sua denominazione esatta fino al consuntivo finale). La sua presentazione però risulta inutilmente frammentata. Ciò rende più difficile l’analisi delle tendenze, utile alla redazione del preventivo a finire, che – non a caso – manca del tutto. Nel complesso, documento migliorato, ma non ancora pienamente soddisfacente.
Piano di Qualifica v2
Nonostante le correzioni apportate, §2 è ancora frammentario, confuso e insoddisfacente, che non riesce a dare un chiaro conto degli obiettivi di qualità fissati e della loro quantificazione relativa a specifiche metriche. Anche l’appendice A è altrettanto insoddisfacente, perché il suo compito sarebbe fornire evidenza e analisi critica dell’esito delle verifiche effettuate rispetto agli obiettivi di qualità di cui sopra. Nel complesso, documento da rivedere.
Glossario v2 Bene. Servirà però includere l’indice dei contenuti (e quindi delle voci).
