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 de l’entreprise répondent aux exigences de l’analyse de cas.

Tests d’acceptation acceptance-tests

Les tests d’acceptation sont effectués lorsqu’une application est prête pour la production. Les tests sont effectués par un groupe représentant les différents types d’utilisateurs finaux, à l’aide de scénarios réels.

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. Elles doivent être définies avec le client 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é des Adobes adobe-security-checklist

Le Liste de contrôle de sécurité des Adobes est la liste de contrôle officielle fournie pour s’assurer que 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 à l’Adobe adobe-support-portal-project-set-up

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

Les détails peuvent être enregistrés ; par exemple, à propos des technologies et versions mises en oeuvre. Elles assurent la transparence entre le client et l’Adobe.

Formation des administrateurs AEM aem-administrator-training

Formation à la solution pour le personnel administratif. Voir Services de formation d’Adobe pour plus d’informations.

Formation des auteurs AEM aem-author-training

Formation destinée au personnel qui produira (créera) du contenu pour la solution. Voir Services de formation d’Adobe pour plus d’informations.

Exit de certification AEM aem-certification-exam

Assurez-vous que les personnages appropriés sont enregistrés pour prendre les mesures appropriées examens de certification.

AEM certifié aem-certified

Assurez-vous que le personnage approprié a transmis les examens de certification.

Formation technique AEM aem-technical-training

Offrez une formation technique pour les persona appropriés, par exemple : les développeurs, les architectes, les ingénieurs et les utilisateurs en entreprise.

Accord sur les indicateurs de performance clés définis comme objectifs pour le projet agreement-on-kpis-defined-as-goals-for-the-project

Les indicateurs de performances clés (IPC) 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 réalisés dans la réalisation de ces objectifs. Les indicateurs de performance clés constituent un mécanisme de mesure.

Alignement des indicateurs clés de performance et métier align-business-and-performance-kpis

L’alignement de vos indicateurs de performance clés (IPC) métier et de performance permet d’assembler 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 atteindre l’objectif proposé.

Alignement de l’architecture de contenu avec les IPC 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 (IPC) pertinents.

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

La feuille de route du client se compose de jalons de haut niveau et d’objectifs métier. 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.

Il se concentre 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 toute autre tâche opérationnelle qui doit être exécutée pour la maintenance en cours de la solution.

Personnel correctement formé appropriately-trained-staff

Assurez-vous que votre équipe est composée du personnel disposant de la formation appropriée. Pour les équipes de 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

Vous bénéficiez ainsi d’une vue de haut niveau du système et de l’architecture de la solution. À ce stade, il s’agit d’un projet qui sera révisé et affiné ultérieurement.

Approbation du conseil d’examen de l’architecture architecture-review-board-sign-off

Le conseil d'examen de l'architecture est un organisme interorganisationnel qui :

Le comité de révision doit être représentatif de toutes les parties prenantes clés impliquées dans l’architecture. En règle générale, ils se composent d’un groupe de cadres responsables de la révision 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 indicateurs de performance clés 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). Il décrit le plan général pour les tests d’automatisation afin de vous assurer que :

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 sont au courant 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 sont au courant 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 mises en oeuvre dans la solution. Il est nécessaire pour la stratégie de sauvegarde et de restauration de l’entreprise.

Sauvegarde et restauration testées backup-and-restore-tested

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

Analyse de cas 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 (dans la mesure du possible/pertinent) et mettre en évidence les avantages et les risques pour tous les cas.

Un document d’analyse de cas doit être une définition claire de toutes les options, concluante par un argument convaincant pour la mise en oeuvre de la solution proposée.

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

L’analyste métier doit confirmer qu’il comprend parfaitement :

IPC métier business-kpis

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

Les indicateurs de performance clés de l’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 indicateurs de performance clés appropriés à votre entreprise/scénario avec des définitions claires de ce qu’ils sont, de la manière dont ils seront mesurés, de la manière dont ils seront utilisés et par qui.

Documentation sur les exigences métier business-requirements-documentation

Un document sur les exigences de l’entreprise (BRD) décrit la solution métier pour un projet, fournissant une spécification claire des besoins et des attentes du client en matière d’entreprise. Le BRD 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 de la solution ou de l’architecture identifiée et alignée par rapport aux attentes en matière de ROI et d’IPC 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 produire 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 final. Il doit être conforme aux IPC de performance.

Par exemple, des éléments tels que des images, des fichiers 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 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 tous les rôles/personnages appropriés ont reçu le manuel des opérations.

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

Assurez-vous que tous les rôles/personnages appropriés ont reçu le rapport de test de performance.

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

Assurez-vous que tous les rôles/personnages appropriés ont reçu les notes de mise à jour.

Communication de la portée et des 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 de documents de formation et de guides de l’utilisateur communicate-training-materials-and-user-guides

Assurez-vous que tous les rôles/personnages appropriés reçoivent le matériel de formation et les guides de l’utilisateur.

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

Assurez-vous que toutes les exigences de sécurité du client 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 composants qui seront utilisés dans la nouvelle application. Inclut des détails tels que des règles d’héritage, des autorisations et des relations, entre autres.

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 de spécification pour chacun des composants à mettre en oeuvre.

Concept pour les 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 :

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. Il sera utilisé pour générer la future architecture de contenu. Il sera également utilisé pour le concept de migration.

Stratégie de sauvegarde et de restauration du client customer-backup-and-restore-policy

Stratégies du client concernant :

Consignes relatives au code client customer-coding-guidelines

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

Stratégies de déploiement/publication du client customer-deployment-release-policies

Stratégies du client qui définissent comment et quand les déploiements/versions peuvent être effectués.

Il s’agit souvent d’échéances, de planification et d’exigences de validation.

Stratégies ou exigences de surveillance du client customer-monitoring-policies-or-requirements

Stratégies et exigences du client concernant ce qui doit être surveillé. Ces recommandations s’ajoutent aux recommandations spécifiées dans le concept de surveillance.

Calendrier des versions de la production client customer-production-release-schedule

Le planning défini par le client pour les versions dans les environnements de production.

Stratégies et exigences de création de rapports du client customer-reporting-policies-and-requirements

Toutes les stratégies et/ou exigences du client concernant les rapports. Il peut s’agir :

Feuille de route du client 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 au client.

Stratégies de sécurité du client customer-security-policies

Le client (entreprise et informatique) aura des stratégies qui définissent les niveaux de sécurité requis pour la solution. Il peut s’agir :

Instructions relatives aux spécifications du client customer-specification-guidelines

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

Rapports de test client customer-test-reports

Rapports du client au prospect de qualité pendant la période de test d’acceptation utilisateur (UAT).

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

Toutes les personnalisations et/ou les correctifs appliqués doivent être documentés, car ils peuvent affecter 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.

Stratégies et processus de déploiement/publication deployment-release-policies-and-processes

Stratégies formalisées couvrant à la fois le déploiement et la ou les versions de votre projet. Il peut s’agir :

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

Configuration de l’environnement de développement de document document-development-environment-setup

Documentation de l’environnement de développement.

Configuration de l’environnement de production de document document-production-environment-setup

Documentation de l’environnement de production.

Configuration de l’environnement de test de document 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 envoyée à la charge de seuil et aux niveaux de performance.

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

Exécution du ou 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 sur 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 appropriés de l’équipe.

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érience 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 appareils et l’expérience utilisateur, entre autres.

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

Détails des exigences de 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. Cela 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.

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

Approuvez, de la part des parties prenantes de l’entreprise, que le système de secours et les procédures connexes garantissent les fonctionnalités métier essentielles.

Confirmation de faisabilité des indicateurs clés de performance 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 indicateurs de performance clés 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. Cela repose sur la variable 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 :

Planification de l’activation go-live-schedule

Chronologie et planification des activités requises pour :

Chemins heureux définis happy-paths-defined

Un chemin heureux est un scénario par défaut ne présentant aucune condition exceptionnelle ou d’erreur. Elle comprend la séquence des activités exécutées lorsque tout se passe comme prévu.

Estimations concernant le matériel hardware-estimates

Estimations initiales de :

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 ventilation 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, donc ce document ne doit pas être une estimation.

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

La conception de solution de haut niveau explique l’architecture qui sera utilisée pour le développement de la solution. Le diagramme d’architecture fournit un aperçu de l’ensemble du système, identifiant les principaux composants qui seront 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 très haut niveau du système. Il 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, il n’y a aucune interface sur ce diagramme.

Structure de contenu historique historical-content-structure

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

Performances historiques et IPC de performance historique historical-performance-and-historical-performance-kpis

Vous devez collecter et documenter les statistiques de performances et les indicateurs de performance clés du système hérité. Ils sont ensuite utilisés comme point de référence et pour l’évaluation comparative de la nouvelle solution.

Identification des solutions/fonctionnalités clés essentielles identify-critical-key-solutions-functionalities

Liste des fonctionnalités métier critiques.

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

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

Mise en oeuvre - 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.

Mise en oeuvre - Stratégie d’automatisation implementation-automation-strategy

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

Mise en oeuvre - Architecture de contenu implementation-content-architecture

Mise en oeuvre de l’architecture du contenu, des concepts de balisage et de la réutilisation du contenu.

Mise en oeuvre - Conception de l’expérience implementation-experience-design

Mise en oeuvre des exigences pour la prise en charge de la conception de l’expérience.

Mise en oeuvre - Système et procédures de secours implementation-fallback-system-and-procedures

Mise en oeuvre du système de secours et des procédures associées.

Mise en oeuvre - Intégration implementation-integration

Mise en oeuvre d’intégrations avec tous les systèmes externes requis.

Mise en oeuvre - Stratégie de migration implementation-migration-strategy

Migration ainsi que la validation du contenu et des autres artefacts pour la nouvelle solution.

Mise en oeuvre - Rôles et droits implementation-roles-and-rights

Mise en oeuvre des rôles et des droits, des utilisateurs et des groupes.

Mise en oeuvre - Concept de sécurité implementation-security-concept

Mise en oeuvre de toutes les mesures de sécurité, y compris les valeurs par défaut AEM.

Mise en oeuvre - Logiciel de sécurité implementation-security-software

Mise en oeuvre de la sécurité des applications logicielles.

Mise en oeuvre - Concept de sécurité de l’architecture système implementation-system-architecture-security-concept

Mise en oeuvre de la sécurité du système.

Mise en oeuvre - Gestion des URL implementation-url-handling

Mise en oeuvre du concept de gestion des URL.

Mise en oeuvre - Workflows implementation-workflows

Mise en oeuvre des workflows conçus.

Concept de mise en oeuvre implementation-concept

Le concept de mise en œuvre fournit les principes directeurs de l’ensemble de la mise en œuvre. Il doit prendre en considération :

Ce concept peut également décrire les structures, bibliothèques et autres artefacts utilisés dans la solution.

Informer la prise en charge des Adobes du calendrier d’activation inform-adobe-support-about-the-go-live-schedule

Contactez l’assistance Adobe pour vous assurer que toute prise en charge nécessaire peut être activée pendant la mise en service.

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 résultante 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 de s’assurer que tous les problèmes sont résolus.

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 de s’assurer que tous les problèmes sont résolus.

Tous les intervenants du projet doivent avoir accès à afin de faciliter la transparence de l’état 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é est la technologie, le système informatique ou le programme d’application existants qui sera remplacé par la nouvelle solution.

Les détails de l’ancien système doivent être collectés afin que vous sachiez ce qui peut être retiré, quand et l’impact sur tout autre système.

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

un aperçu des outils qui seront utilisés dans la mise en oeuvre ; les outils doivent inclure les éléments suivants :

Liste des utilisateurs qui ont besoin d’un accès au portail d’assistance à l’Adobe list-of-users-that-require-access-to-adobe-support-portal

Liste de tous les utilisateurs et rôles devant accéder au portail d’assistance à l’Adobe.

La liste comprend normalement l’architecte de la solution et/ou le personnel informatique du client.

Analyse des fichiers journaux log-file-analysis

Une analyse, ainsi que les recommandations qui en résultent, définissant ce qui doit être consigné afin de 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 AEM tâches de maintenance telles que :

Plan de migration migration-plan

documenter la migration ; inclusion

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 :

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 service du nouveau système. Cela peut signifier un gel du contenu, une double publication ou la maintenance d'un système alpha.

Surveillance - CPU 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 en :

Surveillance - Système(s) externe(s) 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 par la solution :

Surveillance - Demandes monitoring-requests

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

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

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

Surveillance - Système monitoring-system

surveiller 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 oeuvre des étapes d’intervention pour réduire la charge.

Concept de surveillance monitoring-concept

les concepts de surveillance à appliquer à votre solution ; incorporation :

Surveillance des points faibles potentiels monitoring-potential-weak-points

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

Par exemple :

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

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

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

Définir :

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 oeuvre 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 test à l’encre) est une attaque sur un système informatique qui recherche des failles de sécurité, susceptibles d’avoir accès aux caractéristiques et aux données de l’ordinateur.

Tests de pénétration - transmis penetration-tests-passed

Tous les critères requis sont transmis.

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 performance et d’évolutivité performance-and-scalability-concept

Document conceptuel sur la manière de vous assurer que votre mise en oeuvre respecte les IPC de performance et de mettre à l’échelle la solution de sorte qu’elle continue à satisfaire ces IPC.

Évaluation des performances performance-benchmark

L’évaluation 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.

IPC de performance performance-kpis

Ils définissent les indicateurs de performance clés (IPC) 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 IPC de performances performance-tests-results-match-performance-kpis

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

Concept de test basé sur le personnage persona-based-testing-concept

Le test basé sur le personnage est une méthode basée sur les différentes personnes décrites dans les conceptions d’expérience. Il teste également les comptes et leurs niveaux d’autorisations associés.

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

Tests et vérification du point de vente par rapport à la documentation sur les exigences poc-tested-and-verified-against-requirement-documentation

La preuve de concept (PDC) est évaluée par rapport aux exigences afin de s’assurer que les deux sont alignés.

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 ligne de base de l’environnement de production production-environment-baseline-performance-tests

Il est habituel d’exécuter un test de ligne de base 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 en production, ainsi que de tous les problèmes connus. L’approbation est donnée dans le cadre du planning d’activation.

Processus et stratégie d’approbation de production production-sign-off-process-and-policy

Stratégie 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

Le estimation initiale étaient de haut niveau et conformes aux exigences de haut niveau de la mise en oeuvre.

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é, 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 oeuvre. 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 de création de rapports du projet et de l’équipe.

Souvent, il se présente sous la forme ou comprend un graphique pour présenter un aperçu visuel des calendriers et des responsabilités. De nombreux outils sont disponibles pour vous aider.

Document d’étendue du projet project-scope-document

Le document sur la portée du projet vous demande d’identifier et de documenter une liste des éléments suivants :

Il couvre ce qui doit être réalisé, ainsi que le travail à faire, pour réaliser le projet.

Rapports d’état du projet dans une cadence définie project-status-reports-within-a-defined-cadence

Les rapports d’état du projet sont remis selon le calendrier convenu et le format requis.

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

La preuve de concept (POC) met en oeuvre un nombre limité de fonctions pour la solution.

Il doit tenter de démontrer la faisabilité de la solution, vérifier qu’elle peut remplir l’objectif requis et prouver qu’elle est potentiellement utilisée.

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 périodiquement les anciennes versions afin de maintenir l’intégrité et la taille du référentiel.

Format et cadence 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é.

Version coordonnée release-coordinated

Le chef 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 :

Il est utilisé avec le Runbook pour exécuter les étapes et les vérifications préalables et post-installation.

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

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

Termes du contrat pertinents relevant-contract-terms

Vous devez mettre en évidence les termes spécifiques du contrat qui sont pertinents pour la mise en oeuvre du projet ; comme les jalons contractuels, les périodes de facture ou les besoins en personnel.

Cadence des rapports reporting-cadence

Avec le client, définissez la fréquence des rapports qui leur sont remis.

Optimisation du référentiel repository-optimization

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

Pour contrecarrer la taille toujours croissante 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 aux Adobes request-for-setting-up-project-section-in-adobe-support-portal

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

Documentation requise requirements-documentation

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

Ressources disponibles pour la prise en charge de l’activation resources-available-to-support-go-live

Assurez-vous que tous les rôles requis pour la mise en ligne sont fournis en personnel et disponibles.

Évaluation des risques risk-assessment

L’évaluation des risques est effectuée par le ou les services informatiques et/ou de sécurité du client.

Il évalue les risques techniques et commerciaux du projet. L’évaluation est nécessaire pour que la solution garantisse la conformité aux stratégies 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 du retour sur investissement roi-expectations

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

Ils 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 stratégies de sécurité.

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

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

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

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

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

Ces instructions 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 spécifique au projet des éléments, basée sur le concept de sécurité, ainsi que toute stratégie supplémentaire requise 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

Une description de haut niveau couvrant la configuration de sécurité des éléments suivants :

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 des efforts.

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

Signez les parties prenantes pour vous assurer que la mise en oeuvre de la sécurité est conforme aux politiques et aux attentes.

Configuration des processus d’assistance set-up-support-processes

Définissez les processus de prise en charge requis en place.

Contrats de niveau de service pour les 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 oeuvre et l’assistance.

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

Les tests de détection 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 détection de fumée exécutés pour la validation du système smoke-tests-executed-for-system-validation

Les tests de détection 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

la stratégie de haut niveau pour l'architecture logicielle; notamment les services, servlets, structures et autres décisions de mise en oeuvre.

Conseil d’examen des solutions établi et calendrier des réunions solution-review-board-established-and-meeting-cadence-set

Le conseil d’examen des solutions est généralement composé des parties prenantes des clients.

Le conseil 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.

Runbook de solution solution-runbook

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

Approbation de la solution et processus d’acceptation 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 d’exploitation.

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 du client 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 le client. Ce processus garantit la clarté et la fermeté de la portée des exigences.

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

Personnel interne qui aura besoin d’une formation pour administrer la solution.

Personnel sélectionné pour la formation de l’auteur et de l’utilisateur final staff-selected-for-author-and-end-user-training

Personnel interne qui aura besoin d’une formation pour 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. Certains 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 oeuvre réelle 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 oeuvre proprement dite sont en phase avec l’ensemble du projet et des attentes, à la fois internes à l’équipe de projet et clients.

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 du client.

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

Le client, le responsable de projet et le chef de projet 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 du responsable de la qualité consiste à s’assurer qu’il existe des ressources disponibles pour prendre en charge n’importe quel utilisateur lors des tests. Par exemple, pour aider l’utilisateur à 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 à l’Adobe support-processes-and-access-to-adobe-support-portal

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

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

un document détaillant l’architecture du système ; notamment les interfaces, l’emplacement réseau et les intégrations pour tous les environnements.

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

Cette section décrit de manière approfondie la manière de rendre l’architecture du système compatible avec toutes les stratégies de sécurité. Cela peut couvrir :

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 du risque (ou dans d’autres révisions) 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 qui doit communiquer avec le client, ainsi que des détails sur comment et quand.

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

Alignement avec l’ensemble du projet et des attentes, à la fois interne à l’équipe du projet et au client.

Exigences techniques technical-requirements

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

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

Identifier et vérifier les risques techniques potentiels. Les risques techniques peuvent inclure :

Spécifications techniques technical-specification

La Spécification technique couvre (entre autres informations) :

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 en place 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 seront utilisés pour automatiser les tests, y compris ceux pour les cas pratiques.

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

Suite d’automatisation et outil 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 très détaillée des tests pour le projet. notamment les tests d’assurance qualité, d’UAT, de performance, de sécurité et 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 méthode Stratégie de test.

Étendue du test testing-scope

Ces exigences sont spécifiques à la mise en oeuvre 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 de haut niveau pour l’assurance qualité et les tests d’acceptation utilisateur. Cela inclut les chronologies, la cadence de création de rapports et l’exécution.

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

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

Spécification de l’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. doivent être conformes aux stratégies 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 oeuvre 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 conjointement avec des 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 :

Chronologie 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 de système, l'architecture et les tests.

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

Matériel de formation training-materials

Matériel à utiliser dans les sessions de formation. Les documents doivent être créés spécifiquement pour la solution et conçus pour être utilisés conjointement avec les guides de l’utilisateur.

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

Le personnage approprié doit confirmer qu’il comprend parfaitement :

Concept de gestion des URL url-handling-concept

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

Le concept doit également couvrir :

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, ils définissent les interactions entre un rôle et la solution. Le rôle peut être un utilisateur 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 de l’utilisateur user-guides

Les guides de l’utilisateur fournissent des informations et de l’aide aux utilisateurs de la solution :

Plan budgétaire validé validated-budget-plan

Le plan budgétaire doit être examiné et validé par toutes les parties prenantes. Ils doivent vérifier les détails tels que la facturation, les montants et les méthodes/minutage de la création de rapports sur le budget.

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

Le test en 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 aux niveaux unité, intégration et système du processus de test du logiciel.

Spécifications de workflow workflow-specifications

Sur la base du concept de processus, ces spécifications doivent définir, en détail, les étapes qui créeront le processus complet.

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 de processus décrit :