Tabella riassuntiva

DBS Software

Ricezione

• 23/1 11:17 (entro scadenza)
• Archivio ZIP a livello singolo (senza suddivisione in cartelle)
• Documenti in formato MS Word sorgente
• Piano di progetto aggiornato per consultazione ricevuto, su sollecito, oltre scandenza
  

ST

Aspetti strutturali

• Mancano il testo del sommario, la lista di distribuzione e la lista delle modifiche

Contenuto

• Discrete la visione generale del prodotto (§2) e la descrizione del suo contesto d'uso (§3)
• Discreta la definizione del prodotto (§4); mancano però casi d'uso e scenari che giustifichino i diagrammi delle classi forniti
• Attenzione alla congruenza e completezza del glossario 
• Apprezzabile lo sforzo di cattura dei requisiti; manca tuttavia la specifica della loro relazione con le componenti identificate. In generale, occorre tenere sotto controllo le seguenti relazioni: (1) da singola componente ad insieme di requisiti; (2) da singolo requisito ad elemento od attributo di componente che lo soddisfa; (3) da singolo requisito a metodo di verifica e relativa prova, analisi, dimostrazione
  

PQ

Aspetti strutturali

• Mancano sommario, indice e lista delle modifiche
• Il piano delle prove riferito dal documento non è stato inviato per revisione
• Le definizioni in §3 deve essere solo quelle significative per il lettore di questo documento
  

Contenuto

• In §5 non si indica le cadenza di emissione del verbale sullo stato di avanzamento delle prove
• I termini "anomalia" e "discrepanza" sono usati ma non sono definiti
• Manca una strategia per l'accertamento della risoluzione dei problemi
• In §6.3 si contempla una generica "necessità" di ordinamento di disponibilità di componenti; manca però la specifica del criterio di necessità adottato, che non dovrà ovviamente essere "a posteriori"
• E' richiesto essere precisi sul numero di ripetizioni delle prove previste ai fini di verifica. Per la riduzione della varianza nell'esito di alcune verifiche occorre prevedere test di lunga durata
• In §6.4 si ha un erronea interpretazione del termine "revisione", per il quale si deve intendere uno dei due processi di supporto definiti da ISO 12207 come "joint review" e "audit"
  

Giudizio complessivo

• Qualche carenza sia formale che sostanziale. Globalmente accettabile, ma può e deve essere migliorato. Il documento ST può essere considerato finale e le migliorie richieste saranno attese nel suo successore, DP.
  

Gurusoft

Ricezione

• 23/1 12:07 (oltre scadenza)
• Archivio ZIP a livello singolo (senza suddivisione in cartelle)
• Documenti in formato MS Word sorgente
• Piano di progetto aggiornato per consultazione ricevuto, su sollecito, oltre scandenza
  

ST

Aspetti strutturali

• Mancano indicazioni sulla redazione ed approvazione del documento

Contenuto

• Insufficiente la descrizione del contesto d'uso del prodotto (§3). Occorre almeno rispondere alle domande: "per chi", "come", e "dove"
• Per "metodo di definizione" si intende l'indicazione del formalismo utilizzato, per esempio: uso standard di UML
  
• Incompleti i diagrammi forniti per la definizione del prodotto (§4.2); mancano in particolare i nomi delle relazioni. I diagrammi delle classi dovrebbe essere preceduti (e conseguentemente giustificati) dai casi d'uso e gli scenari da cui essi derivano
• Imprecisa la specifica degli strumenti da utilizzare
  
• Totalmente omessa la specifica della relazione tra requisiti e componenti identificate. Occorre tenere sotto controllo le seguenti relazioni: (1) da singola componente ad insieme di requisiti; (2) da singolo requisito ad elemento od attributo di componente che lo soddisfa; (3) da singolo requisito a metodo di verifica e relativa prova, analisi, dimostrazione
  

PQ

Aspetti strutturali

• Non è appropriato che il redattore approvi se stesso. Occorre dotarsi di norme di progetto che assicurino una autorità di approvazione indipendente
• Il piano delle prove riferito dal documento non è stato inviato per revisione

Contenuto

• Buono le definizione in §3. Attenzione alla completezza (omesse, per esempio, voce relative ai termini "bug" e "discrepanza"
• Buona la strategia di gestione amministrativa in §5; mancano tuttavia meccanismi per l'accertamento della risoluzione dei problemi
• Inadeguato il trattamento del tracciamento tra componenti, prove e requisiti
• Troppo generica l'ammissione di presunta incompletezza del piano delle prove; occorre dotarsi di (e descrivere) strategie adeguate per assicurarne la completezza entro i tempi richiesti
  

Giudizio complessivo

• Diverse carenze significative, sia sul piano formale che su quello sostanziale. Il livello attuale del documento non è ancora accettabile. Si richiede l'emissione di una versione migliorativa del documento ST precedente all'emissione del successivo documento DP.
  

Mountain System

Ricezione

• 23/1 09:10 (entro scadenza)
• Archivio ZIP a struttura gerarchica (con suddivisione in cartella)
• Documenti in formato sorgente HTML
• Piano di progetto aggiornato per consultazione consegnato
  

ST

Aspetti strutturali

• Manca il testo del sommario ed è incompleta la lista di distribuzione (manca il nome del docente Conte)
• Improprio il riferimento generico a documenti posti nel sito Web aziendale
  

Contenuto

• Accettabile la visione generale del prodotto. Attenzione però all'uso di termini impropri quali "testaggio"
• Troppo succinta la descrizione del contesto d'uso del prodotto, la quale deve almeno rispondere alle domande: "per chi", "come", e "dove". Impropria l'indicazione lasca di una possibile esecuzione anche su piattaforma Linux: deve essere chiaro al committente se questa possibilità verrà garantita o meno
• Discreta la definizione del prodotto, che sarà bene però rivedere e completare. Sarà bene trasformare espressioni gergali come "Il suo frame prevede combo box" in italiano compiuto ed assicurare la completezza del glossario (vedi anche l'uso del termine "stream")
• La voce "dati trattati" in sezione §5 è intesa specificare gli ingressi e le uscite della componente in oggetto
• Buona ma incompleta l'intuizione di rendere in forma matriciale tra relazione tra componenti e requisiti. Occorre tenere sotto controllo le seguenti relazioni: (1) da singola componente ad insieme di requisiti; (2) da singolo requisito ad elemento od attributo di componente che lo soddisfa; (3) da singolo requisito a metodo di verifica e relativa prova, analisi, dimostrazione
  

PQ

Aspetti strutturali

• Manca il testo del sommario ed è incompleta la lista di distribuzione (manca il nome del docente Conte)

Contenuto

• Buona la visione generale della strategia di verifica
• Mancano meccanismi per l'accertamento della risoluzione dei problemi 
• La sezione "attività di verifica" deve indicare sia l'intento che l'esito delle forme di verifica previste. Si intende che tale contenuto sia incrementale, ma già dalla presente revisione è possibile mostrare il tracciamento di requisiti e componenti e, nel piano delle prove, di esse con i requisiti
  

Giudizio complessivo

• Discreto livello di qualità complessiva. Le lacune sopra individuate possono essere facilmente risolte. Il documento ST può essere considerato finale.
  

Porto Software

Ricezione

• 23/1 12:01 (oltre scadenza)
• Sequenza di allegati singoli (senza archiviazione e senza suddivisione interna)
• Documenti in formato MS Word sorgente
• Piano di progetto aggiornato per consultazione non consegnato
  

ST

Aspetti strutturali

• Manca il testo del sommario ed è incompleta la lista di distribuzione (manca il nome dei docenti)
• Il documento può assumere stato "formale" solo dopo l'approvazione, che al momento non è ancora stata emessa
• Stupisce che il documento Analisi dei Requisiti riferito sia in versione 0.3, la cui numerazione suggerisce lo stato preliminare

Contenuto

• Carente il livello di descrizione della visione generale del prodotto (§2) e del suo contesto d'uso (§3). Quest'ultimo deve almeno rispondere alle domande: "per chi", "come", e "dove"
• E' sconsigliato, ed è di bassa resa, l'uso esclusivo di linguaggio naturale per la definizione del prodotto e delle sue componenti. Tale scelta rende assolutamente necessaria la correttezza della forma espressiva (per esempio: mai usare soggetto sottinteso) e dei riferimenti incrociati (per esempio: "vedi funzionalità 2")
• E' fortemente consigliato, invece, almeno l'uso di diagrammi di casi d'uso e scenari che chiariscano gli aspetti chiave di funzionamento del sistema.
• La descrizione dei componenti risente della mancanza di un formalismo espressivo adeguato anche se è apprezzabile lo sforzo di uniformare lo stile di descrizione. Il redattore del documento deve porsi la domanda se l'informazione fornita in §5 sia sufficiente per consentire l'implementazione del prodotto: la specifica tecnica è adeguata solo se la risposta è affermativa
• Del tutto inadeguata la discussione della relazione tra componenti e requisiti. Occorre tenere sotto controllo le seguenti relazioni: (1) da singola componente ad insieme di requisiti; (2) da singolo requisito ad elemento od attributo di componente che lo soddisfa; (3) da singolo requisito a metodo di verifica e relativa prova, analisi, dimostrazione
  

PQ

Aspetti strutturali

• Manca il testo del sommario ed è incompleta la lista di distribuzione (manca il nome del docente Conte)
• Non basta la data di un documento per definirne il riferimento: fa invece testo la sua versione
  

Contenuto

• Buono il contenuto delle definizioni anche se mancano i termini "anomalia" e "discrepanza". Sarà bene ordinare il contenuto per voce di definizione e non per identificatore "def.n". Si noti inoltre che un "modulo" definisce una componente logica del sistema
• E' buona prassi utilizzare ruoli (funzioni) e non nomi di persone nel formulare strategie, per esempio di verifica
• Ci si chiede come abbiate determinato ed accertato la validità della vostra specifica delle risorse minime necessarie per l'installazione del prodotto
• Si noti inoltre che tra le risorse necessarie e quelle disponibile occorre considerare anche quelle che occorreranno al fornitore per l'esecuzione delle attività di verifica
• Mancano meccanismi per l'accertamento della risoluzione dei problemi 
• In §6.3 si menziona una "presentazione finale" che non è prevista nel calendario degli adempimenti previsti dal committente
• La sezione "attività di verifica" deve indicare sia l'intento che l'esito delle forme di verifica previste. Si intende che tale contenuto sia incrementale, ma già dalla presente revisione è possibile mostrare il tracciamento di requisiti e componenti e, nel piano delle prove, di esse con i requisiti
  

Giudizio complessivo

• Alcune scelte ingenue od eccessivamente difensive (come l'uso di linguaggio naturale per la specifica) degradano la qualità complessiva del prodotto nonostante lo sforzo evidentemente messo in atto. Si richiede l'emissione di una versione migliorativa del documento ST precedente all'emissione del successivo documento DP.