SWEg (C1)
Presentazione: 24 Giudizio complessivo sui documenti: 22 (penalità: 1 punto)
Consegna e considerazioni generali
Consegna: effettuata oltre i termini di scadenza (penalità), includendo anche materiale non pertinente, come lo Studio di Fattibilità. Lettera di
presentazione: l’affiliazione del committente è errata. Comunicare
ufficialmente la riduzione dei costi comporta un rischio inutile per il fornitore, fin quando vi siano (come ve ne sono nel vostro caso) ancora incertezze residue sui tempi e gli esiti di fine lavori. In vista dell’ingresso in RQ, la lettera di presentazione dovrebbe anche riportare l’indirizzo del repository del codice attualmente sviluppato. Verbali: ora raccolti in cartelle, ma senza novità nel periodo, segno di scarsi rapporti con il proponente e rari incontri decisionali interni. Registro delle modifiche: apportate le correzioni richieste.
Verifiche tipografiche e grammaticali insufficienti.
Presentazione Tono e contenuti poco convinti e poco convincenti. Poco efficace l’introduzione alla demo. Buona l’illustrazione del concetto di prodotto.
Norme di Progetto v3
L’organizzazione del documento continua a essere insoddisfacente, segno di vostra scarsa attenzione alle segnalazioni ricevuti (o scarsa intenzione di comprenderle e attuarle. I contenuti di §2 attengono evidentemente ai processi organizzativi, che voi, colpevolmente, non trattate. I contenuti di §3 attengono al processo di documentazione, che è parte dei processi di supporto. I contenuti di §5 sono poco decifrabili, trattando di “sviluppo” che è processo primario, ma includendo anche attività appartenenti ad altre categorie di processi. Deludenti per pochezza di contenuti e superficialità, le norme che accompagnano le attività tecniche (progettazione e codifica) centrali nel periodo tra RP e RQ. Nel complesso, il documento è gravemente insufficiente.
Analisi dei Requisiti v3 Corretti gli errori segnalati in sede di RP: bene.
Specifica Tecnica v2
§2.1.4: “Svantaggi: Richiede l’installazione di componenti aggiuntive in ogni dispositivo del gruppo”. Può questa caratteristica essere riportata come svantaggio legato alla tecnologia? §2.1.6: cosa intendete con performance
“perfette”? Sono sufficienti per quello che si deve fare? “Astrazione della macchina fisica a confronto a linguaggi più vecchi come C++.”? §2.2.2: da eliminare se Spring Boot non è più utilizzato nell’architettura. Fig.2:
immagine illeggibile. Migliorate le descrizioni delle relazioni fra componenti.
Come già segnalato in sede di RP, la contestualizzazione dei design pattern deve avvalersi di diagrammi delle classi opportunamente costruiti sulla propria architettura. Pag. 58: il diagramma fuoriesce dalla pagina. Pag. 82:
non è chiara la figura e la sua posizione.
Documento migliorato rispetto alla precedente versione, ma con errori grossolani frutto di insufficiente attenzione nella verifica. Da rivedere.
Definizione di Prodotto
La sezione dei riferimenti è completamente vuota, il che non può essere:
correggere. La versione del glossario riferita nel documento deve essere disponibile. I metodi devono essere riportati con i propri parametri in input e output, che devono essere opportunamente descritti. Inoltre la descrizione dei metodi (almeno quelli più importanti) deve essere ampliata. Rivedere anche l’impaginazione, attualmente troppo dispersiva e confusionaria (allineamento centrale?). Anche gli attributi dei tipi devono essere descritti. Pag. 16: saltata la formattazione sulla lista dei metodi. Per quale ragione la descrizione delle componenti fisiche del front-end risulta avere completamente un’altra formattazione? Uniformare il documento. Meglio la seconda parte relativa al front-end. Molto bene i diagrammi di sequenza, anche se non è chiaro perché i messaggi abbiano quasi tutti una doppia “()()”. §6.3 attiene al PdQ.
Il documento, soprattutto nella prima parte, è raffazzonato e insufficiente per dettaglio. Meglio la seconda parte di descrizione delle componenti del front- end. Molto bene i diagrammi di sequenza, da aumentare di numero. Rivedere.
Manuali Manuale utente: §1.3 da estendere indicando le informazioni necessarie per la comunicazione di eventuali difetti del software. §2.1.3: “Javascritp”. §2.2:
considerate di prevedere anche un manuale separato di installazione. §3.2: il manuale descrive la pagina dal punto di vista tecnico, elencandone le componenti. Usate un approccio più descrittivo per quanto di interesse dell’utente finale, ossia le funzionalità. Pag. 7: “defaul”. Includere un glossario specializzato.
Documento in stato ancora embrionale, che deve essere completato, e anche modificato nell’approccio di descrizione dell’applicazione.
Piano di Progetto v3
Le scelte che presentate in §2 dovrebbero tenere conto dell’analisi dei rischi, mentre al momento ne sono premessa. Apprezzabile l’attualizzazione nell’analisi dei rischi, tabelle 11 e 13 (dove è la 12?), che voi chiamate erroneamente “attuazione”; essa tuttavia manca di riportare le misure di mitigazione applicate e il loro esito (che serve anche alla loro manutenzione correttiva). Interessante l’analisi delle criticità rilevate nel periodo di rendicontazione (nel consuntivo di periodo). Esse hanno certamente causato una ri-pianificazione delle attività rimanenti, della quale però non vi è traccia in §8. Il documento, pur se migliorato, presenta ancora difetti importanti.
Piano di Qualifica v2
Il documento, immaturo per struttura e superficiale per contenuti, resta gravemente insufficiente, e segnala anche – pur se con presentazione poco chiara – un inadeguato stato di avanzamento delle verifiche tramite test rispetto agli obiettivi della RQ. L’accesso alla RA non vi sarà permesso prima di aver fornito un quadro chiaro, compiuto e dettagliato delle verifiche effettuate, dimostrandone completamento conforme alle attese.
Glossario v3 Mancano indice e bookmark. Buono il resto.
