Glossario

Il presente glossario elenca (in modo alfabetico) i dettagli di tutti i documenti Consegna dalla lista di controllo del progetto.

Accettazione da parte delle parti in causa

L'accettazione da parte degli operatori economici conferma che, in qualità di soggetti chiave, sono in linea con la soluzione e hanno dato il loro consenso sul modo in cui i requisiti aziendali soddisfano i requisiti aziendali.

Test 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 sono utilizzate per confermare che:

• Project soddisfa i requisiti del cliente.
• La soluzione è adatta allo scopo.
• Gli utenti accettano la soluzione e prevedono di utilizzarla.
• Il cliente accetta il progetto.

Prima pianificate e progettate i test di accettazione, più semplice sarà la distribuzione finale. Devono essere definiti insieme al cliente e al team Quality Assurance.

Anche se potreste non essere in grado di 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 (funzionalità e prestazioni).

Accesso al sistema di prova coordinato

Assicurarsi che i livelli di accesso del sistema richiesti siano stati assegnati a tutti i ruoli.

elenco di controllo della sicurezza Adobe

L' elenco di controllo della sicurezza del Adobe è l'elenco di controllo ufficiale fornito per garantire che il AEM sia sicuro al momento dell'installazione. Contiene le misure di sicurezza e i passaggi di verifica necessari per garantire l'integrità dell'istanza.

progetto del portale di supporto Adobe

Il 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. Queste forniscono trasparenza tra il cliente e il Adobe .

AEM formazione dell'amministratore

Formazione per il personale amministrativo della soluzione. Per ulteriori informazioni, vedere Adobe Training Services.

Formazione su AEM Author

Formazione per il personale addetto alla produzione (authoring) di contenuti per la soluzione. Per ulteriori informazioni, vedere Adobe Training Services.

AEM esame di certificazione

Assicurarsi che la persona appropriata sia registrata per sostenere gli esami di certificazione pertinenti.

AEM certificato

Assicurarsi che la persona appropriata abbia superato gli esami di certificazione pertinenti.

AEM formazione tecnica

fornire una formazione tecnica per la persona appropriata; ad esempio, sviluppatori, architetti, ingegneri e professionisti.

Accordo sui KPI definiti come obiettivi per il progetto

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 business e prestazioni

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

Allineamento dell'architettura dei contenuti con KPI

Assicurarsi che l'architettura del contenuto proposta sia allineata con gli indicatori prestazioni chiave (KPI, Key Performance Indicators) pertinenti.

Allineamento della roadmap del cliente con la cronologia del progetto

La roadmap dei clienti è composta da pietre miliari 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 tracciati.

Definizione architettura applicazione

L' architettura dell'applicazione deve definire chiaramente il comportamento delle applicazioni proposte.

Si concentra su:

• Come interagiranno tra loro e con gli utenti.
• I dati che devono essere consumati e prodotti dalle applicazioni, piuttosto che la loro struttura interna.

Attività di manutenzione specifiche per l'applicazione definite

Oltre alle attività di manutenzione standard di Adobe Experience Manager (AEM), è necessario definire qualsiasi altra attività operativa da eseguire per la manutenzione continua della soluzione.

Personale adeguatamente formato

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

• almeno un AEM sviluppatore lead certificato

• almeno un architetto certificato AEM

• almeno il 75% degli sviluppatori AEM certificati;

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

Diagramma di architettura

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

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

Bozza architettura

Questo fornisce una vista di alto livello del sistema e dell'architettura della soluzione. In questa fase si tratta di un progetto che sarà riesaminato e perfezionato in una fase successiva.

Scheda di revisione dell'architettura - Disconnessione

La commissione di revisione dell'architettura è un organismo interorganizzativo che:

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

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

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
• controllati in base ai KPI

Strategia di test automatizzato

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

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

Strategia di test automatizzato convalidata rispetto al carico realistico e previsto

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

Strategia di automazione

L'automazione delle distribuzioni assicura una distribuzione più rapida e coerente. La strategia di automazione delinea la configurazione di tali meccanismi di automazione; compresi:

• frequenza
• utensili 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 della segnalazione
• canali di comunicazione

Informazioni sulle definizioni di successo e sui 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 descrive le funzionalità tecniche che verranno implementate nella soluzione. È richiesto dalla politica aziendale di backup e ripristino.

Backup e ripristino testati

Test completo basato sul concetto di backup e ripristino.

Casi aziendali

Un documento business case illustra 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 (ove 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 Analytics 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 fase nel progetto

KPI aziendali

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

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

Documentazione sui requisiti aziendali

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

Nell'esaminare la soluzione aziendale, il BRD dovrebbe rispondere alla domanda: "Cosa vogliono fare gli affari?"

Disattivazione di qualsiasi adeguamento necessario alla soluzione o all'architettura identificata e allineata rispetto al ROI e alle aspettative 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.

Eventuali adeguamenti risultanti 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 nella cache delinea gli elementi che verranno memorizzati 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 dovrebbero attenersi nello sviluppo della soluzione. Tra questi possono essere inclusi:

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

Manuale delle operazioni di comunicazione

Assicurarsi che tutte le persone/i ruoli appropriati abbiano ricevuto il Manuale delle Operazioni.

Comunicare il report di test delle prestazioni

Assicurarsi che tutte le persone/i ruoli appropriati abbiano ricevuto il report Performance Test.

Comunica note sulla versione

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

Comunicare l'ambito e le aspettative al team

Assicurati che il team del progetto sia pienamente consapevole e in linea con l’ambito del progetto e le aspettative di realizzazione.

Comunicare Materiali di formazione e Guide utente

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

Conformità ai requisiti di sicurezza dei clienti

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

Conformità con il concetto di sicurezza

Assicurarsi che il concetto di sicurezza sia in vigore.

Concetto di relazione Componenti e Modelli

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

Specifiche di relazione componenti e modelli

Descrizione dettagliata del concetto di relazione tra componenti e modelli.

Specifica componenti

Dettagli delle specifiche per ciascuno dei componenti da implementare.

Concetto per blocchi 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.

Pianificare/implementare modelli di queste interfacce per garantire che il test sia 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 del contenuto
• assegnazione di tag ai concetti
• strategie per il riutilizzo dei contenuti

Contenuto convalidato per la migrazione

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

Bozza contratto

Una prima bozza del contratto legale.

Struttura e formato contenuto corrente

Documentazione dell'architettura e del formato del contenuto corrente. Questo verrà utilizzato per generare la futura architettura dei contenuti. Sarà anche utilizzato 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 che il backup funziona come previsto
• ripristino in caso di guasto

Linee guida sulla codifica dei clienti

Eventuali linee guida/requisiti del cliente sulle modalità di sviluppo da seguire.

Criteri di distribuzione/rilascio cliente

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

Questi includono spesso timeline, requisiti per la pianificazione e la disconnessione.

Criteri o requisiti di monitoraggio clienti

Criteri e requisiti del cliente su ciò che deve essere monitorato. Tali raccomandazioni si sommano a quelle specificate nel concetto di monitoraggio.

Pianificazione rilascio produzione cliente

Pianificazione definita dal cliente per le versioni negli ambienti di produzione.

Criteri e requisiti per la segnalazione dei clienti

Eventuali criteri e/o requisiti che il cliente ha in relazione alla segnalazione. Tra questi possono essere:

• con quale frequenza dovrebbero essere trasmesse relazioni specifiche
• il formato per report specifici
• requisiti speciali

Roadmap dei clienti

Formulare una roadmap delle principali tappe da realizzare, sia tecnologiche che aziendali. Questa roadmap viene quindi comunicata al cliente.

Criteri di protezione del cliente

Il cliente (business e IT) avrà delle politiche che definiscono i livelli di sicurezza richiesti per la soluzione. Tra questi possono essere:

• Requisiti per il superamento di 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 cifratura (SSL), i certificati, l'autenticazione e la sessione.

Linee guida sulle specifiche del cliente

Eventuali linee guida del cliente relative al formato, alla consegna e alla firma delle specifiche.

Report test cliente

Rapporti dal cliente al responsabile qualità durante il periodo di test di accettazione utente (UAT).

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, le modifiche principali apportate all’interfaccia utente di AEM.

• Eventuali aggiornamenti richiesti per la soluzione corrente devono essere documentati in modo completo; possono includere:

  • fix pack cumulativi (CFP)
  • service pack (SP)
  • hotfix
  • upgrade

Report test di accettazione utente giornaliero

Rapporti o riunioni risultanti dal test di accettazione dell’utente (UAT). Essi dovrebbero precisare:

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

Protezione predefinita attivata

Verificare che le impostazioni di protezione predefinite per AEM siano state abilitate o implementate.

Criteri e processi di distribuzione/rilascio

Criteri formalizzati relativi alla distribuzione e alle versioni del progetto. Tra questi possono essere:

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

Cadenza distribuzione stabilita

Definite la frequenza richiesta per le distribuzioni tra gli ambienti.

Metodologia di sviluppo

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

Nel definire la metodologia è necessario predefinire specifici risultati finali e artifact creati e completati dal team del progetto per sviluppare o mantenere l'applicazione.

Definizione del ruolo di sviluppo

Definite quale sviluppatore e/o ruolo esegue IT (prestazioni o altro) e/o unit test all'interno della soluzione.

Ambiente di sviluppo pronto

Verificare che l'ambiente di sviluppo sia configurato con gli strumenti integrati necessari per l'automazione delle installazioni.

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

Il team per lo 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 fase nel progetto

Specifica finestre di dialogo

Dettagli sulle finestre di dialogo necessarie per la soluzione.

Impostazione ambiente di sviluppo documenti

Documentazione dell'ambiente di sviluppo.

Impostazione ambiente produzione documenti

Documentazione dell'ambiente di produzione.

Imposta ambiente test documento

Documentazione dell'ambiente di prova.

Prova di durata

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

Test di durata eseguito

Esecuzione delle prove di durata.

Concetto di gestione errori

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

Documentazione relativa alla gestione degli errori

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

Processi di escalation

Definizione di tutti i processi di escalation. Saranno disponibili processi separati per ciascun livello di progetto:

• Team del progetto
• Cliente
• Adobe

Definizione di sessioni periodiche di valutazione della qualità

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

Struttura delle autorizzazioni esistenti

Documentazione del set 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

Il promotore del progetto raccoglie le aspettative aziendali relative al successo del progetto. È importante che all'inizio di un progetto siano disponibili tutte le aspettative, in quanto queste dovrebbero influenzare tutte le decisioni prese durante l'attuazione.

Le aspettative possono includere:

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

Requisiti di Experience Designs

Requisiti per l'intera esperienza della soluzione. Vengono trattati fattori quali la personalizzazione, la persistenza tra dispositivi diversi e l'esperienza degli utenti, tra l'altro.

Specifiche esperienza

Dettagli sui requisiti di progettazione dell'esperienza.

Sistema esterno e dipendenze utente/Contesto di sistema

Un diagramma (o un 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 di fallback e procedura

Definizione del sistema di fallback:

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

Sistema di fallback e procedura testata

Test end-to-end del sistema di fallback.

Sistema di fallback disconnetti dai soggetti aziendali

Disconnettiti, dalle parti interessate aziendali, dal fatto che il sistema di fallback e le procedure correlate garantiranno 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 finalizzato e firmato. Si basa su Contract Draft.

Funzionalità della soluzione accettata dalle parti interessate

Conferma che le parti interessate accettano pienamente:

• funzionalità della soluzione
• eventuali problemi noti nella soluzione

Go Live Schedule

Timeline e pianificazione delle attività richieste per:

• preparazione per andare live
• vai live

Percorsi felici definiti

Un percorso felice è uno scenario predefinito senza condizioni eccezionali o di errore. È composta 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

L'hardware sarà 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 suddivisione generalizzata dei requisiti del sistema, che comprende aspetti quali:

• Processi aziendali
• Principali funzioni del sistema

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

Progettazione di soluzioni di alto livello

Il design di soluzioni di alto livello spiega l'architettura che verrà utilizzata per sviluppare la soluzione. Il diagramma dell'architettura fornisce una panoramica dell'intero sistema, identificando i principali componenti che saranno sviluppati per il prodotto e le loro interfacce.

Mappa del sistema ad alto livello

Questa mappa di sistema dovrebbe fornire un diagramma di livello molto alto 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 contenuto storico

Definizione della struttura del contenuto del sistema legacy. Questo viene utilizzato per riferimento e anche per preparare la strategia di migrazione.

KPI prestazioni storiche e prestazioni storiche

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

Identificare le soluzioni/funzionalità chiave critiche

Un elenco delle funzionalità business critical.

Implementazione - Modifiche in base ai risultati del test di transizione

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

Implementazione: strategia di test automatizzato

Impostazione degli strumenti e dei processi necessari per supportare il test automatizzato.

Implementazione - Strategia di automazione

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

Implementazione - Architettura dei contenuti

Implementazione dell’architettura dei contenuti, concetti relativi ai tag e riutilizzo dei contenuti.

Implementazione - Progettazione esperienza

Implementazione dei requisiti per supportare Experience Design.

Implementazione - Sistema di fallback e procedure

Attuazione del sistema di fallback e delle relative procedure.

Implementazione - Integrazione

Implementazione delle 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, comprese le 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 implementazione fornisce i principi guida per l'intera implementazione. Dovrebbe tener conto:

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

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

Informazioni supporto del Adobe Informazioni sulla pianificazione Go Live

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

Progettazione esperienza iniziale

Concetti preliminari per i progetti delle esperienze.

Verifica integrazione

Verifica e conferma risultante di tutte le integrazioni, sia interne che esterne.

Questo deve 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 di tracciamento dei problemi e processi

Un sistema di monitoraggio, insieme 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 al fine di facilitare la trasparenza dello stato del progetto.

Esempi includono Atlassian JIRA e HP Quality Center.

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 precedente

Per il progetto il sistema legacy è la tecnologia, il sistema informatico o il programma applicativo esistente che verrà sostituito 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 per l'attuazione; gli strumenti dovrebbero includere:

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

Elenco di utenti che richiedono l'accesso a portale di supporto del Adobe

Un elenco di tutti gli utenti e i ruoli che dovranno accedere al portale di supporto del Adobe .

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

Analisi file di registro

Un'analisi, insieme alle raccomandazioni che ne risultano, che definisce gli elementi da registrare per monitorare la soluzione:

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

Attività di manutenzione (AEM specifiche) testate e abilitate

Effettuare test e attivare AEM attività di manutenzione quali:

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

Piano di migrazione

Documentare la migrazione; incluso

• calendario 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. Dovrebbe riguardare:

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

Dovrebbe inoltre suggerire come mantenere i contenuti aggiornati (o il più aggiornati 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

È necessario monitorare l'utilizzo tramite:

• repository
• file di registro

Monitoraggio - Sistemi esterni

Monitorare eventuali connessioni tra la soluzione e i sistemi esterni:

• tasso di traffico
• picchi
• stabilità

Monitoraggio - Larghezza di banda della rete

Controlla l'utilizzo della larghezza di banda di rete da parte della soluzione:

• tasso medio di traffico
• picchi
• stabilità

Monitoraggio - Richieste

Monitorate le richieste effettuate alla soluzione.

Monitoraggio - Punti di sicurezza

Monitorare i punti di sicurezza definiti.

Monitoraggio - Sistema

monitorare il sistema nel suo complesso; ad esempio:

• availability
• rendimento medio
• picchi di prestazioni
• alert

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; con:

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

Monitoraggio dei potenziali punti deboli

Occorre individuare e definire punti specifici che potrebbero essere suscettibili di fallimento. Occorre inoltre definire le eventuali attività di controllo connesse a tali attività.

Esempi:

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

Criteri di monitoraggio comunicati al tecnico di sistema

Assicurare che i tecnici del sistema e il personale operativo siano a conoscenza e comprensione di eventuali politiche di monitoraggio.

Rapporti di monitoraggio - Struttura in posizione

Definisci:

• quando devono essere generati i rapporti di monitoraggio
• a cui devono essere consegnati

Documentazione 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:

• tutti i compiti operativi
• contatti chiave
• piani di distribuzione
• elenchi di controllo pre/post-distribuzione
• qualsiasi altra attività critica

Dovrebbe inoltre precisare i concetti di attuazione per:

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

Pacchetto preparato

Pacchetto software creato e consegnato pronto per la distribuzione.

Test di penetrazione

Un test di penetrazione (noto informalmente come "pen test") è un attacco a un sistema informatico che cerca carenze di sicurezza, ottenendo potenzialmente 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'attività che spiegano 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 come ridimensionare la soluzione in modo che continui a soddisfare tali KPI.

Benchmark delle prestazioni

Il Benchmark Prestazioni è utilizzato per definire test di prestazioni, test di durata e monitoraggio. A tal fine, valuta le caratteristiche di prestazione della soluzione e dell'hardware del sistema.

KPI prestazioni

Definiscono i 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 delle query del database.

Test delle prestazioni - Report

Report creati per l'attività, con dettagli sui risultati dei test di prestazioni.

Test delle prestazioni - Risultati corrispondenti KPI delle prestazioni

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

Concetto di test basato su Persona

Il test basato su Persona è un metodo basato sulle diverse persone descritte in Experience Designs. Vengono inoltre verificati gli account e i relativi livelli di autorizzazioni.

Questo viene spesso utilizzato in Test di accettazione utente (UAT).

POC testato e verificato rispetto alla documentazione relativa ai requisiti

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

Elenco di controllo post-distribuzione

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

Elenco di controllo pre-distribuzione

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

Test delle prestazioni di base dell'ambiente di produzione

In genere, è consigliabile eseguire un test di base su un'installazione standard di AEM. Questo viene quindi utilizzato come punto di riferimento per testare l'implementazione e l'hardware.

Pronto ambiente di produzione

Verificate che l'ambiente di produzione sia pronto, con distribuzioni automatizzate.

Disattivazione della produzione dalle parti in causa

Prima di andare in diretta nell'ambiente di produzione, è necessario concedere l'opzione Disconnessione produzione (PSO). Questo è il risultato di una revisione del rilascio che andrà in produzione, insieme a eventuali problemi noti. La disconnessione viene fornita come parte della pianificazione Go Live.

Processo e criterio di disattivazione dei segnali di produzione

Criterio e processo necessari per ottenere il segno di produzione prima di spostare il pacchetto nell'ambiente di produzione.

Piano di comunicazione del progetto

Definire il piano di comunicazione sia per gli operatori aziendali che per il team del progetto.

Sforzi per il progetto - Stime finali

Le stime iniziali sono state di alto livello e sono state effettuate in base ai requisiti di alto livello per l'implementazione.

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

Tali stime vengono utilizzate per le risorse e il budget.

Sforzi per il progetto - Stime iniziali

Le stime iniziali sono di alto livello e sono effettuate in base ai requisiti di alto livello per l'attuazione. Questo verrà riesaminato e perfezionato in una fase successiva.

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 aiutarlo.

Documento ambito progetto

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

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

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

Rapporti sullo stato del progetto all'interno di una cadenza definita

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

Prova del concetto (POC)

Il Proof of Concept (POC) implementa una gamma limitata di funzioni per la soluzione.

Esso dovrebbe mirare a dimostrare la fattibilità della soluzione, verificare che possa soddisfare lo scopo richiesto e dimostrare che esiste il potenziale del suo utilizzo.

Rimuovi regole

AEM conserva più versioni di risorse e contenuti. Le regole di rimozione 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

Definite il contenuto e il formato richiesti del rapporto sulla qualità, insieme alla frequenza con cui deve essere trasmesso.

Rilascia coordinate

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

Note sulla versione

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

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

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

Rilascio in esecuzione sull'ambiente di produzione

Versione finale in esecuzione e attiva in produzione.

Termini del contratto rilevanti

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

Cadenza report

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

Ottimizzazione repository

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 maggiori del repository, è stata messa in atto una strategia di ottimizzazione per rimuovere i dati obsoleti.

Richiesta di configurazione della sezione Progetto nel portale di supporto del Adobe

La richiesta ufficiale di impostare il progetto nel portale di supporto del Adobe .

Documentazione dei requisiti

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

Risorse disponibili per il supporto Go Live

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

Valutazione dei rischi

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

Essa 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 comprende la valutazione dei rischi. Insieme coprono:

• rischi identificati
• possibili soluzioni a tali rischi qualora emergano nell'attuazione

Aspettative ROI

Definite le aspettative di 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 diritti Concetto

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

• role
• groups
• users
• permissions
• nonché gestione e provisioning degli utenti

Ruoli e diritti Concetto soddisfa le linee guida sulla sicurezza

Rivedete il concetto Ruoli e diritti per essere certi che soddisfi i criteri di protezione.

Ruoli e diritti specifici

Specifica dettagliata basata sul concetto Ruoli e diritti.

Architettura di sicurezza Recommendations

Recommendations relativo alla sicurezza per l'architettura software e hardware.

Linee guida sulla codifica basata sulla protezione

Le presenti linee guida definiscono le modalità di codifica per lo sviluppo, in base a requisiti di sicurezza quali:

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

Elenco di controllo protezione

Elenco di controllo specifico del progetto, basato sul concetto di sicurezza insieme a eventuali politiche aggiuntive necessarie 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 protezione necessaria per l'applicazione, l'architettura e l'infrastruttura.

Progetto di concetto di sicurezza

Un profilo di alto livello che copre l'impostazione della sicurezza dei seguenti elementi:

• applicazione
• architettura
• infrastruttura

Problemi di sicurezza elencati e valutati

Tutte le questioni di sicurezza della soluzione elencata e valutata; comprese le stime dello sforzo.

Disattivazione della sicurezza dai soggetti aziendali

Per assicurarsi che l'implementazione della sicurezza sia conforme alle politiche e alle aspettative, è necessario disconnettersi dalle parti interessate.

Configurare i processi di supporto

Impostate 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 test del fumo

I test di fumo consistono in una serie di passaggi definiti che consentono di verificare le funzionalità chiave della soluzione per garantire le operazioni di base e la 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 dovrebbero essere eseguiti su tutti i sistemi per garantire il corretto funzionamento delle funzionalità di base della soluzione in fase di installazione o installazione in qualsiasi ambiente.

Strategia di architettura del software

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

Scheda di revisione della soluzione - Set di cadenza della riunione

La Solution Review Board è in genere composta da parti interessate del cliente.

Il consiglio di amministrazione organizza regolarmente riunioni per esaminare in modo continuativo i requisiti attualmente in vigore e le specifiche pertinenti. L'obiettivo è quello di garantire l'allineamento con la definizione e i criteri di successo e di contribuire allo sviluppo dei requisiti.

Runbook soluzione

Istruzioni per l'installazione della soluzione, insieme alle attività operative di base da eseguire all'installazione.

Procedura di approvazione e disattivazione della soluzione

Il processo di approvazione e di approvazione 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

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

Specifiche funzionalità speciali

Dettagli di qualsiasi funzionalità speciale considerata al di fuori del normale ambito di sviluppo sulla piattaforma AEM.

Linee guida sulle specifiche

Eventuali 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 assicura chiarezza e fermezza di portata per i requisiti.

Personale selezionato per AEM formazione amministratore

Personale interno che necessiterà di formazione per gestire la soluzione.

Personale selezionato per la formazione Autore e Utente finale

Personale interno che necessita di formazione per creare la soluzione.

Parti interessate

Le parti in causa 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 tutti i soggetti interessati al di fuori del team di implementazione effettivo sono a conoscenza di:

• definizioni di successo
• criteri di successo

Le parti interessate comprendono il progetto e le aspettative

Confermare che tutti i soggetti coinvolti al di fuori del team di implementazione effettivo sono in linea con il progetto e le aspettative generali, sia interni al team del 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 a tutti i requisiti di segnalazione del cliente.

Criteri di successo e definizione

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

• Definisce un risultato positivo per il progetto.
• I criteri specifici necessari per soddisfare tale definizione di successo.

Tali criteri sono utilizzati per garantire che i criteri di successo siano soddisfatti:

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

Supporto per la convalida dei problemi segnalati

Parte delle responsabilità del responsabile qualità è garantire che vi siano risorse disponibili per supportare qualsiasi utente durante il test. Ad esempio, per aiutare l'utente durante il test, durante la segnalazione dei problemi e per aiutare a convalidare i problemi nell'ambiente di test.

Processi di supporto e accesso al portale di supporto Adobe

L'accesso al portale di supporto del Adobe è fondamentale per l'invio di ticket su qualsiasi problema relativo ai prodotti che potrebbe verificarsi durante l'implementazione.

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

Definizione architettura di sistema

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

Documentazione sull'architettura del sistema

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

Concetto di sicurezza dell'architettura di sistema

Un profilo di alto livello su come rendere l'architettura del sistema conforme a qualsiasi criterio di protezione. Può trattarsi di:

• firewall e regole firewall
• zone di protezione
• gestori locali e generali del traffico
• server Web
• proxy e proxy inversi

Fattori di rischio del sistema identificati e verificati

Eventuali fattori di rischio riscontrati nella valutazione del rischio (o in altri esami) sono identificati e valutati:

• il livello di rischio implicito in ciascuno
• insieme agli sforzi stimati 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 consapevoli di chi dovrebbe comunicare con il cliente, insieme ai dettagli su come e quando.

Il team comprende il progetto e le aspettative

Allineamento con il progetto complessivo e le aspettative, 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:

• cross-site scripting
• campi di input dell'utente finale
• infrastruttura
• era tecnologica
• numero di integrazioni
• e dipendenze

Specifiche tecniche

Le specifiche tecniche comprendono (tra le altre informazioni):

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

Specifica modello

Le specifiche per i modelli richiesti. Tali informazioni dovrebbero includere, tra gli altri, i dettagli parsys, blueprint e la 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 test

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

Pronto ambiente di test

Verificate che l'ambiente di test sia pronto, con distribuzioni automatizzate in atto per garantire che tutti i codici dei candidati alla release siano aggiornati per il test.

Report test

relazioni che descrivono i risultati delle prove; compresi:

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

Va osservato che:

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

Suite di test

Selezione della suite di automazione e degli utensili. Questi verranno utilizzati per automatizzare i test, compresi quelli per i casi di utilizzo.

Suite di strumenti di test selezionata

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

Concetto di test

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

Verifica dei piani

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

Verifica ambito

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 da parte degli utenti. Ciò include timeline, cadenza dei rapporti e esecuzione.

Concetto di integrazione di terze parti

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

Specifica di integrazione di terze parti

Informazioni dettagliate sui requisiti (funzionali e non funzionali) per le funzionalità supportate e l'integrazione dei sistemi di terze parti.

Concetto di sicurezza di terze parti

Concetto per garantire la sicurezza delle integrazioni di terze parti. Devono essere conformi alle politiche di sicurezza appropriate.

Sistema di terze parti per l'integrazione

Assicurarsi 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 di test di terze parti

Definisce:

• casi di utilizzo per testare le integrazioni
• funzionalità relative a qualsiasi applicazione di terze parti

Definizione di soglia

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

Esempio:

• quanti kilobyte (KB) di registri 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

In tal modo dovrebbero essere definite 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.

Totale sforzi di progetto

È opportuno consolidare tutte le stime dello sforzo, provenienti da ciascuno dei principali elementi del progetto; compresi, sovraccarico, sviluppo, progettazione di sistemi, attività architettoniche e di collaudo.

Se l'accordo prevede un livello di sostegno, dovrebbero essere inclusi 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

La persona appropriata dovrebbe confermare che comprendono appieno:

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

Concetto di gestione URL

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

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

Il concetto dovrebbe inoltre riguardare:

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

Casi di utilizzo

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 di utilizzo convertiti in scenari di test

Gli scenari di test si basano sui casi di utilizzo tecnico e aziendale. 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 budget convalidato

Il piano di bilancio deve essere rivisto e convalidato da tutte le parti interessate. Devono controllare dettagli quali fatturazione, importi e metodi/tempi di segnalazione del bilancio.

Risultati test casella bianca

White box test è un metodo che verifica le strutture interne o il funzionamento di un'applicazione, anziché la sua 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 consentiranno di creare l'intero flusso di lavoro.

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

• caso di utilizzo
• role
• step
• events
• gestione degli errori

Concetto dei flussi di lavoro

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

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