Donuts'Keys (C04)
Presentazione: 29 Giudizio complessivo sui documenti: 27,5
Consegna Consegna avvenuta oltre i termini consentiti. Penalità: 0,5 punti.
Considerazioni generali
Attenzione alla congruenza delle procedure di verifica e approvazione: il registro delle modifiche di PdP denuncia incongruenze procedurali in quanto l'incaricato delle correzioni non può essere in capo alla verifica e tantomeno all'approvazione.
Il dott. Palazzi non è committente, ma il proponente del capitolato C04.
La vostra descrizione del contenuto dello standard ISO/IEC 12207 è gravemente errata. La specifica dei riferimenti non aderisce a uno standard professionale perché non agevola il lettore nel localizzare in modo non ambiguo e dispersivo l'informazione riferita.
Insufficiente attenzione anche alla correttezza linguistica: p.es., PP, Sez.
6.1: “consapevolmente a quanto riscontrato”; PQ, Sez. 2.1: “si occuperà di assicurarsi”; Sez. 4.4: “misuarzione”, e diversi altri.
Norme di Progetto
Aggiornamento non fornito: ciò rende impossibile valutare la qualità delle norme applicate alle fasi di progettazione, programmazione, verifica e validazione: il documento dovrà essere obbligatoriamente fornito in ingresso alla RA.
Specifica Tecnica (v3.0)
Interessante la suddivisione per revisione del diario delle modifiche. Le vostre argomentazioni sulla scelta del linguaggio di programmazione e sulla fattibilità di eseguire una RIA su una postazione di lavoro di
“vecchia data” sono eccessivamente di parte (suonano come una giustificazione a posteriori di una scelta fatta a priori) e quindi non del tutto accettabili. Sez. 5.3.4: la descrizione del Mediator è stata migliorata, ma non è stato fornito l’esempio (in termini di classi) richiesto in sede di RPP. La fig. 19 è illeggibile e la sua descrizione è troppo scarna per l’insieme di informazioni che invece introduce. Sez.
6.4 e 6.5: più che chiamare le sezioni con la tipologia dei diagrammi sarebbe stato opportuno dar loro un nome funzionalmente significativo.
Cap.7: cos’è una “libreria interna”? Sez. 7.2: l’interfaccia Igraphic non deriva da MovieClip nel diagramma. Non tutte le componenti sono mappate su requisiti: come mai? Argomentare.
Il documento è migliorato, e alcuni errori sono stati corretti. Le informazioni sulla parte effettivamente sviluppata dal gruppo sono ancora poche. Il documento è sicuramente sufficiente, ma non ancora
“molto buono”, come invece avrebbe potuto essere.
Definizione di Prodotto
Pag. 5: l'impaginazione della sez. 1.1 differisce sensibilmente da quella delle altre sezioni. Sez. 1.3: il glossario e il documento di ST sono riferimenti informativi e non normativi (quali sono, invece, le norme di progetto nella parte relativa alla progettazione). Mancano di
conseguenza i riferimenti informativi. Bene le altre informazioni introduttive. Sez. 2.1: viene citata la versione 2.0 del documento di ST, che però è differente da quella indicata nei riferimenti. Lo standard di progettazione non può essere l’architettura logica descritta in ST. Manca una introduzione generale alla descrizione delle componenti di dettaglio.
Bene invece la descrizione della componente logica, anche se converrà arricchire il tutto con diagrammi delle classi e/o dei package. Cap. 3:
cos’è un asset grafico? Chiarite il concetto localmente o inserite la voce nel glossario. Sez. 3.1: dove viene specificato il supertipo della classe XMLLanguageHandler? Sez. 3.2: correggete i riferimenti alle stringhe
“XMLConfigHandler” e “XMLConfigSRHandler”, che al momento non sono stringhe. Chiarite come il metodo load() debba gestire gli errori di caricamento. Quali sono i tipi di loader istanziabili? Il termine
“Dispatchato” è un neologismo deprecabile. Sez. 3.3: uniformate la convenzione per definire classi estese e implementazioni di interfaccia.
XMLHandler viene definita come classe astratta, non è chiaro quali siano i metodi che la rendono tale. Sez. 4.1: attenzione alla
formattazione. La superclasse non è viewComponent. Cosa fa esattamente LetDragApplicationHandler? Attenzione al testo spurio:
Stage(): “DA CHIEDERE A NICOLA”. Sez. 4.6:
insertSimulationMediator dovrebbe avere la “I” maiuscola, perché nome di classe. Per inciso, la classe non esiste, vi siete forse dimenticati un Window?. Sez. 4.7, attenzione alla formattazione. Sez. 4.13: attenzione alla concordanza dei generi: “componenti grafiche [..] legati”. La descrizione iniziale della sezione non è chiara. Sez. 5.1: se registerProxy è una classe del framework allora il nome va in maiuscolo;
analogamente in sez. 5.3 per showAlertCommand. Sez. 6.1: BaseButton estende una classe che ha lo stesso nome del package, ma la scelta di nomi è pessima. Sez. 6.3: un’altra classe Component? Le classi che ereditano da Component dovrebbero riportare anche il package relativo.
Bene l’appendice A, che può essere molto utile al programmatore.
Il documento è di buona qualità, anche se solo in parte. Le descrizioni sono abbastanza dettagliate, anche se talvolta con un troppi sottintesi.
Restano alcuni errori da correggere ed è necessario inserire qualche diagramma di sequenza o attività che descriva i metodi più complessi.
Manca completamente il tracciamento tra le componenti di dettaglio e i requisiti (e viceversa): provvedere.
Manuale Utente Ottimo, a meno di svariate amenità linguistiche e terminologiche.
Ricordate che PDF è un acronimo e come tale va scritto in maiuscolo.
Piano di Progetto (v3.0)
Restano curiosamente validi i rilievi già fatti in sede di RPP: il
documento è ben impostato e presenta contenuti apprezzabile per quanto riguarda la pianificazione; restano però insufficienti il resoconto e la valutazione dell'attuazione, addirittura nulla per quanto riguarda la gestione dei rischi, e scarsa per il preventivo a fine, che non consente di valutare la congruità delle risorse residue per la verifica e la validazione rispetto allo stato reale dello sviluppo.
Piano di Qualifica (v4.0)
Sez. 2.2: incongruo – e concettualmente errato – che l'analisi statica venga categorizzata come un elemento della “fase di testing”. Sez. 2.3.1:
è riduttivo affidare al verificatore “la gestione della qualità”, che invece di norma è in capo a ruoli di progetto o funzioni aziendali più autorevoli.
Sez. 2.4: incongruo il titolo “Test di Verifica”, così come il punto
“verifica e validazione” a fine elenco.
Per il resto, il documento è di contenuto significativo e apprezzabile, a meno di alcune ingenuità: occorre sintetizzare l'esito di tutte le azioni previste dal piano e non soltanto di (alcuni) test e conviene farlo in forma tabulare piuttosto che testuale e verboso; occorre poi ragionare criticamente sulle risultanze. Risulta poi curioso che abbiate definito indicatori particolarmente creativi (secondo euristiche di vostra concezione originale) senza preoccuparsi di applicarle e di relazionare sull'esito riscontrato.
Glossario Aggiornamento non fornito.
