NOVE (C6)
Presentazione: 18 Giudizio complessivo sui documenti: 22 Consegna e considerazioni generali
Consegna: vista la sua funzione, la lettera di presentazione non può essere nascosta nella cartella dei documenti esterni. Lettera di presentazione: niente da segnalare. Verbali: bene, ma restano pochi quelli esterni. Registro delle modifiche: mal impaginato e scarsamente leggibile.
Presentazione Modesta per intensità di partecipazione, maturità e qualità del contenuto informativo. Demo povera.
Norme di Progetto v3 Qualche miglioria nei contenuti, che però restano modesti per profondità, a fronte di una buona struttura. La denominazione del file contenente questo documento non è conforme.
Analisi dei Requisiti v3 I requisiti sono stati suddivisi come richiesto. Resta non chiara la suddivisione fra i requisiti utente e quelli di sistema.
PB
Colloquio mal preparato o non preparato affatto. Il gruppo non era pronto e completo all’orario pattuito, e l’esposizione è stata frammentaria, senza alcun filo conduttore. Nessun materiale dedicato è stato utilizzato, limitandosi a esporre caoticamente diagrammi recuperati alla rinfusa da un file system remoto. Mentre l’architettura del prodotto è di buona qualità e ben congegnata, il colloquio è stato gravemente insufficiente.
Manuali
La lista di distribuzione di entrambi i manuali dovrebbe includere il proponente. Manuale sviluppatore: §2.1.1.1: se il prodotto presenta vincoli sulle versioni dei browser, essi devono essere esplicitati. MVC è un pattern che non prevede l’utilizzo di nodi differenti e molteplici. Rivedere la parte architetturale. Fornire una didascalia alle figure. Quanto pensate sia utile un diagramma delle classi come quello di pag. 7 in un documento di questo tipo?
§5.2.1.3: probabilmente su Solidity saranno costruiti pattern ad hoc. Avete provato a verificarne l’esistenza? I diagrammi riportati nel documento sono troppo dettagliati e quindi poco leggibili. Non è presente alcun glossario: siete sicuri che non vi siano termini che necessitino di contestualizzazione? Il documento dovrebbe fornire le informazioni necessarie a uno sviluppatore per manutenere e estendere il prodotto. Per permetterlo, occorre descrivere bene le interfacce di comunicazione con l’esterno e fra le componenti, restando a un livello di dettaglio differente rispetto a quello che avete adottato.
Manuale utente: Tra i requisiti minimi di sistema è fondamentale inserire le versioni minime dei broswer supportati. §2.1.2: è sufficiente non indicare il browser fra quelli supportati, se effettivamente non lo è. Come si accede al prodotto? Tramite quale URL? Quando si producono screenshot per un manuale, è bene eliminare la parte di immagine che visualizza informazioni legate all’ambiente d’uso personale. È necessario legare maggiormente le immagini e le descrizioni, ad esempio utilizzando numeri per identificare le sezioni. Non viene indicata alcuna procedura per segnalare malfunzionamenti.
Non viene fornito alcun glossario. Il manuale ha forma corretta, ma non lega la parte visiva con quella testuale. Provate a ispirarvi a un tutorial.
Piano di Progetto v3
Permane l’assenza di attualizzazione dell’analisi dei rischi. Molto interessante la pianificazione in stile SEMAT. Deludente la povertà di riflessione sugli scostamenti rilevati nel consuntivo di periodo, che rendono il preventivo a finire un mero esercizio contabile.
Piano di Qualifica v3 Documento ora accettabile per struttura, ma eccessivamente scarno nel resoconto dell’esito delle verifiche (inclusi i test, dei quali manca la specifica, che invece è parte integrante del PdQ.
Glossario v3 Il PDF manca dei bookmark.
