Glossario glossary

Questo glossario elenca (in ordine alfabetico) i dettagli di tutti i documenti del deliverable dell'elenco di controllo progetto.

Accettazione da parte delle parti interessate acceptance-from-business-stakeholders

L’accettazione da parte delle parti interessate conferma che, in qualità di parti interessate chiave, sono in linea con la soluzione e hanno dato la loro approvazione sul modo in cui i requisiti aziendali soddisfano il business case.

Test di accettazione acceptance-tests

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.

I test di accettazione vengono utilizzati per confermare che:

Prima pianifica e progetta i test di accettazione, più semplice sarà la distribuzione finale. Devono essere definiti insieme al cliente e al team di controllo qualità.

Anche se potrebbe non essere possibile definire tutti i dettagli all'inizio del progetto, le definizioni iniziali dovrebbero essere discusse e concordate. Le prove di accettazione saranno probabilmente basate sui requisiti fondamentali (funzionalità e prestazioni).

Accesso al sistema di test coordinato access-to-test-system-coordinated

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

Elenco di controllo della sicurezza di Adobe adobe-security-checklist

L'elenco di controllo di sicurezza di Adobe è l'elenco di controllo ufficiale fornito per garantire la protezione di Adobe Experience Manager (AEM) durante l'installazione. Contiene le misure di sicurezza e i passaggi di verifica necessari per garantire l’integrità dell’istanza.

Configurazione del progetto del portale di assistenza Adobe adobe-support-portal-project-set-up

Il portale di supporto Adobe consente ai partner e ai clienti dell’implementazione di configurare l’implementazione dell’AEM come progetto nel portale di supporto.

È possibile registrare i dettagli, ad esempio sulle tecnologie e le versioni implementate. Ciò garantisce la trasparenza tra il cliente e l’Adobe.

Formazione per gli amministratori AEM aem-administrator-training

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

Formazione per autori AEM aem-author-training

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

Esame certificazione AEM aem-certification-exam

Assicurati che gli utenti tipo appropriati siano registrati per sostenere i esami di certificazione pertinenti.

Certificato AEM aem-certified

Assicurati che la persona appropriata abbia superato i esami di certificazione pertinenti.

Formazione tecnica AEM aem-technical-training

Fornisci formazione tecnica per la persona appropriata, ad esempio sviluppatori, architetti, ingegneri e professionisti aziendali.

Contratto sui KPI definiti come obiettivi per il progetto agreement-on-kpis-defined-as-goals-for-the-project

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

Allineare i KPI aziendali e quelli relativi alle prestazioni align-business-and-performance-kpis

L’allineamento degli indicatori prestazioni chiave (KPI, Key Performance Indicators) aziendali e delle prestazioni consente di riunire tutte le persone e i processi coinvolti dall’interno dell’organizzazione. Ciò a sua volta contribuisce a ridurre la quantità di tempo e di sforzi necessari per raggiungere gli obiettivi aziendali e soddisfare lo scopo proposto.

Allineamento dell’architettura dei contenuti ai KPI alignment-of-content-architecture-with-kpis

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

Allineamento della roadmap del cliente alla sequenza temporale del progetto alignment-of-the-customer-roadmap-with-project-timeline

La roadmap del cliente è composta da milestone di alto livello e obiettivi aziendali. La tempistica del progetto deve aderire a questa strategia e allinearsi ad essa, pertanto tutti i rischi potenziali e/o le possibili deviazioni devono essere evidenziati e monitorati.

Definizione architettura applicazione application-architecture-definition

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

Si concentra su:

Attività di manutenzione specifiche dell’applicazione definite application-specific-maintenance-tasks-defined

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

Personale Adeguatamente Formato appropriately-trained-staff

Assicurati che il tuo team sia composto da personale con la formazione appropriata. Per i team di progetto, si consiglia di avere tutte le caratteristiche seguenti:

Diagramma architettura architecture-diagram

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

Bozza dell'architettura architecture-draft

In questo modo è possibile ottenere una visione di alto livello dell'architettura del sistema e della soluzione. In questa fase si tratta di una bozza che sarà riesaminata e perfezionata in fasi successive.

Firma della bacheca di revisione dell'architettura architecture-review-board-sign-off

L'Architecture Review Board è un organismo interorganizzativo che:

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

Suite di test automatizzata adattata ai contenuti e ai risultati reali rispetto ai KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Script di automazione e casi di utilizzo automatizzati di base:

Strategia di test automatizzati automated-testing-strategy

Questa strategia definisce un framework per gli script automatizzati riutilizzabili, insieme all'approccio pianificato dal team di controllo qualità. Descrive il piano generale per i test di automazione per garantire:

Strategia di test automatizzati convalidati in base al carico realistico e previsto automated-testing-strategy-validated-against-realistic-and-expected-load

La strategia di test automatizzati deve essere convalidata e regolata in base al contenuto e al carico previsto per la soluzione.

Strategia di automazione automation-strategy

L’automazione delle implementazioni garantisce distribuzioni più rapide e coerenti. La strategia di automazione delinea la configurazione di tali meccanismi di automazione, tra cui:

A conoscenza del piano di comunicazione aware-of-communication-plan

L’intero team del progetto e tutte le parti interessate devono confermare di essere a conoscenza di:

Consapevole delle definizioni e dei criteri di successo aware-of-success-definitions-and-criteria

L’intero team del progetto e tutte le parti interessate devono confermare di essere a conoscenza di:

Concetto di backup e ripristino backup-and-restore-concept

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

Test di backup e ripristino backup-and-restore-tested

Test completo basato sul concetto di backup e ripristino.

Casi di studio business-case-s

Un documento business case presenta gli argomenti relativi all’esecuzione dell’azione, all’esecuzione di un’azione alternativa (se disponibile) o alla mancata esecuzione di alcuna azione. Le argomentazioni dovrebbero essere equilibrate, basate su fatti concreti (ove possibile/pertinenti) e mettere in evidenza sia i benefici che i rischi per tutti i casi.

Un documento di analisi dell'attività economica dovrebbe contenere una definizione chiara di tutte le opzioni e contenere un argomento convincente a favore dell'attuazione della soluzione proposta.

Analista aziendale comprende l'ambito del progetto e le aspettative business-analyst-understands-scope-of-project-and-expectations

L’analista commerciale deve confermare di aver compreso appieno:

KPI aziendali business-kpis

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

I KPI aziendali definiscono valori misurabili che dimostrano l’efficacia con cui un’azienda sta raggiungendo gli obiettivi aziendali chiave. È importante scegliere i KPI appropriati alla tua azienda/scenario con definizioni chiare di cosa sono, come sono misurati, come vengono utilizzati e da chi.

Documentazione sui requisiti aziendali business-requirements-documentation

Un documento sui requisiti aziendali (Business Requirements Document, BRD) descrive la soluzione aziendale per un progetto, fornendo una chiara definizione delle esigenze e delle aspettative aziendali del cliente. La direttiva BRD distingue anche tra soluzione aziendale e soluzione tecnica.

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

Approvazione dell'azienda per eventuali adeguamenti necessari alla soluzione o all'architettura identificati e allineati alle aspettative di ROI e KPI business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

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

Qualsiasi modifica derivante da questi processi deve essere rivista e approvata dall'azienda e valutata rispetto agli obiettivi generali.

Strategia di memorizzazione in cache caching-strategy

La Strategia di memorizzazione in cache delinea cosa verrà memorizzato nella cache per l’utente finale. Deve essere conforme ai KPI relativi alle 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 per la codifica coding-guidelines

Le linee guida per la codifica definiscono i principi di base che gli sviluppatori devono rispettare durante lo sviluppo della soluzione. Tra questi possono figurare:

Comunica manuale operazioni communicate-operations-manual

Accertarsi che tutti gli utenti/ruoli appropriati abbiano ricevuto il Manuale delle operazioni.

Comunica rapporto test prestazioni communicate-performance-test-report

Assicurati che tutti gli utenti tipo/ruoli appropriati abbiano ricevuto il rapporto Test delle prestazioni.

Comunicare le note sulla versione communicate-release-notes

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

Comunica ambito e aspettative al team communicate-scope-and-expectations-to-team

Assicurati che il team di progetto sia pienamente a conoscenza dell’ambito del progetto e delle aspettative relative alla consegna, e che sia in linea con esso.

Comunicazione dei materiali di formazione e delle guide utente communicate-training-materials-and-user-guides

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

Conformità ai requisiti di sicurezza del cliente compliance-with-customer-security-requirements

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

Conformità con il concetto di sicurezza compliance-with-security-concept

Verificare che il concetto di sicurezza sia attivo.

Concetto di relazione componenti e modelli components-and-templates-relationship-concept

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

Specifiche di relazione di componenti e modelli components-and-templates-relationship-specification

Dettagli del concetto di relazione dei componenti e dei modelli.

Specifiche dei componenti components-specification

Dettagli delle specifiche per ciascuno dei componenti da implementare.

Concetto per il modello di interfacce esterne concept-for-mock-ups-of-external-interfaces

Il 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ù possibile simili a quelli di produzione.

Documento sull’architettura dei contenuti content-architecture-document

Documentazione dell’architettura proposta per il contenuto. I dettagli dovrebbero comprendere, tra l'altro:

Contenuto convalidato per la migrazione content-validated-for-migration

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

Bozza contratto contract-draft

Una bozza iniziale del contratto legale.

Struttura e formato del contenuto corrente current-content-structure-and-format

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

Criteri di backup e ripristino del cliente customer-backup-and-restore-policy

Politiche del cliente relative a:

Linee guida per la codifica dei clienti customer-coding-guidelines

Eventuali linee guida/requisiti del cliente su come deve essere condotto lo sviluppo.

Criteri di distribuzione/rilascio del cliente customer-deployment-release-policies

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

Questi spesso includono i requisiti di timeline, pianificazione e approvazione.

Criteri o requisiti di monitoraggio del cliente customer-monitoring-policies-or-requirements

Criteri e requisiti del cliente su cosa monitorare. Questi si aggiungono a tutte le raccomandazioni specificate nel concetto di monitoraggio.

Pianificazione rilascio produzione cliente customer-production-release-schedule

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

Criteri e requisiti di reporting per clienti customer-reporting-policies-and-requirements

Qualsiasi politica, o requisito, o entrambi, che il cliente ha in relazione alla generazione di rapporti. Questi possono includere:

Roadmap del cliente customer-roadmap

Elaborare una tabella di marcia delle principali tappe da realizzare, sia tecnologiche che imprenditoriali. Questa roadmap viene quindi comunicata al cliente.

Criteri di sicurezza del cliente customer-security-policies

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

Linee guida sulle specifiche cliente customer-specification-guidelines

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

Rapporti sui test dei clienti customer-test-reports

Segnala al lead di qualità durante il periodo di test di accettazione utente (UAT, User Acceptance Test).

Documentazione di personalizzazioni e hotfix che influiscono sugli aggiornamenti customizations-and-hotfixes-that-affect-upgrades-documented

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

Rapporto test accettazione utente giornaliera daily-user-acceptance-test-report

Report o riunioni risultanti dal test di accettazione utente (UAT, User Acceptance Testing). Dovrebbero specificare:

Protezione predefinita abilitata default-security-enabled

Verificare che le impostazioni di sicurezza predefinite per l'AEM siano state attivate/implementate.

Criteri e processi di distribuzione/rilascio deployment-release-policies-and-processes

Criteri formalizzati relativi sia alla distribuzione che alle versioni del progetto. Questi possono includere:

Cadenza di implementazione stabilita deployment-cadence-established

Definisci la frequenza di implementazioni negli ambienti.

Metodologia di sviluppo development-methodology

Una metodologia di sviluppo del software comporta la suddivisione 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 deliverable e artefatti specifici creati e completati dal team di progetto per sviluppare o gestire l’applicazione.

Definizione ruolo di sviluppo development-role-definition

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

Ambiente di sviluppo pronto development-environment-ready

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

Il team di sviluppo comprende l’ambito del progetto e le aspettative development-team-understands-scope-of-project-and-expectations

Il team di sviluppo deve confermare di aver compreso appieno:

Specifiche finestre di dialogo dialogs-specification

Dettagli sulle finestre di dialogo necessarie per la soluzione.

Configurazione dell’ambiente di sviluppo dei documenti document-development-environment-setup

Documentazione dell’ambiente di sviluppo.

Impostazione dell’ambiente di produzione dei documenti document-production-environment-setup

Documentazione dell’ambiente di produzione.

Impostazione ambiente di prova documenti document-test-environment-setup

Documentazione dell’ambiente di test.

Test di durata durability-test

Il test di durata mostra le prestazioni della soluzione sotto un carico specifico. I test misurano il tempo di sopravvivenza della soluzione quando viene sottoposta al carico di soglia e a quali livelli di prestazioni.

Test di durata eseguito durability-test-executed

Esecuzione delle prove di durata.

Concetto sulla gestione degli errori error-handling-concept

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 error-handling-documentation

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

Processi di riassegnazione escalation-processes

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

Stabilire sessioni regolari di revisione della qualità establish-regular-quality-review-sessions

Organizzare riunioni periodiche di valutazione della qualità con i membri del gruppo appropriati.

Struttura autorizzazioni esistente existing-permissions-structure

Documentazione del set esistente di autorizzazioni e gruppi definiti per la soluzione legacy o all’interno dell’organizzazione.

Mappa dei sistemi esistente existing-systems-map

Un diagramma (o un insieme di diagrammi) dei sistemi e delle dipendenze esistenti.

Definizioni e criteri di successo previsti expected-success-definitions-and-criteria

Lo sponsor del progetto raccoglie le aspettative aziendali relative al successo del progetto. È importante disporre di tutte le aspettative all’inizio di un progetto, in quanto esse dovrebbero influenzare tutte le decisioni prese durante l’attuazione.

Le aspettative possono includere:

Requisiti di Experience Design experience-designs-requirements

Requisiti per l'intera esperienza della soluzione. Ciò riguarda, tra gli altri, fattori come la personalizzazione, la persistenza tra dispositivi e l’esperienza utente.

Specifiche dell’esperienza experience-specifications

Dettagli sui requisiti di progettazione dell’esperienza.

Dipendenze utente e sistema esterno/Contesto del sistema external-system-and-user-dependencies-system-context

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

Sistema e procedura di fallback fallback-system-and-procedure

La definizione del sistema di fallback:

Test del sistema e della procedura di fallback fallback-system-and-procedure-tested

Test completo del sistema di fallback.

Disconnessione del sistema di fallback dalle parti interessate del business fallback-system-sign-off-from-business-stakeholders

Dare l’approvazione, da parte delle parti interessate, del fatto che il sistema di fallback e le procedure correlate garantiscono le funzionalità aziendali critiche.

Conferma di fattibilità sui KPI feasibility-confirmation-on-kpis

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

Contratto finalizzato finalized-contract

Prima di procedere con il progetto è necessario stipulare e firmare un contratto. Si basa sulla bozza di contratto.

Funzionalità della soluzione accettata dalle parti interessate functionality-of-the-solution-accepted-by-stakeholders

Conferma che le parti interessate accettano pienamente:

Pianificazione lancio go-live-schedule

Timeline e pianificazione delle attività necessarie per:

Definiti percorsi felici happy-paths-defined

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

Stime hardware hardware-estimates

Stime iniziali di:

L'hardware sarà disponibile per soddisfare i requisiti hardware-will-be-available-to-fulfill-requirements

Conferma che in tutti gli ambienti sarà installato il minimo hardware richiesto.

Requisiti di alto livello high-level-requirements

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

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

Progettazione di soluzioni di alto livello high-level-solution-design

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

Mappa di sistema di alto livello high-level-system-map

Questa mappa del sistema dovrebbe fornire un diagramma di alto livello del sistema. Differisce 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 historical-content-structure

Definizione della struttura del contenuto del sistema legacy. Questo viene utilizzato come riferimento e anche durante la preparazione della strategia di migrazione.

Indicatori prestazioni chiave cronologici e prestazioni cronologiche historical-performance-and-historical-performance-kpis

Raccogli e documenta le statistiche sulle prestazioni e i KPI relativi alle prestazioni dal sistema legacy. Questi vengono poi utilizzati come punto di riferimento e per eseguire il benchmark della nuova soluzione.

Identificare le principali soluzioni/funzionalità identify-critical-key-solutions-functionalities

Elenco delle funzionalità business critical.

Implementazione - Modifiche in base ai risultati del test di penetrazione implementation-changes-based-on-penetration-test-results

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

Implementazione - Strategia di test automatizzati implementation-automated-testing-strategy

Impostazione degli strumenti e dei processi necessari per supportare test automatizzati.

Implementazione - Strategia di automazione implementation-automation-strategy

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

Implementazione - Architettura dei contenuti implementation-content-architecture

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

Implementazione - Progettazione delle esperienze implementation-experience-design

Implementazione dei requisiti per supportare Experience Design.

Implementazione - Sistema e procedure di fallback implementation-fallback-system-and-procedures

Attuazione del sistema di fallback e delle relative procedure.

Implementazione - Integrazione implementation-integration

Implementazione delle integrazioni con tutti i sistemi esterni richiesti.

Implementazione - Strategia di migrazione implementation-migration-strategy

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

Implementazione - Ruoli e diritti implementation-roles-and-rights

Implementazione di ruoli e diritti, utenti e gruppi.

Implementazione - Concetto di sicurezza implementation-security-concept

Attuazione di tutte le misure di sicurezza, compresi i casi di inadempienza del AEM.

Implementazione - Software di sicurezza implementation-security-software

Implementazione della protezione delle applicazioni software.

Implementazione - Concetto di sicurezza dell'architettura di sistema implementation-system-architecture-security-concept

Attuazione della sicurezza del sistema.

Implementazione - Gestione degli URL implementation-url-handling

Implementazione del concetto di gestione URL.

Implementazione - Flussi di lavoro implementation-workflows

Implementazione dei flussi di lavoro progettati.

Concetto di implementazione implementation-concept

Il concetto di implementazione fornisce i principi guida per l'intera implementazione. Esso dovrebbe prendere in considerazione:

Questo concetto delinea anche i framework, le librerie e altri artefatti utilizzati nella soluzione.

Informa l’Adobe di supporto sulla pianificazione del lancio inform-adobe-support-about-the-go-live-schedule

Contatta il supporto Adobe per assicurarti che tutto il supporto necessario possa essere abilitato durante il lancio.

Progettazioni esperienza iniziale initial-experience-designs

Concetti preliminari per la progettazione delle esperienze.

Integration Testing integration-testing

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

Per garantire la stabilità del sistema, è necessario automatizzare ed eseguire frequentemente questa operazione.

Processo di tracciamento problemi issue-tracking-process

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

Sistema e processi di Issue Tracking issue-tracking-system-and-processes

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

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

Alcuni esempi includono Atlassian JIRA e HP Quality Center.

Il processo del sistema di Issue Tracking è configurato e integrato issue-tracking-system-process-is-set-up-and-integrated

Gli strumenti selezionati sono completamente integrati e l'accesso è concesso a tutti i ruoli richiesti.

Sistema legacy legacy-system

Per il progetto, il sistema legacy è la tecnologia, il sistema 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 list-of-development-tools-to-be-used

Una descrizione sommaria degli strumenti utilizzati nell’implementazione; gli strumenti dovrebbero includere:

Elenco di utenti che richiedono l’accesso al portale di supporto Adobe list-of-users-that-require-access-to-adobe-support-portal

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

L'elenco è normalmente composto dall'architetto della soluzione e/o dal personale IT del cliente.

Analisi file di registro log-file-analysis

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

Attività di manutenzione (specifiche per AEM) testate e abilitate maintenance-tasks-aem-specific-tested-and-enabled

Testare e abilitare le attività di manutenzione dell’AEM quali:

Piano di migrazione migration-plan

Documentare la migrazione; tra cui

Strategia di migrazione migration-strategy

Descrizione completa dei contenuti esistenti, dell'architettura dei contenuti e dei formati associati alla nuova soluzione. Essa dovrebbe riguardare:

Dovrebbe anche consigliare come mantenere i contenuti aggiornati (o il più possibile aggiornati) durante il periodo tra la migrazione e l’effettiva pubblicazione del nuovo sistema. Questo potrebbe significare un blocco dei contenuti, una doppia pubblicazione o il mantenimento di un sistema alfa.

Monitoraggio - CPU monitoring-cpu

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

Monitoraggio - I/O su disco monitoring-disk-i-o

Monitoraggio delle velocità di input e output del disco della soluzione:

Monitoraggio - Spazio su disco monitoring-disk-space

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

Deve monitorare l’uso entro:

Monitoraggio - Sistemi esterni monitoring-external-system-s

Monitorare eventuali connessioni tra la soluzione e i sistemi esterni:

Monitoraggio - Larghezza di banda di rete monitoring-network-bandwidth

Monitora l'utilizzo della larghezza di banda della soluzione:

Monitoraggio - Richieste monitoring-requests

Monitora le richieste effettuate alla soluzione.

Monitoraggio - Punti di sicurezza monitoring-security-points

Monitora i punti di sicurezza definiti.

Monitoraggio - Sistema monitoring-system

Monitora il sistema complessivo; ad esempio:

Monitoraggio - Soglia e intervento monitoring-threshold-and-intervention

Monitoraggio della soglia definita della soluzione insieme all'implementazione di interventi per ridurre il carico.

Concetto di monitoraggio monitoring-concept

I concetti di monitoraggio da applicare alla soluzione; inclusi:

Monitoraggio dei punti deboli potenziali monitoring-potential-weak-points

Devono essere identificati e definiti punti specifici che potrebbero essere suscettibili di fallimento. Dovrebbero essere definiti anche eventuali compiti di monitoraggio correlati a tali attività.

Alcuni esempi:

Criterio di monitoraggio comunicato al System Engineer monitoring-policy-communicated-to-system-engineer

Verificare che gli ingegneri di sistema e il personale operativo conoscano e comprendano tutti i criteri di monitoraggio.

Relazioni di monitoraggio - Struttura esistente monitoring-reports-structure-in-place

Definisci:

Documentazione sulle attività operative operational-tasks-documentation

Tutti i compiti operativi sono documentati e la loro frequenza è definita.

Manuale operativo operations-manual

Manuale contenente tutte le informazioni necessarie per il corretto funzionamento e la manutenzione della soluzione:

Dovrebbe inoltre descrivere in dettaglio i concetti di attuazione per:

Pacchetto preparato package-prepared

Pacchetto software creato e consegnato pronto per la distribuzione.

Test di penetrazione penetration-tests

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

Test di penetrazione - Superati penetration-tests-passed

Vengono passati tutti i criteri richiesti.

Test di penetrazione - Risultati penetration-tests-results

Rapporti creati per l’azienda che illustrano i risultati del test di penetrazione.

Concetto di prestazioni e scalabilità performance-and-scalability-concept

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

Benchmark delle prestazioni performance-benchmark

Il benchmark delle prestazioni viene utilizzato per definire test delle prestazioni, test di durata e monitoraggio. A tale scopo, è necessario valutare le caratteristiche prestazionali della soluzione e dell'hardware di sistema.

KPI per prestazioni performance-kpis

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

Test delle prestazioni - Rapporto performance-tests-report

Rapporti creati per l’azienda, con i dettagli dei risultati dei test delle prestazioni.

Test delle prestazioni: i risultati corrispondono ai KPI delle prestazioni performance-tests-results-match-performance-kpis

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

Concetto di test basati su persone persona-based-testing-concept

I test basati su persone sono un metodo basato su diversi utenti tipo descritti in Progettazioni esperienze. Inoltre, verifica gli account e i livelli di autorizzazione correlati.

Questa funzione viene spesso utilizzata nei test di accettazione utente (UAT, User Acceptance Testing).

Test e verifica POC in base alla documentazione dei requisiti poc-tested-and-verified-against-requirement-documentation

Il Proof of Concept (POC) viene misurato in base ai requisiti per garantire che entrambi siano allineati.

Elenco di controllo per la distribuzione di Post post-deployment-checklist

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

Elenco di controllo pre-distribuzione pre-deployment-checklist

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

Test delle prestazioni di base dell’ambiente di produzione production-environment-baseline-performance-tests

Di solito si esegue un test di base su un’installazione standard di AEM. Questo viene quindi utilizzato come benchmark per testare l'implementazione e l'hardware rispetto a.

Ambiente di produzione pronto production-environment-ready

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

Approvazione della produzione da parte delle parti interessate production-sign-off-from-business-stakeholders

Prima di eseguire il lancio nell’ambiente di produzione, è necessario concedere l’abbonamento alla produzione (PSO). Questo è il risultato di una revisione della versione che entrerà in produzione, insieme a eventuali problemi noti. L’abbonamento viene dato nell’ambito della pianificazione del lancio.

Processo e criteri di approvazione produzione production-sign-off-process-and-policy

La policy e il processo necessari per ottenere l’approvazione della produzione prima di spostare il pacchetto nell’ambiente di produzione.

Piano di comunicazione del progetto project-communication-plan

Definisci il piano di comunicazione per le parti interessate e il team del progetto.

Sforzi del progetto - Stime finali project-efforts-final-estimates

Le stime iniziali erano di alto livello ed erano effettuate in base ai requisiti di alto livello per l'implementazione.

Questi vengono ora rivisti, perfezionati e ampliati per fornire le stime finali. Le stime devono essere fornite da ciascun responsabile del progetto, compresi la gestione del progetto, la consulenza, l’architettura, il test e lo sviluppo.

Queste stime vengono utilizzate per le risorse e la definizione del budget.

Sforzi nel progetto - Stime iniziali project-efforts-initial-estimates

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

Organizzazione del progetto project-organization

Documentazione necessaria per definire l'organizzazione e la struttura di reporting del progetto e del team.

Spesso assume la forma, o include, di un grafico per presentare una panoramica visiva delle tempistiche e delle responsabilità. Sono disponibili molti strumenti per risolvere questo problema.

Documento ambito progetto project-scope-document

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

Esso descrive ciò che deve essere realizzato, insieme al lavoro da fare, per realizzare il progetto

Relazioni sullo stato del progetto entro una cadenza definita project-status-reports-within-a-defined-cadence

Le relazioni sullo stato del progetto vengono consegnate in base alla pianificazione concordata e nel formato richiesto.

Prova di concetto (POC) proof-of-concept-poc

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

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

Regole di rimozione purge-rules

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

Formato e cadenza rapporto qualità quality-report-format-and-cadence

Definisci il contenuto e il formato richiesti per il rapporto sulla qualità, insieme alla frequenza con cui deve essere consegnato.

Rilascio coordinato release-coordinated

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

Note sulla versione release-notes

Le note sulla versione fanno parte della documentazione della versione. Le note sulla versione includono:

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

Versione in esecuzione nell’ambiente di produzione release-running-on-production-environment

Versione finale in esecuzione e attiva in produzione.

Condizioni di contratto rilevanti relevant-contract-terms

Evidenziare i termini contrattuali specifici rilevanti per l'attuazione del progetto, ad esempio le tappe contrattuali, i periodi di fatturazione o i requisiti del personale.

Cadenza di reporting reporting-cadence

Definire, insieme al cliente, la frequenza dei rapporti consegnati.

Ottimizzazione dell’archivio repository-optimization

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 dell’archivio, viene messa in atto una strategia di ottimizzazione per rimuovere i dati obsoleti.

Sezione Richiesta di configurazione del progetto nel portale di supporto Adobe request-for-setting-up-project-section-in-adobe-support-portal

La richiesta ufficiale di configurare il progetto nel portale di assistenza Adobe.

Documentazione sui requisiti requirements-documentation

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

Risorse disponibili per il supporto Go Live resources-available-to-support-go-live

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

Valutazione del rischio risk-assessment

La valutazione dei rischi viene eseguita dal reparto IT del cliente, dal reparto di sicurezza o da entrambi.

Valuta i rischi tecnici e commerciali del progetto. La valutazione è necessaria affinché la soluzione garantisca la conformità con i criteri di sicurezza.

Piano di attenuazione dei rischi risk-mitigation-plan

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

Aspettative di ROI roi-expectations

Definire le aspettative di ritorno sull'investimento (ROI) associate alla soluzione.

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

Concetto di ruoli e diritti roles-and-rights-concept

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

Il concetto di ruoli e diritti soddisfa le linee guida sulla sicurezza roles-and-rights-concept-meets-security-guidelines

Revisione del concetto di ruoli e diritti per garantire che soddisfi i criteri di sicurezza.

Ruoli e diritti roles-and-rights-specification

Specifica dettagliata basata sul concetto di ruoli e diritti.

Architettura di sicurezza Recommendations security-architecture-recommendations

Recommendations si occupa della sicurezza dell'architettura software e hardware.

Linee guida per la codifica basata sulla sicurezza security-based-coding-guidelines

Queste linee guida definiscono come deve essere eseguita la codifica di sviluppo, in base ai requisiti di sicurezza, ad esempio:

Elenco di controllo della sicurezza security-checklist

Elenco di controllo specifico per il progetto, basato sul concetto di sicurezza insieme a eventuali criteri aggiuntivi necessari per garantire la conformità della soluzione.

Spesso questo è incluso anche come parte dei passaggi post-distribuzione nel runbook.

Concetto di sicurezza security-concept

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

Bozza del concetto di sicurezza security-concept-draft

Uno schema di alto livello che copre la configurazione di sicurezza del:

Problemi di sicurezza elencati e valutati security-issues-listed-and-assessed

Tutti i problemi di sicurezza della soluzione elencata e valutata, incluse le stime dello sforzo.

Approvazione della sicurezza da parte delle parti interessate del business security-sign-off-from-business-stakeholders

Chiedi alle parti interessate di garantire che l’implementazione della sicurezza sia conforme ai criteri e alle aspettative.

Configurare i processi di supporto set-up-support-processes

Impostare i processi di supporto richiesti.

SLA per sistemi di terze parti slas-for-third-party-systems

Garantire la disponibilità degli accordi sui livelli di servizio (SLA) e la loro comunicazione ai team di sviluppo e operativi per l'utilizzo durante l'implementazione e il supporto.

Concetto di prova del fumo smoke-test-concept

Le prove di fumo consistono in una serie di fasi definite che verificano le funzionalità chiave della soluzione per garantire le operazioni e le funzionalità di base della soluzione.

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

Test antifumo eseguiti per la convalida del sistema smoke-tests-executed-for-system-validation

I test antifumo devono essere eseguiti su tutti i sistemi per garantire il corretto funzionamento della funzionalità di base della soluzione durante l'installazione o la distribuzione in qualsiasi ambiente.

Strategia dell'architettura software software-architecture-strategy

Strategia di alto livello per l'architettura software, inclusi servizi, servlet, framework e altre decisioni di implementazione.

Preparazione della commissione di esame della soluzione e set di cadenza delle riunioni solution-review-board-established-and-meeting-cadence-set

Il Solution Review Board è composto da rappresentanti del cliente.

Il consiglio di amministrazione tiene riunioni periodiche per esaminare su base continuativa i requisiti attualmente definiti e le relative specifiche. L’obiettivo è garantire l’allineamento con la definizione di successo e i criteri e fornire inoltre un contributo allo sviluppo dei requisiti.

Runbook della soluzione solution-runbook

Istruzioni di installazione per la soluzione, insieme alle attività operative di base da eseguire al momento dell'installazione.

Processo di approvazione e accettazione della soluzione solution-sign-off-and-acceptance-process

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 special-functionality-concept

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

Specifiche di funzionalità speciali special-functionality-specification

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

Linee guida per le specifiche specification-guidelines

Eventuali linee guida del cliente su come eseguire la specifica.

Definizione e comunicazione del processo di revisione e approvazione delle specifiche specification-review-and-approval-process-defined-and-communicated

Dovrebbe essere istituita una chiara procedura per l’approvazione delle specifiche da parte del cliente. Questo processo garantisce la chiarezza e la solidità dell'ambito di applicazione dei requisiti.

Personale selezionato per la formazione di amministratore AEM staff-selected-for-aem-administrator-training

Personale interno che necessita di formazione per gestire la soluzione.

Personale selezionato per la formazione di autore e utente finale staff-selected-for-author-and-end-user-training

Personale interno che necessita di formazione per lavorare sulla soluzione.

Parti interessate stakeholders

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 consapevoli delle definizioni e dei criteri di successo stakeholders-are-aware-of-success-definitions-and-criteria

Conferma che tutte le parti interessate al di fuori del team di implementazione effettiva sono a conoscenza dei seguenti elementi:

Le parti interessate comprendono il progetto e le aspettative stakeholders-understand-project-and-expectations

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

Definizione formato rapporto di stato status-report-format-definition

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

Criteri e definizione di successo success-criteria-and-definition

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

Questi vengono utilizzati per garantire il rispetto dei criteri di successo:

Supporto nella convalida dei problemi segnalati support-in-validation-of-reported-issues

Parte delle responsabilità del responsabile della qualità è garantire che siano disponibili risorse a supporto di qualsiasi utente durante il test. Ad esempio, per aiutare l’utente durante il test, la segnalazione di problemi e la convalida dei problemi nell’ambiente di test.

Processi di supporto e accesso al portale di supporto Adobe support-processes-and-access-to-adobe-support-portal

L’accesso al portale di supporto Adobe è fondamentale per l’invio di ticket su eventuali problemi basati sui prodotti che possono verificarsi durante l’implementazione.

L’accesso deve essere allocato ai membri chiave del team.

Definizione dell'architettura di sistema system-architecture-definition

Proposta iniziale e definizione dell’architettura per tutti gli ambienti della soluzione.

Documentazione sull’architettura di sistema system-architecture-documentation

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

Concetto sulla sicurezza dell'architettura di sistema system-architecture-security-concept

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

Fattori di rischio del sistema identificati e verificati system-risk-factors-identified-and-verified

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

Il team è consapevole delle definizioni e dei criteri di successo team-is-aware-of-success-definitions-and-criteria

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

Il team è a conoscenza del piano di comunicazione team-is-aware-of-the-communication-plan

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

Il team comprende il progetto e le aspettative team-understands-project-and-expectations

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

Requisiti tecnici technical-requirements

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

Fattori di rischio tecnico verificati technical-risk-factors-verified

Identificare e verificare i potenziali rischi tecnici. I rischi tecnici possono includere:

Specifiche tecniche technical-specification

Le specifiche tecniche riguardano (tra l'altro):

Specifica modello template-specification

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

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

Casi di test test-cases

I casi di test specificano i passaggi dettagliati necessari per eseguire il test funzionale della soluzione.

Contenuto di prova test-content

Il contenuto del test deve essere il più possibile simile al contenuto di produzione. Deve essere di una selezione sufficientemente ampia da consentire la verifica di tutti gli scenari.

Ambiente di prova pronto test-environment-ready

Assicurati che l’ambiente di test sia pronto, con implementazioni automatizzate implementate per garantire che tutto il codice candidato alla versione sia aggiornato per il test.

Rapporti sui test test-reports

Relazioni che descrivono i risultati delle prove, tra cui:

Si noti che:

Suite di test test-suite

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

Suite di strumenti di prova selezionata test-tooling-suite-selected

Suite di automazione e strumenti selezionati per l’automazione del caso d’uso e altre attività di esecuzione dei test.

Concetto di test testing-concept

Il concetto di test è il profilo di alto livello dei test per il progetto, tra cui test di controllo qualità, UAT, prestazioni, sicurezza e integrazione.

Piani di prova testing-plans

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

Ambito test testing-scope

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

Strategia di test testing-strategy

La strategia di test delinea la strategia di alto livello per la garanzia della qualità e i test di accettazione da parte degli utenti. Ciò include le timeline, la cadenza di reporting e l’esecuzione.

Concetto di integrazione di terze parti third-party-integration-concept

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

Specifiche di integrazione di terze parti third-party-integration-specification

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

Concetto di sicurezza di terze parti third-party-security-concept

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

Sistema di terze parti per l'integrazione third-party-system-for-integration

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 third-party-systems-access-enabled

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

Concetto di testing di terze parti third-party-testing-concept

Definisce:

Definizione soglia threshold-definition

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

Ad esempio:

Timeline e Milestone timeline-and-milestones

Ciò dovrebbe definire i calendari dei progetti e le tappe contrattuali da utilizzare per:

Totale sforzi progetto total-project-efforts

Tutte le stime di sforzo, provenienti da ogni lead del progetto, devono essere consolidate, inclusi i costi generali, lo sviluppo, l'ingegneria di sistema, l'architettura e i test.

Se l'accordo prevede un livello di sostegno, dovrebbero essere inclusi anche il sostegno e gli sforzi operativi.

Materiale per la formazione training-materials

Materiale da utilizzare nelle sessioni di formazione. I materiali devono essere creati specificamente per la soluzione e progettati per essere utilizzati con le Guide utente.

Comprendere l'ambito del progetto e le aspettative understands-scope-of-project-and-expectations

L’utente tipo appropriato deve confermare di aver compreso appieno:

Concetto di gestione URL url-handling-concept

Il concetto di gestione URL deve includere funzionalità URL specifiche per AEM, tra cui:

Il concetto dovrebbe comprendere anche:

Casi d’uso use-cases

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 utente o sistema esterno.

Casi d’uso convertiti in scenari di test use-cases-converted-into-test-scenarios

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 per l’utente user-guides

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

Piano di budget convalidato validated-budget-plan

Il piano di bilancio deve essere rivisto e convalidato da tutte le parti interessate. Devono controllare dettagli quali fatturazione, importi e metodi/tempistiche dei rapporti di budget.

Risultati test white box white-box-test-results

Il test del white box è un metodo che verifica le strutture interne o il funzionamento di un'applicazione, anziché la sua funzionalità. I test white box possono essere applicati a livello di unità, integrazione e sistema del processo di test software.

Specifiche del flusso di lavoro workflow-specifications

In base al concetto di flussi di lavoro, queste specifiche definiscono in dettaglio i passaggi che creano l’intero flusso di lavoro.

Le specifiche di ciascun flusso di lavoro devono includere (come minimo):

Concetto sui flussi di lavoro workflows-concept

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