Kern3lP4anic (C2)
Presentazione: 25 Giudizio complessivo sui documenti: 24
Consegna e considerazioni generali
Consegna: niente da segnalare. Lettera di presentazione: errori (già segnalati e successivamente corretti) nel testo e nell’indirizzamento. Verbali: buoni per impianto ed esaustivi per contenuti. Sorprendentemente, mancano decisioni tracciabili (per esserlo avrebbero bisogno di identificatore), come se la discus- sione – sia interna che esterna – avesse avuto solo valenza informativa. In un verbale interno vi sono tracce di metadati non trattati. Registro delle
modifiche: la localizzazione delle modifiche effettuate aumenterà specificandola in modo numerico e non narrativo; occorrerà anche mi- gliorarne la tracciabilità rispetto alle decisioni o esigenze di modifica. Con - venzioni di denominazione: per evitare sovrascritture non intenzionali tra do- cumenti con lo stesso nome base, converrà includervi il numero progressivo di versione. Convenzioni tipografiche: converrà riportare, in intestazione o piè di pagina, il nome del documento e la sua versione. Attenzione agli spazi di se- parazione, che talvolta mancano (p.es., prima della data di ultima visita nei ri- ferimenti informativi).
Presentazione Buona veste grafica e buon ritmo espositivo. Dettaglio progettuale troppo minuto, con insufficiente visione d’insieme e molte inutili ridondanze. Buono il resto dei contenuti.
Norme di Progetto v2
Il tentativo di migliorare l’organizzazione e il contenuto del documento non è andato a buon fine. La strutturazione gerarchica non è consistente: al I livello dovrebbero stare le classi di processo, al II i processi di interesse, al III, le loro attività interne. Gli strumenti forniscono supporto alle attività di processo: la loro presentazione è dunque più efficace (e meno ridondante) se posta al IV li- vello della struttura di cui sopra, nel contesto delle attività che essi adiuvano.
Il materiale incluso in §6 e §7 non si integra in alcun modo intellegibile con il resto del documento, quando invece ci si aspetta che il perseguimento della qualità applichi a specifiche attività (di specifici processi) e a specifici loro prodotti. Con questa trattazione, invece, il materiale risulta di nulla efficacia.
Come già segnalato in sede di RR, i contenuti relativi alle attività tecniche, specialmente quelle centrali per la RP, restano insufficienti per profondità.
Documento da rivedere per organizzazione e da migliorare per profondità.
Analisi dei Requisiti v2
UC1: è privo di scenario principale e non è chiaro in che modo l’utente possa interagire con il sistema per attivarlo. Tutti i casi d’uso devono avere uno scenario principale, per quanto banale esso possa essere. Negli scenari derivanti da UC5 non è chiaro il ruolo dell’attore secondario Slack. In che modo partecipa al caso d’uso? UC7.2.4 e altri, come già segnalato in sede di RR, sono presenti relazioni fra casi d’uso non conformi con lo standard UML.
Fra i requisiti di qualità manca ancora la stesura di un manuale utente.
Inserire lo scenario principale, obbligatorio. Inserire il requisito di qualità sul manuale utente. Correggere i casi d’uso sintatticamente non conformi.
Definizione di Prodotto
Fig. 1: la componente “service” viene solitamente annoverata nel Model all’interno del pattern MVC. Il pattern Observer non è contestualizzato nello stesso modo nel quale lo sono gli altri pattern utilizzati. Bene l’inserimento nei diagrammi delle librerie esterne utilizzate. Sarebbe opportuno però evidenziarle con un colore differente. Bene la descrizione delle componenti di dettaglio. Nei diagrammi di sequenza sarebbe opportuno inserire anche i messaggi di ritorno in modo tale da facilitare il lettore nella comprensione del flusso delle informazioni. Inoltre, le descrizioni di questi diagrammi andrebbero estese. Bene il tracciamento.
Il documento ha forma corretta. Il contenuto ha discreto livello di dettaglio.
Verificare se sia possibile raggiungere un dettaglio maggiore per alcune, selezionate, componenti di dettaglio.
Piano di Progetto v2 Sul piano logico, l’analisi dei rischi (che voi trattate, bene, in §3) informa la pianificazione (che voi iniziate a trattare a monte, in §2) favorendo l’inclusio-
ne di attività di mitigazione o precauzioni. Valutate l’opportunità di inversione di contenuti, e di più stretto collegamento tra cause ed effetti.
§5: i dati di tabella 28 e quelli di tabella 30 non concordano con quelli di tabella 32. La presentazione dei dati di impegno inoltre non consente di determinare gli obiettivi delle ore di investimento, impedendo quindi di valutarne la congruità.
§6: come già segnalato in sede di RR, includere il consuntivo di periodo nel PdP serve essenzialmente a ragionare su come raffinare e correggere il preventivo del periodo rimanente (“preventivo a finire”), ciò che voi non fate.
Nel complesso, documento buono, ma con aspetti da rivedere.
Piano di Qualifica v2
§2: le scadenze temporali e le conseguenti esigenze di pianificazione attengono al PdP e non al PdQ.
§3: apprezzabile lo sforzo di specifica di obiettivi di qualità precisamente quantificati; discutibile invece e inefficace l’assenza di una loro distinzione tra quelli pertinenti alla qualità di processo e quelli alla qualità di prodotto. Di tali obiettivi dovrà essere fornita evidenza di verifica: ciò che voi fate,
ragionevolmente bene, in appendice.
§4: la specifica dei test deve includere anche quelli di (non-)regressione; è da presumere che essi non saranno altro che la ripetizione di specifici test (TU, TI) già previsti, ma questa logica (o altra eventuale) va esplicitamente prevista e dichiarata.
§5: il tracciamento è parte integrante della verifica; questi contenuti devono pertanto essere posti nella corrispondente appendice.
Documento con buoni miglioramenti, ma ulteriori spazio di miglioramento.
Glossario v2 Bene.
