Glasgow Dev (C3)
Presentazione: 23 Giudizio complessivo sui documenti: 22 (penalità: 1 punto)
Consegna e considerazioni generali
Consegna con errori, corretti tardivamente, oltre i termini di scadenza (penalità). Lettera di Presentazione: persiste l’errore nella denominazione dell’affiliazione del committente, già segnalato in sede di RR. Verbali: la consegna non include alcun verbale; sarebbe preoccupante se ciò riflettesse il mancato svolgimento di incontri decisionali sia interni che con il proponente;
altrettanto grave l’omissione di redazione o di inclusione nel materiale di consegna. Registro delle modifiche: migliorato nella direzione delle richieste, ma la specifica di localizzazione non è ancora abbastanza efficace.
Riferimenti: bene. Verifica di qualità: persistono numerosi errori tipografici nei contenuti, e qualche imperfezione stilistica, segno di verifica ancora non abbastanza attenta e quindi in violazione dei vostri stessi obiettivi di qualità.
Presentazione Erogazione incerta ed esitante. Poca visione d’insieme sul prodotto atteso, pur se con molte evidenti correlazioni nel contenuto tecnico proposto.
Norme di Progetto v2
Bene per struttura (a meno dell’iniziale minuscola nel titolo di §2). Restano poveri i contenuti, che trattano di molti argomenti (in ampiezza) ma in modo superficiale (e quindi non in sufficiente ampiezza). Questo difetto è
particolarmente marcato per le attività tecniche a maggior valore aggiunto come la progettazione, che è di massima centralità nel periodo tra RP e RQ.
Essa sembra invece limitarsi alla produzione di documenti, il che non può essere, perché la documentazione è prodotto di un processo di supporto, cioè di attività accessorie e complementari, ma non primarie. Il prodotto della progettazione è l’architettura del sistema, che deve perseguire e garantire determinate qualità. Nel complesso, documento da rivedere.
Analisi dei Requisiti v2
Non avete esteso §2, come invece richiesto in sede di RR. UC1.2: siete sicuri di voler implementare una ricerca che non restituisce valori come un errore?
Non descrivendo i “campi del questionario”, UC1.4.2 e UC1.4.2.1 non hanno alcuna differenza tra loro. RQ01: quali sono i manuali necessari? Troppo generico. RV01: suddividere in più sotto-requisiti. §4.2.5: questa informazione dovrebbe trovare collocazione nel PdQ.
Corretta la maggior parte degli errori individuati in sede di RR: bene.
Specifica Tecnica
Da un punto di vista funzionale, l’uso del documento di ST è strettamente interno al fornitore: esso viene reso disponibile al committente per ragioni contrattuali, ma non ad altro pubblico. §2.1.3: quale versione di JavaScript utilizzate? Questa informazione non si può omettere. E quale versione di AngularJs? Fig. 1: “Vendor” non può essere definito un package, perché al suo interno si trovano le librerie esterne all’applicazione. Non avete fornito una descrizione sufficientemente dettagliata dell’architettura generale. Come si integrano le varie librerie utilizzate? Le relazioni delle componenti fra loro devono essere descritte fornendo una giustificazione funzionale a ognuna di esse. Fig. 7: perché vi sono componenti che non hanno dipendenze nè entranti nè uscenti? Fig. 8: le classi di modello non dovrebbero avere al proprio interno dipendenze verso le classi di tipo Service. La dipendenza dovrebbe essere esattamente opposta. Rivedere. Verificate la dipendenza fra i tipi View e i tipi Controller: in un MVC dovrebbe essere definita esattamente nel verso opposto. Come viene implementato in questo caso l’MVVM di Angular? Nei diagrammi delle classi è opportuno inserire il nome dei package cui afferiscono le varie componenti, anziché fornire dei riquadri senza nome. Nei diagrammi di attività molte (quasi tutte) guardie nei branch, non indicano l’espressione di guardia: correggere. Fig. 75: è presente un’azione con due flussi entranti. Fig. 79: molte azioni costituiscono delle strade senza uscita, ossia senza alcun cammino verso un’azione di terminazione. Questo è un problema comune a molti altri diagrammi di attività. In generale, il dettaglio raggiunto dai diagrammi di attività è propri di un documento AR, ma insufficiente per ST. I design pattern devono essere contestualizzati utilizzando opportuni diagrammi delle classi che li visualizzino all’interno
dell’architettura. Il pattern Three-Tier non viene realizzato dal front-end.
Il documento è discreto per struttura. Manca però una descrizione approfondita dell’architettura ad alto livello. Come si integrano esattamente le varie librerie utilizzate? Correggere i diagrammi di attività. Contestualizzare i pattern. Da rivedere.
Piano di Progetto v2
§1.5: quello che chiamate “ciclo di sviluppo” è invece “modello di sviluppo”.
§2: apprezzabile la trasformazione in stile di presentazione tabellare.
Altrettanto apprezzabile l’integrazione dell’analisi dei rischi con la sua attualizzazione, la quale però ha bisogno anche di valutare l’effetto delle misure di mitigazione adottate, per la loro manutenzione migliorativa.
§3: alla piena adesione al modello di sviluppo incrementale non basta prevedere occasionali incrementi, soprattutto ove essi siano limitati a prodotti documentali. Più in generale, la vostra pianificazione pare essere
esclusivamente incentrata sulla produzione di documenti, dimenticando la vera natura del prodotto atteso dal progetto.
§5: permangono, e si aggravano, i rilievi mossi sui contenuti di §6 di questo documento nella versione presentata in sede di RR.
Il documento resta insufficiente.
Piano di Qualifica v2
Documento accettabile (pur se non pienamente soddisfacente) per struttura.
Da migliorare gli obiettivi di qualità individuati in §2, che sono pochi per quantità, troppo generici e superficiali per contenuto, e di scarsa utilità per la ricerca del miglioramento. Questo difetto ha impatto negativo sul valore informativo di §C. Bene invece §B.
Suggerimento: la presentazione dei riscontri ottenuti nelle attività di verifica che ripetano identiche misurazioni in diverse occasioni si presta naturalmente allo stile di serie storiche (valori in ordinata, e momenti di misurazione in ordinata), così da evidenziare tendenze.
Il documento resta insoddisfacente.
Glossario v2 Il documento non va numerato, perché la sua organizzazione per voci alfabetiche lo rende direttamente indicizzabile.
