Glossario glossary

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

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

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

Prove di accettazione 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.

Le prove di accettazione vengono utilizzate per confermare che:

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

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

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

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

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

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

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

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

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

Formazione per l'amministratore AEM aem-administrator-training

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

Formazione sull’authoring di AEM aem-author-training

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

Esame di certificazione AEM aem-certification-exam

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

AEM certificato aem-certified

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

Formazione tecnica AEM aem-technical-training

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

Accordo sui KPI definiti come obiettivi del progetto 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 verso obiettivi e obiettivi organizzativi. Una volta che un'organizzazione ha analizzato la sua missione e definito i suoi obiettivi, deve misurare i progressi verso tali obiettivi. I KPI forniscono un meccanismo di misurazione.

Allinea KPI (Key Performance Indicator) per Business e Performance align-business-and-performance-kpis

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

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

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

Allineamento della Roadmap dei clienti con la Timeline del progetto alignment-of-the-customer-roadmap-with-project-timeline

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

Definizione dell'architettura applicativa application-architecture-definition

La architettura dell'applicazione definire chiaramente il comportamento delle domande 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 tutte le altre attività operative da eseguire per la manutenzione continua 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, la raccomandazione deve avere tutti i seguenti elementi:

Diagramma dell'architettura architecture-diagram

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

Bozza di architettura architecture-draft

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

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

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

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

Suite di test automatizzata adattata per contenuti e risultati reali rispetto ai KPI 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 automatizzato automated-testing-strategy

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

Strategia di test automatizzato convalidata in base a carico realistico e previsto automated-testing-strategy-validated-against-realistic-and-expected-load

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

Strategia di automazione automation-strategy

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

Piano di comunicazione aware-of-communication-plan

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

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

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

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

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

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

Test completo basato sul concetto di backup e ripristino.

Business case business-case-s

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

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

Business Analyst Comprende l'ambito del progetto e le aspettative business-analyst-understands-scope-of-project-and-expectations

L'analista aziendale deve confermare di aver compreso appieno:

KPI aziendali business-kpis

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

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

Documentazione sui requisiti aziendali business-requirements-documentation

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

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

Disattivazione dell'attività su qualsiasi adeguamento necessario alla soluzione o all'architettura identificata e allineata in base alle aspettative sul ROI e sui KPI 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 test di penetrazione possono produrre problemi e risultati che devono essere affrontati nell'architettura o nello sviluppo della soluzione.

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

Strategia di memorizzazione nella cache caching-strategy

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

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

Linee guida sulla codifica coding-guidelines

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

Manuale delle operazioni di comunicazione communicate-operations-manual

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

Rapporto sul test delle prestazioni della comunicazione communicate-performance-test-report

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

Comunicare le note sulla versione communicate-release-notes

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

Comunicare Ambito e aspettative al team communicate-scope-and-expectations-to-team

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

Comunicare i materiali di formazione e le guide utente communicate-training-materials-and-user-guides

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

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

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

Conformità al concetto di sicurezza compliance-with-security-concept

Assicurati che il concetto di sicurezza sia attivo.

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

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

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

Descrizione dettagliata del concetto di relazione tra componenti e modelli.

Specifiche dei componenti components-specification

Dettagli delle specifiche per ciascuno dei componenti da implementare.

Concetto per la simulazione di interfacce esterne concept-for-mock-ups-of-external-interfaces

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

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

Documento sull’architettura dei contenuti content-architecture-document

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

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

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

Progetto di contratto contract-draft

Una prima bozza del contratto giuridico.

Struttura e formato dei contenuti correnti current-content-structure-and-format

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

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

Politiche del cliente riguardanti:

Linee guida sulla codifica dei clienti customer-coding-guidelines

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

Criteri di distribuzione/rilascio dei clienti customer-deployment-release-policies

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

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

Criteri o requisiti per il monitoraggio dei clienti customer-monitoring-policies-or-requirements

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

Pianificazione del rilascio della produzione dei clienti customer-production-release-schedule

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

Criteri e requisiti per la generazione di rapporti sui clienti customer-reporting-policies-and-requirements

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

Roadmap dei clienti customer-roadmap

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

Criteri di sicurezza del cliente customer-security-policies

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

Linee guida sulle specifiche del 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

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

Personalizzazioni e Hotfix che influiscono sugli aggiornamenti documentati customizations-and-hotfixes-that-affect-upgrades-documented

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

Rapporto sul test giornaliero di accettazione degli utenti daily-user-acceptance-test-report

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

Protezione predefinita attivata default-security-enabled

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

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

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

Cadenza della distribuzione stabilita deployment-cadence-established

Definisci la frequenza richiesta per le distribuzioni in ambienti diversi.

Metodologia di sviluppo development-methodology

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

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

Definizione del ruolo di sviluppo development-role-definition

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

Ambiente di sviluppo pronto development-environment-ready

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

Il team per lo sviluppo capisce l'ambito del progetto e le aspettative development-team-understands-scope-of-project-and-expectations

Il team di sviluppo deve confermare di aver compreso appieno:

Specifiche delle finestre di dialogo dialogs-specification

Dettagli sulle finestre di dialogo necessarie per la soluzione.

Impostazione dell'ambiente di sviluppo 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 dell’ambiente di test del documento document-test-environment-setup

Documentazione dell’ambiente di test.

Test di durevolezza durability-test

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

Test di durevolezza eseguito durability-test-executed

Esecuzione delle prove di resistenza.

Concetto di 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 scalabilità escalation-processes

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

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

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

Struttura delle autorizzazioni esistenti existing-permissions-structure

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

Mappa dei sistemi esistenti existing-systems-map

Diagramma (o 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 che all'inizio di un progetto siano disponibili tutte le aspettative, poiché queste dovrebbero influenzare tutte le decisioni prese durante l'attuazione.

Le aspettative possono includere:

Requisiti di Experience Design experience-designs-requirements

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

Specifiche esperienza experience-specifications

Dettagli sui requisiti di progettazione delle esperienze.

Sistema esterno e dipendenze utente/contesto di sistema external-system-and-user-dependencies-system-context

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

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

Definizione del sistema di fallback:

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

Test end-to-end del sistema di fallback.

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

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

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

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 finalized-contract

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

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

Conferma che le parti interessate accettano pienamente:

Vai alla programmazione in tempo reale go-live-schedule

Timeline e pianificazione delle attività necessarie per:

Percorsi felici definiti happy-paths-defined

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

Stime hardware hardware-estimates

Stime iniziali di:

Hardware disponibile per soddisfare i requisiti hardware-will-be-available-to-fulfill-requirements

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

Requisiti di alto livello high-level-requirements

La definizione dei requisiti di alto livello fornisce una ripartizione 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 design della soluzione di alto livello spiega l'architettura che verrà utilizzata per lo sviluppo della soluzione. Il diagramma dell'architettura fornisce una panoramica dell'intero sistema, identificando i componenti principali che verranno sviluppati per il prodotto e le relative interfacce.

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

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

Struttura dei contenuti storici historical-content-structure

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

KPI per prestazioni storiche e prestazioni storiche historical-performance-and-historical-performance-kpis

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

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

Elenco delle funzionalità aziendali critiche.

Implementazione: modifiche basate sui risultati dei test di penetrazione implementation-changes-based-on-penetration-test-results

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

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

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

Implementazione - Strategia di automazione implementation-automation-strategy

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

Implementazione - Architettura dei contenuti implementation-content-architecture

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

Implementazione - Progettazione esperienza 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 di integrazioni con tutti i sistemi esterni richiesti.

Implementazione - Strategia di migrazione implementation-migration-strategy

Migrazione e 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

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

Implementazione - Software di sicurezza implementation-security-software

Implementazione della sicurezza dell'applicazione software.

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

Implementazione della sicurezza del sistema.

Implementazione - Gestione URL implementation-url-handling

Implementazione del concetto di gestione degli URL.

Implementazione - Flussi di lavoro implementation-workflows

Implementazione dei flussi di lavoro progettati.

Concetto di implementazione implementation-concept

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

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

Informazioni sul supporto di Adobe per la pianificazione Go Live inform-adobe-support-about-the-go-live-schedule

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

Progettazione esperienza iniziale initial-experience-designs

Concetti preliminari per i progetti delle esperienze.

Test di integrazione integration-testing

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

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

Processo di tracciamento dei problemi issue-tracking-process

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

Sistema e processi di tracciamento dei problemi issue-tracking-system-and-processes

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

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

Ne sono esempi Atlassian JIRA e HP Quality Centre.

Il processo del sistema di tracciamento dei problemi è configurato e integrato issue-tracking-system-process-is-set-up-and-integrated

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

Sistema legacy legacy-system

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

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

Elenco degli strumenti di sviluppo da utilizzare list-of-development-tools-to-be-used

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

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

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

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

Analisi dei file di registro log-file-analysis

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

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

Testare e attivare attività di manutenzione AEM quali:

Piano di migrazione migration-plan

documentare la migrazione; compreso

Strategia di migrazione migration-strategy

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

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

Monitoraggio - CPU monitoring-cpu

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

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

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

Monitoraggio - Spazio su disco monitoring-disk-space

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

Controlla l'utilizzo di:

Monitoraggio - Sistemi esterni monitoring-external-system-s

Monitorare le connessioni tra la soluzione e i sistemi esterni:

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

Monitorare 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

monitorare l'intero sistema; ad esempio:

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

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

Concetto di monitoraggio monitoring-concept

Concetti di monitoraggio da applicare alla soluzione; incorporante:

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

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

Gli esempi includono (tra gli altri):

Criteri di monitoraggio comunicati al tecnico del sistema monitoring-policy-communicated-to-system-engineer

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

Monitoraggio dei report - Struttura in corso monitoring-reports-structure-in-place

Definisci:

Documentazione sulle attività operative operational-tasks-documentation

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

Manuale operativo operations-manual

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

Dovrebbe inoltre illustrare in dettaglio i concetti di attuazione per:

Pacchetto preparato package-prepared

Pacchetto software generato e consegnato pronto per la distribuzione.

Test di penetrazione penetration-tests

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

Test di penetrazione - Superato penetration-tests-passed

Vengono passati tutti i criteri richiesti.

Test di penetrazione - Risultati penetration-tests-results

Report creati per l'azienda che spiega 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 delle prestazioni e su come scalare la soluzione in modo che continui a soddisfare tali KPI.

Benchmark delle prestazioni performance-benchmark

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

KPI delle prestazioni performance-kpis

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

Test delle prestazioni - Report performance-tests-report

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

Test delle prestazioni - Risultati e prestazioni dei KPI performance-tests-results-match-performance-kpis

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

Concetto di test basato su Persona persona-based-testing-concept

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

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

POC Testato e verificato rispetto alla documentazione sui requisiti poc-tested-and-verified-against-requirement-documentation

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

Elenco di controllo post-distribuzione post-deployment-checklist

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

Lista 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 della linea di base dell'ambiente di produzione production-environment-baseline-performance-tests

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

Ambiente di produzione pronto production-environment-ready

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

Disattivazione della produzione dalle parti interessate production-sign-off-from-business-stakeholders

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

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

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

Piano di comunicazione del progetto project-communication-plan

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

Sforzi Di Progetto - Stime Finali project-efforts-final-estimates

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

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

Queste stime vengono utilizzate per le risorse e il budget.

Sforzi Per I Progetti - Stime Iniziali project-efforts-initial-estimates

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

Organizzazione del progetto project-organization

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

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

Documento ambito progetto project-scope-document

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

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

Report sullo stato del progetto in una cadenza definita project-status-reports-within-a-defined-cadence

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

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

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

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

Regole di eliminazione purge-rules

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

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

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

Rilascia 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 devono includere:

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

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

Versione finale in esecuzione e attiva in produzione.

Termini del contratto rilevanti relevant-contract-terms

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

Cadenza dei rapporti reporting-cadence

Insieme al cliente, definisci la frequenza dei rapporti che gli vengono 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 crescenti dell'archivio, viene implementata una strategia di ottimizzazione per rimuovere i dati obsoleti.

Richiesta di configurazione della sezione Progetto nel portale di supporto Adobe request-for-setting-up-project-section-in-adobe-support-portal

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

Documentazione sui requisiti requirements-documentation

Questa serie di documenti copre 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 necessari per andare in diretta siano dotati di personale e disponibili.

Valutazione del rischio risk-assessment

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

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

Piano di attenuazione dei rischi risk-mitigation-plan

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

Aspettative sul ROI roi-expectations

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

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

Ruoli e concetto di diritti roles-and-rights-concept

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

Ruoli e concetto dei diritti soddisfa le linee guida sulla sicurezza roles-and-rights-concept-meets-security-guidelines

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

Ruoli e specifiche dei diritti roles-and-rights-specification

Specifica dettagliata basata sul concetto Ruoli e diritti.

Architettura della sicurezza Recommendations security-architecture-recommendations

Recommendations relativo alla sicurezza dell'architettura software e hardware.

Linee guida sulla codifica basate sulla sicurezza security-based-coding-guidelines

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

Lista di controllo sicurezza security-checklist

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

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

Concetto di sicurezza security-concept

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

Bozza del concetto di sicurezza security-concept-draft

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

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

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

Disattivazione della sicurezza dalle parti interessate security-sign-off-from-business-stakeholders

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

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

Imposta i processi di supporto richiesti.

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

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

Concetto di prova del fumo smoke-test-concept

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

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

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

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

Strategia di architettura del software software-architecture-strategy

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

Commissione di revisione della soluzione istituito e set di cadenza della riunione solution-review-board-established-and-meeting-cadence-set

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

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

Runbook della soluzione solution-runbook

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

Procedura di spegnimento e accettazione della soluzione 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 per qualsiasi funzionalità speciale considerata al di fuori del normale ambito di sviluppo sulla piattaforma AEM.

Specifiche delle funzionalità speciali special-functionality-specification

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

Linee guida specifiche specification-guidelines

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

Processo di revisione e approvazione delle specifiche Definito e comunicato specification-review-and-approval-process-defined-and-communicated

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

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

Personale interno che necessita di formazione per gestire la soluzione.

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

Personale interno che necessita di formazione per creare la 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 a conoscenza delle definizioni di successo e dei criteri stakeholders-are-aware-of-success-definitions-and-criteria

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

Le parti interessate comprendono i progetti 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 e le aspettative generali, sia interne al team di progetto che al cliente.

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

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

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

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

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 lead sulla qualità consiste nell’assicurarsi che vi siano risorse disponibili per supportare qualsiasi utente durante il test. Ad esempio, per aiutare l’utente durante il test, quando si verificano problemi di reporting e per contribuire a convalidarli rispetto all’ambiente di test.

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

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

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

Definizione dell'architettura di sistema system-architecture-definition

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

Documentazione di System Architecture system-architecture-documentation

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

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

Descrizione dettagliata di come rendere l'architettura del 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 esami) sono identificati e valutati:

Il team è a conoscenza delle definizioni di successo e dei criteri 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 su 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

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

Specifiche tecniche technical-specification

La specifica tecnica riguarda (tra l'altro):

Specifiche del modello template-specification

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

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

Casi di test test-cases

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

Contenuto del test test-content

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

Ambiente di test pronto test-environment-ready

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

Report di test test-reports

relazioni che descrivono i risultati delle prove; compresi:

Va osservato che:

Suite di test test-suite

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

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

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

Concetto di prova testing-concept

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

Piani di prova testing-plans

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

Ambito di prova 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 il controllo della qualità e il test di accettazione degli utenti. Ciò include timeline, frequenza di reporting e esecuzione.

Concetto di integrazione di terze parti 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 sulla sicurezza di terzi 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 integrazione di terze parti 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 insieme ai sistemi di terze parti.

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

Definisce:

Definizione della soglia threshold-definition

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

Ad esempio:

Timeline e pietre miliari timeline-and-milestones

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

Sforzi totali per i progetti total-project-efforts

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

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

Materiali di formazione training-materials

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 understands-scope-of-project-and-expectations

L’utente di riferimento deve confermare di comprendere pienamente:

Concetto di gestione degli URL url-handling-concept

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

Il concetto dovrebbe anche riguardare:

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 un utente o un 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 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. Essi devono controllare dettagli quali la fatturazione, gli importi e i metodi/i tempi di segnalazione del budget.

Risultati del test della casella bianca white-box-test-results

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

Specifiche del flusso di lavoro workflow-specifications

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

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

Concetto dei flussi di lavoro workflows-concept

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