Co.Code (C2)
Presentazione: 26 Giudizio complessivo sui documenti: 26
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: i costi, ricalcolati, sono ora più accettabili. L’indirizzo del repository corrente del codice avrebbe dovuto essere specificato qui e non nella comunicazione di invio. Verbali:
buoni i verbali interni; la scarsità di quelli esterni continua invece a segnalare insufficiente contatto con il proponente. Registro delle modifiche: bene per dettaglio e organizzazione; resta discutibile il criterio di incremento di numero di versione, che porta a crescita abnorme.
Presentazione Buoni lo stile grafico e il flusso di erogazione. Contenuti poco (per nulla) correlati con la visione complessiva del prodotto realizzato. Ottima la demo.
Norme di Progetto v3
§2.2.5: lo scopo della progettazione non può limitarsi alla redazione di documenti. La documentazione, infatti, è un processo di supporto e non uno primario, proprio per via della sua inferiore centralità rispetto alle attività tecniche. Riflettete sulle differenze con gli obiettivi dichiarati per la codifica.
§3.2: la configurazione non si limita al versionamento.
§3.6: i processi tipicamente designano azioni; la qualità non è un processo, ma un obiettivo.
§4: l’(auto)formazione, cui siete frequentemente ricorsi, è da annoverare tra i processi organizzativi.
Nel complesso, il documento ha subito utili integrazioni e buone correzioni migliorative, esponendo però anche i difetti sopra segnalati.
Analisi dei Requisiti v3 Chi è l’attore principale associato a UC9? Chiarire. Fig. 11 non corrisponde a quanto poi descritto. Per il resto, bene.
Definizione di Prodotto
Pag. 18: “E’ possibili fare operazioni”. Bene la presentazione dell’architettura.
Fig.3: in che modo dal diagramma delle classi si dovrebbe evincere che l’architettura (e non il pattern) utilizzato è a microservizi? Ogni package individua un microservizio? In questo caso, la presenza del package Utility, condiviso tra essi, causa forte accoppiamento. Ottima la profondità di analisi delle componenti di dettaglio. Nei diagrammi di sequenza vengono utilizzati unicamente messaggi asincroni fra le componenti. Intenzionale? Anche le risposte ai messaggi sono modellate come messaggi asincroni. Intendete modellare un sistema a callback o è un errore? Bene i diagrammi di sequenza e il tracciamento. Non tutti i pattern descritti, invece, vengono contestualizzati nell’architettura: provvedere.
Documento completo, quasi pronto per guidare l’implementazione. Per completarlo, servirà contestualizzare i pattern ove segnalato.
Manuali
Manuale utente: bene la descrizione della procedura di segnalazione di problematiche d’uso. Vista la macchinosità e la lunghezza della procedura per il deployment dell’applicazione, valutare l’opportunità di dividere il manuale parte amministrazione/installazione e parte utente. Bene la descrizione delle funzionalità, che però necessita di esposizione più visuale e immediata.
Buona la struttura generale. Completare e migliorare ove segnalato.
Piano di Progetto v3
Effettuate migliorie nella direzione delle segnalazioni ricevute in sede di RP, con esito efficace solo per §2 e §4. Il consuntivo [di periodo] resta deludente, perché si limita a presentare la stretta contabilità economica, senza ragionare sulle presunte cause delle discrepanze e senza proporre miglioramenti correttivi alla pianificazione del periodo rimanente (ciò che è atteso dal preventivo a finire). Su questo fronte, il documento resta deludente.
Piano di Qualifica v3
Bene §C, ma incompleta, in conseguenza delle mancanze di §B, che non riporta lo stato di implementazione dei test e di conseguenza nasconde l’esigenza di riportarne anche lo stato di superamento. Vista la significatività di questo aspetto per la RQ, il documento è gravemente insufficiente.
Glossario v3 Bene.
