MashUp (C1)
Presentazione: 25 Giudizio complessivo sui documenti: 27
Consegna e considerazioni generali
La lettera di presentazione è ora buona per l'ingresso in RR, ma non ancora corretta per il contesto della RP. In particolare, il prezzo del prodotto non può variare rispetto a quanto approvato in sede di RR, se non a beneficio del committente. Nessun nuovo verbale. Il livello di dettaglio nel registro delle modifiche è insufficiente per localizzare le variazioni apportate all'interno del documento. Tale registro è tipicamente ordinato per numero di versione, non per tipo di modifica.
Presentazione Presentazione discreta per impianto e stile di erogazione. Qualche ingenuità nella strategia di integrazione.
Norme di Progetto
Il documento si giova del buon impianto già adottato in ingresso alla RR. Lo stile dei contenuti resta ancora prevalentemente narrativo-testuale, anche se qualche correzione è stata effettuata. Interessante l'idea di riportare in appendice A le liste di controllo: è auspicabile che esse siano trattate a contenuto crescente, con la progressiva crescita dell'esperienza.
Analisi dei Requisiti v2
Figg. 20, 23, 24, 25, 26, 29, 30, 31, 32, : esistono più azioni che hanno più di un flusso entrante. Correggere. RDV1 e RDV1.3 sono lo stesso requisito.
La parte dei casi d’uso del documento ha ora una buona struttura. I diagrammi di attività sono da rivedere, poiché ancora presentano numerosi errori.
Nel complesso, buono.
Specifica Tecnica
Bene i riferimenti informativi. Pag. 3: “soluzione implementativi”. Pag. 3:
esistono degli algoritmi di offuscamento del codice Js che possono sopperire allo svantaggio individuato. Pag. 5: “responsive” è un termine da inserire nel glossario. Three-tier non è un design pattern, ma un tipo (o stile) di
architettura. Pag. 9: MVW non è un design pattern, ma uno slogan. Angular implementa MVVM e MVC. “Il diagramma seguente illustra l’interazione delle varie parti.”: non è presente alcun diagramma. L’architettura three-tier solitamente è vista all’interno di un medesimo modulo di un prodotto. §3.2.4:
descrivere maggiormente la soluzione adottata. Fig. 2: il ViewModel è condiviso fra View e Contoller e non è prerogativa del Controller. Bene la struttura utilizzata per descrivere le componenti logiche, ma deve essere posta maggior attenzione sulle relazioni che queste individuano tra di loro. Fig. 5:
solitamente le convenzioni di programmazione richiederebbero che i nomi dei metodi siano scritti in con la prima lettera minuscola. Pag. 18: “p la classe che racchiude”. Riportare possibilmente anche i tipi degli oggetti $scope, o per lo meno individuare quali oggetti siano definiti all’interno dei Controller. In generale rivedere l’utilizzo nel back end dell’associazione di composizione e verificare che sia realmente necessaria in tutte le parti individuate. Fig. 21:
RequestHandler.get_Istance → get_instance, inoltre deve essere definito come statico. Bene l’utilizzo del pattern Front Controller, ma è stato verificato se esistessero dei framework che potevano fornire la medesima funzionalità? Nel back end, non è chiaro cosa rappresenti il tipo Dictionary utilizzato nelle classi Command. Descrivere il motivo per il quale è stato necessario individuare una serie di tipi “lista” nei modelli delle risposte per i servizi REST. Sez. 4.3: “Questo significache non c++G’è un diagramma di come”. Non è chiaro il motivo per il quale non si sia voluto creare uno strato che astraesse l’utilizzo del db Google. Argomentare. Par. 5.1.1.: solitamente gli URL che rappresentano le risorse sono plurali (come riportato in tabella nella stessa pagina). Gli URL individuati da voi sono invece al singolare.
Argomentare. Rivedere i primi design pattern come già segnalato inizialmente. Bene la descrizione dei pattern, ma dovrebbe essere sempre coadiuvata da un diagramma delle classi, non solo per alcuni di essi. Fig. 46:
il metodo formattaDati dovrebbe essere protetto e astratto nella classe ChartCreator.
Il documento ha un’ottima profondità di analisi e l’architettura individuata appare solida e ragionata. È necessario descrivere in che modo i framework e le librerie individuate si integrano nell’architettura del prodotto, fornendo esempi e riportando nei diagrammi delle classi i tipi di contatto. Non è stato
utilizzato alcun diagramma di sequenza o attività. Il documento in generale dovrebbe porre maggiore attenzione sull’interazione fra le componenti.
Piano di Progetto v3
Manca correlazione tra l'analisi dei rischi (§2) e la pianificazione (§3), mentre dovrebbe essere che le strategie di mitigazione dei rischi di maggior impatto siano a poste a monte della pianificazione adottata. Il “consuntivo interno al team” (§6) non è contenuto atteso e rilevante per il corpo del PdP; può invece essere collocato in appendice, con premessa che ne spieghi la funzione. I contenuti di §7 sono da intendere come “consuntivo di periodo”. Curioso (un po' alla Windows) che il preventivo a finire (§7.1.2) sia nascosto nel
consuntivo (§7). I contenuti di tale preventivo a finire sono insoddisfacenti, perché si limitano a posticipare indistintamente al futuro le opportunità e le esigenze di ripianificazione riscontrati.
Nel complesso, il documento ha impianto e contenuti discreti, con però ancora le lacune residue sopra rilevate.
Piano di Qualifica v3
I contenuti di §3, attualmente molto modesti, possono essere arricchiti con una organizzazione più esplicitamente orientata al miglioramento continuo, correlata con gli attuali contenuti delle appendici C, D. La presentazione del ciclo PDCA in §A.3 è errata e va corretta. Quanto chiamate “pianificazione dei test” in appendice B è invece una specifica, la quale è meglio presentata integralmente in forma tabulare. Tale specifica andrà a suo tempo
accompagnata dall'esito corrispondente.
Nel complesso, il documento ha subito apprezzabili modifiche migliorative nella direzione delle rilievi mossi in sede di RR, ma non è ancora
soddisfacente.
Glossario v3 Niente da segnalare.
