Glossario

Questo glossario elenca i dettagli (in modo casuale) di tutti i documenti consegnabili dal Elenco di controllo del progetto.

Accettazione da parte delle parti interessate

L'accettazione da parte delle parti interessate conferma che esse, in qualità di parti interessate chiave, sono allineate con la soluzione e hanno dato la loro approvazione su come i requisiti aziendali soddisfano il caso aziendale.

Prove di accettazione

Il test di accettazione viene eseguito quando un'applicazione è pronta per la produzione. I test vengono eseguiti da un gruppo che rappresenta i vari tipi di utenti finali, utilizzando scenari reali.

Le prove di accettazione vengono utilizzate per confermare che:

• Project soddisfa i requisiti del cliente.
• La soluzione è adatta allo scopo.
• Gli utenti accettano la soluzione e possono immaginare di lavorare con essa.
• Il cliente accetta il progetto.

Prima pianifichi e progetti i test di accettazione, più facile sarà l'implementazione finale. Devono essere definiti insieme al cliente e al team di Quality Assurance.

Sebbene non sia possibile definire tutti i dettagli all'inizio del progetto, le definizioni iniziali dovrebbero essere discusse e concordate. I test di accettazione saranno probabilmente basati sui requisiti fondamentali (funzionali e di prestazioni).

Accesso al sistema di test coordinato

Assicurati che a tutti i ruoli siano stati assegnati i livelli richiesti di accesso al sistema.

Elenco di controllo della sicurezza di Adobe

La Elenco di controllo della sicurezza di Adobe è la checklist ufficiale fornita per garantire che AEM sia sicuro al momento dell’installazione. Contiene le misure di sicurezza e i passaggi di verifica necessari per garantire l’integrità dell’istanza.

Configurazione del progetto del portale di supporto Adobe

L'Adobe Support Portal consente ai partner e ai clienti di implementazione di impostare l'implementazione AEM come progetto nel portale di supporto.

I dettagli possono essere registrati; ad esempio, informazioni sulle tecnologie e sulle versioni implementate. Ciò garantisce la trasparenza tra il cliente e l'Adobe.

Formazione per l'amministratore AEM

Formazione del personale amministrativo della soluzione. Consulta la sezione Servizi di formazione Adobe per ulteriori informazioni.

Formazione sull’authoring di AEM

Formazione per il personale che produrrà (authoring) contenuti per la soluzione. Consulta la sezione Servizi di formazione Adobe per ulteriori informazioni.

Esame di certificazione AEM

Assicurati che la persona appropriata sia registrata per prendere il pertinente esami di certificazione.

AEM certificato

Assicurati che la persona appropriata abbia superato il esami di certificazione.

Formazione tecnica AEM

Fornire una formazione tecnica per l'utente interessato; ad esempio, sviluppatori, architetti, ingegneri e professionisti del business.

Accordo sui KPI definiti come obiettivi del progetto

Gli indicatori prestazioni chiave (KPI, Key Performance Indicators) consentono a un'organizzazione di definire e misurare i progressi verso obiettivi e obiettivi organizzativi. Una volta che un'organizzazione ha analizzato la sua missione e definito i suoi obiettivi, deve misurare i progressi verso tali obiettivi. I KPI forniscono un meccanismo di misurazione.

Allinea KPI (Key Performance Indicator) per Business e Performance

L’allineamento dei KPI (Key Performance Indicators) aziendali e delle prestazioni consente di riunire tutte le persone e i processi coinvolti dall’interno dell’organizzazione. Ciò contribuisce a ridurre il tempo e lo sforzo necessari per raggiungere gli obiettivi aziendali e raggiungere lo scopo proposto.

Allineamento dell’architettura dei contenuti con i KPI

Assicurati che l’architettura dei contenuti proposta sia allineata con gli indicatori prestazioni chiave (KPI, Key Performance Indicators) pertinenti.

Allineamento della Roadmap dei clienti con la Timeline del progetto

Il Customer Roadmap è composto da tappe e obiettivi aziendali di alto livello. La Timeline del progetto deve aderire e allinearsi a questa strategia, in modo che tutti i rischi potenziali e/o eventuali deviazioni debbano essere evidenziati e monitorati.

Definizione dell'architettura applicativa

La architettura dell'applicazione definire chiaramente il comportamento delle domande proposte.

Si concentra su:

• Come interagiranno tra loro e con gli utenti.
• I dati da consumare e produrre dalle applicazioni, anziché la loro struttura interna.

Attività di manutenzione specifiche dell'applicazione definite

Oltre alle normali attività di manutenzione di Adobe Experience Manager (AEM), è necessario definire tutte le altre attività operative da eseguire per la manutenzione continua della soluzione.

Personale adeguatamente formato

Assicurati che il tuo team sia composto da personale con la formazione appropriata. Per i team di progetto, la raccomandazione deve avere tutti i seguenti elementi:

• almeno uno sviluppatore lead certificato AEM

• almeno un architetto certificato AEM

• almeno il 75% dei tuoi sviluppatori AEM certificati;

  questo consente agli sviluppatori certificati di guidare gli sviluppatori junior e garantisce la condivisione delle conoscenze e la trasparenza

Diagramma dell'architettura

Il diagramma dell'architettura è una rappresentazione grafica dell'architettura. Comprende la rappresentazione di:

• i concetti
• i principi
• elementi e componenti che fanno parte dell’architettura

Bozza di architettura

Questo offre una visione di alto livello del sistema e dell'architettura della soluzione. In questa fase si tratta di un progetto che sarà riesaminato e perfezionato in fasi successive.

Disattivazione della bacheca di revisione dell'architettura

Il consiglio di revisione dell'architettura è un organismo interorganizzativo che:

• supervisiona l'attuazione di una strategia coerente
• garantisce la conformità ai sistemi

Il comitato di revisione dovrebbe essere rappresentativo di tutte le principali parti interessate coinvolte nell'architettura. In genere si tratta di un gruppo di dirigenti responsabili della revisione e della manutenzione dell'architettura generale.

Suite di test automatizzata adattata per contenuti e risultati reali rispetto ai KPI

Script di automazione e casi di utilizzo automatizzati di base:

• adattato al contenuto produttivo
• confrontati con i KPI

Strategia di test automatizzato

Questa strategia definisce un framework per gli script automatizzati riutilizzabili, insieme all'approccio pianificato dal team Quality Assurance (QA). Illustra il piano generale di test di automazione per garantire:

• un maggiore ritorno sull'investimento (ROI)
• maggiore copertura dei test
• maggiore affidabilità del test con ripetizione di qualità

Strategia di test automatizzato convalidata in base a carico realistico e previsto

La strategia di test automatizzato deve essere convalidata e regolata in base al contenuto e al carico previsto che sarà sulla soluzione.

Strategia di automazione

L’automazione delle implementazioni assicura distribuzioni più veloci e coerenti. La strategia di automazione delinea la configurazione di tali meccanismi di automazione; compresi:

• frequenza
• attrezzature da utilizzare
• ambienti da distribuire in

Piano di comunicazione

L’intero team del progetto e tutti gli interessati devono confermare di essere a conoscenza di quanto segue:

• struttura di reporting
• cadenza delle relazioni
• canali di comunicazione

Consapevole delle definizioni di successo e dei criteri

L’intero team del progetto e tutti gli interessati devono confermare di essere a conoscenza di quanto segue:

• definizioni di successo
• criteri di successo

Concetto di backup e ripristino

Il concetto di backup e ripristino delinea le funzionalità tecniche che verranno implementate nella soluzione. È richiesto dalla politica aziendale di backup e ripristino.

Test di backup e ripristino

Test completo basato sul concetto di backup e ripristino.

Business case

Un documento relativo a un business case presenta gli argomenti relativi all’adozione dell’azione, all’adozione di azioni alternative (se disponibili) o al mancato intervento. Gli argomenti dovrebbero essere equilibrati, basati su fatti concreti (laddove possibile/pertinente) e mettere in evidenza sia i benefici che i rischi per tutti i casi.

Un documento di business case dovrebbe essere una chiara definizione di tutte le opzioni, concludendo con un argomento convincente per l'attuazione della soluzione proposta.

Business Analyst Comprende l'ambito del progetto e le aspettative

L'analista aziendale deve confermare di aver compreso appieno:

• la portata del progetto
• tutte le aspettative dei clienti
• che questa è la base per tutte le decisioni prese per persona, per ogni fase del progetto

KPI aziendali

Le organizzazioni utilizzano indicatori di prestazioni chiave (KPI, Key Performance Indicators) per valutare il loro successo nel raggiungimento degli obiettivi.

I KPI aziendali definiscono valori misurabili che mostrano l’efficacia con cui un’azienda sta raggiungendo gli obiettivi aziendali chiave. È importante scegliere KPI appropriati per la tua attività/scenario con definizioni chiare di cosa sono, come verranno misurati, come verranno utilizzati e da chi.

Documentazione sui requisiti aziendali

Un documento sui requisiti aziendali (BRD) descrive in dettaglio la soluzione aziendale per un progetto, fornendo una specifica chiara delle esigenze e delle aspettative aziendali del cliente. Il BRD distingue anche tra la soluzione aziendale e la soluzione tecnica.

Nell'esaminare la soluzione commerciale, il BRD dovrebbe rispondere alla domanda: "Cosa vuole fare l'azienda?"

Disattivazione dell'attività su qualsiasi adeguamento necessario alla soluzione o all'architettura identificata e allineata in base alle aspettative sul ROI e sui KPI

I processi di valutazione dei rischi e test di penetrazione possono produrre problemi e risultati che devono essere affrontati nell'architettura o nello sviluppo della soluzione.

Gli eventuali adeguamenti derivanti da tali processi devono essere rivisti e approvati dall'azienda e valutati in base agli obiettivi generali.

Strategia di memorizzazione nella cache

La strategia di memorizzazione in cache delinea cosa verrà memorizzato nella cache per l’utente finale. Deve essere conforme ai KPI delle prestazioni.

Ad esempio, elementi come immagini, javascript e altri file server possono essere memorizzati nella cache per migliorare le prestazioni di una soluzione.

Linee guida sulla codifica

Le linee guida sulla codifica definiscono i principi di base a cui gli sviluppatori devono attenersi durante lo sviluppo della soluzione. Tra questi figurano, tra l'altro:

• convenzioni di denominazione
• utilizzo del servizio
• utilizzo della libreria

Manuale delle operazioni di comunicazione

Assicurati che tutti i ruoli/persone appropriati abbiano ricevuto il Manuale delle Operazioni.

Rapporto sul test delle prestazioni della comunicazione

Assicurati che tutti i ruoli/persone appropriati abbiano ricevuto il rapporto di test delle prestazioni.

Comunicare le note sulla versione

Assicurati che tutte le persone/ruoli appropriati abbiano ricevuto le Note sulla versione.

Comunicare Ambito e aspettative al team

Assicurati che il team del progetto sia pienamente consapevole e allineato con l’ambito del progetto e le aspettative di consegna.

Comunicare i materiali di formazione e le guide utente

Assicurati che tutti i ruoli/persone appropriati ricevano il materiale di formazione e le guide utente.

Conformità ai requisiti di sicurezza del cliente

Assicurati che siano presenti tutti i requisiti di sicurezza del cliente.

Conformità al concetto di sicurezza

Assicurati che il concetto di sicurezza sia attivo.

Concetto di relazione per i componenti e i modelli

Struttura dei modelli e dei componenti che verranno utilizzati nella nuova applicazione. Include dettagli quali regole di ereditarietà, autorizzazioni e relazioni, tra gli altri.

Specifiche di relazione per i componenti e i modelli

Descrizione dettagliata del concetto di relazione tra componenti e modelli.

Specifiche dei componenti

Dettagli delle specifiche per ciascuno dei componenti da implementare.

Concetto per la simulazione di interfacce esterne

Concetto di come sviluppare e testare interfacce esterne che potrebbero non essere aperte/disponibili per gli ambienti di sviluppo o di test.

Pianifica/implementa modelli di queste interfacce per garantire che i test siano il più vicino possibile a un comportamento simile alla produzione.

Documento sull’architettura dei contenuti

Documentazione dell'architettura proposta del contenuto. I dettagli dovrebbero includere, tra l'altro:

• struttura contenuto
• assegnazione di tag ai concetti
• strategie per il riutilizzo dei contenuti

Contenuto convalidato per la migrazione

Il contenuto di sistema legacy viene rivisto e il contenuto selezionato viene convalidato per la migrazione alla nuova soluzione.

Progetto di contratto

Una prima bozza del contratto giuridico.

Struttura e formato dei contenuti correnti

Documentazione dell'architettura e del formato dei contenuti correnti. Verrà utilizzato per generare la futura architettura dei contenuti. Sarà utilizzato anche per il concetto di migrazione.

Criteri di backup e ripristino del cliente

Politiche del cliente riguardanti:

• processi di backup sia per i dati che per la soluzione
• archiviazione del backup
• conferma del funzionamento previsto del backup
• ripristino in caso di guasto

Linee guida sulla codifica dei clienti

Linee guida/requisiti del cliente su come si dovrebbe procedere allo sviluppo.

Criteri di distribuzione/rilascio dei clienti

Criteri del cliente che definiscono come e quando è possibile effettuare distribuzioni/release.

Questi includono spesso le timeline, i requisiti di pianificazione e di cancellazione.

Criteri o requisiti per il monitoraggio dei clienti

Criteri e requisiti del cliente su ciò che deve essere monitorato. Si tratta di raccomandazioni oltre a quelle specificate nel concetto di monitoraggio.

Pianificazione del rilascio della produzione dei clienti

La pianificazione definita dal cliente per le versioni negli ambienti di produzione.

Criteri e requisiti per la generazione di rapporti sui clienti

Eventuali criteri e/o requisiti che il cliente ha in relazione alla segnalazione. Questi possono includere:

• con quale frequenza devono essere presentati i rapporti specifici
• il formato per report specifici
• requisiti speciali

Roadmap dei clienti

Formulare una tabella di marcia delle principali tappe da attuare, sia sul piano tecnologico che su quello aziendale. Questa roadmap viene quindi comunicata al cliente.

Criteri di sicurezza del cliente

Il cliente (business e IT) avrà politiche che definiscono i livelli di sicurezza richiesti per la soluzione. Questi possono includere:

• Requisiti per il passaggio a una valutazione del rischio.
• Requisiti per le prove di penetrazione passante.
• eventuali requisiti di sicurezza specifici; come l’escape di tutti i campi di input, l’utilizzo della crittografia (SSL), i certificati e l’autenticazione e la sessione.

Linee guida sulle specifiche del cliente

Tutte le linee guida del cliente relative al formato, alla consegna e all'approvazione delle specifiche.

Rapporti sui test dei clienti

Rapporti dal cliente al lead di qualità durante il periodo del test di accettazione utente (UAT, User Acceptance Test).

Personalizzazioni e Hotfix che influiscono sugli aggiornamenti documentati

Eventuali personalizzazioni e/o hotfix applicati devono essere documentati in quanto possono influenzare gli aggiornamenti futuri:

• AEM può essere personalizzato in base alle esigenze aziendali. Tutte le personalizzazioni che possono influenzare l’aggiornamento devono essere documentate in modo completo. Ad esempio, eventuali modifiche principali all’interfaccia utente di AEM.

• Tutti gli aggiornamenti necessari per la soluzione corrente devono essere documentati in modo completo; possono includere:

  • cumulative fix pack (CFP)
  • Service Pack (SP)
  • hotfix
  • upgrade

Rapporto sul test giornaliero di accettazione degli utenti

Rapporti o riunioni risultanti dal test di accettazione degli utenti (UAT). Essi dovrebbero precisare:

• le emissioni segnalate
• definizione delle priorità di tali questioni

Protezione predefinita attivata

Assicurati che le impostazioni di protezione predefinite per AEM siano state abilitate/implementate.

Criteri e processi di distribuzione/rilascio

Criteri formali relativi alla distribuzione e alle versioni del progetto. Questi possono includere:

• tempo di rilascio
• pianificazione delle vacanze
• frequenza
• e può dipendere dall'ambiente in questione

Cadenza della distribuzione stabilita

Definisci la frequenza richiesta per le distribuzioni in ambienti diversi.

Metodologia di sviluppo

Una metodologia di sviluppo del software comporta l'interruzione dell'intero processo di sviluppo del software in fasi distinte (o fasi), ciascuna con attività distinte. L'obiettivo è migliorare la pianificazione e la gestione.

Quando definisci la metodologia, devi predefinire specifici risultati finali e artefatti creati e completati dal team di progetto per sviluppare o mantenere l’applicazione.

Definizione del ruolo di sviluppo

Definire lo sviluppatore e/o il ruolo che esegue i test IT (prestazioni o altro) e/o di unità all'interno della soluzione.

Ambiente di sviluppo pronto

Assicurati che l’ambiente di sviluppo sia configurato con gli strumenti integrati necessari per l’automazione delle distribuzioni.

Il team per lo sviluppo capisce l'ambito del progetto e le aspettative

Il team di sviluppo deve confermare di aver compreso appieno:

• la portata del progetto
• tutte le aspettative dei clienti
• che questa è la base per tutte le decisioni prese per persona, per ogni fase del progetto

Specifiche delle finestre di dialogo

Dettagli sulle finestre di dialogo necessarie per la soluzione.

Impostazione dell'ambiente di sviluppo documenti

Documentazione dell'ambiente di sviluppo.

Impostazione dell’ambiente di produzione dei documenti

Documentazione dell'ambiente di produzione.

Impostazione dell’ambiente di test del documento

Documentazione dell’ambiente di test.

Test di durevolezza

Il test di resistenza mostra le prestazioni della soluzione sotto un carico specifico. I test misurano per quanto tempo la soluzione sopravvive quando viene sottoposta al carico limite e a quali livelli di prestazioni.

Test di durevolezza eseguito

Esecuzione delle prove di resistenza.

Concetto di gestione degli errori

La gestione degli errori si riferisce all’anticipazione, al rilevamento e alla risoluzione degli errori di programmazione, applicazione e comunicazione.

Documentazione sulla gestione degli errori

Documentazione dettagliata della gestione degli errori proposta, basata sul concetto di gestione degli errori.

Processi di scalabilità

Definizione di tutti i processi di escalation. Per ciascun livello di progetto saranno disponibili processi separati:

• Team di progetto
• Cliente
• Adobe

Stabilire sessioni regolari di revisione della qualità

Organizzare regolarmente riunioni di valutazione della qualità con i membri del team appropriati.

Struttura delle autorizzazioni esistenti

Documentazione dell'insieme esistente di autorizzazioni e gruppi definiti per la soluzione legacy o all'interno dell'organizzazione.

Mappa dei sistemi esistenti

Diagramma (o insieme di diagrammi) dei sistemi e delle dipendenze esistenti.

Definizioni e criteri di successo previsti

Lo sponsor del progetto raccoglie le aspettative aziendali relative al successo del progetto. È importante che all'inizio di un progetto siano disponibili tutte le aspettative, poiché queste dovrebbero influenzare tutte le decisioni prese durante l'attuazione.

Le aspettative possono includere:

• KPI specifici, ad esempio l’aumento percentuale delle pagine servite
• tempo di pubblicazione dei contenuti inferiore
• obiettivi di livello superiore, ad esempio un'interfaccia di facile utilizzo

Requisiti di Experience Design

Requisiti per l'intera esperienza della soluzione. Questo copre fattori come la personalizzazione, la persistenza tra dispositivi e l’esperienza degli utenti, tra gli altri.

Specifiche esperienza

Dettagli sui requisiti di progettazione delle esperienze.

Sistema esterno e dipendenze utente/contesto di sistema

Un diagramma (o insieme di diagrammi) che delinea l'intero ecosistema della soluzione. Ciò dovrebbe includere elementi quali le integrazioni esterne, le interfacce, le dipendenze e le reti.

Sistema e procedura di fallback

Definizione del sistema di fallback:

• le funzionalità business critical che devono continuare a funzionare in caso di guasto critico
• i processi necessari in caso di fallback

Sistema di fallback e procedura testata

Test end-to-end del sistema di fallback.

Disattivazione del sistema di fallback dalle parti interessate

Disattivare il sistema di fallback e le relative procedure per garantire le funzionalità aziendali critiche.

Conferma di fattibilità sui KPI

Risultati di uno studio di fattibilità per la progettazione di soluzioni sia AEM che ad alto livello. Questi devono essere misurati in base ai KPI per garantire che possano essere soddisfatti.

Contratto finito

Prima di procedere con il progetto è necessario un contratto concluso e firmato. Questo si basa sul Progetto di contratto.

Funzionalità della soluzione accettata dalle parti interessate

Conferma che le parti interessate accettano pienamente:

• funzionalità della soluzione
• eventuali problemi noti nella soluzione

Vai alla programmazione in tempo reale

Timeline e pianificazione delle attività necessarie per:

• preparazione per andare in diretta
• l'effettivo andare in diretta

Percorsi felici definiti

Un percorso felice è uno scenario predefinito senza condizioni eccezionali o di errore. È composto dalla sequenza di attività eseguite quando tutto va come previsto.

Stime hardware

Stime iniziali di:

• l'hardware necessario per l'installazione AEM di base
• eventuali requisiti aggiuntivi, basati sulla progettazione di soluzioni di alto livello

Hardware disponibile per soddisfare i requisiti

Conferma che tutti gli ambienti dispongono dell’hardware minimo richiesto.

Requisiti di alto livello

La definizione dei requisiti di alto livello fornisce una ripartizione generalizzata dei requisiti del sistema, che comprende aspetti quali:

• Processi aziendali
• Funzioni principali del sistema

I dettagli di base su queste funzioni sono generalmente noti, pertanto questo documento non deve essere una stima.

Progettazione di soluzioni di alto livello

Il design della soluzione di alto livello spiega l'architettura che verrà utilizzata per lo sviluppo della soluzione. Il diagramma dell'architettura fornisce una panoramica dell'intero sistema, identificando i componenti principali che verranno sviluppati per il prodotto e le relative interfacce.

Mappa di sistema di alto livello

Questa mappa del sistema dovrebbe fornire un diagramma di livello molto elevato del sistema. Si differenzia dal contesto della soluzione in quanto è una mappa generalizzata di tutti i sistemi coinvolti, non ci sono interfacce in questo diagramma.

Struttura dei contenuti storici

Definizione della struttura dei contenuti del sistema legacy. Questo viene utilizzato come riferimento e anche nella preparazione della strategia di migrazione.

KPI per prestazioni storiche e prestazioni storiche

È necessario raccogliere e documentare statistiche sulle prestazioni e KPI delle prestazioni dal sistema legacy. Questi vengono poi utilizzati come punto di riferimento e per l'analisi comparativa della nuova soluzione.

Identificare le soluzioni/funzionalità principali

Elenco delle funzionalità aziendali critiche.

Implementazione: modifiche basate sui risultati dei test di penetrazione

Implementazione di tutte le modifiche necessarie (che sono state firmate) alla soluzione in base ai risultati dei test di penetrazione.

Implementazione - Strategia di test automatizzata

Configurazione degli strumenti e dei processi necessari per supportare i test automatizzati.

Implementazione - Strategia di automazione

Configurazione del set di utensili e dei processi necessari per supportare l'automazione.

Implementazione - Architettura dei contenuti

Implementazione dell’architettura dei contenuti, dei concetti di assegnazione tag e del riutilizzo dei contenuti.

Implementazione - Progettazione esperienza

Implementazione dei requisiti per supportare Experience Design.

Implementazione - Sistema e procedure di fallback

Attuazione del sistema di fallback e delle relative procedure.

Implementazione - Integrazione

Implementazione di integrazioni con tutti i sistemi esterni richiesti.

Implementazione - Strategia di migrazione

Migrazione e convalida di contenuti e altri artefatti per la nuova soluzione.

Implementazione - Ruoli e diritti

Implementazione di ruoli e diritti, utenti e gruppi.

Implementazione - Concetto di sicurezza

Implementazione di tutte le misure di sicurezza, compresi i default AEM.

Implementazione - Software di sicurezza

Implementazione della sicurezza dell'applicazione software.

Implementazione - Concetto di sicurezza dell'architettura di sistema

Implementazione della sicurezza del sistema.

Implementazione - Gestione URL

Implementazione del concetto di gestione degli URL.

Implementazione - Flussi di lavoro

Implementazione dei flussi di lavoro progettati.

Concetto di implementazione

Il concetto di attuazione fornisce i principi guida per l'intera attuazione. Esso dovrebbe tener conto:

• Operazioni
• Manutenzione
• Compatibilità
• Riutilizzabilità
• Sicurezza
• Scalabilità

Questo concetto può anche definire i framework, le librerie e altri artefatti utilizzati nella soluzione.

Informazioni sul supporto di Adobe per la pianificazione Go Live

Contatta il Supporto Adobe per assicurarti che tutto il supporto necessario possa essere attivato durante il go live.

Progettazione esperienza iniziale

Concetti preliminari per i progetti delle esperienze.

Test di integrazione

Test e la conseguente conferma di tutte le integrazioni, sia interne che esterne.

Questo dovrebbe essere automatizzato ed eseguito frequentemente per garantire la stabilità del sistema.

Processo di tracciamento dei problemi

I processi chiari registrano tutti i problemi riscontrati e tengono traccia delle attività in corso allo scopo di garantire che tutti i problemi siano risolti.

Sistema e processi di tracciamento dei problemi

Un sistema di tracciamento, unitamente ai processi richiesti, per registrare tutti i problemi riscontrati e monitorare le attività in corso allo scopo di garantire che tutti i problemi siano risolti.

Tutte le parti interessate del progetto dovrebbero avere accesso per facilitare la trasparenza dello stato del progetto.

Ne sono esempi Atlassian JIRA e HP Quality Centre.

Il processo del sistema di tracciamento dei problemi è configurato e integrato

Lo strumento selezionato è completamente integrato e l'accesso è concesso a tutti i ruoli richiesti.

Sistema legacy

Per il progetto, il sistema legacy è la tecnologia, il sistema informatico o il programma applicativo esistenti che verranno sostituiti dalla nuova soluzione.

I dettagli del sistema legacy devono essere raccolti in modo da sapere cosa può essere ritirato, quando e l'impatto su qualsiasi altro sistema.

Elenco degli strumenti di sviluppo da utilizzare

Una descrizione degli strumenti che saranno utilizzati nell'attuazione; gli strumenti dovrebbero comprendere:

• strumenti di documentazione
• strumenti di tracciamento dei problemi
• strumenti di distribuzione
• strumenti di creazione

Elenco di utenti che richiedono l’accesso al portale di supporto Adobe

Elenco di tutti gli utenti e i ruoli che dovranno accedere al portale di supporto Adobe.

L'elenco è normalmente composto dal Solution Architect e/o dal personale IT del cliente.

Analisi dei file di registro

Un’analisi, insieme ai consigli risultanti, che definisce cosa deve essere registrato per monitorare la soluzione:

• attività da registrare
• livello di granularità
• informazioni registrate per ogni attività

Attività di manutenzione (AEM specifiche) testate e abilitate

Testare e attivare attività di manutenzione AEM quali:

• compattazione
• pulizia del sistema
• pulizia del flusso di lavoro

Piano di migrazione

documentare la migrazione; compreso

• timeline della migrazione
• piano di manutenzione dei contenuti, in base alla strategia di migrazione

Strategia di migrazione

Una descrizione completa dei contenuti, dell’architettura dei contenuti e dei formati esistenti mappati alla nuova soluzione. Esso dovrebbe riguardare:

• dettagli tecnici della migrazione automatizzata, se possibile
• test di fumo da eseguire dopo la migrazione, per convalidare il contenuto migrato

Dovrebbe inoltre raccomandare come mantenere i contenuti aggiornati (o il più aggiornato possibile) durante il periodo tra la migrazione e l’effettivo funzionamento del nuovo sistema. Ciò potrebbe significare il blocco dei contenuti, la doppia pubblicazione o la manutenzione di un sistema alfa.

Monitoraggio - CPU

Monitoraggio dell'utilizzo della CPU del sistema da parte della soluzione:

• media
• picchi

Monitoraggio - I/O disco

Monitoraggio delle velocità di ingresso e uscita del disco della soluzione:

• media
• picchi

Monitoraggio - Spazio su disco

Monitoraggio dell'utilizzo dello spazio su disco da parte della soluzione:

• media
• crescita nel tempo

Controlla l'utilizzo di:

• archivio
• file di registro

Monitoraggio - Sistemi esterni

Monitorare le connessioni tra la soluzione e i sistemi esterni:

• tasso di traffico
• picchi
• stabilità

Monitoraggio - Larghezza di banda della rete

Monitorare l'utilizzo della larghezza di banda della soluzione:

• tasso medio di traffico
• picchi
• stabilità

Monitoraggio - Richieste

Monitora le richieste effettuate alla soluzione.

Monitoraggio - Punti di sicurezza

Monitora i punti di sicurezza definiti.

Monitoraggio - Sistema

monitorare l'intero sistema; ad esempio:

• disponibilità
• prestazioni medie
• picchi di prestazioni
• avvisi

Monitoraggio - Soglia e intervento

Monitoraggio della soglia definita della soluzione e attuazione delle misure di intervento per ridurre il carico.

Concetto di monitoraggio

Concetti di monitoraggio da applicare alla soluzione; incorporante:

• Monitoraggio standard AEM
• monitoraggio del sistema
• requisiti di monitoraggio specifici per i clienti

Monitoraggio dei punti deboli potenziali

Devono essere identificati e definiti punti specifici che potrebbero essere suscettibili di errori. Occorre inoltre definire i compiti di controllo connessi a tali compiti.

Gli esempi includono (tra gli altri):

• flussi di lavoro chiave
• elaborazione delle transazioni
• punti di integrazione

Criteri di monitoraggio comunicati al tecnico del sistema

Assicurati che i tecnici del sistema e il personale operativo conoscano e comprendano le politiche di monitoraggio.

Monitoraggio dei report - Struttura in corso

Definisci:

• quando è necessario generare relazioni di monitoraggio
• a cui devono essere consegnati

Documentazione sulle attività operative

Tutti i compiti operativi documentati, con la loro frequenza definita.

Manuale operativo

Manuale che fornisce tutte le informazioni necessarie per il buon funzionamento e la manutenzione della soluzione:

• tutte le attività operative
• contatti chiave
• piani di distribuzione
• liste di controllo pre/post-distribuzione
• qualsiasi altra attività critica

Dovrebbe inoltre illustrare in dettaglio i concetti di attuazione per:

• soddisfare i KPI di prestazioni
• scalabilità della soluzione per continuare a soddisfare tali KPI

Pacchetto preparato

Pacchetto software generato e consegnato pronto per la distribuzione.

Test di penetrazione

Un test di penetrazione (noto informalmente come test a penna) è un attacco a un sistema informatico che cerca carenze di sicurezza, potenzialmente ottenendo l'accesso alle caratteristiche e ai dati del computer.

Test di penetrazione - Superato

Vengono passati tutti i criteri richiesti.

Test di penetrazione - Risultati

Report creati per l'azienda che spiega i risultati del test di penetrazione.

Concetto di prestazioni e scalabilità

Documento concettuale su come garantire che l’implementazione soddisfi i KPI delle prestazioni e su come scalare la soluzione in modo che continui a soddisfare tali KPI.

Benchmark delle prestazioni

Il parametro Performance Benchmark viene utilizzato per definire test delle prestazioni, test di durata e monitoraggio. A tal fine, valuta le caratteristiche prestazionali della soluzione e dell'hardware di sistema.

KPI delle prestazioni

Definiscono gli indicatori prestazioni chiave (KPI, Key Performance Indicators) necessari per misurare le prestazioni del sistema. Alcuni esempi includono il tempo di caricamento della pagina, il tempo di risposta del server e le prestazioni della query del database.

Test delle prestazioni - Report

Report creati per l'attività, che descrivono i risultati dei test delle prestazioni.

Test delle prestazioni - Risultati e prestazioni dei KPI

I risultati devono corrispondere ai KPI definiti e alle aspettative in termini di prestazioni.

Concetto di test basato su Persona

Il test basato su Persona è un metodo basato sui diversi utenti tipo descritti nei progetti di esperienza. Inoltre, verifica gli account e i relativi livelli di autorizzazioni.

Questo viene spesso utilizzato nel test di accettazione utente (UAT, User Acceptance Testing).

POC Testato e verificato rispetto alla documentazione sui requisiti

La prova del concetto (POC) è valutata rispetto ai requisiti per garantire che entrambi siano allineati.

Elenco di controllo post-distribuzione

Elenco di controllo per definire la serie di controlli e attività da eseguire dopo ogni distribuzione.

Lista di controllo pre-distribuzione

Elenco di controllo per definire la serie di controlli e attività da eseguire prima di ogni distribuzione.

Test delle prestazioni della linea di base dell'ambiente di produzione

In genere, si esegue un test della linea di base su un’installazione standard di AEM. Viene quindi utilizzato come punto di riferimento per testare l’implementazione e l’hardware.

Ambiente di produzione pronto

Verifica che l’ambiente di produzione sia pronto, con implementazioni automatizzate.

Disattivazione della produzione dalle parti interessate

Prima di passare dal vivo all’ambiente di produzione, è necessario concedere l’autorizzazione alla produzione (PSO). Questo è il risultato di una revisione del rilascio che andrà in produzione, insieme a eventuali problemi noti. La disattivazione viene fornita come parte della pianificazione Go Live.

Processo e criteri di Disattivazione produzione

Il criterio e il processo necessari per ottenere il Disegno di produzione prima di spostare il pacchetto nell’ambiente di produzione.

Piano di comunicazione del progetto

Definire il piano di comunicazione sia per i soggetti interessati aziendali che per il team del progetto.

Sforzi Di Progetto - Stime Finali

La stime iniziali sono stati di alto livello e sono stati realizzati in base ai requisiti di alto livello per l'attuazione.

Questi sono ora rivisti, perfezionati ed ampliati per fornire le stime finali. Le stime dovrebbero essere fornite da ciascun responsabile del progetto, compresi la gestione del progetto, la consulenza, l'architettura, i test e lo sviluppo.

Queste stime vengono utilizzate per le risorse e il budget.

Sforzi Per I Progetti - Stime Iniziali

Le stime iniziali sono di alto livello e sono effettuate in base ai requisiti di alto livello per l'attuazione. Questo aspetto sarà riesaminato e perfezionato in fasi successive.

Organizzazione del progetto

La documentazione necessaria per delineare la struttura organizzativa e di reporting del progetto e del team.

Spesso assume la forma o include un grafico per presentare una panoramica visiva delle timeline e delle responsabilità. Ci sono molti strumenti disponibili per aiutare a questo.

Documento ambito progetto

Il documento di ambito del progetto richiede di identificare e documentare un elenco di:

• Obiettivi specifici del progetto
• Risultati finali
• Funzioni
• Funzioni
• Attività
• Termini
• Sforzo pianificato

Esso copre quanto deve essere realizzato, unitamente al lavoro da svolgere, per realizzare il progetto

Report sullo stato del progetto in una cadenza definita

Rapporti sullo stato del progetto consegnati in base al programma concordato e con il formato richiesto.

Prova del concetto (POC)

La prova del concetto (POC) implementa una gamma limitata di funzioni per la soluzione.

L'obiettivo dovrebbe essere quello di dimostrare la fattibilità della soluzione, verificare che possa soddisfare lo scopo richiesto e dimostrare che esiste il potenziale del suo utilizzo.

Regole di eliminazione

AEM gestisce più versioni di risorse e contenuti. Le regole di eliminazione sono progettate e configurate per rimuovere periodicamente le versioni precedenti al fine di mantenere lo stato e le dimensioni dell’archivio.

Formato rapporto qualità e cadenza

Definisci il contenuto e il formato richiesti del rapporto sulla qualità, nonché la frequenza con cui deve essere consegnato.

Rilascia coordinato

Il project manager coordina tutti i ruoli necessari per il rilascio in produzione.

Note sulla versione

Le note sulla versione fanno parte della documentazione della versione. Le note sulla versione devono includere:

• prerequisiti
• requisiti
• problemi risolti
• problemi noti nella versione

Viene utilizzato con il Runbook per eseguire i passaggi e i controlli pre e post di installazione.

Rilascio in esecuzione nell’ambiente di produzione

Versione finale in esecuzione e attiva in produzione.

Termini del contratto rilevanti

Devi evidenziare termini contrattuali specifici rilevanti per l'implementazione del progetto; quali le tappe contrattuali, i periodi di fattura o i requisiti del personale.

Cadenza dei rapporti

Insieme al cliente, definisci la frequenza dei rapporti che gli vengono consegnati.

Ottimizzazione dell’archivio

I dati non vengono mai sovrascritti in un file tar, l'utilizzo del disco aumenta anche quando si aggiornano solo i dati esistenti.

Per contrastare le dimensioni sempre crescenti dell'archivio, viene implementata una strategia di ottimizzazione per rimuovere i dati obsoleti.

Richiesta di configurazione della sezione Progetto nel portale di supporto Adobe

Richiesta ufficiale di configurazione del progetto nel portale di supporto Adobe.

Documentazione sui requisiti

Questa serie di documenti copre i requisiti funzionali e non funzionali, insieme agli sforzi stimati.

Risorse disponibili per il supporto Go Live

Assicurati che tutti i ruoli necessari per andare in diretta siano dotati di personale e disponibili.

Valutazione del rischio

La valutazione dei rischi viene eseguita dal reparto IT e/o sicurezza del cliente.

Valuta i rischi tecnici e commerciali del progetto. La valutazione è necessaria per garantire il rispetto delle politiche di sicurezza.

Piano di attenuazione dei rischi

Il piano di attenuazione dei rischi include la valutazione dei rischi. Insieme coprono:

• rischi identificati
• eventuali soluzioni a tali rischi qualora dovessero sorgere nell'attuazione

Aspettative sul ROI

Definisci le aspettative sul ritorno sull'investimento (ROI) associate alla soluzione.

Essi mirano a indicare l'efficienza della soluzione in termini economici definendo i benefici/profitti attesi in relazione all'investimento stimato.

Ruoli e concetto di diritti

Specifica dettagliata dei concetti relativi ai ruoli e ai diritti di accesso necessari per la nuova applicazione, compresa una descrizione ad alto livello di:

• ruoli
• gruppi
• utenti
• permissions
• nonché gestione e provisioning degli utenti

Ruoli e concetto dei diritti soddisfa le linee guida sulla sicurezza

Rivedi il concetto Ruoli e diritti per assicurarti che soddisfi i criteri di sicurezza.

Ruoli e specifiche dei diritti

Specifica dettagliata basata sul concetto Ruoli e diritti.

Architettura della sicurezza Recommendations

Recommendations relativo alla sicurezza dell'architettura software e hardware.

Linee guida sulla codifica basate sulla sicurezza

Le presenti linee guida definiscono le modalità di esecuzione del codice di sviluppo, in base a requisiti di sicurezza quali:

• convenzioni di denominazione
• librerie
• linee guida per i quadri di riferimento
• Utilizzo API

Lista di controllo sicurezza

Elenco di controllo degli elementi specifici del progetto, in base al concetto di sicurezza e a eventuali criteri aggiuntivi necessari per garantire la conformità della soluzione.

Spesso questo viene incluso anche come parte delle fasi post-distribuzione nel runbook.

Concetto di sicurezza

Definire e documentare i dettagli della configurazione di sicurezza necessaria per l'applicazione, l'architettura e l'infrastruttura.

Bozza del concetto di sicurezza

Un profilo di alto livello che copre la configurazione di sicurezza dei seguenti elementi:

• applicazione
• architettura
• infrastruttura

Problemi di sicurezza elencati e valutati

Tutti i problemi di sicurezza della soluzione elencata e valutata; comprese le stime dello sforzo.

Disattivazione della sicurezza dalle parti interessate

Disconnettiti dalle parti interessate per garantire che l’implementazione della sicurezza sia conforme alle politiche e alle aspettative.

Configurare i processi di supporto

Imposta i processi di supporto richiesti.

SLA per sistemi di terze parti

Assicurati che gli accordi a livello di servizio (SLA) siano disponibili e comunicati ai team di sviluppo e alle operazioni da utilizzare durante l'implementazione e il supporto.

Concetto di prova del fumo

I test sul fumo consistono in una serie di passaggi definiti che testano le funzionalità chiave della soluzione per garantire le operazioni di base e le funzionalità della soluzione.

Vengono eseguiti, in qualsiasi ambiente, dopo l’installazione o la distribuzione.

Test di fumo eseguiti per la convalida del sistema

I test sul fumo devono essere eseguiti su tutti i sistemi per garantire il corretto funzionamento delle funzionalità di base della soluzione in fase di installazione o distribuzione in qualsiasi ambiente.

Strategia di architettura del software

La strategia ad alto livello per l'architettura del software; compresi servizi, servlet, framework e altre decisioni di implementazione.

Commissione di revisione della soluzione istituito e set di cadenza della riunione

La Solution Review Board è di solito composta da parti interessate dei clienti.

Il consiglio d'amministrazione tiene riunioni periodiche per esaminare su base continuativa i requisiti attualmente in fase di definizione e le specifiche pertinenti. L'obiettivo è garantire l'allineamento con la definizione e i criteri di successo e contribuire allo sviluppo dei requisiti.

Runbook della soluzione

Istruzioni per l'installazione della soluzione, oltre alle attività operative di base da eseguire al momento dell'installazione.

Procedura di spegnimento e accettazione della soluzione

Il processo di approvazione e accettazione delinea i criteri che devono essere soddisfatti prima che la soluzione possa essere rilasciata in un ambiente produttivo.

Può anche fungere da pietra miliare contrattuale.

Concetto di funzionalità speciale

Il concetto iniziale per qualsiasi funzionalità speciale considerata al di fuori del normale ambito di sviluppo sulla piattaforma AEM.

Specifiche delle funzionalità speciali

Dettagli di eventuali funzionalità speciali considerate al di fuori del normale ambito di sviluppo sulla piattaforma AEM.

Linee guida specifiche

Linee guida del cliente sulle modalità da seguire per la specifica.

Processo di revisione e approvazione delle specifiche Definito e comunicato

Dovrebbe essere messo in atto un processo chiaro per l'approvazione delle specifiche da parte del cliente. Questo processo garantisce chiarezza e fermezza di portata per i requisiti.

Personale selezionato per AEM formazione di amministratore

Personale interno che necessita di formazione per gestire la soluzione.

Personale selezionato per la formazione sull'autore e sull'utente finale

Personale interno che necessita di formazione per creare la soluzione.

Parti interessate

Le parti interessate sono le persone e/o i ruoli chiave che hanno un interesse significativo nel progetto. Alcuni contribuiranno al bilancio del progetto.

Le parti interessate possono essere interne e/o esterne.

Le parti interessate sono a conoscenza delle definizioni di successo e dei criteri

Conferma che tutte le parti interessate al di fuori del team di implementazione effettivo sono a conoscenza di:

• definizioni di successo
• criteri di successo

Le parti interessate comprendono i progetti e le aspettative

Conferma che tutte le parti interessate al di fuori del team di implementazione effettivo sono in linea con il progetto e le aspettative generali, sia interne al team di progetto che al cliente.

Definizione del formato del rapporto di stato

I rapporti sullo stato sono uno strumento chiave di comunicazione. Il formato deve essere allineato con eventuali requisiti di reporting del cliente.

Criteri di successo e definizione

Il cliente, il promotore del progetto e il project manager o consulente devono specificare:

• Che cosa definisce un esito positivo per il progetto.
• I criteri specifici necessari per soddisfare tale definizione di successo.

Vengono utilizzati per garantire il rispetto dei criteri di successo:

• Come base per i KPI.
• Nel prendere decisioni durante l'intera attuazione.

Supporto nella convalida dei problemi segnalati

Parte delle responsabilità del lead sulla qualità consiste nell’assicurarsi che vi siano risorse disponibili per supportare qualsiasi utente durante il test. Ad esempio, per aiutare l’utente durante il test, quando si verificano problemi di reporting e per contribuire a convalidarli rispetto all’ambiente di test.

Processi di supporto e accesso al portale di supporto Adobe

L’accesso al portale di supporto Adobe è fondamentale per l’invio di ticket su eventuali problemi relativi ai prodotti che potrebbero verificarsi durante l’implementazione.

L'accesso deve essere assegnato ai membri chiave del team.

Definizione dell'architettura di sistema

Una proposta iniziale e una definizione dell'architettura per tutti gli ambienti della soluzione.

Documentazione di System Architecture

un documento che descrive l'architettura del sistema; tra cui interfacce, posizione della rete e integrazioni per tutti gli ambienti, tra le altre informazioni.

Concetto di sicurezza dell'architettura di sistema

Descrizione dettagliata di come rendere l'architettura del sistema conforme a qualsiasi criterio di sicurezza. Ciò può riguardare:

• firewall e regole firewall
• zone di sicurezza
• gestori locali e generali del traffico
• server web
• proxy e proxy inverso

Fattori di rischio del sistema identificati e verificati

Tutti i fattori di rischio individuati nella valutazione del rischio (o in altri esami) sono identificati e valutati:

• il livello di rischio implicito in ciascuno di essi
• insieme all'impegno stimato per eventuali modifiche all'implementazione necessarie per affrontarle.

Il team è a conoscenza delle definizioni di successo e dei criteri

Conferma che l’intero team è a conoscenza delle definizioni e dei criteri di successo.

Il team è a conoscenza del piano di comunicazione

Conferma che tutti i membri del team sono a conoscenza di chi deve comunicare con il cliente, insieme ai dettagli su come e quando.

Il team comprende il progetto e le aspettative

Allineamento con il progetto e le aspettative generali, sia interne al team di progetto che al cliente.

Requisiti tecnici

Questi requisiti sono specifici per l'implementazione tecnica dei servizi che supportano la soluzione.

Fattori di rischio tecnico verificati

Individuare e verificare i potenziali rischi tecnici. I rischi tecnici possono comprendere:

• vulnerabilità cross-site scripting
• campi di input rivolti all’utente finale
• infrastruttura
• era tecnologica
• numero di integrazioni
• e dipendenze

Specifiche tecniche

La specifica tecnica riguarda (tra l'altro):

• interfacce
• configurazioni
• API
• servizi che supportano i requisiti della soluzione

Specifiche del modello

Specifiche dei modelli richiesti. Questi dovrebbero includere dettagli, tra cui parsys, blueprint e mappatura dell’ereditarietà.

Le specifiche si basano sui requisiti aziendali e sui requisiti di esperienza.

Casi di test

Casi di test specifici i passaggi dettagliati necessari per eseguire il test funzionale della soluzione.

Contenuto del test

Il contenuto del test deve essere il più vicino possibile al contenuto di produzione. Deve essere sufficientemente ampia da consentire il test di tutti gli scenari.

Ambiente di test pronto

Assicurati che l’ambiente di test sia pronto, con distribuzioni automatizzate in atto per garantire che tutto il codice candidato per la versione sia aggiornato per il test.

Report di test

relazioni che descrivono i risultati delle prove; compresi:

• difetti sollevati
• stato dei casi di test eseguiti
• altri argomenti correlati alla qualità

Va osservato che:

• Qualsiasi team di test deve poter rimanere neutrale e fornire i risultati dei test.
• Spetta al responsabile del progetto valutare le eventuali implicazioni dei risultati e decidere le azioni appropriate.

Suite di test

Selezione della suite di automazione e degli strumenti. Questi verranno utilizzati per automatizzare i test, compresi quelli per i casi d’uso.

Suite di strumenti di test selezionata

Suite di automazione e utensili selezionati per l'automazione dei casi d'uso e altre attività di esecuzione dei test.

Concetto di prova

Il concetto di prova è il profilo molto alto di test per il progetto; tra cui test di QA, UAT, prestazioni, sicurezza e integrazione.

Piani di prova

Tali piani delineano in modo più dettagliato l'esecuzione dei test per ciascuna fase di sviluppo e si basano Strategia di test.

Ambito di prova

Questi requisiti sono specifici per l'implementazione tecnica dei servizi che supportano la soluzione.

Strategia di test

La strategia di test delinea la strategia di alto livello per il controllo della qualità e il test di accettazione degli utenti. Ciò include timeline, frequenza di reporting e esecuzione.

Concetto di integrazione di terze parti

Concetto a livello di architettura e di sistema per l'integrazione con sistemi di terze parti.

Specifiche di integrazione di terze parti

Dettagli dei requisiti (funzionali e non funzionali) per la funzionalità supportata e l'integrazione dei sistemi di terze parti.

Concetto sulla sicurezza di terzi

Concetto per garantire la sicurezza di eventuali integrazioni di terze parti. Deve essere conforme ai criteri di sicurezza appropriati.

Sistema di integrazione di terze parti

Assicurati che tutti i sistemi di terze parti siano disponibili, con la documentazione appropriata, per l’implementazione dell’integrazione.

Accesso ai sistemi di terze parti abilitato

Diritti di accesso richiesti concessi ai rispettivi ruoli utilizzati insieme ai sistemi di terze parti.

Concetto sui test di terze parti

Definisce:

• casi d’uso per testare le integrazioni
• funzionalità relative a qualsiasi applicazione di terze parti

Definizione della soglia

Definisce i valori chiave per i punti di monitoraggio nel sistema.

Ad esempio:

• quanti kilobyte (KB) di log non inviati generano un avviso nell’istanza del server principale
• il numero di millisecondi di ritardo medio per transazione tollerati prima che venga generato un avviso sul server principale

Timeline e pietre miliari

Questo dovrebbe definire le tempistiche del progetto e le tappe contrattuali da utilizzare per:

• Fatturazione.
• Allineamento rispetto alle definizioni di successo, ai criteri di successo e ai KPI.

Sforzi totali per i progetti

Occorre consolidare tutte le stime dello sforzo, da ciascuno dei responsabili del progetto; compresi i costi generali, lo sviluppo, l'ingegneria del sistema, gli sforzi di architettura e di collaudo.

Se l'accordo prevede un livello di sostegno, occorre includere anche gli sforzi di sostegno e di funzionamento.

Materiali di formazione

Materiali da utilizzare nelle sessioni di formazione. I materiali devono essere creati appositamente per la soluzione e progettati per essere utilizzati insieme alle Guide utente.

Comprende l'ambito del progetto e le aspettative

L’utente di riferimento deve confermare di comprendere pienamente:

• la portata del progetto
• tutte le aspettative dei clienti
• che questa è la base per tutte le decisioni prese per persona, per ogni fase del progetto

Concetto di gestione degli URL

Il concetto di gestione degli URL dovrebbe coprire AEM specifiche funzionalità URL, tra cui:

• URL personalizzati
• esternalizzazione dei collegamenti
• pagine di errore
• mappatura

Il concetto dovrebbe anche riguardare:

• eventuali regole di riscrittura
• host virtuali nel server web
• Considerazioni SEO, ad esempio robots.txt
• una mappa del sito

Casi d'uso

Un caso d’uso è l’elenco delle azioni o dei passaggi dell’evento necessari per raggiungere un obiettivo. In genere definiscono le interazioni tra un ruolo e la soluzione. Il ruolo può essere un utente o un sistema esterno.

Casi d’uso convertiti in scenari di test

Gli scenari di test si basano sui casi d’uso tecnici e aziendali. Vengono utilizzati per verificare che il comportamento della soluzione sia quello previsto.

Guide utente

Le Guide utente forniscono informazioni e assistenza agli utenti della soluzione:

• autori
• alimentazione
• amministratori

Piano di budget convalidato

Il piano di bilancio deve essere rivisto e convalidato da tutte le parti interessate. Essi devono controllare dettagli quali la fatturazione, gli importi e i metodi/i tempi di segnalazione del budget.

Risultati del test della casella bianca

Il test della casella bianca è un metodo che esegue il test delle strutture o dei funzionamenti interni di un'applicazione, anziché delle sue funzionalità. Il test della scatola bianca può essere applicato a livello di unità, integrazione e sistema del processo di test software.

Specifiche del flusso di lavoro

In base al concetto Flussi di lavoro, queste specifiche devono definire in dettaglio i passaggi che creeranno l’intero flusso di lavoro.

Le specifiche di ciascun flusso di lavoro devono includere (almeno):

• caso d'uso
• ruoli
• step
• risultati
• gestione degli errori

Concetto dei flussi di lavoro

I flussi di lavoro ti consentono di automatizzare le attività AEM. Il concetto dei flussi di lavoro delinea:

• i processi che avranno bisogno di automazione
• i servizi e i ruoli in AEM che saranno interessati