Glossaire

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

L’acceptation des parties prenantes professionnelles confirme que les parties prenantes principales sont alignées sur la solution et ont approuvé la manière dont les exigences de l’entreprise satisfont l’étude de cas.

Les tests d’acceptation sont réalisé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, en utilisant des scénarios de la vraie vie. 

Des tests d’acceptation sont utilisés pour confirmer que :

• le projet remplit les exigences du client ;
• la solution est adaptée à son objectif ;
• les utilisateurs acceptent la solution et peuvent envisager de l’utiliser ;
• le client accepte le projet.

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

Bien que vous ne puissiez pas définir tous les détails au tout début du projet, les définitions initiales devraient être discutées et validées. Les tests d’acceptation reposeront probablement sur les exigences de base (fonctionnelles et de performance).

Assurez-vous que les niveaux requis d’accès au système ont été accordés à tous les rôles.

La liste de contrôle de sécurité d’Adobe est la liste de contrôle officielle fournie pour assurer qu’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.

Le portail d’assistance à la clientèle Adobe permet aux partenaires et aux utilisateurs de configurer l’implémentation AEM comme un projet sur le portail d’assistance à la clientèle.

Des informations peuvent être enregistrées ; par exemple, sur les technologies et les versions mises en œuvre. Cela fournit de la transparence entre le client et Adobe.

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

Formation pour le personnel qui produit du contenu pour la solution. Voir les services de formation Adobe pour plus d’informations.

Assurez-vous que les personnages appropriés sont inscrits pour passer les examens de certification pertinents.

Assurez-vous que les personnages appropriés ont réussi les examens de certification pertinents.

Fournissez la formation technique pour les personnages appropriés, par exemple : les développeurs, architectes, ingénieurs et utilisateurs en entreprise.

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 la progression vers ces objectifs. Les IPC fournissent un mécanisme de mesure. 

L’alignement de vos indicateurs de performances clés (IPC) métier et relatifs aux performances aident à regrouper toutes les personnes et tous les processus de l’organisation. Cela permet donc de réduire la durée et les efforts nécessaires pour atteindre les objectifs métier et remplir l’objectif proposé.

Assurez-vous que l’architecture de contenu proposée est alignée sur les indicateurs de performances clés (IPC) appropriés.

La feuille de route du client se compose de jalons de haut niveau et d’objectifs métier. La chronologie du projet doit se conformer à cette stratégie et s’aligner sur celle-ci, de sorte que tous les risques potentiels et/ou déviations possibles doivent être indiqués et faire l’objet d’un suivi.

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

Notamment :

• la façon dont elles interagiront les unes avec les autres et avec les utilisateurs ; 
• les données à consommer et générées par les applications, plutôt que leur structure interne.

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 effectuée pour la maintenance en continu de la solution.

Assurez-vous que votre équipe se compose d’un personnel ayant reçu une formation appropriée. Pour les équipes de projet, nous recommandons chacun des éléments suivants :

• au moins un développeur en chef certifié AEM ;
• au moins un architecte certifié AEM ;
• au moins 75 % de vos développeurs certifiés AEM ;
  cela permet aux développeurs certifiés de jouer le rôle de mentors auprès des développeurs juniors, ainsi que de garantir le partage et la transparence des connaissances.

Le schéma d’architecture est une représentation graphique de l’architecture. Elle inclut une représentation :

• des concepts ;
• de leurs principes ;
• des éléments et des composants qui font partie de l’architecture.

Il fournit une vue de haut niveau du système et de l’architecture de la solution. À ce stade, il s’agit d’un brouillon qui sera révisé et affiné à un stade ultérieur.

Le conseil d’examen de l’architecture est un corps trans-organisationnel qui :

• supervise l’implémentation d’une stratégie cohérente ;
• garantit la conformité des systèmes.

Le conseil d’examen doit représenter toutes les parties prenantes principales impliquées dans l’architecture. Elles comprennent généralement un groupe de dirigeants chargés de la révision et de la maintenance de l’architecture globale.

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

• adaptés au contenu de production ;
• vérifiés par rapport aux IPC.

Cette stratégie définit une structure pour les scripts automatisés réutilisables, ainsi que l’approche prévue par l’équipe d’assurance qualité. Elle décrit le plan global pour tester l’automatisation afin d’assurer :

• un retour sur investissement (ROI) plus élevé ;
• une couverture de test élargie ;
• une fiabilité accrue des tests avec une répétition de la qualité.

La stratégie de test automatisé doit être validée et ajustée selon le contenu et la charge attendue de la solution. 

L’automatisation des déploiements assure un déploiement plus rapide et homogène. La stratégie d’automatisation décrit la configuration de tels mécanismes d’automatisation, notamment :

• la fréquence ;
• les outils à utiliser ;
• les environnements de déploiement.

Toute l’équipe de projet et l’ensemble des parties prenantes doivent confirmer qu’ils ont connaissance :

• de la structure hiérarchique ;
• de la fréquence des rapports ;
• des canaux de communication.

Toute l’équipe de projet et l’ensemble des parties prenantes doivent confirmer qu’ils ont connaissance :

• des définitions de réussite ;
• des critères de réussite.

Le concept de sauvegarde et de restauration décrit les fonctionnalités techniques qui seront mises en œuvre dans la solution. Il est requis par la stratégie de sauvegarde et de restauration de l’entreprise.

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

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, en fonction de faits concrets (dans la mesure du possible/si approprié) et mettre en évidence à la fois les avantages et les risques pour tous les cas.

Un document d’étude de cas doit être une définition claire de toutes les options, en concluant avec un argument convaincant pour une implémentation de la solution proposée. 

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

• la portée du projet ;
• toutes les attentes des clients ;
• qu’il s’agit de la base de toutes les décisions prises par personnage et par phase dans le projet.

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

Les indicateurs de performances clés métier définissent des valeurs mesurables qui montrent l’efficacité avec laquelle une entreprise atteint les objectifs commerciaux clés. Il est important de sélectionner des IPC pertinents pour votre activité/scénario avec des définitions claires de leur nature, de la façon dont ils seront mesurés, de leur utilisation et des personnes qui les utiliseront.

Le document des exigences de l’entreprise décrit la solution d’entreprise pour un projet, en spécifiant clairement les besoins et attentes métier du client. Le document des exigences de l’entreprise distingue également la solution métier 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 ? »

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

Tous les réglages provenant de ces processus doivent être vérifiés et approuvés par l’entreprise et évalués par rapport aux objectifs généraux.

La stratégie de mise en cache décrit ce qui sera mis en cache pour l’utilisateur final. Elle doit être compatible avec les IPC de performance.

Par exemple, des éléments tels que des images, du code JavaScript et d’autres fichiers de serveur peuvent être mis en cache de façon à améliorer la performance d’une solution.

Les consignes de codage définissent les principes de base que les développeurs doivent respecter lors du développement de la solution. Elles peuvent inclure, entre autres :

• les conventions d’attribution de noms ;
• l’utilisation des services ;
• l’utilisation des bibliothèques.

Assurez-vous que chaque personnage/rôle approprié a reçu le manuel des opérations.

Assurez-vous que chaque personnage/rôle approprié a reçu le rapport de test de performances.

Assurez-vous que chaque personnage/rôle approprié a reçu les notes de mise à jour.

Assurez-vous que l’équipe de projet a pleinement connaissance de la portée du projet, ainsi que des attentes pour la livraison et qu’elle est prête à s’y conformer.

Assurez-vous que chaque personnage/rôle approprié reçoit les documents de formation et les guides de l’utilisateur.

Assurez-vous que toutes les exigences de sécurité des clients sont en place.

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

Aperçu des modèles et des composants qui seront utilisés dans la nouvelle application. Contient des informations telles que les règles d’héritage, les autorisations et les relations.

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

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

Concept sur la façon de développer et de tester toutes les interfaces externes qui ne sont pas ouvertes/disponibles pour les environnements de développement ou de test.

Planifiez/mettez en œuvre les maquettes de ces interfaces pour assurer que les tests sont aussi proches que possible du comportement en production.

Documentation de l’architecture de contenu proposée. Les détails doivent inclure notamment :

• l’arborescence de contenu ;
• les concepts de balisage ;
• les stratégies pour la réutilisation du contenu.

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

Une version initiale du contrat juridique.

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

Stratégies du client concernant :

• les processus de sauvegarde pour les données et la solution ;
• le stockage de la sauvegarde ;
• la confirmation que la sauvegarde fonctionne comme prévu ;
• la restauration en cas d’échec.

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

Stratégies du client définissant quand et comment les déploiements/publications de versions peuvent être effectués.

Il s’agit souvent de chronologies, de la planification et des conditions d’approbation.

Stratégies et exigences du client sur ce qui doit être surveillé. Elles s’ajoutent à toutes les recommandations spécifiées dans le concept de surveillance.

La planification qui est définie par le client pour la publication des versions sur les environnements de production.

Toutes les stratégies et/ou exigences du client concernant les rapports. Elles peuvent inclure :

• combien de fois les rapports spécifiques doivent être fournis ;
• le format des rapports spécifiques ;
• les besoins particuliers.

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

Le client (métier et informatique) aura des stratégies qui définissent les niveaux de sécurité nécessaires pour la solution. Elles peuvent inclure :

• les exigences pour réussir une évaluation des risques ; 
• les exigences pour réussir les tests de pénétration.
• Toute exigence de sécurité spécifique, telle que l’échappement de tous les champs de saisie, l’utilisation du chiffrement (SSL), les certificats, l’authentification et la gestion des sessions.

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

Rapports du client pour le responsable de la qualité au cours de la période de test d’acceptation utilisateur.

Tous les correctifs et/ou personnalisations appliqués doivent être documentés, car ils peuvent affecter les futures mises à niveau :

• AEM peut être hautement personnalisé selon vos besoins. Toutes les personnalisations qui peuvent affecter la mise à niveau doivent être entièrement documentées. Par exemple, toutes les modifications majeures de l’interface utilisateur (IU) AEM. 
• Toutes les mises à jour requises pour la solution actuelle doivent être entièrement documentées. Celles-ci peuvent inclure :
  • des Cumulative Fix Packs (CFP) ;
  • des Service Packs (SP) ;
  • des correctifs ;
  • des mises à niveau.

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

• les problèmes signalés ;
• l’établissement des priorités de ces problèmes.

Assurez-vous que les paramètres de sécurité par défaut d’AEM ont été activés/mis en œuvre. 

Stratégies formalisées couvrant à la fois le déploiement et la ou les versions de votre projet. Elles peuvent inclure :

• l’heure des versions ;
• la planification des jours fériés ;
• la fréquence ;
• et peuvent dépendre de l’environnement en question.

Définissez la fréquence requise des déploiements sur l’ensemble des environnements.

Une méthodologie de développement logiciel implique de diviser l’ensemble du processus de développement logiciel en phases (ou étapes) distinctes, chacune avec des activités qui lui sont propres. 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 les éléments livrables et les artefacts spécifiques qui sont créés par l’équipe de projet pour développer votre application ou en effectuer la maintenance.

Définissez quel développeur et/ou rôle réalise les tests informatiques (de performances ou autre) et/ou unitaires dans la solution.

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 doit confirmer qu’elle comprend totalement :

• la portée du projet ;
• toutes les attentes des clients ;
• qu’il s’agit de la base de toutes les décisions prises par personnage et par phase dans le projet.

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

Documentation de l’environnement de développement.

Documentation de l’environnement de production.

Documentation de l’environnement de test.

Le test de durabilité indique les performances de la solution sous une charge spécifiée. Il mesure le temps de survie et les niveaux de performance de la solution en présence de la charge seuil.

Exécution du ou des tests de durabilité.

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

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

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

• Équipe du projet
• Client
• Adobe

Organisez des réunions régulières d’examen de la qualité avec les membres appropriés de l’équipe.

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

Un schéma (ou un ensemble de schémas) des systèmes et des dépendances existants.

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 exceptions peuvent inclure :

• les IPC spécifiques, tels que l’augmentation du pourcentage de pages proposées ;
• un temps de publication du contenu réduit ;
• des objectifs de niveau supérieur, tels qu’une interface conviviale.

Exigences pour toute l’expérience de la solution. Elles couvrent des facteurs tels que la personnalisation, la persistance et l’expérience utilisateur interpériphérique.

Détails des exigences de conception de l’expérience.

Un schéma (ou ensemble de schémas) décrivant la totalité de l’écosystème de la solution. Il doit inclure des éléments tels que les intégrations, les interfaces, les dépendances et les réseaux externes.

La définition du système de secours comprend :

• les fonctionnalités métier stratégiques qui doivent continuer à fonctionner en cas de défaillance critique ;
• les processus indispensables dans le cas de l’utilisation du système de secours.

Test de bout en bout du système de secours.

Approbation des parties prenantes de l’entreprise signifiant que le système de secours et les procédures associées assureront les fonctionnalités métier stratégiques.

Résultats d’une étude de faisabilité à la fois pour AEM et la conception de haut niveau de la solution. Ils doivent être évalués par rapport aux IPC afin de s’assurer que ceux-ci peuvent être remplis.

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

Confirmation que les parties prenantes acceptent entièrement :

• la fonctionnalité de la solution ;
• tout problème connu dans la solution.

Chronologie et planification des activités requises pour :

• la préparation de l’activation ;
• l’activation.

Les scénarios les plus simples sont des scénarios par défaut ne comprenant aucune condition exceptionnelle ou d’erreur. Ils sont composés de la séquence d’activités exécutée lorsque tout se passe comme prévu.

Estimations initiales des éléments suivants :

• le matériel requis pour l’installation de base d’AEM ;
• toute exigence supplémentaire, en fonction de la conception de haut niveau de la solution.

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

La définition des exigences de haut niveau fournit une ventilation généralisée des exigences du système, couvrant notamment :

• les processus métier ;
• les fonctions système importantes.

Les informations de base sur ces fonctions étant généralement connues, ce document ne doit pas être une estimation.

La conception de la solution de haut niveau explique l’architecture qui sera utilisée pour développer la solution. Le schéma d’architecture fournit une présentation de l’ensemble du système, identifiant les principaux composants qui seront développés pour le produit et leurs interfaces.

Cette carte système doit fournir un schéma de très haut niveau du système. Elle se différencie du contexte de la solution en ce qu’elle constitue une carte généralisée de tous les systèmes concernés ; aucune interface n’est représentée sur ce schéma.

Définition de la structure de contenu du système hérité. Elle est utilisée pour référence, mais également lors de la préparation de la stratégie de migration.

Vous devez recueillir et documenter les statistiques et les IPC de performance du système hérité. Ceux-ci sont ensuite utilisés comme point de référence et pour l’évaluation des performances de la nouvelle solution.

Liste des fonctionnalités métier stratégiques.

Mise en œuvre de toutes les modifications requises (qui ont été approuvées) de la solution d’après les résultats des tests de pénétration.

Configuration des outils et des processus nécessaires pour prendre en charge les tests automatisés.

Configuration du jeu d’outils et des processus nécessaires pour prendre en charge l’automatisation.

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

Mise en œuvre des exigences pour prendre en charge la conception de l’expérience.

Mise en œuvre du système de secours et des procédures relatives.

Mise en œuvre des intégrations avec tous les systèmes externes requis.

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

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

Mise en œuvre de toutes les mesures de sécurité, y compris les paramètres par défaut d’AEM.

Mise en œuvre de la sécurité des applications logicielles.

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

Mise en œuvre du concept de gestion des URL.

Mise en œuvre des workflows conçus.

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

• Opérations
• Maintenance
• Compatibilité
• Réutilisation
• Sécurité
• Évolutivité

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

Contactez l’assistance d’Adobe pour vous assurer que toute prise en charge nécessaire puisse être activée pendant l’activation.

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

Test, et confirmation résultante, de toutes les intégrations, à la fois internes et externes.

Il devrait être automatisé et exécuté fréquemment pour garantir la stabilité du système.

Des processus clairs enregistrent tous les problèmes rencontrés et suivent les activités en cours dans le but de vérifier que tous les problèmes sont résolus.

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 vérifier que tous les problèmes sont résolus.

Toutes les parties prenantes du projet doivent y avoir accès pour faciliter la transparence de l’état du projet.

Des exemples incluent Atlassian JIRA et HP Quality Center.

Les outils sélectionnés sont complètement intégrés et l’accès est accordé à tous les rôles requis.

Pour votre projet, le système hérité est la technologie, le système informatique ou le programme d’application existant qui sera remplacé par la nouvelle solution.

Les détails du système hérité doivent être collectés, de manière à savoir ce qui peut être retiré et à quel moment, ainsi que l’impact sur les autres systèmes.

Description des outils qui seront utilisés dans la mise en œuvre. Ils doivent inclure :

• les outils de documentation ;
• les outils de suivi des problèmes ;
• les outils de déploiement ;
• les outils de compilation.

Liste de tous les utilisateurs et rôles qui ont besoin d’accéder au portail d’assistance d’Adobe.

La liste est généralement composée de l’architecte de la solution et/ou du personnel informatique du client.

Analyse, ainsi que les recommandations résultantes, définissant ce qui doit être consigné pour surveiller la solution :

• les activités à consigner ;
• le niveau de granularité ;
• les informations consignées pour chaque activité.

Tester et activer les tâches de maintenance d’AEM telles que :

• la compression ;
• le nettoyage du système ;
• la purge des workflows.

Documentez la migration, notamment :

• la chronologie de la migration ;
• le plan de maintenance du contenu, selon la stratégie de migration.

Une description complète du contenu existant, de l’architecture du contenu et des formats associés à la nouvelle solution. Elle doit aborder :

• les détails techniques de la migration automatisée si possible ;
• les tests de détection de fumée à exécuter après la migration pour valider le contenu migré.

Nous recommandons également de maintenir le contenu à jour (ou le plus à jour possible) au cours de la période entre la migration et l’activation du nouveau système. Il peut s’agir d’un blocage de contenu, d’une double publication ou de la maintenance d’un système alpha.

Surveillance de l’utilisation de l’unité centrale du système par la solution :

• moyenne ;
• pics.

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

• moyenne ;
• pics.

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

• moyenne ;
• croissance au fil du temps.

Vous devriez surveiller l’utilisation via :

• le référentiel ;
• les fichiers journaux.

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

• la vitesse de trafic ;
• les pics.
• la stabilité.

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

• la vitesse moyenne du trafic ;
• les pics.
• la stabilité.

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

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

Surveillez le système global, par exemple :

• la disponibilité ;
• les performances moyennes ;
• les pics de performance ;
• les alertes.

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

Les concepts de surveillance à appliquer à votre solution, y compris :

• la surveillance AEM standard ;
• la surveillance du système ;
• les exigences de surveillance spécifiques du client.

Les points spécifiques susceptibles de présenter des défaillances doivent être identifiés et définis. Toutes les tâches de surveillance associées à ces derniers doivent également être définies.

Les exemples incluent (entre autres) :

• les workflows principaux ;
• le traitement des transactions ;
• les points d’intégration.

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

Définissez :

• quand les rapports de surveillance doivent être générés ;
• à qui ils doivent être livrés.

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

Manuel fournissant toutes les informations requises pour la réussite des opérations et la maintenance de la solution :

• toutes les tâches opérationnelles ;
• les principaux contacts ;
• les plans de déploiement ;
• les listes de contrôle avant et après déploiement ;
• toutes les autres tâches critiques.

Il doit également décrire les concepts de mise en œuvre pour :

• satisfaire les IPC de performance ;
• dimensionner la solution afin de continuer à satisfaire ces IPC.

Module de l’application compilé et livré prêt pour le déploiement.

Un test de pénétration (également appelé « pen test » en anglais) est une attaque sur un système informatique qui recherche les failles de sécurité pouvant donner accès aux fonctions et aux données de l’ordinateur.

Tous les critères requis sont satisfaits.

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

Document conceptuel sur la manière de s’assurer que votre mise en œuvre satisfait les IPC de performance et de dimensionner la solution de sorte qu’elle continue à satisfaire ces IPC.

L’évaluation des performances permet de définir les tests de performances et de durabilité, ainsi que la surveillance. Pour ce faire, elle évalue les caractéristiques de performance de la solution et du matériel du système.

Ils définissent les indicateurs de performances clés (IPC) requis pour mesurer les performances du système. Il peut s’agir notamment du temps de chargement des pages, du temps de réponse du serveur, ainsi que de la performance des requêtes de la base de données.

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

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

Le test basé sur les personnages est une méthode basée sur les différents personnages décrite dans les conceptions de l’expérience. Il teste également les comptes et leurs niveaux d’autorisation associés.

Il est souvent utilisé dans les tests d’acceptation utilisateur.

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

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

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

Il est habituel d’effectuer un test de ligne de base sur une installation AEM standard. Il est alors utilisé comme une évaluation des performances par rapport à laquelle tester la mise en œuvre et le matériel.

Vérifiez que l’environnement de production est prêt, avec les déploiements automatisés en place.

Avant l’activation sur l’environnement de production, l’approbation de production doit être accordée. Elle est le résultat d’une révision de la version qui ira en production, ainsi que de tous les problèmes connus. L’approbation est donnée dans le cadre de la planification de l’activation.

Stratégie et processus requis pour obtenir l’approbation de la production avant de passer le module dans l’environnement de production.

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

Les estimations initiales étaient de haut niveau et établies selon les exigences de haut niveau pour 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 livrées par chaque responsable de projet approprié, y compris la gestion de projets, le consulting, l’architecture, le test et le développement.

Ces estimations sont utilisées pour la gestion des ressources et la budgétisation.

Les estimations initiales sont de haut niveau et établies selon les exigences de haut niveau pour la mise en œuvre. Elles seront révisées et affinées ultérieurement.

La documentation nécessaire pour décrire l’organisation et la structure hiérarchique du projet et de l’équipe.

Prend souvent la forme d’un graphique, ou inclut un graphique, pour fournir une présentation visuelle des chronologies et des responsabilités. Il existe de nombreux outils disponibles pour vous y aider.

Le document sur la portée du projet requiert que vous identifiez et documentiez une liste incluant les éléments suivants :

• Objectifs spécifiques au projet
• Éléments livrables
• Fonctionnalités
• Fonctions
• Tâches
• Échéances
• Effort attendu

Il explique ce qui doit être atteint, ainsi que le travail à réaliser pour livrer le projet.

Les rapports sur l’état du projet livrés selon la planification convenue et dans le format requis.

La preuve de concept met en œuvre un choix limité de fonctions pour la solution.

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

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 préserver l’intégrité et la taille du référentiel.

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

Le chef de projet coordonne tous les rôles requis pour la publication en production.

Les notes de mise à jour font partie de la documentation de la version. Elles doivent englober :

• les conditions préalables ;
• les exigences incluses ;
• les problèmes résolus ;
• les problèmes connus de la version.

Elles sont utilisées avec le runbook pour effectuer des étapes et des vérifications avant et après installation.

Version finale exécutée et active en production.

Vous devez mettre en évidence les conditions spécifiques du contrat qui sont pertinentes pour la mise en œuvre du projet, comme les jalons contractuels, les périodes de facturation ou les exigences en matière de personnel.

Avec le client, définissez la fréquence des rapports à leur remettre.

Les données ne sont jamais remplacées dans un fichier tar ; l’utilisation du disque augmente même si vous mettez uniquement à jour des données existantes.

Pour contrebalancer la taille en croissance perpétuelle du référentiel, une stratégie d’optimisation est mise en place de façon à supprimer les données obsolètes.

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

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

Assurez-vous que tous les rôles requis pour l’activation sont remplis et disponibles.

L’évaluation des risques est exécutée par le ou les départements informatique et/ou de sécurité du client.

Elle évalue les risques techniques et métier du projet. L’évaluation est requise pour assurer la conformité de la solution aux stratégies de sécurité.

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

• les risques identifiés ;
• les solutions possibles à ces risques s’ils surviennent dans la mise en œuvre.

Définissez les attentes en termes de retour sur investissement associées à la solution.

Elles ont pour but d’indiquer l’efficacité de la solution en termes économiques en définissant les bénéfices/profits estimés par rapport aux investissements prévus.

Spécification détaillée des concepts associés aux rôles et aux droits d’accès requis pour la nouvelle application, y compris une description de haut niveau des :

• rôles ;
• groupes ;
• utilisateurs ;
• autorisations ;
• ainsi que la gestion et l’approvisionnement des utilisateurs.

Passez en revue le concept de rôles et de droits pour vous assurer qu’il respecte les stratégies de sécurité. 

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

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

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

• les conventions d’attribution de noms ;
• les bibliothèques ;
• les consignes pour les structures ;
• l’utilisation des API.

Liste de contrôle spécifique au projet, basée sur le concept de sécurité ainsi que toute stratégie supplémentaire nécessaire pour assurer la conformité de la solution.

Elle est souvent également incluse dans le cadre des étapes de post-déploiement au sein du runbook.

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

Une description de haut niveau de la configuration de sécurité de :

• l’application ;
• l’architecture ;
• l’infrastructure.

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

Approbation des parties prenantes pour garantir que la mise en œuvre de la sécurité est conforme aux stratégies et aux attentes.

Mettez en place les processus de prise en charge requis.

Assurez-vous que les contrats de niveau de service sont disponibles et transmis aux équipes de développement et des opérations pour qu’elles puissent les utiliser lors de la mise en œuvre et de l’assistance.

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

Ils sont exécutés sur n’importe quel environnement après l’installation ou le déploiement. 

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

Stratégie de haut niveau de l’architecture logicielle, incluant les services, les servlets, les structures et d’autres décisions de mise en œuvre.

Le conseil d’examen de la solution est généralement constitué des parties prenantes du côté client.

Le conseil organise des réunions régulières pour passer en revue de manière continue les exigences en cours d’étude et les spécifications pertinentes. L’objectif est de garantir la concordance avec la définition et les critères de réussite, et de fournir des suggestions dans le cadre du développement des exigences.

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

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 initial pour toute fonctionnalité spéciale qui est considérée comme étant en dehors de la portée normale du développement sur la plate-forme AEM.

Détails de toute fonctionnalité spéciale qui est considérée comme étant en dehors de la portée normale du développement sur la plate-forme AEM.

Toutes les consignes sur la manière dont la spécification doit être effectuée.

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 interne qui doit être formé pour administrer la solution.

Personnel interne qui doit être formé pour créer dans la solution.

Les parties prenantes sont les personnes et/ou les rôles clés qui ont un impact significatif sur le projet. Certaines contribueront au budget du projet. 

Les parties prenantes peuvent être internes et/ou externes. 

Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre ont connaissance :

• des définitions de réussite ;
• des critères de réussite.

Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont alignées sur l’ensemble du projet et des attentes, à la fois en interne au sein de l’équipe de projet et chez le client.

Les rapports d’état sont un outil de communication clé. Le format doit être aligné sur toutes les exigences du client en ce qui concerne la création de rapports.

Le client, le sponsor du projet et le chef de projet ou le consultant doivent spécifier :

• ce qui définit la réussite du projet ;
• les critères spécifiques nécessaires pour satisfaire à cette définition de réussite.

Ils sont utilisés pour vous assurer que les critères de réussite sont remplis :

• comme base pour les IPC ; 
• lorsque vous prenez des décisions pour toute la mise en œuvre.

L’une des responsabilités du responsable de la qualité est de s’assurer qu’il existe des ressources disponibles pour assister tout utilisateur lors des tests. Par exemple, afin d’aider l’utilisateur au cours des tests, lors du signalement des problèmes et afin d’aider à valider les problèmes par rapport à l’environnement de test.

L’accès au portail d’assistance d’Adobe est indispensable pour soumettre des tickets concernant tout problème concernant le produit qui peut se poser lors de la mise en œuvre. 

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

Proposition et définition initiales de l’architecture pour tous les environnements de la solution.

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

Description de haut niveau de la façon de rendre l’architecture du système conforme à toutes les stratégies de sécurité. Cela peut couvrir :

• les pare-feu et règles de pare-feu ;
• les zones de sécurité ;
• les gestionnaires de trafic locaux et généraux ;
• les serveurs web ;
• les proxys et proxys inverses.

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

• le niveau de risque implicite de chacun ;
• ainsi que les efforts estimés pour les éventuelles modifications de la mise en œuvre requises pour les résoudre.

Confirmation que l’ensemble de l’équipe est consciente des définitions et des critères de réussite.

Confirmation que tous les membres de l’équipe savent qui doit communiquer avec le client, comment et à quel moment.

Alignement avec l’ensemble du projet et des attentes, à la fois internes au sein de l’équipe de projet et chez le client.

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

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

• les scripts intersite ;
• les champs de saisie pour l’utilisateur final ;
• l’infrastructure ;
• l’âge des technologies ;
• le nombre d’intégrations ;
• et les dépendances.

Les spécifications techniques abordent (entre autres informations) :

• les interfaces ;
• les configurations ;
• les API ;
• les services qui prennent en charge les exigences de la solution.

Spécifications des modèles requis. Elles doivent englober les détails, y compris le système de paragraphe (parsys), le plan directeur et le mappage d’héritage, entre autres.

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

Les cas de test spécifient les étapes détaillées nécessaires pour exécuter le test fonctionnel de la solution.

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

Assurez-vous que l’environnement de test est prêt, avec les déploiements automatisés en place afin de vous assurer que tout le code de la version finale (RC) est à jour à des fins de test.

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

• les défauts signalés ;
• l’état des cas de test exécutés ;
• les autres remarques relatives à la qualité.

Il convient de noter les informations suivantes :

• N’importe quelle équipe de test devrait pouvoir rester neutre et fournir les résultats de test.
• Il est de la responsabilité du chef de projet d’évaluer toutes les implications des résultats et de décider de l’action appropriée. 

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

Outils et suite d’automatisation sélectionnés pour l’automatisation de cas d’utilisation et d’autres tâches d’exécution des tests.

Le concept de test est la description de très haut niveau des tests du projet, notamment, l’assurance qualité, ainsi que les tests d’acceptation par les utilisateurs, de performance, de sécurité et d’intégration.

Ces plans décrivent en détail l’exécution des tests pour chaque phase du développement et sont basés sur la stratégie de test.

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

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 fréquence des rapports et l’exécution.

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

Détails des exigences (fonctionnelles et non fonctionnelles) pour la prise en charge de la fonctionnalité et de l’intégration des systèmes tiers.

Concept pour garantir la sécurité de toutes les intégrations tierces. Doit être compatible avec les stratégies de sécurité appropriées.

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

Droits d’accès requis octroyés aux rôles correspondants utilisés conjointement avec les systèmes tiers.

Définit :

• les cas d’utilisation pour tester les intégrations ;
• les fonctionnalités associées à toute application tierce.

Définit les valeurs clés des points de surveillance au sein du système.

Par exemple :

• le nombre de kilo-octets (Ko) de journaux non envoyés génère un avertissement sur l’instance de serveur principale ;
• le nombre de millisecondes de délai moyen par transaction tolérées avant qu’un avertissement ne soit généré sur le serveur principal.

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

• la facturation ; 
• la concordance aux définitions et critères de réussite, ainsi qu’aux IPC.

Toutes les estimations des efforts de chacun des responsables du projet doivent être consolidées, notamment les efforts de surcharge, de développement, d’ingénierie système, d’architecture et de test.

S’il existe un niveau d’assistance inclus dans l’accord, les efforts de prise en charge et de production doivent également être inclus.

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

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

• la portée du projet ;
• toutes les attentes des clients ;
• qu’il s’agit de la base de toutes les décisions prises par personnage et par phase dans le projet.

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

• les URL de redirection vers un microsite ;
• l’externalisation des liens ;
• les pages d’erreur ;
• le mappage.

Le concept doit également inclure :

• toute règle de réécriture ;
• les hôtes virtuels sur le serveur web ;
• les considérations relatives à l’optimisation pour les moteurs de recherche, telles que robots.txt ;
• un plan de site.

Un cas d’utilisation constitue la liste des actions ou des étapes d’événements 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.

Les scénarios de test sont basés sur les cas d’utilisation techniques et métier. Ils sont utilisés pour tester que le comportement de la solution fonctionne comme prévu.

Les guides de l’utilisateur fournissent des informations et de l’assistance pour les utilisateurs de la solution :

• les créateurs ;
• les utilisateurs avancés ;
• les administrateurs.

Le plan budgétaire doit être révisé et validé par toutes les parties prenantes. Elles doivent vérifier les informations comme la facturation, les montants et les méthodes/échéances des rapports sur le budget.

Les tests boîte blanche suivent une méthode qui examine les structures ou mécanismes internes d’une application, par opposition à sa fonctionnalité. Les tests boîte blanche peuvent être appliqués au niveau des unités, de l’intégration et des systèmes du processus de test logiciel.

Basées sur le concept des workflows, ces spécifications doivent définir, en détail, les étapes qui créent le workflow complet.

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

• un cas d’utilisation ;
• les rôles ;
• les étapes ;
• les résultats ;
• la gestion des erreurs.

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

• les processus qui auront besoin d’une automatisation ;
• les services et les rôles dans AEM qui seront affectés.