Zeta Solutions (C3)
Presentazione: 26 Giudizio complessivo sui documenti: 27,5
Consegna Puntuale per tempistica e buona per modalità, fatta salva la fastidiosa e indesiderabile presenza di file e cartelle nascosti.
Considerazioni generali
Presentazione di apprezzabile qualità per stile e organizzazione, ma con qualche incertezza sul piano dei contenuti.
Attenzione agli accenti (gravi, acuti) e alla spaziatura prima e dopo le parentesi. Interessante l'idea di redigere un documento interno con la
trascrizione delle comunicazioni intercorse con il committente: andranno però evitati gli errori tipografici e inoltre va valutata l'opportunità di chiedere il consenso del committente all'uso formale di comunicazioni informali.
Norme di Progetto v3.0
Documento di contenuto eccellente nella presentazione degli strumenti utilizzati, ma non del tutto logico e consequenziale nella struttura, che ancora non raggiunge la necessaria (e ordinata) copertura di tutte le attività di sviluppo e verifica svolte all'interno del progetto.
Analisi dei Requisiti v3.0 Gli errori evidenziati in RP sono stati corretti. Bene.
Specifica Tecnica v2.0
Cap. 2: evitate che il titolo vada a capo. L’ordine di esposizione dei contenuti introduttivi rivisto è migliore. Corretti i diagrammi di attività, ma ancora non è descritta la relazione fra le componenti architetturali (che invece viene discussa nel documento DP): il documento di ST è il luogo ideale e più naturale per farlo.
Restano ancora piccoli errori nel documento. Considerando ST e DP nel complesso vi troviamo tutte le informazioni necessarie, ma spesso il DP contiene informazioni che avrebbero dovuto apparire in ST (come peraltro già richiesto in sede di RP).
Definizione di Prodotto Il documento di DP descrive le componenti di dettaglio in modo atomico, e quindi con minore attenzione alle relazioni fra componenti che invece è scopo del documento di ST. Indicate con precisione la versione di UML che utilizzate. Il diagramma in fig. 1 è poco leggibile. Inserite una diagramma dei package che semplifichi le relazioni e poi trattate blocchi informativi minori, in modo da avere diagrammi più fruibili. Pag. 18: la descrizione degli attributi della classe RescueMe (e non solo) indica che questi eseguono delle
operazioni: vi pare ragionevole? Stessa pagina: onModuleLoad non viene specifica con la signature di metodo. “setta” à imposta. Fig. 7: le vere relazioni di realizzazione sono probabilmente in direzione opposta a quella da voi disegnata: verificate. Descrivete meglio la motivazione del disegno architetturale da voi adottato. Pag. 18: lo username dell’utente corrente non può essere inserito all’interno di una costante, perché, altrimenti è visibile da tutti gli altri utenti. Inoltre, con due utenti autenticati possono insorgere dei problemi di errata valorizzazione dell’utente corrente. La classe
ManagedNewRequestWidget, pur appartenendo alla componente di view, possiede un riferimento a un web service per recuperare direttamente le informazioni dal Model, violando MVC e MVP: correggere. Molte altre classi hanno il medesimo problema. Classe Statistic: poiché è esplicitamente descritto che servirà a soddisfare un particolare requisito, riportate il suo codice. Pag. 62. Nei diagrammi delle classi gli attributi/operazioni statici/he non sono sottolineate come è invece richiesto dalla convenzione UML. Pag.
85: la descrizione del metodo di una interfaccia deve essere maggiore (solitamente si documenta maggiormente l’interfaccia e non le realizzazioni).
Inoltre è saltata la formattazione. Par. 3.1.15.2: l’interfaccia del model espone un metodo che verrà richiamato direttamente dalla View, in violazione del pattern MVC3 di Spring. Pag. 87: segnatura à firma in italiano o signature in inglese. Molti metodi delle componenti del package shared non hanno una descrizione associata: provvedere. Pag. 127: “finalizzate di rete”. Bene il tracciamento e le appendici, anche se il completamento del codice va segnalato nel documento di PdP.
Il documento è ben strutturato, anche se talvolta la descrizione delle componenti non segue un ordine chiaro e riconoscibile (passate dalla
descrizione delle componenti di model alla descrizione delle componenti di control senza una demarcazione netta). Il grado di dettaglio è buono. Non sono presenti diagrammi di attività o sequenza. Alcune imprecisioni architetturali.
Manuali
Manuale_per_installatore_1.0.0.pdf
I manuali sono documenti a distribuzione e uso esterno: non inserite riferimenti a documenti di sviluppo (sez. 2.2). Sez. 3.2: sottolineate
maggiormente il fatto che “nome” è il nome dell’applicazione scelto nei passi precedenti. Bene. Non prevedete errori in fase di installazione?
Manuale_Utente_Amministratore_di_Autorità_1.0.0.pdf
Pag. VII: eliminare dal documento la pagina vuota. Per il browser Chrome non indicate la versione minima/consigliata. Cap. 3: le funzionalità riportate in questo capitolo sono molte di più rispetto a quelle riportate in fig. 1:
rivedere. Bene l’esposizione, ma il contenuto non è coerente con il titolo del documento.
Manuale_Utente_Amministratore_di_Sistema_1.0.0.pdf Bene.
Piano di Progetto v3.0
Al di là di qualche errore di battitura, che denota carenze nella verifica, il contenuto della sezione 7.2 è interessante e mostra che, inconsapevolmente, avete fatto ricorso a tecniche del metodo agile per ovviare ai problemi derivanti dal ritardo che avete cumulato. Il preventivo a finire pare superficiale e comunque non congruente con la criticità della situazione. Il resto del documento è di apprezzabile qualità.
Piano di Qualifica v3.0 Buono il documento principale, eccellente l'allegato.
Glossario v3.0
Buono. La definizione di “dead code”, per quanto plausibile, non corrisponde all'accezione consolidata. Anche la definizione di “embedded” ha qualche originalità. La definizione di “wrapper” non è specifica ed esclusiva di Java.
