Tabella riassuntiva
Legenda:
- : qualche carenza
= : accettabile
+ : discreto
DBS Software
Ricezione
- 13/2 11:21 (entro scadenza)
- Buono il formato di consegna, con le seguenti eccezioni
- Al nome del documento PQ corrisponde il contenuto del documento
DP
- Documento "Piano delle prove" non leggibile (da Acroread 5.1)
DP
Aspetti strutturali
- Documento ST non incluso nella lista dei riferimenti
- Improprio ed erroneo l'uso di cammino assoluto (!) per specificare
la collocazione dei moduli sorgenti
Contenuto
- Apprezzabile lo sforzo di approfondimento e di completezza della
descrizione, particolarmente apprezzabile lo sforzo di utilizzare diagrammi
UML per la descrizione degli aspetti statici e dinamici del sistema
- Nei diagrammi delle classi mancano pero' molte descrizioni
delle associazioni
- Non chiaro il diagramma degli oggetti (?) fornito come descrizione
della "Comunicazione in generale", con uso improprio del simbolo delle "note".
- Non fornito lo standard di codifica, con giustificazione insufficiente;
parte consistente delle norme richieste derivano semplicemente dall'adozione
di Javadoc come strumento di documentazione del codice e di un qualunque
editore di testi sensibile alla sintassi Java; gli unici elementi specifici
delle norme da definire da parte del progetto avrebbero dovuto riguardare
la dimensione massima delle unita' di codice sorgente (che attualmente in
2 casi superano le 400 linee) ai fini di verificabilita' e manutenibilita',
i criteri d'uso di metodi e dati privati e la fissazione del livello massimo
di annidamento dei rami condizionali
- Buona ma unidirezionale la tabella delle relazioni componenti-requisiti
- Buona la qualita' del codice e la densita' dei commenti (0.81); non
e' stato pero' fornito alcuno script di guida per la compilazione
Piano di progetto v1.8
- Importante sbilanciamento dell'impegno di un membro del progetto rispetto
al resto del gruppo (+27%)
PQ
Aspetti strutturali
- Documento non pervenuto -- sovrascritto dal DP (chiara lacuna
nella gestione della configurazione di progetto)
Contenuto
Giudizio
complessivo
- DP e codice allegato mostrano aspetti positivi che fanno ben sperare.
Diverse ingenuita' ed errori nel resto della gestione della consegna e, presumibilmente,
del progetto nel suo complesso. Si richiede la consegna del PQ per completare
la RPD. Sara' importante ribilanciare il livello di impegno tra i membri del
gruppo
Gurusoft
Ricezione
- 13/2 08:05 (preannuncio piano di contingenza)
DP
Aspetti strutturali
- Docunento non pervenuto, come preannunciato da piano di contingenza
Contenuto
ST v2.0
- Apprezzabile lo sforzo di miglioramento rispetto alle versione precedente;
particolarmente buona la quantita' dei diagrammi forniti, di discreta qualita'
- Nomi di associazioni non sempre appropriate neil diagrammi delle
classi
PQ
Aspetti strutturali
- Docunento non pervenuto, come preannunciato da piano di contingenza
Contenuto
Giudizio
complessivo
- Sospeso in attesa di consegna dei documenti richiesti
Mountain System
Ricezione
- 13/2 01:51 (entro scadenza)
- Ottimo formato di consegna
- Documentazione in formato sorgente HTML, ma con adeguata giustificazione
DP
Aspetti strutturali
- Manca il testo del sommario, che non e' l'indice del contenuto
del documento
- Manca la menzione del documento DP nella lista dei riferimenti
- Ridondante la ripetuta menzione "analisi dei requisiti" nelle tabelle
di relazione in appendice (al suo posto basta un semplice sistema alfanumerico
che identifichi univocamente il documento sorgente e l'elemento in esso
contenuto)
Contenuto
- Buon rigore descrittivo e buona completezza di contenuto, per
quanto con alcune ingeguita' e manchevolezze
- Insufficiente la menzione dell'uso della notazione UML per lo standard
di disegno architetturale: UML consente di rappresentare aspetti del sistemi
da vari punti di vista per i quali offre varie forme di diagrammi; uno standard
completo determina i punti di vista rilevanti per il progetto e specifica
quali diagrammi utilizzare per rappresentarli
- Completamente omessa la descrizione della struttura dinamica e
del comportamento dinamico del sistema: la presentazione della specifica
delle componenti non distingue tra classi attive e classi passive
- Nessuna norma si preoccupa di assicurare il contenimento della
complessita' dei moduli di codice sorgente ai fini di verificabilita' e
manutenibilita' (4 moduli, ciascuno costituito da una singola classe in
un singolo file, hanno dimensione superiore alle 200 linee e 2 di essi superano
le 600), di raccomandare pratiche consistenti per l'uso di metodi e dati
privati, e di fissare un limite massimo al livello di annidamento dei rami
condizionali
- Buona la bidirezionalita' delle tabelle di relazione componenti-requisiti
- Buono il riferimento normativo all'uso di Javadoc; vaghe ed
indefinite, pero', le nozioni di modifica "picoola" o "grande"
- Discreta la qualita' del codice, che potrebbe pero' essere utilmente
raggruppato in package; eccessivamente ridotta la densita' di commenti
(0.33)
- Preoccupante il fatto che ogni tentativo di esecuzione dell'eseguibile
risulti in guasto fatale del sistema!
ST v1.1
Commenti sulla revisione successiva alla RPP
- Continua a mancare il testo del sommario
- Globalmente discreti i diagrammi, che dovrebbero pero' essere numerati
per consentire un agile riferimento
- Nel "diagramma UML" (che e' definizione impropria perche' troppo
generica) la specifica dell'interfaccia e' fuori posto, ed i nomi delle
associazioni appartengono chiaramente a due diversi livelli di analisi o
astrazione (le associazioni di tipo "invia" fanno pensare piu' ad un diagramma
di collaborazione -- dinamico -- che un diagramma delle classi -- statico
--)
- Sarebbe bene semplificare i diagrammi di collaborazione con l'uso
del simbolo "multiobject" e messaggio ripetuto
- Nel diagramma UseCase vi sono due relazioni di dipendenza
non chiare
- Globalmente buono il resto del contentuo
Norme di progetto v1.1
Piano di progetto v1.8
- Distribuzione fortemente ineguale dello sforzo consuntivo per risorsa
(47h - 68h)
PQ
Aspetti strutturali
- Manca il testo del sommario, che non e' l'indice del contenuto
del documento
Contenuto
- L'analisi del codice (come di qualsiasi altro prodotto) deve rigorosamente
ed esclusivamente essere effettuate da terzi, condizione non pienamente
soddisfatta dalla presente piano
- Buona la completezza complessiva dei casi di prova previsti; non
chiaro il beneficio di prevedere la ripetizione di un caso di livello inferiore
a livello di prova di collaudo (caso di prova n. 1)
- Ingenua ed inadeguata la specifica dell'uscita attesa del caso di
prova n. 2 (ogni distribuzione statistica diventa significativa solo entro
intervalli dati di osservazione, cio' che non e' definito nel caso in questione);
forse e' opportuna una riflessione generale su come effettivamente verificare
le distribuzioni statistiche previste in analisi dei requisiti ed in specifica
tecnica
Giudizio complessivo
- Buona qualita' complessiva. Alcune lacune restano da rimediare
e diversi miglioramenti sono ancora possibili su ciascuno dei documenti sin
qui prodotti. Particolarmente importante sara' riuscire a bilanciare il
livello di impegno tra i membri del gruppo di progetto
Porto Software
Ricezione
- 13/1 11:05 (entro scadenza)
- Consegna incompleta, a testimonianza della situazione incerta
ed instabile del gruppo
DP
Aspetti strutturali
Contenuto
- Sara' bene comprendere che la parte descrittiva del sistema fornita
nel documento DP non puo' essere semplicemente una riproposizione dello stesso
materiale fornito nel documento ST
- Per quanto attiene al contenuto attuale, si noti quanto segue
- Standard di disegno architetturale
Affermato che lo standard utilizzato e' UML, non serve richiamare
le regole fondamentali stesse del linguaggio; a meno che non si voglia
modificarle o specificarle in modo particolare
- Standard di denominazione di entita', relazioni ed oggetti
Descrizione non chiara con errori formali
- Standard di programmazione
Largamente incompleto. Si vedano, a mo' di suggerimento, le osservazioni
fatte sugli standard di programmazione adottati dagli altri gruppi di progetto
- Gestione comunicazioni tra navicella madre e controllo missione.
Nelle righe 14-20 e' da rivedere la descrizione
ST v2.0
- Apprezzabile lo sforzo di completamento e miglioramento rispetto alla
versione precedente
- Si notino pero' le seguenti osservazioni:
- Il sommario e' inteso essere un breve riassunto testuale del contenuto
del documento, non la riproposizione del suo indice dei contenuti
- L'uso ripetuto dello stesso diagramma -- anche se posto in contesti
diversi -- non aggiunge informazione, anzi ne detrae se contiene la ripetizione
di errori (tipo "randomizato")
- Improprio l'uso del termine "programma" per definire le varie componenti
del sistema, a meno che il prodotto finale non sia effettivamente costituito
da un insieme distribuito di programmi autonomi coordinati
- Impropria tecnicamente e terminologicamente la discussione in §6
PQ
Aspetti strutturali
Contenuto
- Varie improprieta' linguistiche
- Livello di contenuto solo parzialmente completato dal collegamento
al documento "piano delle prove v2.0"
- Documento non passato al vaglio del responsabile di qualita' (vedi,
per esempio, la sequenza di punti di domanda "????????" in sezione Riferimenti)
- Improprie le definizioni di verifiche statiche ed interfaccia grafica
- Varie improprieta' lessicali, concettuali e metodologiche relativamente
a:
- 5.2: Trattamento delle discrepanze
- 6.3: Dettaglio delle verifiche tramite test
- 6.4: Dettaglio delle revisioni
Giudizio complessivo
- Sospeso in attesa di chiarimento sul futuro del gruppo di progetto