Zephyrus (C3)
Presentazione: 29 Giudizio complessivo sui documenti: 28
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: manca indicazione della data di consegna prevista. Verbali: bene. Registro delle modifiche: la localizzazione delle modifiche effettuate aumenterà specificandola in modo numerico e non narrativo; occorrerà anche migliorarne la tracciabilità rispetto alle decisioni o esigenze di modifica. Riferimenti: quando l’oggetto riferito è una collezione (web o libro), occorre precisare le parti di interesse specifico.
Presentazione Difficoltà tecniche affrontate con scarsa reattività. Ottima visione d’insieme, con apprezzabile comprensione della prospettiva d’uso. Molto buoni l’impianto grafico, la fluidità di erogazione e la qualità dei contenuti.
Norme di Progetto v2
Ottimo per struttura e per ampiezza di contenuti. Migliorabile per profondità, specialmente per le attività tecniche di maggior impatto e significatività di periodo (segnatamente la progettazione).
Analisi dei Requisiti v2 Documento ulteriormente migliorato rispetto alla versione presentata in RR.
Molto bene.
Specifica Tecnica
Pag. 11: “OPTION”. Per cosa utilizzate questo verbo nel server RiskApp?
Bene l’individuazione delle librerie esterne nei diagrammi delle classi. Anche le relazioni con le altre classi devono essere opportunamente descritte dal punto di vista funzionale. Molto bene l’alternanza tra mockup e diagrammi di attività, che però devono essere maggiormente descritti. Inoltre, il dettaglio di questi diagrammi è più consono a un documento AR che ST. Nei diagrammi di attività, inserire una guardia per ogni possibile branch. Il tracciamento con i requisiti deve andare verso le componenti logiche, ossia le classi individuate.
Non con i package. Correggere e aumentare il livello di profondità di analisi ove necessario. Molto bene la descrizione dei pattern utilizzati.
Il documento presenta struttura ottima. Il livello di analisi è adeguato. Va rivisto il tracciamento e posta maggiore attenzione alla descrizione delle relazioni fra la componenti logiche.
Piano di Progetto v2
Documento che conferma piena maturità per organizzazione, presentazione e qualità dei contenuti. L’analisi del consuntivo (“di periodo”, questa è la sua denominazione regolamentare fino all’ingresso in RA) non deve solo badare a che i conti si bilancino al più vicino evento di controllo, ma piuttosto imparare dall’esperienza del periodo trascorso e usarla per migliorare il preventivo del periodo rimanente (“a finire”), non tanto e non solo sul piano economico, ma per la ripartizione delle ore tra ruoli e tra membri.
Piano di Qualifica v2
§2: buona per organizzazione e qualità di contenuti.
§3: poco utile e poco efficace; i suoi contenuti sono per lo più di pertinenza del PdP (§3.1-3) e delle Norme (§3.3); i secondi parziali e non esaustivi.
§D: la specifica dei test è partecipa all’attuazione delle strategie di
perseguimento degli obiettivi di qualità specificati in §2. La loro collocazione in appendice rende poco percepibile questo stretto legame.
§E-F: i contenuti di queste appendici sono da intendere come la presentazione dell’esito delle verifiche di raggiungimento degli obiettivi fissati in §2. Poiché la loro estensione si incrementa con l’avanzamento delle attività di progetto, la loro migliore collocazione è in appendice. La separazione tra essi secondo i periodi temporali non è invece efficace, perché il primo e più importante legame è tra gli obiettivi quantitativi di qualità fissati in §2 e il riscontro ottenuto (anche in successivi momenti temporali). Chiaramente, le verifiche attese sono tutte quelle necessarie a coprire tutti gli obiettivi. Un obiettivo dichiarato in §2 non può rimanere scoperto, se non per assenza (si spera temporanea) del suo oggetto di verifica (p.es., il codice in questo momento).
Nel complesso, il documento è molto migliorato, ma non è ancora del tutto soddisfacente per organizzazione e ampiezza di contenuti.
Glossario v2 Bene.
