SWEvoq (C4)
Presentazione: 23 Giudizio complessivo sui documenti: 26
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: la riduzione del prezzo presentato al committente, pur se ammissibile, è rischiosa per il fornitore, che in quel modo sta rinunciando a margini di riserva, trasferendoli in beneficio al committente, senza poter poi fare marcia indietro. Registro delle modifiche: bene. Verbali: bene per struttura e contenuti. Le decisioni, ora chiaramente riconoscibili, andrebbero rese anche più facilmente tracciabili. La cartella che contiene i verbali (esterni o interni) non dovrà avere una data riferibile a un suo particolare contenuto.
Presentazione Buon impianto grafico. Buona fluidità di erogazione, ma insufficiente controllo dei tempi. Discreto dettaglio tecnico, ma con alcuni errori di metodo e di concetto. Carenti la visione d’insieme e la prospettiva d’uso.
Norme di Progetto v2 Bene.
Analisi dei Requisiti v2
§2 non è stata estesa come richiesto in sede di RR. UC1: contiene tantissimi errori. Con le inclusioni si cercano di modellare precondizioni, con le estensioni dei sotto-casi. Gli stessi errori si ripetono anche in altri casi d’uso.
Rivedere. Come già segnalato in RR, tutti i casi d’uso devono riportare uno scenario principale. Non sono riportate le condizioni di estensione e degli scenari alternativi, ne nei diagrammi ne nelle descrizioni dei casi d’uso.
Il documento ha migliore grado di maturità rispetto alla versione precedente, ma sussistono ancora troppi errori nei diagrammi dei casi d’uso. Da rivedere.
Specifica Tecnica
§2.7.2.3: attenzione ai copia-incolla. Tutte le relazioni fra componenti devono essere descritte anche dal punto di vista funzionale. Se possibile, evidenziare in colore differente le librerie esterne all’applicazione all’interno dei diagrammi delle classi. Nei diagrammi delle classi, se sono presenti tipi astratti, è necessario indicarlo con chiarezza (ad esempio, fig. 16). Mettere maggior enfasi sulla struttura del pattern MVP: attualmente non è possibile discernere se il suo uso sia corretto. Rivedere i pattern Singleton e Facade applicati, perché non sono conformi a quanto previsto dallo standard. Siete sicuri di voler utilizzare il pattern Singleton? Come pensate di sviluppare gli unit test che lo coinvolgono? Bene i diagrammi di attività, ma il loro livello di dettaglio è più consono a un documento AR che ST. Bene il tracciamento.
Il documento raggiunge un livello di dettaglio discreto. Focalizzarsi maggiormente sulla visione generale iniziale dell’architettura. Valutare un software di dependency injection. Per il resto, bene.
Piano di Progetto v2
§2, §3: i contenuti di queste sezioni sono fortemente connessi tra loro e possono quindi essere agevolmente e opportunamente integrati.
§7: quello che chiamate “consuntivo” è invece da considerare “consuntivo di periodo”, fino alla chiusura del progetto, in ingresso alla RA. L’analisi di tali dati permette di valutare la bontà della pianificazione o determinare le ragioni di eventuali scostamenti. Tali considerazioni permettono di raffinare il preventivo del periodo rimanente, denominato appunto “preventivo a finire”.
Quanto voi fate in §7.4 non aderisce bene all’intento, perché non contiene una discussione che spieghi le ragioni strategiche delle modifiche e poi, in tabella 28, usa impropriamente il termine “consuntivo” per una colonna che contiene sia costi effettivamente consuntivati che stime (da aggiornare) di preventivo.
Il documento è significativamente migliorato ed è in larga misura soddisfacente. Restano da correggere gli errori concettuali rimasti in §7.
Piano di Qualifica v2
Apprezzabile lo sforzo di riorganizzazione e integrazione del documento, che si è in tal modo avvicinato sensibilmente alle attese. Permangono tuttavia alcune scelte inefficaci, che rendono il documento inconsistente e ridondante.
I contenuti di §2 includono (opportunamente) elementi di strategia, che mettono in questione la presenza di §4, stante che il tema dell’intero PdQ è la definizione di obiettivi di qualità quantificati e verificabili. I contenuti di §3 attengono al Piano di Progetto e sono più opportunamente riferiti invece che
inclusi. Agli obiettivi specificati in §2 dovranno corrispondere gli esiti di verifica risultanti dalle attività a essi dedicate (inclusi ovviamente i test). Tali esiti, che hanno natura incrementale perché crescono con il progredire delle attività di verifica, sono meglio collocati in appendice, per non incidere sul corpo principale del documento. Conviene che essi siano raccolti in una singola appendice e poi suddivisi al suo interno in modo riconducibile agli obiettivi specificati in §2. Tecnicamente, la specifica dei test secondo il modello a V, è parte delle strategie di perseguimento di qualità. Tale specifica è conseguenza di §2, e quindi precede la presentazione degli esiti di verifica.
Una volta recepite le osservazioni di cui sopra, il documento avrà raggiunto uno stadio di sufficiente maturità e piena conformità alle attese.
Glossario v2 Bene. Andrà tuttavia eliminata la numerazione, ridondante perché sottesa dall’ordine alfabetico.
