Glossario glossary

Questo glossario elenca (in ordine alfabetico) i dettagli di tutti i documenti da consegnare dell’elenco di controllo del progetto.

Accettazione da parte degli stakeholder acceptance-from-business-stakeholders

L’accettazione da parte degli stakeholder conferma che questi, in qualità di stakeholder chiave, approvano la soluzione e le modalità con cui i requisiti aziendali soddisfano il caso di business.

Test di accettazione acceptance-tests

I test di accettazione vengono eseguiti 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 pianifichi e progetti i test di accettazione, più semplice sarà la distribuzione finale. Devono essere definiti insieme al cliente e al team di Quality Assurance.

Anche nel caso in cui non ti risulti 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 (funzionalità e prestazioni).

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

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

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

L’elenco di controllo della sicurezza di Adobe è l’elenco di controllo ufficiale fornito per garantire la sicurezza 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 nel portale di supporto Adobe adobe-support-portal-project-set-up

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

È possibile registrare dettagli, ad esempio sulle tecnologie e le versioni implementate. I dettagli promuovono la trasparenza tra il cliente e Adobe.

Formazione per gli amministratori di AEM aem-administrator-training

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

Formazione per autori AEM aem-author-training

Formazione per il personale addetto alla produzione (authoring) del contenuto della soluzione. Per ulteriori informazioni, consulta Adobe Training Services.

Esame di certificazione AEM aem-certification-exam

Assicurati che gli utenti registrati per sostenere i vari esami di certificazione ricoprano ruoli pertinenti.

AEM Certified aem-certified

Assicurati che i diversi esami di certificazione siano stati superati da utenti con i ruoli appropriati.

Formazione tecnica per AEM aem-technical-training

Offri formazione tecnica a utenti con i ruoli appropriati, ad esempio sviluppatori, architetti, ingegneri e professionisti aziendali.

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

I KPI consentono a un’organizzazione di definire e misurare i progressi compiuti per 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 il raggiungimento di tali obiettivi. I KPI offrono un meccanismo di misurazione.

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

L’allineamento dei KPI aziendali e delle prestazioni consente di riunire tutte le persone e i processi coinvolti all’interno dell’organizzazione. Questo a sua volta contribuisce a ridurre il tempo e il lavoro necessari per raggiungere gli obiettivi aziendali e 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 agli indicatori prestazioni chiave (KPI, Key Performance Indicators) pertinenti.

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

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

Definizione di architettura delle applicazioni application-architecture-definition

L’architettura delle applicazioni deve definire chiaramente il comportamento delle applicazioni proposte.

È incentrata su:

Definizione della attività di manutenzione specifiche dell’applicazione application-specific-maintenance-tasks-defined

Oltre alle attività di manutenzione standard 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 formazione adeguata. Per i team di progetto, si consiglia di avere tutte le caratteristiche seguenti:

Diagramma dell’architettura architecture-diagram

Il diagramma dell’architettura è una rappresentazione grafica dell’architettura. È inclusa 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 verrà rivista e perfezionata in fasi successive.

Firma del comitato di revisione dell’architettura architecture-review-board-sign-off

Il comitato di revisione dell’architettura è un organismo interorganizzativo che:

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

Suite di test automatizzati adattati ai contenuti reali e risultati confrontati con i KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Script di automazione e casi d’uso automatizzati di base:

Strategia di test automatizzati automated-testing-strategy

Questa strategia definisce un framework per script automatizzati riutilizzabili, insieme all’approccio pianificato dal team QA (Quality Assurance). Descrive il piano complessivo per i test di automazione al fine di garantire:

Strategia di test automatizzati convalidati rispetto 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 definisce la configurazione di questi meccanismi di automazione, tra cui:

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

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

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

L’intero team del progetto e tutti gli stakeholder 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 dal criterio di backup e ripristino dell’azienda

Backup e ripristino testati backup-and-restore-tested

Test completo end-to-end basato sul concetto di backup e ripristino.

Casi di business business-case-s

Un documento del caso di business presenta le argomentazioni relative all’avvio di un’azione, alla scelta di un’alternativa (se disponibile) o alla decisione di non intraprendere alcuna azione. Le argomentazioni devono essere equilibrate, basate su fatti concreti (o comunque possibili/pertinenti), e mettere in evidenza sia i benefici che i rischi per tutti i casi.

Un documento del caso di business dovrebbe contenere una definizione chiara di tutte le opzioni e concludere con un’argomentazione convincente a favore dell’implementazione della soluzione proposta.

Un analista aziendale 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 gli indicatori chiave di prestazioni (KPI) per valutare i progressi nel raggiungimento degli obiettivi.

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

Documentazione sui requisiti aziendali business-requirements-documentation

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

Nell’esaminare la soluzione aziendale, il BRD dovrebbe rispondere alla domanda:
“Cosa vuole fare l’azienda?”

Approvazione dell’azienda per eventuali modifiche necessarie alla soluzione o all’architettura identificate e allineate alle aspettative del ROI e dei 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 causare 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 del 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 queste possono figurare:

Comunicare il manuale operativo communicate-operations-manual

Assicurati che tutti gli utenti tipo/ruoli appropriati abbiano ricevuto il manuale operativo.

Comunicare rapporto sul test delle prestazioni communicate-performance-test-report

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

Comunicare le note sulla versione communicate-release-notes

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

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

Assicurati che il team sia pienamente a conoscenza e conforme all’ambito del progetto e alle aspettative relative alla consegna.

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

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

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

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

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

Verifica che il concetto di sicurezza sia implementato.

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

La struttura dei modelli e dei componenti utilizzati nella nuova applicazione. Include dettagli quali regole di ereditarietà, autorizzazioni, relazioni e non solo.

Specifiche della relazione tra componenti e modelli components-and-templates-relationship-specification

Dettagli del concetto della relazione tra componenti e modelli.

Specifiche dei componenti components-specification

Dettagli delle specifiche per ciascuno dei componenti da implementare.

Concetto per le versioni fittizie delle interfacce esterne concept-for-mock-ups-of-external-interfaces

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

Pianifica/implementa le versioni fittizie 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 quello 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. Questo viene utilizzato per generare l’architettura del contenuto futura. Verrà utilizzato anche per il concetto di migrazione.

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

Criteri del cliente relativi a:

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

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

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

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

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 relativi a cosa monitorare. Si aggiungono a tutti i consigli specificati nel concetto di monitoraggio.

Pianificazione di rilascio della produzione del cliente customer-production-release-schedule

La pianificazione definita dal cliente per il rilascio negli ambienti di produzione.

Criteri e requisiti di reportistica dei clienti customer-reporting-policies-and-requirements

Qualsiasi criterio o requisito, o entrambi, che il cliente possiede in relazione al reporting. Questi canali possono includere:

Roadmap del cliente customer-roadmap

Elabora una tabella di marcia delle principali tappe da implementare, 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 canali 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.

Report dei test del cliente customer-test-reports

Report del 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:

Report del test di accettazione utente giornaliero daily-user-acceptance-test-report

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

Sicurezza predefinita abilitata default-security-enabled

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

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

Criteri formalizzati relativi sia alla distribuzione che al rilascio del progetto. Questi canali possono includere:

Cadenza di implementazione stabilita deployment-cadence-established

Definisci la frequenza di implementazioni richiesta 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 tappe), 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 del ruolo di sviluppo development-role-definition

Definisci quale sviluppatore e/o ruolo debba eseguire l’IT (prestazioni o altro) e/o i test 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 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 del documento document-development-environment-setup

Documentazione dell’ambiente di sviluppo.

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

Documentazione dell’ambiente di produzione.

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

Documentazione dell’ambiente di test.

Test di resistenza 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 della soglia e a quali livelli di prestazioni.

Test di resistenza eseguito durability-test-executed

Esecuzione dei test 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 escalation escalation-processes

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

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

Organizza 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 set 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 dovrebbero influenzare tutte le decisioni prese durante l’implementazione.

Le aspettative possono includere:

Requisiti per la progettazione dell’esperienza experience-designs-requirements

Requisiti per l’intera esperienza della soluzione. Riguarda fattori come la personalizzazione, la persistenza tra dispositivi, l’esperienza utente e non solo.

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. 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 end-to-end del sistema di fallback.

Approvazione del sistema di fallback degli stakeholder aziendali fallback-system-sign-off-from-business-stakeholders

Approvazione degli stakeholder aziendali 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 della pubblicazione go-live-schedule

Timeline e pianificazione delle attività necessarie per:

Definizione di 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:

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

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

Requisiti di alto livello high-level-requirements

La definizione dei requisiti di alto livello fornisce un raggruppamento generalizzato 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

La progettazione di soluzioni 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 precedente historical-content-structure

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

Prestazioni precedenti e KPI delle prestazioni precedenti historical-performance-and-historical-performance-kpis

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

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

Elenco delle funzionalità aziendali critiche.

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

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

Implementazione - Strategia di automazione implementation-automation-strategy

Configurazione del set di strumenti e dei processi necessari per supportare l’automazione.

Implementazione: architettura dei contenuti implementation-content-architecture

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

Implementazione: progettazione delle esperienze implementation-experience-design

Implementazione dei requisiti per supportare la progettazione delle esperienze.

Implementazione: sistema e procedure di fallback implementation-fallback-system-and-procedures

Implementazione 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

Implementazione di tutte le misure di sicurezza, incluse le impostazioni predefinite di AEM.

Implementazione: software di sicurezza implementation-security-software

Implementazione della sicurezza delle applicazioni software.

Implementazione: concetto di sicurezza dell’architettura di sistema implementation-system-architecture-security-concept

Implementazione della sicurezza del sistema.

Implementazione: gestione dell’URL implementation-url-handling

Implementazione del concetto di gestione dell’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.

Informare il supporto Adobe sulla pianificazione della pubblicazione inform-adobe-support-about-the-go-live-schedule

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

Progettazioni esperienza iniziale initial-experience-designs

Concetti preliminari per le progettazioni delle esperienze.

Test dell’integrazione integration-testing

Testare, e confermare conseguentemente, tutte le integrazioni, sia interne che esterne.

Per garantire la stabilità del sistema, questa operazione deve essere automatizzata ed eseguita frequentemente.

Processo di tracciamento dei problemi issue-tracking-process

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, insieme ai processi richiesti, per registrare tutti i problemi riscontrati e tracciare 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 del progetto.

Alcuni esempi includono Atlassian JIRA e HP Quality Center.

Il processo del sistema di tracciamento dei problemi è 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 del computer 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 delle soluzioni e/o dal personale IT della clientela.

Analisi dei 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

Testa e abilita le attività di manutenzione di AEM, ad esempio:

Piano di migrazione migration-plan

Documenta la migrazione; tra cui

Strategia di migrazione migration-strategy

Descrizione completa dei contenuti esistenti, dell’architettura dei contenuti e dei formati mappati 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 del disco monitoring-disk-i-o

Monitoraggio dei tassi 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:

Devi monitorare l’uso tramite:

Monitoraggio - Sistemi esterni monitoring-external-system-s

Monitoraggio delle connessioni tra la soluzione e i sistemi esterni:

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

Monitoraggio dell’utilizzo della larghezza di banda da parte della soluzione:

Monitoraggio - Richieste monitoring-requests

Monitoraggio delle richieste trasmesse alla soluzione.

Monitoraggio - Punti di protezione monitoring-security-points

Monitoraggio presso i punti di protezione definiti.

Monitoraggio - Sistema monitoring-system

Monitoraggio del sistema complessivo, ad esempio:

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

Monitoraggio della soglia definita per la soluzione, con implementazione di interventi per ridurre il carico.

Monitoraggio - Concetti monitoring-concept

I concetti di monitoraggio da applicare alla soluzione, tra cui:

Monitoraggio - Punti deboli potenziali monitoring-potential-weak-points

È necessario identificare e definire punti specifici che potrebbero originare errori. È importante definire anche eventuali attività di monitoraggio associati a tali punti.

Alcuni esempi:

Monitoraggio - Criteri comunicati al system engineer monitoring-policy-communicated-to-system-engineer

Verifica che i system engineer e lo staff operativo siano conoscano e comprendano tutti i criteri di monitoraggio.

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

Definisci:

Documentazione delle attività operative operational-tasks-documentation

Tutte le attività operative sono documentate e la loro frequenza è definita.

Manuale operativo operations-manual

Manuale con tutte le informazioni necessarie per la gestione e manutenzione della soluzione:

Dovrebbe inoltre descrivere nei dettagli i concetti di implementazione 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 pen test) è un attacco a un sistema informatico alla ricerca di punti deboli della sicurezza, che potrebbero consentire l’accesso alle funzioni e ai dati del computer.

Test di penetrazione: superato penetration-tests-passed

Sono stati superati 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 soddisfarli.

Comparazione delle prestazioni performance-benchmark

La comparazione delle prestazioni viene utilizzata per definire i test di prestazioni e durata e il monitoraggio. Il risultato si ottiene valutando le caratteristiche prestazionali della soluzione e dell’hardware di sistema.

KPI delle prestazioni performance-kpis

Si tratta degli indicatori chiave di prestazioni (KPI, Key Performance Indicators) necessari per misurare le performance del sistema. Alcuni esempi includono il tempo di caricamento della pagina, 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, che dettagliano i 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 del test basato su persone persona-based-testing-concept

Il test basato su persone è un metodo che prende come riferimento i diversi utenti tipo descritti nelle progettazioni di esperienze. Inoltre, questo test 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 rispetto alla documentazione dei requisiti poc-tested-and-verified-against-requirement-documentation

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

Elenco di controllo post-distribuzione post-deployment-checklist

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

Elenco di controllo pre-distribuzione pre-deployment-checklist

Elenco di controllo per definire la serie di verifiche 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 linea di base su un’installazione standard di AEM. Questo viene quindi utilizzato come benchmark rispetto al quale testare l’implementazione e l’hardware.

Ambiente di produzione pronto production-environment-ready

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

Approvazione della produzione da parte degli stakeholder production-sign-off-from-business-stakeholders

Prima di eseguire la pubblicazione nell’ambiente di produzione, è necessario concedere la relativa approvazione (PSO, Production Sign-Off). Questo è il risultato di una revisione della versione che entrerà in produzione, insieme a eventuali problemi noti. L’approvazione viene concessa nell’ambito della pianificazione della pubblicazione.

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

I criteri e il processo necessari per ottenere l’approvazione prima di spostare il pacchetto nell’ambiente di produzione.

Piano di comunicazione del progetto project-communication-plan

Definisci il piano di comunicazione per gli stakeholder e il team del progetto.

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

Queste vengono ora riviste, perfezionate e ampliate per fornire le stime finali. Le stime devono essere fornite da ciascun responsabile di progetto pertinente, 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.

Iniziative progetto - Stime iniziali project-efforts-initial-estimates

Le stime iniziali sono di alto livello e vengono effettuate in base ai requisiti di alto livello per l’implementazione. Questo aspetto sarà rivisto e perfezionato in fasi successive.

Organizzazione progetto project-organization

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

Spesso assume la forma di un grafico, o lo include, per presentare una panoramica visiva delle tempistiche e delle responsabilità. Esistono molti strumenti disponibili che aiutano in questa attività.

Documento ambito progetto project-scope-document

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

Descrive gli obiettivi da raggiungere e il lavoro da svolgere per realizzare il progetto

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

I rapporti sullo stato del progetto vengono consegnati in base alla pianificazione concordata e nel formato richiesto.

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

Una prova di concetto (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 esista il potenziale per il 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 in modo da mantenere l’integrità e le dimensioni dell’archivio.

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

Definisce 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 relativa al rilascio. Queste includono:

Vengono utilizzate con un runbook per eseguire i passaggi e i controlli pre e post-installazione.

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

Versione finale in esecuzione e attiva in produzione.

Termini contrattuali rilevanti relevant-contract-terms

Evidenziano i termini specifici del contratto pertinenti all’implementazione del progetto, ad esempio le tappe contrattuali, i periodi di fatturazione o i requisiti del personale.

Cadenza del reporting reporting-cadence

Concordata con la clientela, definisce la frequenza con cui verranno consegnati i rapporti.

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.

Richiesta di configurazione della sezione 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 supporto Adobe.

Documentazione sui requisiti requirements-documentation

Questa serie di documenti descrive i requisiti funzionali e non funzionali, insieme alle iniziative stimate.

Risorse disponibili per il supporto alla pubblicazione resources-available-to-support-go-live

Assicurati che tutti i ruoli richiesti per la pubblicazione siano dotati di personale e disponibili.

Valutazione del rischio risk-assessment

La valutazione del rischio 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 del rischio. Insieme riguardano:

Aspettative di ritorno sull’investimento roi-expectations

Definisci 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

Specifiche dettagliate dei concetti relativi ai ruoli e ai diritti di accesso richiesti per la nuova applicazione, 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.

Specifiche di ruoli e diritti roles-and-rights-specification

Specifiche dettagliate basate sul concetto di ruoli e diritti.

Consigli sull’architettura di sicurezza security-architecture-recommendations

Consigli relativi alla sicurezza per l’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, come:

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-implementazione 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 tratta la configurazione di sicurezza di:

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

Tutti i problemi di sicurezza della soluzione elencati e valutati, incluse le stime dello sforzo.

Approvazione della sicurezza da parte degli stakeholder security-sign-off-from-business-stakeholders

Approvazione degli stakeholder per garantire che l’implementazione della sicurezza sia conforme ai criteri e alle aspettative.

Configura 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

Garantisci che gli accordi sui livelli di servizio (SLA) siano disponibili e vengano trasmessi ai team di sviluppo e delle operazioni per l’utilizzo durante l’implementazione e il supporto.

Concetto di smoke test smoke-test-concept

Gli smoke test 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.

Smoke test eseguiti per la convalida del sistema smoke-tests-executed-for-system-validation

Gli smoke test 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 relative all’implementazione.

Comitato di revisione della soluzione stabilito e programmazione delle riunioni solution-review-board-established-and-meeting-cadence-set

Il Comitato di revisione della soluzione è composto da rappresentanti del cliente.

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

Soluzione Runbook 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 milestone 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 per amministratori 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.

Stakeholder stakeholders

Gli stakeholder sono persone e/o ruoli chiave che hanno un interesse significativo nel progetto. Alcuni contribuiranno al bilancio del progetto.

Gli stakeholder possono essere interni e/o esterni.

Gli stakeholder sono consapevoli delle definizioni e dei criteri di successo stakeholders-are-aware-of-success-definitions-and-criteria

Conferma che tutti gli stakeholder al di fuori del team di implementazione effettiva sono a conoscenza di:

Gli stakholder comprendono il progetto e le aspettative stakeholders-understand-project-and-expectations

Conferma che tutti gli stakholder 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 del 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 il consulente devono specificare:

Questi elementi vengono utilizzati per garantire l’adempimento dei criteri per il successo:

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

Una parte del compito del responsabile della qualità è garantire la disponibilità di risorse per il supporto degli utenti durante i test. Ad esempio per l’assistenza all’utente durante i test, la segnalazione di problemi e la convalida dei problemi nell’ambiente di test.

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

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

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

Definizione dell’architettura del sistema system-architecture-definition

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

Documentazione dell’architettura del sistema system-architecture-documentation

Documento che descrive l’architettura del sistema, incluse le interfacce, il percorso di rete e le integrazioni per tutti gli ambienti.

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

Descrizione di alto livello su come rendere l’architettura di sistema conforme a qualsiasi criterio di sicurezza. Può trattarsi di:

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 controlli) 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 è consapevole 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 consapevoli di chi deve comunicare con la clientela, 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 alla clientela.

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

Identifica e verifica i potenziali rischi tecnici. I rischi tecnici possono includere:

Specifiche tecniche technical-specification

Le specifiche tecniche riguardano (tra le altre informazioni):

Specifiche modello template-specification

Le specifiche dei modelli richiesti. Queste dovrebbero riguardare i 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 del test test-content

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

Ambiente di test pronto test-environment-ready

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

Rapporti sui test test-reports

Rapporti che descrivono i risultati dei test, tra cui:

Si noti che:

Suite di test test-suite

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

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

Suite di automazione e strumenti selezionati per l’automazione dei casi d’uso e di 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à, test di accettazione utente, prestazioni, sicurezza e integrazione.

Piani di test 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 del 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 il test di accettazione da parte degli utenti. Essa include le timeline, la cadenza del 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 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 milestone timeline-and-milestones

Ciò dovrebbe definire timeline dei progetti e milestone contrattuali da utilizzare per:

Sforzi totali progetto total-project-efforts

Tutte le stime dello sforzo, provenienti da ogni lead del progetto, devono essere consolidate, inclusi il sovraccarico, lo sviluppo, l’ingegneria dei sistema, l’architettura e i test.

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

Materiali per la formazione training-materials

I materiali da utilizzare per le sessioni di formazione. I materiali devono essere creati specificamente per la soluzione e progettati per essere utilizzati insieme alle guide utente.

Informazioni sull’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 di 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 budget deve essere rivisto e convalidato da tutti gli stakeholder. Devono controllare dettagli quali fatturazione, importi e metodi/tempistiche dei rapporti di budget.

Risultati test white box white-box-test-results

Il test 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 dovrebbero definire in dettaglio i passaggi che creano l’intero flusso di lavoro.

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

Concetto di flussi di lavoro workflows-concept

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