KaleidosCode (C6)
Presentazione: 25 Giudizio complessivo sui documenti: 23,5
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di Presentazione: comunicare al committente una riduzione sul prezzo già concordato nell’offerta comporta rischi indesiderabili per il proponente, fino a quando non vi siano certezze sui margini effettivi di risparmio. Verbali: apprezzabili le modifiche apportate per stesura, contenuti e organizzazione. In italiano, le decisioni non sono “fatte”, ma “prese”. Come dovreste aver imparato dall’analisi dei requisiti, un documento fatto di frasi lunghe e in stile eccessivamente narrativo è poco tracciabile: così sono i vostri verbali. Registro delle modifiche: bene.
Riferimenti: talvolta troppo generici quelli informativi.
Presentazione Discreta per maturità e valore informativo. Buona per ritmo di erogazione.
Nonostante l’apprezzabile demo finale, era richiesto aprire con un richiamo al concetto di prodotto.
Norme di Progetto v3
Qualche miglioramento (ma più cosmetico che sostanziale) nella direzione delle segnalazioni ricevute in sede di RP, ma evidente confusione nella comprensione della classificazione dei processi secondo ISO/IEC 12207: le attività di verifica costituiscono un processo a se stante (parte dei processi di supporto), e non sono quindi da includere tra quelle dello sviluppo. Il
versionamento è anch’esso un processo di supporto, mentre voi promuovete a quel livello gli strumenti che esso dovrà usare. Sarebbe più utile ed efficace associare gli strumenti selezionati alle attività che essi sono intesi supportare;
confinandoli invece in §3,5, non avete fornito informazione coesa.
Nel complesso, il documento resta insoddisfacente.
Analisi dei Requisiti v2
Come già più volte segnalato, R1Q4 non è un requisito di qualità, ma funzionale. R0P1 è anch’esso requisito funzionale. Quali sono i vincoli per l’utilizzo del sistema? Supporta qualsiasi browser, anche IE5? Specificare opportuni requisiti di vincolo (come già segnalato in sede di RP).
I casi d’uso sono stati migliorati, ma persistono errori già più volte segnalati, che vanno definitivamente corretti. Da rivedere.
Specifica Tecnica v2
Secondo voi, inserire la application logic all’interno delle viste è ragionevole?
È quanto i creatori di Backbone avevano in mente per gli utilizzatori del loro framework? Dal documento non è assolutamente chiaro dove e come i vari framework si integrino con la vostra architettura. Non è chiaro neppure perché presentiaate il pattern MVC, dopo aver dichiarato di non usarlo (come già segnalato in sede di RP).
Documento migliorato, ma non abbastanza. Dovete porre maggiore attenzione sulla integrazione architetturale delle componenti del sistema, così da (di)mostrare come esse producano una architettura coesa e funzionante.
Definizione di Prodotto
Il piè di pagina non riporta il numero complessivo di pagine del documento, segno di insufficiente attenzione nella verifica di conformità. La fig. 4 era già stata utilizzata in precedenza nel documento: non è corretto riportare più volte la stessa immagine. §3.3.1: cos’è una “classe statica”? L’utilizzo del tipo Object per attributi e parametri non permette allo sviluppatore di comprendere lo schema reale dell’oggetto che dovrà essere utilizzato. Individuare un tipo concreto per ogni particolare utilizzo del tipo generico Object. Analogamente per il tipo JSON: riportare in una sezione dedicata gli schemi utilizzati. Cosa rappresenta il tipo “Objects”? Pag. 31: “Nella particolare declinazione MVC adottata da Backbone.js, si occupa anche di gestire gli input dell’utente.” Chi
“si occupa”? Fig.8: per quale ragione il diagramma è stato realizzato con un editore diverso rispetto ai diagrammi precedenti?
Il documento ha struttura corretta, con discreto livello di dettaglio. I tipi degli oggetti utilizzati dalle componenti di dettaglio devono però essere descritti e integrati. Sarà inoltre opportuno inserire diagrammi di sequenza per descrivere in maggior dettaglio gli algoritmi più complessi.
Manuali Manuale utente: in §1.3 scrivete: “Il corrente manuale è rivolto a tutti gli
utenti utilizzatori del prodotto”. Quale il valore informativo di questa frase?
Pag. 3 descrive molte informazioni che però non sono opportunamente supportate da catture di immagini dell’applicazione. Le immagini fornite non correlano con la descrizione fornita nel documento. Un manuale dovrebbe invece guidare l’utente nell’utilizzo dell’applicazione, non limitandosi a elencare gli elementi grafici con i quali potrà interagire. §4.2: specificare la procedura per segnalare eventuali errori. Rivedere secondo le indicazioni.
Piano di Progetto v3
§2: bene. Quando si applicano le misure di mitigazione previste, si deve anche valutarne l’efficacia, provvedendo così alla loro manutenzione migliorativa.
§3: resta, fatalmente, il dominio delle attività di documentazione su quelle di sviluppo. L’effetto è come di trasferire la logica di programma dal main a un suo qualunque sottoprogramma.
§4: bene le correzioni.
§5: interessante osservare come, nonostante le reiterate segnalazioni, la pianificazione più recente, quella rivisitata nel preventivo a finire per il periodo RQ-RA sia massimamente dominata dalla documentazione, al punto da lasciare del tutto indistinte (e quindi non pianificate) le attività tecniche.
Nel complesso, quindi, il documento risulta insoddisfacente.
Piano di Qualifica v3
La separazione tra §2 e §3 rende scarsamente coesa l’informazione in esse contenuta, che pure è evidentemente correlata, come risulta dai riferimenti, e quindi difficilmente manutenibile e poco efficace in lettura.
Buona l’appendice A. I contenuti di §A.1 sono meglio posti in forma tabulare.
Nel complesso, il documento non è ancora del tutto soddisfacente.
Glossario v2 Nessuna variazione.
