anSWEr (C2)
Presentazione: 24 Giudizio complessivo sui documenti: 25
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: niente da segnalare.
Verbali: bene l’intervento a favore della tracciabilità delle decisioni. Non vi sono però verbali esterni recenti, il che segnala insufficiente contatto con il proponente, nonostante il vostro approssimarsi al collaudo. Registro delle modifiche: bene. Riferimenti: bene.
Presentazione Erogazione con incertezze ed esitazioni. Ottima demo.
Norme di Progetto v3
Qualche passo avanti, ma ancora diverse carenze e ingenuità. L’avvicinarsi del collaudo dovrebbe suggerirvi che le attività di sua preparazione attengano al processo di fornitura (§2), insieme a quelle di validazione, che
correttamente collocate tra i processi di supporto. I contenuti tecnici di §2 sono quasi esclusivamente sintattici, e quindi non aiutano nel perseguimento di obiettivi di qualità non sintattiche (p.es., architetturali, per la
progettazione). La menzione “processo di” ridonda nella denominazione di
§3.3. Le norme relative alla redazione dei verbali (§3.1.1.3.4.3) non includono la tracciabilità delle decisioni, che pure avete attuato. I contenuti di §4 sono discreti, ma la loro organizzazione non è logica. Nel complesso, il documento, pur se apprezzabile per alcuni aspetti, presenta diversi importanti difetti.
Analisi dei Requisiti v3 §2.2 non è stata estesa, nonostante le reiterate sollecitazioni in sede di RR e di RP: persistendo l’omissione, persiste la richiesta. Bene i requisiti di qualità, che però sono limitati alla redazione dei manuali. Buone le altre correzioni.
Definizione di Prodotto v2
§1.5: “I parametri in input delle funzioni lambda non verranno riportati in quanto non modicabili e sempre immutati; i parametri sono i seguenti:
event,context, callback”, non è corretto; tutti e tre i parametri individuano un tipo ben preciso. Come è possibile altrimenti specificare al programmatore cosa implementare a partire da questo documento? Non è chiaro perché, nella specifica del front-end, tutti gli attributi dei tipi siano pubblici. Inoltre, l’oggetto $scope individua un tipo ben preciso, costituito da metodi e attributi associati. Trovate un modo di dividere per tipo questi oggetti. §7: “Diagrammi di attivita”. Fig. 17: esistono azioni che hanno più di un flusso uscente e più di un flusso entrante. Il diagramma forse ha uno scope troppo ampio e andrebbe suddiviso in diagrammi più semplici. I design pattern non sono contestualizzati in alcun modo.
Il documento ha mantenuto più o meno la stessa struttura e la stessa profondità di analisi della versione precedente. L’unico diagramma di attività presentato, ha errori di sintassi. Correggere.
Manuali
I manuali non possono riportare riferimenti a documenti interni del fornitore (p.es., Norme), ai quali i loro destinatari non hanno accesso.
Manuale utente: Il glossario deve essere interno al documento; la sua funzione, rivolta all’utente generico, è del tutto diversa da quella del glossario in uso al fornitore. Pag. 3: Assolutamente da eliminare il riferimento al documento di AR. Pag. 4: “autentificazione” ripetuto più volte. Il termine corretto è “autenticazione”. Fig. 1 e 2 (e altre) devono essere opportunamente descritte. L’approccio deve essere quello di un how-to illustrato, che guidi l’utente nella comprensione della funzionalità offerte dal prodotto.
Il documento è in uno stato embrionale e va integrato opportunamente.
Manuale manutentore: il documento è una versione ridotta del DP, ma questa scelta utilitaristica è inappropriata: se il manutentore fosse un attore interno al fornitore, avrà accesso diretto all’intera documentazione di progetto; se invece fosse un attore esterno, sarà interessato unicamente alle componenti perimetrali, che possono essere estese. Da rivedere.
Piano di Progetto v3
§3: effettuate le modifiche suggerite. §8: effettuate le correzioni alla modalità di contabilizzazione delle ore di lavoro. Resta povera la profondità di analisi di consuntivo sulle possibilità criticità della pianificazione. Nel complesso, il documento è buono nel suo corpo principale, ma povero nel ragionare sul
consuntivo di periodo per raffinare la pianificazione alla luce di esso.
Piano di Qualifica v3
Resta il difetto importante (in parte di presentazione e in parte anche di sostanza) già segnalato in sede di RP: gli obiettivi di qualità espressi in modo quantitativo in §2 e §3 devono essere verificati incrementalmente in corso di progetto e i loro riscontri (per quelli ripetibili più volte) devono essere presentati in modo da far emergere le tendenze.
Glossario v3 Bene.
