NPE Developers (C5)
Presentazione: 24 Giudizio complessivo sui documenti: 22
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: nonostante la segnalazione in sede di RR, continua manca un impegno preciso sulla data di consegna prevista. Verbali: nonostante la raccomandazione in sede di RR, i verbali non sono stati raccolti in cartelle separate (esterni e interni). Non è stato ancora adottata e seguita in modo consistente una soluzione atta a tracciare le decisioni. Registro delle modifiche: nonostante la segnalazione in sede di RR, il registro delle modifiche non è ancora organizzato in modo soddisfacente. Sempre a scopo di tracciamento, sarà anche opportuno associare le modifiche alle loro motivazioni.
Presentazione Buon impianto grafico. Buona fluidità di erogazione. Buona descrizione architetturale, erogata però senza visione di sistema nella prospettiva dell’utente e insufficiente dettaglio sulle scelte tecnologiche.
Norme di Progetto v2 Documento buono in partenza per struttura, migliorato per ampiezza di contenuti, ma ancora insufficiente per profondità, specialmente in relazione alle attività di primario interesse per la RP. Da rivedere.
Analisi dei Requisiti v2
Nonostante le segnalazioni ricevute in sede di RR, la sezione relativa alle funzionalità del prodotto non è stata estesa come richiesto. La inclusioni individuate nei casi d’uso vanno riviste: non tutte infatti possono avvenire incondizionatamente. Il documento è migliorato significativamente, sia per struttura, che per profondità di analisi.
Definizione di Prodotto
Pag. 3: “Suddivizione più più logica”. Pag. 3: è presente un punto nell’elenco che non presenta alcuna descrizione. Qual è il vantaggio di avere primitive così grandi all’interno dei diagrammi delle classi (p.es., BaseBubble in fig. 2).
Rivedere graficamente i diagrammi presentati, ora troppo ariosi e vuoti. Non è chiaro perché presentiate singolarmente i package, fornendo pochissime informazioni (quasi nessuna) sul loro contenuto. Un documento DP deve fornire le informazioni necessarie a un programmatore per trasformare in codice l’architettura presentata. Sarebbe stato più opportuno fornire diagrammi che riassumessero l’idea dietro l’archiettura logica. §4: il titolo è
“Specifica Tecnica”, ma state scrivendo un documento DP. Bene l’impostazione data alla presentazione delle componenti fisiche. Figura 163: il diagramma non riporta alcun comportamento dell’unico attore individuato.
Rivedere i diagrammi di sequenza (almeno un sottoinsieme significativo di esse), che devono evidenziare sempre come le componenti di dettaglio interagiscono tra loro. La contestualizzazione dei design pattern deve avvenire attraverso l’utilizzo di opportuni diagrammi delle classi, che riportano le componenti della propria architettura coinvolte nella realizzazione del pattern stesso. Perché avete scelto un approccio ibrido per l’utilizzo della dependency injection?
Il documento ha una prima parte molto (troppo) estesa rispetto al valore informativo che fornisce. Manca invece, ed è mancanza grave, una descrizione chiara dell’architettura del prodotto e delle tecnologie in essa utilizzate. Questo difetto impedisce di comprendere come le componenti di dettaglio interagiscano tra loro, mentre è buona del loro descrizione individuale. Bene il tracciamento. I design pattern utilizzati vanno contestualizzati maggiormente.
Piano di Progetto v2
§2: come già segnalato in sede di RR, la scelta del modello di sviluppo non attiene all’analisi dei rischi, ma – a meno che tale scelta non sia essa stessa fonte specifica di rischio – va posta a monte della pianificazione (§3). Buona invece la presentazione in forma tabellare.
§3: incongruo e inappropriato associare verifica e validazione alla stessa linea di azione. Esse sono aggregati attività (e processi veri e propri) distinte e diverse. Inoltre, la validazione è “finale” per definizione; e dunque ridondante designarne una istanza con tale aggettivo. Permane irrisolta l’incongruenza tra
la dichiarazione di adozione di modello di sviluppo incrementale e la pianificazione presentata, la cui logica appare sostanzialmente sequenziale.
§5: il costo di progetto che presentate in §5.6.2 non è arrotondato, e non avrebbe ragione di esserlo, perché l’arrotondamento per eccesso scaricherebbe costi impropri sul committente, mentre quello per difetto comporterebbe rischi indesiderabili per il fornitore.
§6: nell’indicare le ore non rendicontate, che quindi corrispondono
all’investimento, sarà bene specificare le attività (p.es., auto-formazione) alle quali esse sono dedicate, così da permettere di verificarne la congruità.
§7: quello che designate come “consuntivo”, corrisponde – fino all’ingresso in RA – a “consuntivo di periodo”, come già segnalato in sede di RR. Includere tale informazione nel PdP serve a ragionare su come raffinare e correggere il preventivo del periodo rimanente (che si definisce “preventivo a finire”), ciò che voi non fate, limitandovi a riportare gli scostamenti, senza analizzarne le cause e le conseguenze di più lungo periodo.
Nel complesso, il documento ignora – come molta parte del materiale di consegna – una parte cospicua delle raccomandazioni ricevute in sede di RR, pur arrivando ad avere una struttura vicina ma ancora allineata alle attese e contenuti discreti ma ancora ampiamente migliorabili.
Piano di Qualifica v2
Il documento, pur se significativamente riorganizzato rispetto alla sua versione iniziale, non interpreta in modo soddisfacente le indicazioni e i suggerimenti ricevuti, e presenta contenuti discreti – ma insufficienti rispetto allo stato di ingresso in Rpmax – in modo confuso, frammentario, e di difficile consultazione. Nel complesso, dunque, il documento è gravemente
insufficiente.
Glossario v2 Bene.
