CodeToBeWild (C1)
Presentazione: 26 Giudizio complessivo sui documenti: 27
Consegna Puntuale e precisa.
Considerazioni generali
Presentazione apprezzabile, pur se con qualche incertezza.
Il vostro modo di redigere il registro delle modifiche non fornisce sufficiente dettaglio per individuare localmente i cambiamenti apportati ai documenti sottomessi alla revisione: questa è una lacuna fastidiosa che andrà rimediata in ingresso alla RA.
Norme di Progetto v4.0 Ancora qualche miglioramento nella direzione delle richieste, ma senza raggiungere la necessaria copertura di tutte le attività di sviluppo e verifica svolte all'interno del progetto.
Analisi dei Requisiti v3.0 Bene le correzioni apportate.
Specifica Tecnica v2.0
Il documento di ST non descrive le componenti architetturali come entità isolate, ma attraverso le interazioni che queste hanno tra loro. Bene i diagrammi di sequenza, che però dovrebbero essere descritti in maggior dettaglio. Nella spiegazione del pattern MVC è necessario inserire lo schema a tre classi o package in aggiunta alla “descrizione intuitiva”.
Il documento è stato corretto dagli errori evidenziati in RP e risulta ora essere di fattura discreta. L’architettura individuate è abbastanza semplice, ma funzionale al progetto.
Definizione di Prodotto
Pag. 3: indicate quale versione di UML avete deciso di utilizzare (1.x, 2.x).
Siate più precisi nella descrizione delle didascalie (p.es., fig. 3.1). Inoltre, dato che l’ordine di esposizione delle componenti è legato al pattern MVC, introducete brevemente in modo in cui esso è stato da voi realizzato nell’applicazione (basterà anche un diagramma dei package). Pag. 7: non utilizzate semplici lettere per il nome dei parametri (e delle variabili): isate invece sempre dei nomi significativi; questa tecnica, che deve essere parte standard delle norme di codifica, permette una più semplice manutenzione del codice. Pag. 8: la limitazione a 89 slide per il primo livello è
irragionevolmente restrittiva. Ci sono presentazioni a scopo didattico che includono fino a 500 slide. Pag. 10: l’utente deve poter scegliere la grandezza del testo voluta, senza che questo sia limitato a 3 grandezze predefinite: la limitazione che proponente può andar bene solo nel caso dell’utilizzo di temi e template. Pag. 15: “elaborata e reindirizza”. Par. 3.2.1: manca l’associazione fra numeri gestiti dallo switch e le pagine da gestire con questo. Pag. 15:
“metodo ceh”. Per i metodi della classe Modify la descrizione fornita è troppo approssimativa.
Il documento segue un buon schema di esposizione, anche se manca di una introduzione all’architettura globale di prodotto. Il dettaglio dei metodi è discreto, anche se a volte non sufficiente (p.es., classe Modify). Non sono presenti diagrammi di attività o sequenza: inseritene qualche esempio per descrivere l’esecuzione dei metodi più complessi dell’applicazione.
Nel complesso documento sufficiente.
Manuali
Sez. 1.3: specificherete con maggior precisione cosa un utente deve scrivere all’interno di una email di segnalazione, in modo tale da permettere una gestione efficace delle segnalazioni. Da quale indirizzo è accessibile il prodotto? Specificatelo. Non indicate i requisiti minimi del sistema (p.es, quali browser sono supportati): provvedete. Spostate il par. 3.1.4 all'interno di 3.1.3. Fornite un codice di errore per gli errori meno banali, in modo da favorire una loro segnalazione mena ambigua. Il manuale omette la descrizione di uno degli aspetti fondamentali del prodotto, ossia le gestione delle slide sibling e child.
Il manuale descrive tutte le componenti del prodotto in modo puntale. Tuttavia non offre una visione di tipo “tutorial”, che guidi l’utente nella creazione di una slide. Alcune funzionalità non sono ancora descritte.
Piano di Progetto v4.0 Alla ripartizione dei costi economi riportati preventivo aggiungerete: la percentuale di incidenza per ruolo e il corrispondente in ore. Lo stesso
accorgimento adotterete nella trattazione del consuntivo, il quale dovrà essere anche arricchito con la presentazione dello stato complessivo (e non soltanto visto per intervalli) e la discussione delle criticità che eventualmente ne derivano.
Nel complesso il documento continua a mancare di visione complessiva, per fatti, dati e strategie, pur presentando una buona informazione di dettaglio.
Piano di Qualifica v4.0
Apprezzabile il contenuto delle sezioni 3.1 e 3.2, che però non chiarisce l'attribuzione della responsabilità decisionale che consegue dai flussi che specificate. Gli impegni che prendete in sezione 4.5.1 sembrano superiori alle risorse disponibili: tra le tecniche opzionali preferite quelle che consentono maggiore automazione nell'esecuzione e che al contempo promettono un buon rapporto costi/benefici. Fate poi in modo che l'apprezzabile resoconto che presentate in sezione 5.2 sia coerente con gli impegni presi in sezione 4.5.1.
Cercate poi uno stile di presentazione dei risultati che consenta più
agevolmente di identificare le criticità e le eccellenze, come fate, per esempio, in sezione 5.2.3.2.
Nel complesso si tratta di un documento che presenta apprezzabili miglioramenti rispetto alle versioni precedenti, pur se ancora non ottimo.
Glossario v4.0 Eccellente: sarà saggio trasferirne parte all'interno dei manuali.
