Kaizen Team (C3)
Presentazione: 27 Giudizio complessivo sui documenti: 27 Consegna e considerazioni generali
I verbali ora riportano le decisioni prese, ma non lo fanno ancora in modo tracciabile. Il livello di dettaglio nel registro delle modifiche è insufficiente per localizzare le variazioni apportate all'interno del documento.
Presentazione Buon ritmo di erogazione. Buona qualità nell'esposizione della progettazione.
A tratti un po' verbosi, causando disparità nel tempo di esposizione.
Norme di Progetto v3
Apprezzabile lo sforzo di riorganizzazione dei contenuti secondo le
raccomandazioni ricevute in sede di RR. Buono l'esito. Lo stile di redazione resta purtroppo prevalentemente testuale-narrativo. Buone le appendici.
Interessante l'idea di riportare in appendice le liste di controllo: è auspicabile che esse siano trattate a contenuto crescente, con la progressiva crescita dell'esperienza.
Analisi dei Requisiti v3 Ottimo.
Specifica Tecnica
Nei riferimenti informativi andranno inserite le fonti che avete consultato per studiare le tecnologie presentate nel documento. Solitamente, quando si presenta una tecnologia, oltre ai pro se ne riportano anche i contro, per una più completa giustificazione della scelta. Figg. 1 e successive: la ricezione di un segnale è un’azione di tipo iniziale. Pertanto non è necessario l’utilizzo di un’altra azione di questo tipo. Inoltre, deve essere specificata con
un’opportuna guardia il tempo di attesa. Infine, le guardie devono essere riportate fra parentesi quadre(“[]”). Figg. 2, 5, 6: non è possibile interagire con un branch fra due processi ottenuti mediante fork. §5.2.1: si parla di componente Android, ma la sezione è dedicata alla componente Chuck. La descrizione fornita per la componente Check in §5.2. è disorganizzata e soprattutto non è coadiuvata dall’utilizzo di diagrammi che ne semplifichino l’esposizione. §5.3 soffre dei medesimi problemi. Inoltre, non è chiaro come il pattern MVC venga implementato utilizzando le strutture richieste per un’applicazione Android. §5.4 non presenta invece l’architettura generale del prodotto, ma si limita a presentare un mock up. §6.2.1.2: la descrizione del pattern è troppo generica. Lo scopo riportato può essere attribuito a ogni pattern. È difficile poter presentare in modo efficace un pattern utilizzato nella propria architettura, prima che questa venga esposta nel documento.
Inoltre, la contestualizzazione dei pattern richiede sempre almeno un diagramma delle delle classi associato. È necessario descrivere maggiormente le relazioni fra le componenti logiche individuate, eventualmente con opportuni paragrafi. Fig, 14: rivedere l’utilizzo della primitiva di classe interna nel diagramma, usato probabilmente in modo non corretto. Pag. 37: in pagina è presente del testo che eccede i margini della pagina stessa. Il processo di validazione del documento deve essere migliorato. §6.2.2.5: è concettualmente errato chiamare un tipo con il suffisso “Object”. Pag. 38:
“Dopo che sono stati descritte nel dettaglio tutte le varie classi”. Fig, 16: è presente un tipo astratto, ChartBridge” senza alcuna implementazione concreta. Fig. 18: non è chiaro quale sia il reale vantaggio di avere un oggetto factory per ogni tipologia di Controller. Fig. 19: esiste una reale esigenza per duplicare un intera componente dell’applicazione fra più sotto-prodotti (Norris e Chuck)? Argomentare. Fig. 23: non è possibile utilizzare direttive UML per fornire indicazioni sui pattern utilizzati (<<observer>>). Fig. 26:
riportare comunque le relazioni esistenti tra le classi presenti nel diagramma (ad esempio l’ereditarietà fra le classi). Bene il tracciamento.
Il documento presenta un’esposizione dell’architettura particolare, che non suddivide il discorso per componenti, ma per livelli di astrazione. In questo modo però, si perde il filo logico, dovuto anche alla contestualizzazione dei pattern non incisiva e una descrizione delle interazioni fra le componenti troppo astratta. Manca la descrizione dell’architettura dell’applicazione di prova, Dashboard APS. Nel complesso, documento da rivedere.
Piano di Progetto v3 La fase è uno strumento di pianificazione temporale. Un modello di sviluppo è una strategia. Il modello incrementale non implica fasi, come invece asserite
in §2, ma la pianificazione le può imporre. Bene l'attualizzazione dei rischi in
§4, ma carente l'evidenza di correlazione tra le strategie di mitigazione adottate e la pianificazione presentata in §5. Il costo totale di progetto a preventivo riportato in §6.2.3 differisce, senza giustificazione apparente, da quello presentato in ingresso alla RR. Curioso (un po' alla Windows) che il preventivo a finire (§7.2.3) sia nascosto nel consuntivo (§7). I contenuti di tale preventivo a finire sono insoddisfacenti, perché si limitano a posticipare indistintamente al futuro il problema di ripianificazione riscontrato.
Nel complesso, il documento ha un buon impianto e discreti contenuti, con alcune piccole lacune residue.
Piano di Qualifica v3
Vi è evidente correlazione tra i contenuti attesi di §2 e quelli di §3.7, che ne sono il substrato di quantificazione. Tale correlazione è però mancante nella versione attuale del documento. In un'ottica di miglioramento continuo, i contenuti attesi di §4 (arricchiti con quelli delle appendici E, F) riportano la valutazione della distanza tra l'atteso e il misurato, e identificato le opportune strategie correttive. Anche questa parte di contenuti è attualmente assente. La descrizione del ciclo PDCA riportata in appendice C è errata e va corretta. I contenuti di §5 riguardano la “specifica dei test”, la quale è meglio presentata in forma tabulare. Tale specifica andrà a suo tempo accompagnata dall'esito corrispondente.
Il documento è stato ampiamente rivisto e ha guadagnato in qualità ed efficacia rispetto al rilascio precedente. Resta comunque ancora una distanza non piccola da colmare per raggiungere un livello pienamente soddisfacente.
Glossario Attuate le modifiche migliorative richieste in sede di RR.
