Preparazione per la revisione del progetto iniziale della soluzione

Completato

In genere, condurre la revisione del progetto iniziale della soluzione richiede dalle due alle otto ore circa. Il tempo può variare in base al livello di dettaglio disponibile per la revisione e all'ampiezza della soluzione complessiva. L'architetto di soluzioni collaborerà con la dirigenza del team di implementazione per pianificare il workshop in base alle specifiche della soluzione che saranno oggetto di revisione.

Prima del workshop sulla revisione del progetto iniziale della soluzione, i partecipanti devono accertarsi di avere la massima familiarità possibile con la struttura del workshop e con i tipi di argomenti e i requisiti che saranno affrontati. L'architetto di soluzioni fornirà un ordine del giorno con argomenti e requisiti prima del workshop.

Nota

La revisione del progetto iniziale della soluzione è essenzialmente una discussione; non è concepita come un questionario che può essere completato ed esaminato offline. Sebbene i prerequisiti siano definiti e indicati in anticipo, non è possibile sintetizzare tutti gli argomenti a cui potrebbe condurre la conversazione.

L'architetto di soluzioni si preparerà in anticipo per il workshop esaminando prima gli artefatti del progetto esistenti. Ecco alcuni degli artefatti del progetto utili:

• Cataloghi dei processi: elenchi o gerarchie di processi, sottoprocessi e storie utente che rientrano nell'ambito dell'implementazione.
• Diagrammi di flusso dei processi: diagrammi che possono aggiungere contesto al catalogo dei processi e descrivere l'attività dell'azienda. Nella fase di revisione del progetto iniziale della soluzione, si rivelano molto utili i processi complessivi end-to-end.
• Diagrammi delle applicazioni: diagrammi a blocchi che mostrano i vari componenti della soluzione. Tali diagrammi possono anche fornire un contesto relativo al modo di mappare le funzionalità ai componenti dell'applicazione o al modo di interfacciarsi tra loro dei componenti dell'applicazione.
• Requisiti di scarto: aree di funzionalità note che non sono considerate supportate dal sistema standard.
• Diagrammi del flusso dei dati: in una soluzione con più app Dynamics 365 o servizi e componenti legacy ed esterni, è utile poter identificare l'origine dei dati e il modo in cui vengono spostati e usati nella soluzione.
• Strategia di migrazione dei dati: documenti o registri che riportano le entità da migrare, le fonti da cui proverranno, i volumi, i tempi e le modalità di migrazione. Nella fase di progettazione iniziale della soluzione, è fondamentale accertarsi di conoscerne l'ambito (tabelle e origini dati).
• Registro dell'interfaccia: elenchi di interfacce con requisiti non funzionali e modelli di progettazione che ne documentano l'ambito e l'approccio per l'implementazione.
• Progettazione dell'aggregazione dei dati analitici: diagrammi o registri di origini dati che verranno migrati per analisi aggregate.
• Strategia per gli ambienti: diagrammi a blocchi o di flusso che delineano i tipi di ambienti forniti, come e quando verranno usati e il flusso del codice e della configurazione attraverso di essi.
• Profili di utilizzo del sistema: pianificazioni dei processi operativi e picchi di volumi transazionali per tipo di carico di lavoro.
• Struttura della persona giuridica: diagrammi o registri che mostrano le persone giuridiche modellate nella soluzione e le loro relazioni reciproche.
• Posizioni della distribuzione: diagrammi o registri che indicano le posizioni fisiche in cui verrà distribuita la soluzione insieme ai requisiti di lingua e localizzazione.
• Carta del progetto: documento descrittivo del background del progetto, degli obiettivi e dei risultati chiave attesi, degli stakeholder, dei budget, delle tempistiche e dei traguardi.
• Piano/programmazione del progetto: documento o diagrammi di Gantt che descrivono la pianificazione generale e la dipendenza delle fasi chiave del progetto e delle attività associate.
• Matrice di assegnazione delle responsabilità: tabella delle attività e della relazione dei ruoli del progetto con tali attività. Queste relazioni sono in genere assegnate attraverso una classificazione RACI (responsabile, affidabile, consultiva e informata).
• Piano/strategia di test: documento che descrive i tipi di test eseguiti durante l'implementazione e come questi verranno definiti, implementati e misurati.

Questo non è un elenco esaustivo dei risultati finali del progetto, ma è un buon punto di partenza per il workshop sulla revisione del progetto iniziale della soluzione. I formati, la composizione e i nomi di ciascun documento possono variare da un progetto all'altro. Il componente più importante non è il formato; sono essenziali invece le informazioni disponibili e concordate con tutto il team.

Quando si conduce una revisione del progetto iniziale della soluzione all'inizio del progetto, molti di questi documenti non saranno del tutto sviluppati, il che è accettabile nella maggior parte dei casi. È più importante che sia stato definito l'ambito del progetto e che sia presente un piano concettuale che stabilisca in che modo la soluzione supporterà tale ambito. Se il piano non ha successo, questi elementi vanno indicati a un certo livello nella dichiarazione di lavoro fornita dal partner di consulenza che presta assistenza per l'implementazione. Se sono definiti l'ambito e l'approccio concettuale alla soluzione, la revisione del progetto iniziale della soluzione può concentrarsi sull'approccio concettuale e sul completamento, mentre i workshop più approfonditi potranno concentrarsi sui dettagli quando saranno disponibili.

È accettabile che il progetto usi diversi modi per gestire o tenere traccia delle informazioni sul progetto, differenti da quelli elencati in precedenza. In genere, il formato non è un aspetto critico, se le informazioni sono subito disponibili per i membri del progetto. Se le informazioni elencate in precedenza non sono documentate nel proprio progetto o se non sono documentate in modo tale da essere facilmente accessibili, è necessario dare la priorità alla produzione degli artefatti pertinenti.

Si consiglia di usare diagrammi e rappresentazioni visive per fornire riepiloghi complessivi nell'implementazione, ove possibile. Tali diagrammi e grafici forniscono un rapido mezzo di comunicazione su piani e progetti all'interno del team e con la dirigenza.

Nota

La revisione del progetto iniziale della soluzione non intende essere una revisione esaustiva dei requisiti dettagliati o dei documenti di progettazione. Il team di implementazione lavorerà con un minor livello di dettaglio per ricavare e presentare l'architettura complessiva. Il presupposto è che il team di implementazione evidenzierà i dubbi principali, mentre gli architetti di soluzioni indagheranno sulle potenziali aree problematiche. L'architetto di soluzioni suggerirà workshop approfonditi per esaminare le aree che richiedono un'ulteriore valutazione.