DonkeyCode (C3) Presentazione: 26
Giudizio complessivo sui documenti: 25 (sospeso fino a ripresentazione documento Piano di Progetto)
Consegna
Regolare nei tempi ma carente per organizzazione: mancata distinzione tra documenti esterni (forniti per obbligo regolamentare) e interni (forniti per completezza informativa).
Considerazioni generali
Attenzione alla lingua italiana (“redarre” non esiste, si dice “redigere”) e agli accenti, che con l'uso di LaTeX devono essere inseriti in modo consapevole.
Attenzione anche a usare la sillabazione italiana (ciò che non sembrate fare).
Presentazione buona per contenuto e struttura, ma eccessivamente lunga.
Norme di Progetto Buono sia per impostazione che per ampiezza di contenuti.
Analisi dei Requisiti
L’impostazione generale è sufficiente, ma devono essere corretti gli errori riportati di seguito e ridisegnati interamente alcuni diagrammi. Pre- e post- condizioni devono rispecchiare stati del sistema. Nella descrizione degli scenari non ci sono riferimenti agli stessi. Il perimetro dei casi d’uso
rappresenta il sistema e non il caso d’uso stesso. Il sistema non può essere un attore: correggere in tutti i diagrammi. Le post-condizioni non sono a loro volta scenari. Rivedere le regole di associazione di un codice ai casi d’uso (anche considerato che raggiungete il 5 livello!). Non specificate le relazioni tra i tipi di utenti. Buono il tracciamento dei requisiti.
UC1: la definizione dell’utente deve essere sempre precisa nei casi d’uso, riferendosi agli utenti definiti nel documento di AR. Nella descrizione vi è riferimento esplicito a un segnalante: inserirlo nel diagramma. Attenzione: nel diagramma lo scenario di “Login” non è alternativo (associazione di
estensione). UC1.1: da rivedere, eliminando il sistema come attore (il caso d’uso non deve descrivere il flusso logico dello scenario). Le associazioni fra UC1.1.5, UC 1.3.4 e UC1.1.7 non sono corrette (doppia inclusione). UC1.1.7:
non corretto: il sistema non può essere un attore di un caso d’uso. Il
diagramma non è di attività, quindi non deve esporre dettagli implementativi.
Rivedere (o eliminare). UC1.2: errore di battitura nella condizione di estensione (“Erorre”). Anche in questo caso il diagramma è impropriamente utilizzato come diagramma di attività. Eliminare l’utente “sistema” e correggere facendo estendere direttamente UC.1.1.3 da UC1.2.2. UC.1.4 diventa la post-condizione. UC1.2.1: non corretto: il sistema non può essere un attore di un caso d’uso. Il diagramma non è di attività, quindi non deve esporre dettagli implementativi. Rivedere (o eliminare). UC1.2.1.4: non è chiaro che funzionalità rappresenti il caso d’uso. Il flusso alternativo dovrebbe descrivere il caso in cui il segnalante voglia aggiungere dei commenti.
UC1.2.1.5: non è chiaro che funzionalità rappresenti il caso d’uso. Non è possibile inserire delle condizioni fra le associazioni utenti / scenari, quindi è necessario o specificare meglio l’utente o modificare il caso d’uso. Non occorre utilizzare la derivazione su UC1.2.1.5.3: basta fare un nuovo diagramma di caso d‘uso (fra l’altro chi deriva dovrebbe avere un identificativo di un livello inferiore; p.es., UC1.2.1.5.3.x). La relazione di estensione non è corretta. Rivedere il diagramma. Non è presente la descrizione dei flussi alternativi. UC1.2.1.6: non è chiaro che funzionalità rappresenti il caso d’uso. Nel diagramma una serie di scenari è collegata a UC 1.2.1.6.10 da associazioni senza una etichetta. Attenzioni, i flussi alternativi non comprendono le funzionalità direttamente collegate all’attore, ma quelle attività che possono verificare solo in determinate condizioni. Tutto il resto fa parte del flusso principale. UC1.3: da rivedere, eliminando il sistema come attore (il caso d’uso non deve descrivere il flusso logico dello scenario).
UC2: non chiara la funzionalità rappresentata dal caso d’uso. UC2.1: occorre davvero creare un amministratore ogniqualvolta si crei una nuova autorità?
Studio di Fattibilità Fornito. Contenuto interessante e di buona qualità.
Piano di Progetto
Documento di buona qualità, ma va modificato dove e come richiesto. La lista di riferimenti normativi e informativi è oltremodo ridotta. La clausola
specificata a fine di pagina 3 è ovviamente frutto di un errore tipografico, che però comporta un flagrante conflitto di interesse, che va invece assolutamente
evitato. La vostra pianificazione considera l'impegno erogato e i costi incorsi dal 30/11/10 al 20/12/10, ciò che viola le regole di progetto, che impongono che il tempo di progetto sia contabilizzato solo a partire dalla consegna in ingresso alla RR. Dovrete dunque aggiornare la pianificazione e la relativa contabilità per aderire a tale vincolo, mantenendo conformità con i vincoli di costo totale non inferiore minimo e di impegno orario individuale
nell'intervallo 85:105. L'analisi dei rischi, pur buona, non è ancora gestione in quanto manca di strategie per la rilevazione del livello di rischio e la
conseguente attivazione delle misure previste di mitigazione. Documento da rivedere e ripresentare.
Piano di Qualifica
Risulta incongruo che il documento di capitolato appaia tra i riferimenti informativi invece che normativi. Interessante e impegnativo il contenuto delle sezioni 2.1-2. Vi sono però alcune incongruenze terminologiche che ne minano la congruenza; p.es.: verifica e validazione sono processi e non attività; i contenuti della sezioni 2.3.1 trattano di strategie di verifica e non di quality assurance; essi non sono dunque congruenti con il titolo, con la conseguenza che il tema QA rimane sguarnito.
Nel complesso, il documento è ambizioso, ben impostato e di buona qualità. Il suo contenuto attuale però non pare allineato con lo stato di avanzamento del progetto e fa pensare che i prodotti dell'attività di analisi non siano stati oggetto delle verifiche proposte nel documento PQ. Dovete invece fare in modo che i contenuti del PQ siano sempre applicabili alle attività svolte nel periodo di rendicontazione e poi anche a quelle future.
Glossario Buona l'impostazione e validi i contenuti.
