-
Notifications
You must be signed in to change notification settings - Fork 2
[GLOBAL] Esito RR - Sistemazioni da fare #222
Description
Esito RR
Documenti cruciali 🆘
- Piano di Progetto
- Norme di Progetto
Documenti meno cruciali 👎
- Piano di Qualità
- Analisi dei Requisiti
Documenti OK ✅
- Studio di fattibilità
- Glossario
Considerazioni generali
-
Lettera di presentazione: per convenzione, la prima comunicazione con la quale il fornitore candidato si presenta al committente include in allegato la propria composizione, corredata dei ruoli correnti.
-
Verbali: per la denominazione dei verbali sarà più utile includere la data (in formato AAAAMMGG) che il numero progressivo. Stupisce però che non si siano verificati incontri verbalizzabili più a ridosso della data di consegna in ingresso alla RR.
-
Registro delle modifiche: uno “scatto” di versione che consegua a un’azione di modifica prima della sua verifica di validità, innesca rischi di iterazione che contraddicono l’approccio incrementale che avete dichiarato di adottare.
-
Stile tipografico: le vocali accentate conservano l’accento anche al maiuscolo, che non viene sostituito dall’apostrofo.
-
Stile tipografico: vi è frequente inconsistenza nell’uso delle iniziali maiuscole, sia nei titoli delle parti del documento, che nel corpo del testo, segno di insufficiente attenzione di verifica.
-
Stile redazionale: evitate espressioni come “il fine di ... è quello di” (e similari), dove la parte in grassetto ridonda.
Documenti Interni
Studio di Fattibilità ✅
- Bene.
Norme di Progetto 🆘
- La struttura canonica del documento è: categoria di processi → processo specifico → suoi obiettivi (inclusi quelli qualitativi), attività, procedure e strumenti di supporto. Il vostro documento sembra intuirla, seguendola però lascamente e in modo diseguale, sia per categorizzazione (talvolta non conforme) che per nomenclatura, causando confusione informativa.
- La copertura dei processi di vostro interesse, pur se buona, è ancora insufficiente, e la loro attribuzione alle tre categorie principali non è completamente corretta.
- Le attività coinvolte dal processo di fornitura non sono identificate dai loro prodotti, e includono altro, per esempio i rapporti con il proponente.
- Tra i processi di supporto, considerate l’inclusione del processo di gestione dei cambiamenti, che sarà presto per voi essenziale per dare ordine alle attività correttive che conseguono alla rilevazione di un difetto da correggere. Rivedete al contempo le voci che non corrispondono a processi di quella categoria.
- I contenuti relativi alla normazione della progettazione sono particolarmente scarsi. Tale attività invece è di imminente attuazione e di elevata criticità. Pertanto, la sua trattazione non può essere rimandata oltre, per non incorrere in rischi importanti.
Nel complesso, il documento ha struttura non lontana dal desiderabile, ma contenuti ancora largamente inadeguati e insoddisfacenti. Valutate attentamente le segnalazioni, facendo le correzioni e integrazioni richieste / suggerite, ben prima del prossimo rilascio esterno del documento, per evitare di convivere a lungo con tali difetti.
Documenti esterni
Analisi dei Requisiti 👎
- Non è chiaro perché la versione approvata per il rilascio dal responsabile sia differente rispetto a quella consegnata.
- Fig. 2: un diagramma dei casi d’uso di per sé rappresenta un caso d’uso, e come tale necessita di descrizione.
- UC1.4: chi è l’attore principale di questo caso d’uso (dettaglio implementativo).
- UC1 non può essere presente nel proprio diagramma dei casi d’uso (problema riscontrato anche per altri casi d’uso).
- Fig. 6: non è possibile riportare casi d’uso così eterogenei in uno stesso diagramma dei casi d’uso. Quali pre- e post-condizioni varrebbero per tutti? (Problema comune anche ad altri casi d’uso.)
- UC2: quali informazioni sono riportate nelle dashboard?
- UC5.1, UC5.2, UC5.8, UC6.1, ecc....: quali informazioni sono visualizzate?
- UC6.5.3: individuare una gerarchia di casi d’uso.
- UC9: quali sono le operazioni messe sotto audit?
- UC1.4.2: chi è l’attore principale di questo caso d’uso (non è l’utente non autenticato)?
- UC16 la gerarchia individuata non porta valore aggiunto. UC16.2 l’inclusione non è corretta.
- La visualizzazione dei “messaggi di ritorno” è da modellare come un caso d’uso di visualizzazione.
- Nella tabella dei requisiti non è riportato a quale UC il requisito faccia riferimento, ma solo un generico “UC”.
- RAP-1 - 4 sono requisiti di vincolo.
- RAP-5 ed RAP-6: quale strategia di verifica prevedete per questi casi d’uso? Perché 7.5 sec.?
- RAQ-11 è un requisito di vincolo.
- Non prevedete alcun manuale come documentazione a corredo del prodotto?
- RAV-1 e sotto-casi sono funzionali.
- Rimuovere RA-V-7, RA-V-8, RA-V-9, RA-V-10.
Bene il tracciamento. Nel complesso, la profondità di analisi e la struttura del documento sono corrette. È però necessario correggere i numerosi errori di sintassi UML riscontrati, e approfondire ulteriormente l’analisi ove richiesto.
Piano di Progetto 🆘
- §2 - §A: bene aver provveduto ad arricchire l’analisi dei rischi con la sua attualizzazione (riscontro). Tenete presente che uno dei principali benefici di tale attualizzazione è il raffinamento dell’analisi e delle misure di mitigazione.
- §3: compito principale di ogni pianificazione aderente al modello di sviluppo incrementale, cui voi dichiarate di aderire, è specificare il numero e gli obiettivi degli incrementi previsti, ciò che voi invece omettete.
- §4: nonostante la intelligente scomposizione in periodi di breve durata, la pianificazione che proponente è di fatto determinata dalle revisioni di avanzamento, incrementale solo (e nel migliore dei casi) nella produzione dei documenti richiesti dal contratto. Perciò essa è del tutto incoerente con il modello di sviluppo incrementale che dichiarate, destituendo di fondamento sia la pianificazione temporale che il preventivo economico che presentate in §5. Entrambi vanno rivisti con la massima urgenza.
- §6: l’analisi dei dati di consuntivo relativi al periodo trascorso (da denominare “Consuntivo di periodo” fino a prima dell’ingresso in RA) deve alimentare una rivisitazione correttiva e migliorativa del piano delle attività future, con conseguente attualizzazione del preventivo a finire.
Nel complesso, il documento è professionale per struttura, ma ancora immaturo per contenuti, con il grave difetto concettuale sopra segnalato, la cui gravità richiede intervento urgente.
Piano di Qualifica 👎
-
Buono l’impianto del documento.
-
Occorre però cercare migliore correlazione tra i suoi contenuti e le Norme: a queste infatti attiene la scelta delle metriche di qualità adottate nel progetto e la presentazione degli strumenti di loro rilevazione e valutazione; a quelli invece la scelta dei valori obiettivi (soglie o intervalli).
-
§B: il resoconto delle attività di verifica deve riflettere tutte le metriche adottate, preferendo sempre presentazione “a cruscotto” a quella “a tabella”.
-
Vocabolario: redarre → redigere.
Nel complesso, il documento è apprezzabile per intenzioni e struttura, ma ha contenuto ancora carente. Per evitare di convivere a lungo con i difetti segnalati, sarà opportuno correggerli ben prima del prossimo rilascio pubblico del documento.
Glossario ✅
- Bene.