MashUp (C1)
Presentazione: 30 Giudizio complessivo sui documenti: 28
Consegna e considerazioni generali
La prima pagina del DP e il piè di pagina riportano il numero di versione come 2.0 invece che 1.0. Insufficienti i dettagli forniti per identificare le fonti di taluni riferimenti informativi. Nessun nuovo verbale. Come già segnalato in sede di RP, il registro delle modifiche va ordinato per numero di versione, non per tipo di modifica.
Presentazione Molto bene, anche per la demo.
Norme di Progetto v5 Molto bene.
Sorprendente però la mancata trattazione del processo di validazione.
Analisi dei Requisiti v4 Alcuni diagrammi di attività soffrono ancora del problema rilevato in sede di RP, sintomo di verifica non abbastanza attenta. Si vedano ad esempio i diagrammi in fig. 19 e 25.
Specifica Tecnica v2
§3.2.1 e §6.1.1: come già rilevato in sede di RP, MVW non è un pattern. Il documento ha in parte integrato la contestualizzazione dei design pattern come richiesto in sede di RP. La descrizione delle dipendenze fra le classi potrebbe essere migliorata ulteriormente, scendendo maggiormente nel dettaglio. Nel complesso comunque, il documento è buono.
Definizione di Prodotto
Pag. 4: che significato ha una classe senza attributi o metodi? §3.2.3: non è chiaro il concetto che cercate di esprimere. Per quanto riguarda le classi individuate per le componenti di dettaglio, esse dovrebbero essere il più vicine possibile a quanto implementato concretamente. Se alcuni tipi non trovano implementazione nel linguaggio in uso, non è necessario inserirli, previa opportuna descrizione della motivazione. Pag. 16: la password è inviata in chiaro? Pag. 20: “getAccessToken”, descrivere in che modo viene generato il token. Molto buona la descrizione delle viste. §3.2.9: delle
“configurazioni” (le classi Route) non possono avere comportamento, quindi non possono utilizzare i Controller per portare a termine il proprio compito.
Rivedere la descrizione. Pag. 85: “il modello dati grezzi relativi”.
RequestHandler: riportare anche neld diagramma di dettaglio le componenti statiche. CommandDispatcher: descrivere in che modo venga valorizzato il dizionare che associa le richieste ai relativi comandi. Fornire una valida giustificazione per i metodi statici delle componenti del package
server::miner. Pag. 172: “Questo significa che non c++’è un diagramma”
(errore segnalato anche nel documento di ST in sede di RP). Molto bene i diagrammi di sequenza.
Il documento ha un’ottima profondità di analisi e per la maggior parte delle componenti individuate raggiunge un livello di dettaglio opportuno per il tempo a disposizione. Molto bene.
Manuali
I riferimenti alla documentazione di progetto non possono essere usati in un manuale rivolto a personale esterno.
Manuale amministratore: Bene l’indicazione del workflow per l’apertura di una segnalazione. Buoni i contenuti, ma converrà legare maggiormente le descrizioni delle funzionalità agli screenshot dell’applicazione, utilizzando sottolineature e riquadri direttamente in quest’ultimi.
Manuale utente: Buoni i contenuti, ma – anche in questo caso – converrà legare maggiormente le descrizioni delle funzionalità agli screenshot dell’applicazione, utilizzando sottolineature e riquadri direttamente in quest’ultimi.
Piano di Progetto v5
Il ciclo di vita adottato è una scelta strategica (e non un vincolo) e come tale va collocato all'interno della pianificazione; certamente non prima dell'analisi dei rischi. La presenza di §4 nel corpo del documento è incongrua; discutibile – e fonte di indesiderabile ridondanza – anche la sua inclusione in una sezione a parte. La sua migliore collocazione, semplificata per struttura, è in
appendice. Il titolo di §6 dovrebbe meglio riflettere che il consuntivo di cui si tratta è “corrente” (invece che finale), e ciò spiega la sua correlazione con il preventivo a finire. Come già osservato in sede di RP, la trattazione del
preventivo a finire è erroneamente posta in corrispondenza con il consuntivo di periodo: il compito del preventivo a finire è ragionare sulle risultanze del consuntivo di periodo, facendo scelte strategiche (di investimento o di re- direzione). Il documento è buono, ma non ancora pienamente soddisfacente.
Piano di Qualifica v4
I contenuti attuali di §3 sono più attinenti alle norme che al PdQ. La
descrizione del ciclo PDCA in §A.3 non è ancora soddisfacente. Non è chiaro se l'uso del termine “descrizione” in appendice B sia intenzionale (per segnalare l'informalità dell'informazione rispetto a una specifica) o solo
“pigro”. Molto buone le appendici C-E.
Glossario v3 La data di redazione indicata a pagina 1 non concorda con quanto riportato nel registro delle modifiche. Una migliore automazione delle procedure di popolamento dei relativi campi eviterebbe facilmente questo tipo di errori.
