MILCTDev (C7)
Presentazione: 24 Giudizio complessivo sui documenti: 24
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: impaginazione errata, che presenta una pagina bianca spuria. Il prezzo stipulato in sede di RR non può essere aumentato dal fornitore. Il costo che avete dichiarato è diventato non conforme e dovrete sanarlo prima di chiedere accesso alla RA. Verbali:
bene. Registro delle modifiche: rivedere l’ampiezza, che attualmente fuoriesce dalla pagina. Riferimenti: bene.
Presentazione Discreta per contenuti, ma “mogia” per esposizione. Modesta la demo.
Norme di Progetto v3 Stabile e matura la struttura. Apprezzabili miglioramenti nei contenuti, che però hanno inseguito le attività svolte invece che precederle con opportuna normazione preventiva.
Analisi dei Requisiti v3
UC6.3: la condizione di estensione individuata non è corretta. RVO6: quale distribuzione di Linux deve essere utilizzata? Apprezzabili le migliorie apportate. Per chiudere il documento restano da correggere gli ultimi errori.
PB
Non bene: troppa attenzione al dettaglio; esposizione mancante di un chiaro filo logico, guidato dall’architettura e dalla sua modularizzazione. Nessun accenno ai pattern adottati. L’architettura di prodotto sembra ben pensata, ma è stata esposta malamente nel colloquio.
Manuali
Manuale sviluppatore: Pag. 6: il server di posta deve implementare protocolli di comunicazione e non essere compatibile con librerie di sviluppo. Da dove si reperisce il codice del prodotto? È necessario indicarlo. §4.3: fornire un riferimento alla documento di Spring Mail. §6.1.1: oscura la ragione per cui fornite un esempio di query SQL, visto che l’unico DB che gestite è NoSQL.
§6.2.2: solitamente, per aderire al principio Open-Closed, si preferisce utilizzare meccanismi di Reflection per registrare classi all’interno di una factory. Includere più diagrammi delle classi, per facilitare la comprensione dell’architettura a personale esterno al team di sviluppo. Nel complesso, il documento ha forma corretta, ma contenuti da approfondire e completare.
Manuale utente: Pag. 5: il server di posta deve implementare protocolli di comunicazione e non essere compatibile con librerie di sviluppo. Da dove si reperisce il codice del prodotto? È necessario indicarlo. Per il resto, il documento ha struttura corretta e fornisce le informazioni necessarie.
Piano di Progetto v3
Apprezzabile l’attualizzazione dei rischi in §A, la cui presentazione non usa al meglio la tabella sinottica, preferendo lo stile narrativo, qui inefficace.
Apprezzabili anche le considerazioni poste in §B, che però in realtà sarebbe parte integrante di §6, senza le quali è povera in profondità di analisi degli scostamenti e inconsapevole delle norme contrattuali che proibiscono al fornitore di incrementare il costo del prodotto sancito in sede di RR. Come già segnalato in premessa, tale incremento è inaccettabile e dovrà essere
rettificato prima di richiedere accesso alla RA.
Piano di Qualifica v3
Vi è un disallineamento nel registro delle modifiche. I simboli utilizzati per specificare lo stato di avanzamento di test necessitano di legenda, per ovviare all’ambiguità di notazione tra “implementato” e “superato” (e converso), visto l’uso dello stesso simbolo in §2.3 e §B. È da notare che l’esito dei test dovrebbe essere riportato nel resoconto delle attività di verifica (§A) di cui i test sono parte integrante. Per il resto, molto bene.
Glossario v3 Bene.
