Glossaire glossary

Ce glossaire répertorie (par ordre alphabétique) les détails de tous les documents livrables de la liste de contrôle de projet.

Acceptation des parties prenantes de l’entreprise acceptance-from-business-stakeholders

L’acceptation par les parties prenantes de l’entreprise confirme qu’elles, en tant que parties prenantes clés, sont alignées sur la solution et ont donné leur approbation quant à la manière dont les exigences métier répondent aux exigences de l’analyse de rentabilité.

Tests d’acceptation acceptance-tests

Les tests d’acceptation sont effectués lorsqu’une application est prête pour la production. Ils sont réalisés dans des scénarios réels par un groupe représentant les différents types d’utilisateurs et utilisatrices finaux.

Les tests d’acceptation permettent de confirmer que :

Plus tôt vous planifiez et concevez vos tests d’acceptation, plus facile sera le déploiement final. Ils doivent être définis avec le client ou la cliente et votre équipe d’assurance qualité.

Bien que vous ne puissiez pas définir tous les détails dès le début du projet, les définitions initiales doivent être discutées et convenues. Les tests d’acceptation seront probablement basés sur les exigences fondamentales (fonctionnelles et performance).

Accès au système de test coordonné access-to-test-system-coordinated

Assurez-vous que tous les rôles ont reçu les niveaux d’accès au système requis.

Liste de contrôle de sécurité Adobe adobe-security-checklist

La liste de contrôle de sécurité Adobe est la liste de contrôle officielle fournie pour s’assurer qu’Adobe Experience Manager (AEM) est sécurisé lors de l’installation. Elle contient les mesures de sécurité et les étapes de vérification que vous devez suivre afin de garantir l’intégrité de votre instance.

Configuration du projet du portail d’assistance Adobe adobe-support-portal-project-set-up

Le portail d’assistance Adobe permet aux partenaires, clientes et clients de configurer l’implémentation d’AEM en tant que projet dans le portail d’assistance.

Des informations détaillées peuvent être enregistrées, par exemple sur les technologies et versions mises en œuvre. Elles assurent la transparence entre le client ou la cliente et Adobe.

Formation des administrateurs et administratrices AEM aem-administrator-training

Formation à la solution pour le personnel administratif. Pour plus d’informations, consultez les services de formation Adobe.

Formation de création AEM aem-author-training

Formation destinée au personnel qui produira (créera) du contenu pour la solution. Pour plus d’informations, consultez les services de formation Adobe.

Examen de certification AEM aem-certification-exam

Assurez-vous que les personnes appropriées sont enregistrées pour passer les examens de certification pertinents.

Certifié(e) AEM aem-certified

Assurez-vous que la personne appropriée a réussi les examens de certification pertinents.

Formation technique AEM aem-technical-training

Offrez une formation technique aux personnes appropriées, par exemple pour le développement, l’architecture, l’ingénierie et la pratique des affaires.

Accord sur les KPI définis comme objectifs pour le projet agreement-on-kpis-defined-as-goals-for-the-project

Les indicateurs de performances clés (KPI) aident une organisation à définir et à mesurer la progression vers ses objectifs. Une fois qu'une organisation a analysé sa mission et défini ses objectifs, elle doit mesurer les progrès vers ces objectifs. Les KPI constituent un mécanisme de mesure.

Alignement des KPI de performance et métier align-business-and-performance-kpis

L’alignement de vos KPI métier et de performance permet de rassembler toutes les personnes et tous les processus impliqués au sein de l’organisation. Cela contribue à réduire le temps et les efforts nécessaires pour atteindre les objectifs de l’entreprise et l’objectif proposé.

Alignement de l’architecture de contenu avec les KPI alignment-of-content-architecture-with-kpis

Assurez-vous que l’architecture de contenu proposée est alignée sur les indicateurs de performance clés (KPI) pertinents.

Alignement de la feuille de route cliente avec la chronologie du projet alignment-of-the-customer-roadmap-with-project-timeline

La feuille de route cliente se compose de jalons de haut niveau et d’objectifs commerciaux. La chronologie du projet doit respecter et s’aligner sur cette stratégie, de sorte que tous les risques potentiels et/ou les écarts possibles doivent être mis en évidence et suivis.

Définition de l’architecture d’application application-architecture-definition

L’architecture des applications doit définir clairement le comportement des applications proposées.

Elle est axée sur :

Tâches de maintenance spécifiques à l’application définies application-specific-maintenance-tasks-defined

Outre les tâches de maintenance standard d’Adobe Experience Manager (AEM), vous devez définir toutes les autres tâches opérationnelles qui doivent être exécutées pour la maintenance continue de la solution.

Personnel correctement formé appropriately-trained-staff

Assurez-vous que les membres de votre équipe ont reçu une formation appropriée. Pour les équipes du projet, il est recommandé de disposer de tous les éléments suivants :

Diagramme d’architecture architecture-diagram

Le diagramme d’architecture est une représentation graphique de l’architecture. Il comprend la représentation des éléments suivants :

Version préliminaire de l’architecture architecture-draft

Il s’agit d’une vue d’ensemble du système et de l’architecture de la solution. À ce stade, il s’agit d’une version préliminaire qui sera révisée et affinée ultérieurement.

Validation de l’ARB (Architecture Review Board) architecture-review-board-sign-off

L’ARB est un organisme interorganisationnel qui :

L’ARB doit être représentatif de toutes les parties prenantes clés impliquées dans l’architecture. En règle générale, il est composé d’un groupe de cadres responsables de l’examen et de la maintenance de l’architecture globale.

Suite de tests automatisés adaptée au contenu réel et aux résultats par rapport aux KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Scripts d’automatisation et cas d’utilisation automatisés de base :

Stratégie de test automatisé automated-testing-strategy

Cette stratégie définit un cadre pour les scripts automatisés réutilisables, ainsi que l’approche prévue par l’équipe d’assurance qualité (QA). Elle décrit le plan général pour les tests d’automatisation afin de garantir :

Stratégie de test automatisé validée par rapport à une charge réaliste et attendue automated-testing-strategy-validated-against-realistic-and-expected-load

La stratégie de test automatisé doit être validée et ajustée en fonction du contenu et de la charge attendue sur la solution.

Stratégie d’automatisation automation-strategy

L’automatisation des déploiements permet d’assurer des déploiements plus rapides et cohérents. La stratégie d’automatisation décrit la configuration de tels mécanismes d’automatisation, notamment :

Connaissance du plan de communication aware-of-communication-plan

L’ensemble de l’équipe du projet et toutes les parties prenantes doivent confirmer qu’elles ont connaissance des éléments suivants :

Connaissance des définitions et des critères de réussite aware-of-success-definitions-and-criteria

L’ensemble de l’équipe du projet et toutes les parties prenantes doivent confirmer qu’elles ont connaissance des éléments suivants :

Concept de sauvegarde et de restauration backup-and-restore-concept

Le concept de sauvegarde et de restauration décrit les fonctionnalités techniques qui seront implémentées dans la solution. Il est nécessaire pour la politique de sauvegarde et de restauration de l’entreprise.

Test basé sur la sauvegarde et la restauration backup-and-restore-tested

Test complet de bout en bout basé sur le concept de sauvegarde et de restauration.

Analyses de rentabilité business-case-s

Un document d’étude de cas dresse la liste des arguments relatifs à la réalisation d’une action, à la réalisation d’une autre action (si disponible) ou à l’absence d’action. Les arguments doivent être équilibrés, fondés sur des faits concrets (chaque fois que cela est possible/pertinent) et mettre en évidence les avantages et les risques pour tous les cas.

Un document d’analyse de rentabilité doit être une définition claire de toutes les options, concluant par un argument convaincant pour l’implémentation de la solution proposée.

L’analyste de la rentabilité comprend la portée du projet et les attentes business-analyst-understands-scope-of-project-and-expectations

L’analyste de la rentabilité doit comprendre parfaitement :

KPI d’entreprise business-kpis

Les organisations utilisent des indicateurs de performances clés (IPC) pour évaluer leur capacité à atteindre des cibles.

Les KPI d’entreprise définissent des valeurs mesurables qui montrent l’efficacité avec laquelle une entreprise atteint ses principaux objectifs commerciaux. Il est important de choisir les KPI appropriés à votre entreprise/scénario et de définir clairement ce qu’ils sont, comment ils sont mesurés, comment ils sont utilisés et par qui.

Documentation des exigences de l’entreprise business-requirements-documentation

Un document des exigences de l’entreprise décrit la solution commerciale pour un projet, fournissant une spécification claire des attentes et des besoins commerciaux de la clientèle. Il fait également la distinction entre la solution commerciale et la solution technique.

Lors de l’examen de la solution d’entreprise, le document des exigences de l’entreprise doit répondre à la question suivante :
« Que souhaite faire l’entreprise ? »

Validation par l’entreprise de tout ajustement requis pour la solution ou l’architecture identifié et aligné par rapport aux attentes en matière de ROI et de KPI business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

Les processus d’évaluation des risques et de test de pénétration peuvent générer des problèmes et des résultats qui doivent être abordés dans l’architecture ou le développement de la solution.

Les ajustements résultant de ces processus doivent être examinés et approuvés par l’entreprise, et évalués par rapport aux objectifs généraux.

Stratégie de mise en cache caching-strategy

La stratégie de mise en cache décrit les éléments qui seront mis en cache pour l’utilisateur ou l’utilisatrice finale. Elle doit être conforme aux KPI.

Par exemple, des éléments tels que des images, du code JavaScript et d’autres fichiers serveur peuvent être mis en cache pour améliorer les performances d’une solution.

Consignes de codage coding-guidelines

Les directives de codage définissent les principes de base que les développeurs et développeuses doivent respecter lors du développement de la solution. Il peut s’agir, entre autres :

Communication du manuel des opérations communicate-operations-manual

Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu le manuel des opérations.

Communication du rapport de test de performances communicate-performance-test-report

Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu le rapport de test de performances.

Communication des notes de mise à jour communicate-release-notes

Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu les notes de mise à jour.

Communication de la portée et les attentes à l’équipe communicate-scope-and-expectations-to-team

Assurez-vous que l’équipe du projet est pleinement consciente de la portée du projet et des attentes en matière de diffusion, et qu’elle s’y conforme.

Communication des documents de formation et des guides d’utilisation communicate-training-materials-and-user-guides

Assurez-vous que l’ensemble des personnes/rôles appropriés reçoivent le matériel de formation et les guides d’utilisation.

Conformité aux exigences de sécurité de la clientèle compliance-with-customer-security-requirements

Assurez-vous que toutes les exigences de sécurité de la clientèle sont en place.

Conformité au concept de sécurité compliance-with-security-concept

Assurez-vous que le concept de sécurité est en place.

Concept de relation entre les composants et les modèles components-and-templates-relationship-concept

La composition des modèles et des composants utilisés dans la nouvelle application. Inclut des détails tels que les règles d’héritage, les autorisations et les relations.

Spécification de la relation entre les composants et les modèles components-and-templates-relationship-specification

Détails du concept de relation entre les composants et les modèles.

Spécification des composants components-specification

Détails des spécifications de chacun des composants à mettre en œuvre.

Concept des maquettes des interfaces externes concept-for-mock-ups-of-external-interfaces

Le concept de développement et de test des interfaces externes qui peuvent ne pas être ouvertes/disponibles pour les environnements de développement ou de test.

Planifiez/implémentez des maquettes de ces interfaces pour vous assurer que les tests sont aussi proches que possible du comportement de production.

Document d’architecture de contenu content-architecture-document

Documentation de l’architecture proposée du contenu. Les détails doivent inclure, entre autres, les éléments suivants :

Contenu validé pour migration content-validated-for-migration

Le contenu système hérité est examiné et le contenu sélectionné est validé pour migration vers la nouvelle solution.

Version préliminaire du contrat contract-draft

Une première version du contrat juridique.

Structure et format de contenu actuel current-content-structure-and-format

Documentation de l’architecture et du format du contenu actuel. Elle est utilisée pour générer la future architecture de contenu. Elle sert également pour le concept de migration.

Politique de sauvegarde et de restauration de la clientèle customer-backup-and-restore-policy

Politiques de la clientèle concernant les éléments suivants :

Consignes relatives au code de la clientèle customer-coding-guidelines

Toutes les instructions/exigences de la clientèle concernant la manière dont le développement doit être effectué.

Politiques de déploiement/publication de la clientèle customer-deployment-release-policies

Politiques de la clientèle définissant comment et quand les déploiements/publications peuvent être effectués.

Il s’agit souvent de calendriers, de planifications et d’exigences de validation.

Politiques ou exigences de surveillance de la clientèle customer-monitoring-policies-or-requirements

Stratégies et exigences de la clientèle concernant les éléments à surveiller. Ces recommandations s’ajoutent aux recommandations spécifiées dans le concept de surveillance.

Calendrier des publications de production de la clientèle customer-production-release-schedule

Le planning défini par la clientèle pour les versions des environnements de production.

Politiques et exigences de création de rapports de la clientèle customer-reporting-policies-and-requirements

Toutes les politiques et/ou exigences de la clientèle concernant les rapports. Cela peut inclure :

Feuille de route de la clientèle customer-roadmap

Établissez une feuille de route des principaux jalons à mettre en œuvre, aussi bien sur le plan technologique que métier. Cette feuille de route est ensuite communiquée à la clientèle.

Politiques de sécurité de la clientèle customer-security-policies

La clientèle (entreprise et informatique) aura des politiques qui définissent les niveaux de sécurité requis pour la solution. Cela peut inclure :

Instructions relatives aux spécifications de la clientèle customer-specification-guidelines

Toutes les directives de la clientèle relatives au format, à la diffusion et à l’approbation des spécifications.

Rapports de test de la clientèle customer-test-reports

Rapports de la clientèle à la ou au responsable qualité pendant la période de test d’acceptation utilisateur (UAT).

Personnalisations et correctifs documentés affectant les mises à niveau customizations-and-hotfixes-that-affect-upgrades-documented

Toutes les personnalisations et/ou les correctifs appliqués doivent être documentés, car ils peuvent avoir un impact sur les futures mises à niveau :

Rapport de test d’acceptation utilisateur quotidien daily-user-acceptance-test-report

Rapports ou réunions résultant du test d’acceptation utilisateur (UAT). Ils doivent détailler :

Sécurité par défaut activée default-security-enabled

Assurez-vous que les paramètres de sécurité par défaut d’AEM ont été activés/implémentés.

Politiques et processus de déploiement et de publication deployment-release-policies-and-processes

Politiques formalisées couvrant à la fois le déploiement et les versions de votre projet. Cela peut inclure :

Cadence de déploiement établie deployment-cadence-established

Définissez la fréquence requise des déploiements entre les environnements.

Méthodologie de développement development-methodology

Une méthodologie de développement logiciel implique de diviser l’ensemble du processus de développement logiciel en phases (ou étapes) distinctes, chacune ayant des activités distinctes. L'objectif est d’améliorer la planification et la gestion.

Lors de la définition de la méthodologie, vous devez prédéfinir des livrables et des artefacts spécifiques créés et terminés par l’équipe de projet pour développer ou gérer votre application.

Définition du rôle de développement development-role-definition

Définissez le développeur ou la développeuse et/ou le rôle qui exécute les tests informatiques (performances ou autres) et/ou unitaires dans la solution.

Environnement de développement prêt development-environment-ready

Assurez-vous que l’environnement de développement est configuré avec les outils intégrés requis pour l’automatisation des déploiements.

L’équipe de développement comprend la portée du projet et les attentes development-team-understands-scope-of-project-and-expectations

L’équipe de développement doit confirmer qu’elle comprend parfaitement :

Spécification des boîtes de dialogue dialogs-specification

Détails sur les boîtes de dialogue requises pour la solution.

Documentation de la configuration de l’environnement de développement document-development-environment-setup

Documentation de l’environnement de développement.

Documentation de la configuration de l’environnement de production document-production-environment-setup

Documentation de l’environnement de production.

Documentation de la configuration de l’environnement de test document-test-environment-setup

Documentation de l’environnement de test.

Test de durabilité durability-test

Le test de durabilité affiche les performances de la solution sous une charge spécifique. Les tests évaluent la durée de vie de la solution lorsqu’elle est soumise à la charge seuil et à quels niveaux de performances.

Test de durabilité exécuté durability-test-executed

Exécution des tests de durabilité.

Concept de gestion des erreurs error-handling-concept

La gestion des erreurs fait référence à l’anticipation, la détection et la résolution des erreurs de programmation, d’application et de communication.

Documentation de la gestion des erreurs error-handling-documentation

Documentation détaillée de la gestion des erreurs proposée, basée sur le concept de gestion des erreurs.

Processus de réaffectation escalation-processes

Définition de tous les processus de réaffectation. Il y aura des processus distincts pour chaque niveau de projet :

Créer des sessions régulières d’examen de la qualité establish-regular-quality-review-sessions

Organisez régulièrement des réunions d’examen de la qualité avec les membres d’équipe concernés.

Structure d’autorisations existante existing-permissions-structure

Documentation du jeu existant d’autorisations et de groupes définis pour la solution héritée ou au sein de l’organisation.

Carte des systèmes existants existing-systems-map

Diagramme (ou ensemble de diagrammes) des systèmes et dépendances existants

Définitions et critères de réussite attendus expected-success-definitions-and-criteria

Le sponsor du projet collecte les attentes de l’entreprise associées à la réussite du projet. Il est important de disposer de l’ensemble complet des attentes au début d’un projet, car elles doivent influer sur toutes les décisions prises tout au long de la mise en œuvre.

Les attentes peuvent inclure :

Conditions requises pour la conception d’expériences experience-designs-requirements

Conditions requises pour l’ensemble de l’expérience de la solution Cela couvre des facteurs tels que la personnalisation, la persistance entre plusieurs appareils et l’expérience utilisateur, entre autres.

Spécifications de l’expérience experience-specifications

Détails des conditions requises pour la conception de l’expérience

Système externe et dépendances des utilisateurs/contexte système external-system-and-user-dependencies-system-context

Diagramme (ou ensemble de diagrammes) décrivant l’écosystème complet de la solution Celui-ci doit inclure des éléments tels que les intégrations externes, les interfaces, les dépendances et les réseaux.

Système et procédure de secours fallback-system-and-procedure

La définition du système de secours :

Système et procédure de secours testés fallback-system-and-procedure-tested

Test de bout en bout du système de secours

Validation du système de secours par les parties prenantes de l’entreprise fallback-system-sign-off-from-business-stakeholders

Validez, auprès des parties prenantes de l’entreprise, que le système de secours et les procédures associées garantissent les fonctionnalités métier essentielles.

Confirmation de faisabilité des KPI feasibility-confirmation-on-kpis

Résultats d’une étude de faisabilité pour AEM et la conception de solution de haut niveau Ces indicateurs doivent être mesurés par rapport aux KPI pour s’assurer que ceux-ci peuvent être atteints.

Contrat finalisé finalized-contract

Un contrat finalisé et signé est requis avant de poursuivre le projet. Il repose sur la Version préliminaire du contrat.

Fonctionnalité de la solution acceptée par les parties prenantes functionality-of-the-solution-accepted-by-stakeholders

Confirmation que les parties prenantes acceptent entièrement les points suivants :

Planification de la mise en production go-live-schedule

Chronologie et planification des activités requises pour les points suivants :

Chemins propices définis happy-paths-defined

Un chemin propice est un scénario par défaut ne présentant aucune condition exceptionnelle ni aucune condition d’erreur. Il est composé de la séquence d’activités exécutée lorsque tout se passe comme prévu.

Estimations concernant le matériel hardware-estimates

Estimations initiales des points suivants :

Le matériel sera disponible pour répondre aux exigences. hardware-will-be-available-to-fulfill-requirements

Confirmation que tous les environnements bénéficieront du matériel minimum requis.

Exigences de haut niveau high-level-requirements

La définition des exigences de haut niveau fournit une répartition générale des exigences du système, couvrant des aspects tels que :

Les détails de base sur ces fonctions sont généralement connus. Par conséquent, ce document ne doit pas être une estimation.

Conception de solution de haut niveau high-level-solution-design

La conception de solution de haut niveau explique l’architecture utilisée pour développer la solution. Le diagramme d’architecture donne un aperçu de l’ensemble du système, identifiant les principaux composants développés pour le produit et leurs interfaces.

Carte système de haut niveau high-level-system-map

Cette carte système doit fournir un diagramme de haut niveau du système. Elle diffère du contexte de la solution, en ce sens qu’il s’agit d’une carte générale de tous les systèmes impliqués et qu’il n’y a pas d’interfaces sur ce diagramme.

Structure de contenu historique historical-content-structure

Définition de la structure de contenu du système hérité. Elle est utilisée à titre de référence et lors de la préparation de la stratégie de migration.

Performances historiques et KPI historiques historical-performance-and-historical-performance-kpis

Collectez et documentez les statistiques de performances et les KPI du système hérité. Ceux-ci sont ensuite utilisés comme point de référence et pour l’évaluation comparative de la nouvelle solution.

Identifier les solutions/fonctionnalités clés essentielles identify-critical-key-solutions-functionalities

Liste des fonctionnalités importantes d’entreprise.

Implémentation : modifications basées sur les résultats des tests de pénétration implementation-changes-based-on-penetration-test-results

Implémentation de toutes les modifications requises (qui ont été validées) de la solution en fonction des résultats des tests de pénétration.

Implémentation - Stratégie de test automatisé implementation-automated-testing-strategy

Configuration des outils et des processus requis pour la prise en charge des tests automatisés.

Implémentation - Stratégie d’automatisation implementation-automation-strategy

Configuration de l’ensemble d’outils et des processus requis pour prendre en charge l’automatisation.

Implémentation - Architecture de contenu implementation-content-architecture

Implémentation de l’architecture de contenu, des concepts de balisage et de la réutilisation du contenu.

Implémentation - Conception de l’expérience implementation-experience-design

Implémentation des exigences pour la prise en charge de la conception de l’expérience.

Implémentation - Procédures et système de secours implementation-fallback-system-and-procedures

Implémentation du système de secours et des procédures associées.

Implémentation - Intégration implementation-integration

Implémentation d’intégrations avec tous les systèmes externes requis.

Implémentation - Stratégie de migration implementation-migration-strategy

Migration et validation du contenu et d’autres artefacts pour la nouvelle solution.

Implémentation - Rôles et droits implementation-roles-and-rights

Implémentation des rôles et des droits, des utilisateurs et utilisatrices, et des groupes.

Implémentation - Concept de sécurité implementation-security-concept

Implémentation de toutes les mesures de sécurité, y compris les valeurs par défaut AEM.

Implémentation - Logiciel de sécurité implementation-security-software

Implémentation de la sécurité des applications logicielles.

Implémentation - Concept de sécurité de l’architecture système implementation-system-architecture-security-concept

Implémentation de la sécurité du système.

Implémentation- Gestion des URL implementation-url-handling

Implémentation du concept de gestion des URL.

Implémentation - Workflows implementation-workflows

Implémentation des workflows conçus.

Concept d’implémentation implementation-concept

Le concept de mise en œuvre fournit les principes directeurs de l’ensemble de la mise en œuvre. Il doit tenir compte de :

Ce concept décrit également les cadres, bibliothèques et autres artefacts utilisés dans la solution.

Informer l’assistance Adobe du calendrier d’activation inform-adobe-support-about-the-go-live-schedule

Contactez l’assistance Adobe pour vous assurer que toute assistance nécessaire pourra être mise en place pendant la mise en production.

Conceptions d’expérience initiale initial-experience-designs

Concepts préliminaires pour les conceptions des expériences.

Test d’intégration integration-testing

Tests et confirmation associée de toutes les intégrations, internes et externes.

Cette opération doit être automatisée et exécutée fréquemment pour garantir la stabilité du système.

Processus de suivi des problèmes issue-tracking-process

Des processus clairs enregistrent tous les problèmes rencontrés et effectuent le suivi des activités en cours dans le but d’assurer le traitement de tous les problèmes.

Système et processus de suivi des problèmes issue-tracking-system-and-processes

Un système de suivi, ainsi que les processus requis, pour enregistrer tous les problèmes rencontrés et suivre les activités en cours dans le but d’assurer le traitement de tous les problèmes.

Toutes les parties prenantes du projet doivent y avoir accès à pour faciliter la transparence du statut du projet.

Par exemple, Atlassian JIRA et HP Quality Center.

Le processus du système de suivi des problèmes est configuré et intégré. issue-tracking-system-process-is-set-up-and-integrated

L’outil sélectionné est entièrement intégré et l’accès est accordé à tous les rôles requis.

Système hérité legacy-system

Pour votre projet, le système hérité correspond à la technologie, au système informatique et au programme d’application existants qui seront remplacés par la nouvelle solution.

Il convient de recueillir des informations détaillées sur le système existant, afin de déterminer ce qui peut être retiré et à quel moment, ou encore quel sera l’impact sur les autres systèmes.

Liste des outils de développement à utiliser list-of-development-tools-to-be-used

Présentation des outils qui seront utilisés pour l’implémentation, notamment :

Liste des personnes ayant besoin d’un accès au portail d’assistance Adobe list-of-users-that-require-access-to-adobe-support-portal

Liste de l’ensemble des personnes et des rôles devant accéder au portail d’assistance Adobe.

La liste comprend normalement l’architecte de la solution et/ou le personnel informatique de la société cliente.

Analyse des fichiers journaux log-file-analysis

Une analyse, ainsi que les recommandations qui en résultent, définissant ce qui doit être consigné pour surveiller la solution :

Tâches de maintenance (spécifiques à AEM) testées et activées maintenance-tasks-aem-specific-tested-and-enabled

Testez et activez les tâches de maintenance AEM telles que les suivantes :

Plan de migration migration-plan

Documentation de la la migration, y compris

Stratégie de migration migration-strategy

Description complète du contenu, de l’architecture de contenu et des formats existants mappés à la nouvelle solution. Elle doit couvrir les éléments suivants :

Il est également recommandé de maintenir le contenu à jour (ou le plus à jour possible) pendant la période entre la migration et la mise en production effective du nouveau système. Cela peut impliquer un gel du contenu, une double publication ou la maintenance d’un système alpha.

Surveillance - Processeur monitoring-cpu

Surveillance de l’utilisation du processeur du système par la solution :

Surveillance - E/S de disque monitoring-disk-i-o

Surveillance des débits d’entrée et de sortie du disque de la solution :

Surveillance - Espace disque monitoring-disk-space

Surveillance de l’utilisation de l’espace disque par la solution :

Vous devez surveiller l’utilisation par :

Surveillance - Systèmes externes monitoring-external-system-s

Surveillez toutes les connexions entre la solution et les systèmes externes :

Surveillance - Bande passante réseau monitoring-network-bandwidth

Surveillez l’utilisation de la bande passante réseau de la solution :

Surveillance - Requêtes monitoring-requests

Surveillez les requêtes effectuées sur la solution.

Surveillance - Points de sécurité monitoring-security-points

Surveillez aux points de sécurité définis.

Surveillance - Système monitoring-system

Surveillez l’ensemble du système, par exemple :

Surveillance - Seuil et intervention monitoring-threshold-and-intervention

Surveillance du seuil défini de la solution, ainsi que mise en œuvre des étapes d’intervention pour réduire la charge.

Concept de surveillance monitoring-concept

Les concepts de surveillance à appliquer à votre solution, notamment :

La surveillance des points faibles potentiels monitoring-potential-weak-points

Il convient d’identifier et de définir les points spécifiques susceptibles d’échouer. Toutes les tâches de surveillance qui y sont liées doivent également être définies.

Par exemple :

Politique de surveillance communiquée à l’ingénieur ou ingénieure système monitoring-policy-communicated-to-system-engineer

Assurez-vous que les ingénieurs et ingénieures système et le personnel d’exploitation connaissent et comprennent les politiques de surveillance.

Rapports de surveillance - Structure en place monitoring-reports-structure-in-place

Définissez ce qui suit :

Documentation des tâches opérationnelles operational-tasks-documentation

Toutes les tâches opérationnelles documentées, avec leur fréquence définie.

Manuel des opérations operations-manual

Manuel fournissant toutes les informations requises pour le bon fonctionnement et la maintenance de la solution :

Doit également détailler les concepts de mise en œuvre pour :

Package préparé package-prepared

Package logiciel créé et livré prêt pour le déploiement.

Tests de pénétration penetration-tests

Un test de pénétration (connu sous le nom informel de « pen test ») est une attaque sur un système informatique qui recherche des failles de sécurité, susceptibles d’avoir accès aux fonctionnalités et aux données de l’ordinateur.

Tests de pénétration - Réussis penetration-tests-passed

Tous les critères requis sont remplis.

Tests de pénétration - Résultats penetration-tests-results

Rapports créés pour l’entreprise expliquant les résultats des tests de pénétration.

Concept de performances et d’évolutivité performance-and-scalability-concept

Document conceptuel sur la manière de vous assurer que votre mise en œuvre réponde aux KPI de performance et de mettre à l’échelle la solution afin qu’elle continue à répondre aux exigences de ces KPI.

Référence des performances performance-benchmark

La référence des performances sert à définir les tests de performance, les tests de durabilité et la surveillance. Pour ce faire, elle évalue les caractéristiques de performance de la solution et du matériel du système.

KPI de performance performance-kpis

Ils définissent les KPI requis pour mesurer les performances du système. Voici quelques exemples : temps de chargement des pages, temps de réponse du serveur et performances des requêtes de base de données.

Tests de performance - Rapport performance-tests-report

Rapports créés pour l’entreprise, détaillant les résultats des tests de performance.

Tests de performance - Les résultats correspondent aux KPI de performance performance-tests-results-match-performance-kpis

Les résultats doivent correspondre aux KPI et aux attentes de performance définis.

Concept de test basé sur les personnes persona-based-testing-concept

Les tests basés sur les personnes sont une méthode basée sur les différentes personnes décrites dans les conceptions d’expérience. Ils testent également les comptes et leurs niveaux d’autorisations associés.

Cette méthode est souvent utilisée dans les tests d’acceptation utilisateur (UAT).

Documentation Preuve de concept (POC) testée et vérifiée par rapport aux exigences poc-tested-and-verified-against-requirement-documentation

La preuve de concept (POC) est évaluée par rapport aux exigences afin de s’assurer que toutes sont alignées.

Liste de contrôle post-déploiement post-deployment-checklist

Liste de contrôle permettant de définir la série de vérifications et de tâches à effectuer après chaque déploiement.

Liste de contrôle préalable au déploiement pre-deployment-checklist

Liste de contrôle permettant de définir la série de vérifications et de tâches à effectuer avant chaque déploiement.

Tests de performance de référence de l’environnement de production production-environment-baseline-performance-tests

Il est habituel d’exécuter un test de référence sur une installation standard d’AEM. Il est ensuite utilisé comme référence pour tester l’implémentation et le matériel.

Environnement de production prêt production-environment-ready

Vérifiez que l’environnement de production est prêt et que des déploiements automatisés sont en place.

Approbation de la production par les parties prenantes de l’entreprise production-sign-off-from-business-stakeholders

Avant l’activation sur l’environnement de production, l’approbation de production doit être accordée. Il s’agit du résultat d’une révision de la version qui sera envoyée en production, ainsi que de tous les problèmes connus. L’approbation est donnée dans le cadre du planning de mise en production.

Processus et politique d’approbation de production production-sign-off-process-and-policy

Politique et processus requis pour obtenir l’approbation de production avant de déplacer le package vers l’environnement de production.

Plan de communication du projet project-communication-plan

Définissez le plan de communication pour les parties prenantes de l’entreprise et l’équipe de projet.

Efforts du projet - Estimations finales project-efforts-final-estimates

Les estimations initiales étaient de haut niveau et établies en fonction des exigences de haut niveau de la mise en œuvre.

Elles sont maintenant révisées, affinées et améliorées afin de fournir les estimations finales. Les estimations doivent être fournies par chaque responsable de projet approprié(e), y compris la gestion de projet, le conseil, l’architecture, les tests et le développement.

Ces estimations sont utilisées pour l’approvisionnement et la budgétisation.

Efforts du projet - Estimations initiales project-efforts-initial-estimates

Les estimations initiales sont de haut niveau et établies en fonction des exigences de haut niveau pour la mise en œuvre. Ce point sera révisé et affiné ultérieurement.

Organisation du projet project-organization

La documentation requise pour décrire l’organisation et la structure des rapports du projet et de l’équipe.

Souvent, elle se présente sous la forme d’un graphique, ou en comprend un, pour présenter une vue d’ensemble visuel des calendriers et des responsabilités. De nombreux outils sont disponibles pour vous aider.

Document sur la portée du projet project-scope-document

Le document sur la portée du projet nécessite que vous identifiiez et documentiez une liste des éléments suivants :

Il couvre ce qui doit être accompli, ainsi que le travail à effectuer, pour mener à bien le projet.

Rapports de statut du projet dans une fréquence définie project-status-reports-within-a-defined-cadence

Les rapports de statut du projet sont remis selon le planning convenu et le format requis.

Preuve de concept (PDC) proof-of-concept-poc

La preuve de concept (POC) implémente un nombre limité de fonctions pour la solution.

Elle doit viser à démontrer la faisabilité de la solution, à vérifier qu’elle peut remplir l’objectif requis et à prouver qu’il existe un potentiel d'utilisation.

Règles de purge purge-rules

AEM conserve plusieurs versions des ressources et du contenu. Les règles de purge sont conçues et configurées pour supprimer régulièrement les anciennes versions afin de maintenir l’intégrité et la taille du référentiel.

Format et fréquence du rapport de qualité quality-report-format-and-cadence

Définissez le contenu et le format requis du rapport de qualité, ainsi que la fréquence à laquelle il doit être diffusé.

Coordination release-coordinated

Le ou la responsable de projet coordonne tous les rôles requis pour la mise en production.

Notes de mise à jour release-notes

Les notes de mise à jour font partie de la documentation de la version. Les notes de mise à jour devraient couvrir :

Elles sont utilisées avec le Runbook pour exécuter les étapes et les vérifications avant et après installation.

Exécution de la version dans l’environnement de production release-running-on-production-environment

Version finale en cours d’exécution et active en production.

Termes du contrat pertinents relevant-contract-terms

Mettez en évidence les termes spécifiques du contrat qui sont pertinents pour l’implémentation du projet, tels que les étapes contractuels, les périodes de facturation ou les besoins en personnel.

Fréquence des rapports reporting-cadence

Avec les clientes et clients, définissez la fréquence des rapports qui leur sont remis.

Optimisation du référentiel repository-optimization

Les données ne sont jamais écrasées dans un fichier TAR, l’utilisation du disque augmente même lors de la mise à jour des données existantes.

Pour contrer l’augmentation continue de la taille du référentiel, une stratégie d’optimisation est mise en place pour supprimer les données obsolètes.

Demande de configuration de la section du projet sur le portail d’assistance Adobe request-for-setting-up-project-section-in-adobe-support-portal

Demande officielle de configuration de votre projet sur le portail d’assistance Adobe.

Documentation requise requirements-documentation

Cet ensemble de documentation couvre les exigences fonctionnelles et non fonctionnelles, ainsi que les efforts estimés.

Ressources disponibles pour la prise en charge de la mise en production resources-available-to-support-go-live

Assurez-vous que tous les rôles requis pour la mise en production sont occupés et disponibles.

Évaluation des risques risk-assessment

L’évaluation des risques est effectuée par le service informatique et/ou le service de sécurité de la cliente ou du client.

Il évalue les risques techniques et commerciaux du projet. L’évaluation est nécessaire pour que la solution garantisse la conformité aux politiques de sécurité.

Plan d’atténuation des risques risk-mitigation-plan

Le plan d’atténuation des risques comprend l’évaluation des risques. Ensemble, ils couvrent :

Attentes en matière de retour sur investissement roi-expectations

Définissez les attentes relatives au retour sur investissement (ROI) associées à la solution.

Elles visent à indiquer l’efficacité de la solution en termes économiques, en définissant les bénéfices/profits attendus par rapport à l’investissement estimé.

Concept des rôles et des droits roles-and-rights-concept

Spécification détaillée des concepts relatifs aux rôles et aux droits d’accès requis pour la nouvelle application, y compris une description détaillée des éléments suivants :

Le concept de rôles et de droits respecte les directives de sécurité roles-and-rights-concept-meets-security-guidelines

Examinez le concept Rôles et droits pour vous assurer qu’il respecte les politiques de sécurité.

Spécification des rôles et droits roles-and-rights-specification

Spécification détaillée basée sur le concept des rôles et des droits.

Recommandations de l’architecture de sécurité security-architecture-recommendations

Recommandations liées à la sécurité pour l’architecture logicielle et matérielle.

Directives de codage basées sur la sécurité security-based-coding-guidelines

Ces directives définissent la manière dont le code de développement doit être effectué en fonction des exigences de sécurité, telles que :

Liste de contrôle de sécurité security-checklist

Liste de contrôle des éléments spécifiques au projet, basée sur le concept de sécurité, ainsi que toutes les politiques supplémentaires requises pour garantir la conformité de la solution.

Souvent, cela est également inclus dans les étapes de post-déploiement du runbook.

Concept de sécurité security-concept

Définissez et documentez les détails de la configuration de sécurité requis pour l’application, l’architecture et l’infrastructure.

Version préliminaire du concept de sécurité security-concept-draft

Présentation détaillée couvrant la configuration de sécurité de :

Problèmes de sécurité répertoriés et évalués security-issues-listed-and-assessed

Tous les problèmes de sécurité de la solution répertoriés et évalués, y compris les estimations de l’effort.

Approbation de la sécurité par les parties prenantes de l’entreprise security-sign-off-from-business-stakeholders

Faites valider les parties prenantes pour vous assurer que la mise en œuvre de la sécurité est conforme aux politiques et aux attentes.

Configuration des processus de support set-up-support-processes

Définissez les processus de support requis actuellement appliqués.

SLA pour systèmes tiers slas-for-third-party-systems

Assurez-vous que les contrats de niveau de service (SLA) sont disponibles et communiqués aux équipes de développement et d’exploitation pour utilisation pendant la mise en œuvre et le support.

Concept de test de fumée smoke-test-concept

Les tests de fumée consistent en un ensemble d’étapes définies qui testent les fonctionnalités clés de la solution pour assurer les opérations et les fonctionnalités de base de la solution.

Ils sont exécutés, dans n’importe quel environnement, après installation ou déploiement.

Tests de fumée exécutés pour la validation du système smoke-tests-executed-for-system-validation

Les tests de fumée doivent être exécutés sur tous les systèmes pour garantir le bon fonctionnement des fonctionnalités de base de la solution lors de l’installation ou du déploiement dans n’importe quel environnement.

Stratégie d’architecture logicielle software-architecture-strategy

Stratégie de haut niveau pour l’architecture logicielle, y compris les services, servlets, frameworks et autres décisions d’implémentation.

Mise en place d'une commission d'examen des solutions et définition d'un calendrier de réunions solution-review-board-established-and-meeting-cadence-set

La commission d’examen des solutions est composé des parties prenantes de la clientèle.

La commission organise régulièrement des réunions pour examiner en permanence les exigences actuellement définies et les spécifications pertinentes. L’objectif est d’assurer l’alignement avec la définition et les critères de réussite et de fournir également une contribution à l’élaboration des exigences.

Manuel d’exécution de la solution solution-runbook

Instructions d’installation de la solution, ainsi que les tâches opérationnelles de base à exécuter lors de l’installation.

Processus d’approbation et d’acceptation de la solution solution-sign-off-and-acceptance-process

Le processus d’approbation et d’acceptation décrit les critères qui doivent être remplis avant que la solution ne puisse être publiée dans un environnement de production.

Il peut également servir de jalon contractuel.

Concept de fonctionnalité spéciale special-functionality-concept

Concept initial pour toute fonctionnalité spéciale qui est considérée comme ne relevant pas de la portée normale du développement sur la plateforme AEM.

Spécification des fonctionnalités spéciales special-functionality-specification

Détails de toute fonctionnalité spéciale qui est considérée comme ne relevant pas de la portée normale du développement sur la plateforme AEM.

Instructions de spécification specification-guidelines

Toutes les instructions de la clientèle sur la manière dont la spécification doit être effectuée.

Processus d’examen et d’approbation des spécifications défini et communiqué specification-review-and-approval-process-defined-and-communicated

Un processus clair doit être mis en place pour l’approbation des spécifications par la clientèle. Ce processus garantit la clarté et la fermeté de la portée des exigences.

Personnel sélectionné pour la formation des administrateurs et administratrices AEM staff-selected-for-aem-administrator-training

Personnel interne qui a besoin d’être formé pour pouvoir administrer la solution.

Personnel sélectionné pour la formation de création et des utilisateurs et utilisatrices finaux staff-selected-for-author-and-end-user-training

Personnel interne qui a besoin d’une formation pour pouvoir créer sur la solution.

Parties prenantes stakeholders

Les parties prenantes sont les personnes clés et/ou les rôles qui ont un intérêt important dans le projet. Certaines vont contribuer au budget du projet.

Les parties prenantes peuvent être internes et externes.

Les parties prenantes connaissent les définitions et les critères de réussite stakeholders-are-aware-of-success-definitions-and-criteria

Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont au courant des éléments suivants :

Les parties prenantes comprennent le projet et les attentes stakeholders-understand-project-and-expectations

Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont en phase avec l’ensemble du projet et des attentes, tant au sein de l’équipe de projet que chez la clientèle.

Définition du format du rapport d’état status-report-format-definition

Les rapports d’état sont un outil de communication essentiel. Le format doit être aligné sur toutes les exigences de création de rapports de la clientèle.

Critères et définition de réussite success-criteria-and-definition

La clientèle, le sponsor du projet et la ou le responsable de projet ou la consultante ou le consultant doivent spécifier :

Ils permettent de s’assurer que les critères de réussite sont remplis :

Prise en charge de la validation des problèmes signalés support-in-validation-of-reported-issues

Une partie des responsabilités de la ou du responsable de la qualité consiste à s’assurer qu’il existe des ressources disponibles pour prendre en charge n’importe quel utilisateur ou utilisatrice lors des tests. Par exemple, pour aider l’utilisateur ou utilisatrice à tester, à signaler des problèmes et à valider les problèmes par rapport à l’environnement de test.

Processus d’assistance et accès au portail d’assistance Adobe support-processes-and-access-to-adobe-support-portal

L’accès au portail d’assistance Adobe est essentiel pour soumettre des tickets pour tout problème lié à un produit qui peut survenir lors de la mise en œuvre.

L’accès doit être attribué aux membres clés de l’équipe.

Définition de l’architecture du système system-architecture-definition

Une proposition initiale et une définition de l’architecture pour tous les environnements de la solution.

Documentation de l’architecture du système system-architecture-documentation

Document détaillant l’architecture du système, notamment les interfaces, l’emplacement réseau et les intégrations pour tous les environnements, entre autres informations.

Concept de sécurité de l’architecture système system-architecture-security-concept

Une description approfondie de la manière de rendre l’architecture du système compatible avec toutes les politiques de sécurité. Cela peut couvrir les éléments suivants :

Facteurs de risque du système identifiés et vérifiés system-risk-factors-identified-and-verified

Tous les facteurs de risque figurant dans l’évaluation des risques (ou dans d’autres examens) sont identifiés et évalués :

L’équipe connaît les définitions et les critères de réussite. team-is-aware-of-success-definitions-and-criteria

Confirmation que l’équipe entière est au courant des définitions et des critères de réussite.

L’équipe est au courant du plan de communication. team-is-aware-of-the-communication-plan

Confirmation que tous les membres de l’équipe sont conscients de l’identité de la personne qui doit communiquer avec le client ou la cliente, ainsi que des détails sur la façon et le moment où procéder.

L’équipe comprend le projet et les attentes team-understands-project-and-expectations

Alignement avec l’ensemble du projet et des attentes, à la fois en interne avec l’équipe du projet et avec le client ou la cliente.

Exigences techniques technical-requirements

Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.

Facteurs de risque techniques vérifiés technical-risk-factors-verified

Identifiez et vérifiez les risques techniques potentiels. Les risques techniques peuvent inclure :

Spécifications techniques technical-specification

La spécification technique couvre (entre autres informations) les éléments suivants :

Spécification du modèle template-specification

Les spécifications des modèles requis. Elles doivent couvrir les détails, notamment le parsys, le plan directeur et le mappage d’héritage.

Les spécifications sont basées sur les exigences de l’entreprise et de l’expérience.

Cas de test test-cases

Cas de test spécifiques aux étapes détaillées requises pour exécuter les tests fonctionnels de la solution.

Test du contenu test-content

Le contenu du test doit être le plus proche possible du contenu d’exploitation. Il doit comprendre une sélection suffisamment large afin de permettre de tester tous les scénarios.

Environnement de test prêt test-environment-ready

Assurez-vous que l’environnement de test est prêt, avec des déploiements automatisés pour vous assurer que tout le code du candidat de version est à jour pour les tests.

Rapports de test test-reports

Rapports détaillant les résultats des tests, notamment :

Il convient de noter les éléments suivants :

Suite de tests test-suite

Sélection de la suite d’automatisation et des outils. Ils sont utilisés pour automatiser les tests, y compris ceux pour les cas d’utilisation.

Suite d’outils de test sélectionnée test-tooling-suite-selected

Suite d’automatisation et outils sélectionnés pour l’automatisation des cas d’utilisation et d’autres tâches d’exécution de test.

Concept de test testing-concept

Le concept de test est la description approfondie des tests pour le projet, y compris, l’assurance qualité, l’UAT, les performances, la sécurité et les tests d’intégration.

Plans de test testing-plans

Ces plans décrivent en détail l’exécution des tests pour chaque phase de développement et reposent sur la Stratégie de test.

Portée du test testing-scope

Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.

Stratégie de test testing-strategy

La stratégie de test décrit la stratégie approfondie pour l’assurance qualité et les tests d’acceptation utilisateur. Cela inclut les chronologies, la fréquence de création de rapports et l’exécution.

Concept d’intégration tierce third-party-integration-concept

Concept de niveau architectural et système pour l’intégration à des systèmes tiers.

Spécification d’intégration tierce third-party-integration-specification

Détails des exigences (fonctionnelles et non fonctionnelles) pour les fonctionnalités prises en charge et l’intégration des systèmes tiers.

Concept de sécurité tiers third-party-security-concept

Concept pour assurer la sécurité de toute intégration tierce. Doit être conforme aux politiques de sécurité appropriées.

Système tiers pour l’intégration third-party-system-for-integration

Assurez-vous que tous les systèmes tiers sont disponibles, avec la documentation appropriée, pour la mise en œuvre de l’intégration.

Accès aux systèmes tiers activé third-party-systems-access-enabled

Droits d’accès requis accordés aux rôles respectifs utilisés avec les systèmes tiers.

Concept de test tiers third-party-testing-concept

Définit :

Définition du seuil threshold-definition

Définit les valeurs clés des points de surveillance dans le système.

Par exemple :

Calendrier et jalons timeline-and-milestones

Cela doit définir les calendriers du projet et les jalons contractuels à utiliser pour :

Total des efforts du projet total-project-efforts

Toutes les estimations de l’effort, issues de chacune des pistes du projet, doivent être consolidées, y compris les frais généraux, le développement, l’ingénierie du système, l’architecture et les efforts de test.

Si l'accord comporte un niveau de soutien, les efforts de soutien et d'exploitation devraient également être inclus.

Ressources de formation training-materials

Ressources à utiliser dans les sessions de formation. Les ressources doivent être créées spécifiquement pour la solution et conçues pour être utilisées avec les guides d’utilisation.

Comprend la portée du projet et les attentes understands-scope-of-project-and-expectations

La personne appropriée doit confirmer qu’elle comprend parfaitement les points suivants :

Concept de gestion des URL url-handling-concept

Votre concept de gestion des URL doit couvrir les fonctionnalités d’URL spécifiques à AEM, notamment :

Le concept doit également couvrir les points suivants :

Cas d’utilisation use-cases

Un cas d’utilisation est la liste des actions ou des étapes d’événement nécessaires pour atteindre un objectif. En règle générale, il définit les interactions entre un rôle et la solution. Le rôle peut être un utilisateur, une utilisatrice ou un système externe.

Cas d’utilisation convertis en scénarios de test use-cases-converted-into-test-scenarios

Les scénarios de test sont basés sur les cas d’utilisation techniques et métier. Ils sont utilisés pour tester si le comportement de la solution est conforme aux attentes.

Guides d’utilisation user-guides

Les guides d’utilisation fournissent des informations et de l’aide aux utilisateurs et utilisatrices de la solution :

Plan budgétaire validé validated-budget-plan

Le plan budgétaire doit être examiné et validé par toutes les parties prenantes. Celles-ci doivent vérifier les détails tels que la facturation, les montants et les méthodes/calendriers des rapports sur le budget.

Résultats des tests de boîte blanche white-box-test-results

Le test de boîte blanche est une méthode qui teste les structures ou les rouages internes d’une application, par opposition à ses fonctionnalités. Les tests de boîte blanche peuvent être appliqués au niveau de l’unité, de l’intégration et du système lors du processus de test du logiciel.

Spécifications de workflow workflow-specifications

En s’appuyant sur le concept des workflows, ces spécifications doivent définir les étapes de création du workflow complet en détail.

La spécification de chaque workflow doit inclure (au minimum) :

Concept des workflows workflows-concept

Les workflows permettent d’automatiser les activités AEM. Le concept des workflows décrit :