NetBreak (C1)
Presentazione: 25 Giudizio complessivo sui documenti: 24.5 (penalità 0,5)
Consegna e considerazioni generali
Consegna: la prima consegna è avvenuta tramite invio di allegato, in violazione delle regole. Mancava inoltre una cartella radice, riferita alla revisione di progresso corrente, a contenere tutto il materiale di consegna.
Lettera di Presentazione: manca un impegno preciso sulla data di consegna prevista. Verbali: i verbali devono essere raccolti in apposite cartelle dedicate.
Il corpo di tali verbali deve includere una dichiarazione chiara di agenda, la lista dei presenti e dei ruoli assunti nell’incontro, e un resoconto tracciabile delle decisioni prese. Mancano verbali di riunioni esterne (che pure si sono svolte con il proponente e possono avere avuto impatto sul progetto).
Registro delle modifiche: per facilità di consultazione, il registro delle modifiche va ordinato per versione (quindi chiave di prima colonna), dalla più recente alla più lontana. Le modifiche registrate dovrebbero essere più precisamente localizzabili. Riferimenti: bene. Controllo tipografico: fate maggiore attenzione alla correttezza tipografica. Terminologia: attenzione alla distinzione tra proponente e committente. Convenzioni: considerate la possibilità di segnalare i termini del glossario solo alla loro prima occorrenza.
Presentazione Buon impianto per fluidità di erogazione, ma formato grafico da migliorare.
Insufficiente per dettaglio tecnico e visione di sistema. Diagrammi illeggibili.
Studio di Fattibilità Bene.
Norme di Progetto
Buona la struttura, ma contenuti insufficienti, sia per ampiezza che per profondità. I processi di supporto istanziati omettono erroneamente la
validazione, che è distinta dalla verifica ed è anche esplicitamente richiesta dal progetto. Improprio l’uso del termine “fase” per riferirsi a insiemi di attività con una specifica finalità, senza che esse designino necessariamente un segmento temporale contiguo occupato solo da tali attività.
Nel complesso, documento non ancora soddisfacente: da rivedere.
Analisi dei Requisiti
§2.4: fornire indicazione esatta dei browser supportati, in modo da non incappare in problematiche successive durante le fasi di test del prodotto.
§2.5: “è consigliato” non è verbo utilizzabile nella descrizione di “vincoli”.
Modificare le pre-condizioni in modo tale che descrivano maggiormente lo stato del sistema (meno focalizzato sull’utente). Inserire in modo più espliciti le condizioni che determinano il verificarsi degli scenari alternativi
(estensioni). UC4 e sotto-casi d’uso hanno una relazioni sbagliata fra loro. È infatti necessario utilizzare una relazione di ereditarietà, in quanto i casi 4.x sono specializzazioni di UC4. UC5 è disponibile anche per gli utenti registrati tramite social network? UC5.4 nel diagramma di UC5 non è connesso ad alcun attore. UC6: non è necessario inserire tutti gli attori derivati nel diagramma. UC6.3: quali dati vengono visualizzati? UC9 non è può essere sotto-caso di UC7, che è un caso d’uso di “visualizzazione”. Correggere. I sotto-casi di UC9 sono troppi eterogenei e non tutti sono direttamente collegati con l’operazione di “Acquisto”. Rivedere questo caso d’uso. UC9.3:
le tre tipologie di licenza sono da modellare come cadi ereditati. UC14.1.1 è ad un differente livello di astrazione rispetto a UC14.1. UC14.2.1 soffre del medesimo problema. Non è chiaro se i requisiti riportati in §4.1 siano unicamente di funzionalità o meno. Spostare la descrizione del codice dei requisiti direttamente come descrizione in §4. Nei requisiti di qualità non vengono riportati requisiti di processo. Nulla viene detto su eventuali manuali.
RVO6 è requisito di qualità. Rivedere i requisiti di vincoli, alcuni troppo generici, altri in realtà di qualità. RPD1 e RPD2 non sono requisiti, perché non si riferiscono a quantità misurabili. Bene il tracciamento.
Documento di buona fattura, da rivedere correggendo gli errori segnalati nei diagrammi dei casi d’uso e sistemando i requisiti non funzionali.
Piano di Progetto §3: buona l’analisi dei rischi, ma la presentazione narrativa e a lista ne diminuisce l’efficacia. Da preferire la struttura tabellare, che è di più
immediata consultazione e anche induce alla sintesi. Manca inoltre una analisi di occorrenza (e mitigazione) attualizzata al periodo di rendicontazione.
§5: la pianificazione presentata descrive una logica di sviluppo
sostanzialmente sequenziale (invece che incrementale, come dichiarato in §4), e focalizzata sulla produzione di documenti più che su quella del sistema richiesto dal capitolato.
§6: la presentazione dei dati di previsione di impegno deve scorporare esplicitamente la quota di investimento: la modalità da voi scelta lo fa in modo ritardato e quindi non tempestivo e poco efficace. Errato attribuire all’investimento l’intera attività di analisi, stante che una parte di essa si colloca dopo lo svolgimento della RR.
§8: al documento mancano il consuntivo di periodo (che deve permettere di correlare la realtà contabile alle corrispondenti previsioni) e la discussione di come gli eventuali scostamenti impattino sul preventivo a finire.
Nel complesso, documento con buon potenziale, ma da rivedere.
Piano di Qualifica Documento insoddisfacente per interpretazione di struttura (ereditata acriticamente) e profondità di contenuti. Ciò causa ridondanze di contenuto e scarsa coesione nel trattamento degli argomenti. Da rivedere in profondità.
Glossario Il documento va indicizzato alfabeticamente (come un dizionario) e non tramite sezioni numerate. Bene il resto.
