Glossaire

Ce glossaire présente les listes (alpabetiquement) de tous les documents livrables figurant dans la liste de vérification du projet.

Acceptation des parties prenantes

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.

Tests d’acceptation

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

Accès au système de test coordonné

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

Liste de contrôle de sécurité d’Adobe

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.

Configuration du projet de portail d’assistance à la clientèle Adobe

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 pour les administrateurs AEM

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

Formation pour les auteurs AEM

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

Examen de certification AEM

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

Certifié AEM

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

Formation technique AEM

dispenser une formation technique à la personne concernée ; par exemple, les développeurs, les architectes, les ingénieurs et les professionnels du monde des affaires.

Accord sur les indicateurs de performances clés, définis comme les objectifs du projet

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.

Alignement des indicateurs de performances clés métier et relatifs aux performances

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

Alignement de l’architecture de contenu avec les IPC

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

Alignement de la feuille de route du client avec la chronologie du projet

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.

Définition de l’architecture des applications

L'architecture d'application 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.

Tâches de maintenance spécifiques aux applications définies

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.

Personnel correctement formé

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

Schéma d’architecture

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.

Brouillon d’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.

Approbation du conseil d’examen de l’architecture

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

• supervise la mise en oeuvre 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.

Suite de test automatisée adaptée au contenu réel et résultats comparés aux IPC

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

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

Stratégie de test automatisé

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

Stratégie de test automatisé validée par rapport à une charge réaliste et attendue

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

Stratégie d’automatisation

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.

Connaissance du plan de communication

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.

Connaissance des définitions et des critères de réussite

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.

Concept de sauvegarde et de restauration

Le concept de sauvegarde et de restauration décrit les fonctionnalités techniques qui seront mises en œuvre dans la solution. Elle est requise par la politique de sauvegarde et de restauration de la Société.

Sauvegarde et restauration testées

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

Étude(s) de cas

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 comprend la portée du projet et les attentes

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.

Indicateurs clés de performances métier

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.

Documentation des exigences de l’entreprise

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 commerciale, la BRD doit répondre à la question suivante :
"Que veut faire l'entreprise ?"

Validation par l’entreprise de tous les réglages nécessaires de la solution ou de l’architecture identifiée et alignée par rapport aux attentes de retour sur investissement et d’IPC

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.

Stratégie de mise en cache

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.

Consignes de codage

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.

Communication du manuel des opérations

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

Communication du rapport de test de performances

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

Communication des notes de mise à jour

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

Communication de la portée et des attentes à l’équipe

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.

Communication des documents de formation et des guides de l’utilisateur

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

Conformité aux exigences de sécurité des clients

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

Conformité au concept de sécurité

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

Concept de relation entre les composants et les modèles

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.

Spécification de la relation entre les composants et les modèles

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

Spécification des composants

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

Concept pour les maquettes des interfaces externes

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.

Document d’architecture de contenu

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.

Contenu validé pour migration

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

Version préliminaire du contrat

Une version initiale du contrat juridique.

Structure et format du contenu actuel

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égie de sauvegarde et de restauration du client

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.

Consignes du client concernant le codage

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

Stratégies du client pour le déploiement/la publication de version

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 ou exigences du client concernant la surveillance

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.

Planification du client pour la publication de versions de production

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

Stratégies et exigences du client concernant les rapports

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.

Feuille de route du client

É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

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.

Consignes du client concernant les spécifications

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

Rapports de test du client

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

Personnalisations et correctifs qui affectent les mises à niveau documentés

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, toute modification majeure apportée à l’interface utilisateur de l’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.

Rapport quotidien de test d’acceptation utilisateur

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.

Sécurité par défaut activée

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

Stratégies et processus de déploiement/publication de version

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.

Cadence de déploiement établie

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

Méthodologie de développement

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éfinition des rôles de développement

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

Environnement de développement prêt

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

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.

Spécification des boîtes de dialogue

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

Documentation de l’environnement de développement

Documentation de l’environnement de développement.

Documentation de l’environnement de production

Documentation de l’environnement de production.

Documentation de l’environnement de test

Documentation de l’environnement de test.

Test de durabilité

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.

Test de durabilité exécuté

Exécution du ou des tests de durabilité.

Concept de gestion des erreurs

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 de la gestion des erreurs

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

Processus de réaffectation

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

• Équipe du projet
• Client
• Adobe

Organisation de sessions régulières d’examen de la qualité

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

Structure des autorisations existantes

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

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

Définitions et critères de réussite attendus

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 celles-ci devraient influencer toutes les décisions prises tout au long de la mise en oeuvre.

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 ;
• objectifs de niveau supérieur, tels qu’une interface conviviale

Exigences de conception de l’expérience

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.

Spécifications de l’expérience

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

Système externe et dépendances des utilisateurs/contexte système

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.

Système et procédure de secours

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.

Système et procédure de secours testés

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

Approbation du système de secours par les parties prenantes de l’entreprise

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.

Confirmation de la faisabilité des IPC

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.

Contrat finalisé

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

Fonctionnalité de la solution acceptée par les parties prenantes

Confirmation que les parties prenantes acceptent entièrement :

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

Planification de l’activation

Chronologie et planification des activités requises pour :

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

Scénarios les plus simples définis

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 concernant le matériel

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.

Le matériel sera mis à disposition pour remplir les exigences

Confirmation que tous les environnements auront le matériel minimum requis en place.

Exigences de haut niveau

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.

Conception de la solution de haut niveau

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.

Carte système de haut niveau

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.

Structure de contenu historique

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.

Performance historique et IPC de performance historique

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.

Identification des solutions et fonctionnalités essentielles

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

Mise en œuvre – Modifications basées sur les résultats des tests de pénétration

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.

Mise en œuvre – Stratégie de test automatisé

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

Mise en œuvre – Stratégie d’automatisation

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

Mise en œuvre – Architecture de contenu

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

Mise en œuvre – Conception de l’expérience

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

Mise en œuvre – Système et procédures de secours

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

Mise en œuvre – Intégration

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

Mise en œuvre – Stratégie de migration

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

Mise en œuvre – Rôles et droits

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

Mise en œuvre – Concept de sécurité

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

Mise en œuvre – Logiciel de sécurité

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

Mise en œuvre – Concept de sécurité de l’architecture du système

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

Mise en œuvre – Gestion des URL

Mise en œuvre du concept de gestion des URL.

Mise en œuvre – Workflows

Mise en œuvre des workflows conçus.

Concept de mise en œuvre

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.

Informer l’assistance d’Adobe de la planification d’activation

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

Conceptions de première expérience

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

Test d’intégration

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.

Processus de suivi des problèmes

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.

Système et processus de suivi des problèmes

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.

Le processus de suivi des problèmes est configuré et intégré

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

Système hérité

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.

Liste des outils de développement à utiliser

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 des utilisateurs qui ont besoin d’un accès au portail d’assistance d’Adobe

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 de fichier journal

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

Tâches de maintenance (spécifiques à AEM) testées et activées

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

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

Plan de migration

Documentez la migration, notamment :

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

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 – Unité centrale

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

• moyenne ;
• pics.

Surveillance – E/S de disque

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

• moyenne ;
• pics.

Surveillance – Espace disque

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.

Surveillance – Systèmes externes

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

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

Surveillance – Bande passante réseau

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

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

Surveillance – Requêtes

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

Surveillance – Points de sécurité

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

Surveillance – Système

Surveillez le système global, par exemple :

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

Surveillance – Seuil et intervention

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

Concept de surveillance

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.

Surveillance des points faibles potentiels

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.

Stratégie de surveillance communiquée à l’ingénieur système

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

Rapports de surveillance – Structure en place

Définissez les éléments suivants :

• lorsque des rapports de surveillance doivent être générés
• à qui ils doivent être livrés.

Documentation des tâches opérationnelles

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

Manuel des opérations

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 préparé

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

Tests de pénétration

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.

Tests de pénétration – Réussis

Tous les critères requis sont satisfaits.

Tests de pénétration – Résultats

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

Concept de performance et d’évolutivité

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.

Évaluation des performances

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

IPC de performances

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.

Tests de performance – Rapport

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

Tests de performance – Les résultats correspondent aux IPC de performances

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

Concept de test basé sur les personnages

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.

Preuve de concept testée et vérifiée par rapport à la documentation des exigences

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 post-déploiement

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 prédéploiement

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

Tests de performance de ligne de base en environnement de production

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.

Environnement de production prêt

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

Approbation de la production par les parties prenantes de l’entreprise

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.

Processus et stratégie d’approbation de la production

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

Plan de communication du projet

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

Efforts du projet – Estimations finales

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.

Efforts du projet – Estimations initiales

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.

Organisation du projet

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.

Document sur la portée du projet

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
• Fonctions
• Fonctions
• Tâches
• Échéances
• Effort attendu

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

Rapports sur l’état du projet dans une cadence définie

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

Preuve de concept (PDC)

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.

Règles de purge

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.

Format et cadence du rapport de qualité

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

Publication coordonnée

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

Notes de mise à jour

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.

Exécution de la version dans l’environnement de production

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

Conditions de contrat appropriées

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.

Fréquence des rapports

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

Optimisation du référentiel

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 de configuration de la section du projet sur le portail d’assistance d’Adobe

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

Documentation sur les besoins

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

Ressources disponibles pour supporter l’activation

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

Évaluation des risques

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

Plan d’atténuation des risques

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

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

Attentes en termes de retour sur investissement

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.

Concept de rôles et de droits

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.

Le concept de rôles et de droits satisfait aux consignes de sécurité

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 des rôles et des droits

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

Recommandations relatives à l’architecture de sécurité

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

Consignes de codage basées sur la sécurité

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 de sécurité

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.

Concept de sécurité

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é

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

• l’application ;
• Architecture
• l’infrastructure.

Problèmes de sécurité répertoriés et évalués

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

Approbation de la sécurité par les parties prenantes de l’entreprise

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

Mise en place des processus de prise en charge

Mettez en place les processus de prise en charge requis.

Contrats de niveau de service pour les systèmes tiers

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.

Concept de test de détection de fumée

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.

Tests de détection de fumée exécutés pour la validation du système

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 l’architecture logicielle

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.

Conseil d’examen de la solution établi et fréquence des réunions définie

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.

Runbook de la solution

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

Approbation de la solution et processus d’acceptation

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

Il peut également servir de jalon contractuel.

Concept de fonctionnalité spéciale

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.

Spécification des fonctionnalités spéciales

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.

Consignes relatives à la spécification

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

Processus de révision des spécifications et d’approbation défini et communiqué

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

Personnel interne qui doit être formé pour administrer la solution.

Personnel sélectionné pour la formation des auteurs et utilisateurs finaux

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

Parties prenantes

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.

Les parties prenantes ont connaissance des définitions et des critères de réussite

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.

Les parties prenantes comprennent le projet et les attentes

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.

Définition du format du rapport d’état

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.

Critères et définition de réussite

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.

Assistance pour la validation des problèmes signalés

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.

Processus d’assistance et accès au portail d’assistance d’Adobe

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.

Définition de l’architecture du système

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

Documentation de l’architecture du système

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.

Concept de sécurité de l’architecture du système

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.

Facteurs de risque du système identifiés et vérifiés

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 impliqué dans chacune d'elles
• ainsi que les efforts estimés pour les éventuelles modifications de la mise en œuvre requises pour les résoudre.

L’équipe a connaissance des définitions et des critères de réussite

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

L’équipe a pris connaissance du plan de communication

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

L’équipe comprend le projet et les attentes

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

Exigences techniques

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

Facteurs de risque techniques vérifiés

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 dépendances

Spécifications techniques

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

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 opérationnelles et les exigences d’expérience.

Cas de test

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

Contenu du test

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

Environnement de test prêt

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 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 éléments suivants :

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

Suite de tests

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.

Suite d’outils de test sélectionnée

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.

Concept de test

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.

Plans de test

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.

Portée de test

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

Stratégie de test

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 d’intégration tierce

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

Spécifications d’intégration tierce

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 de sécurité tierce

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

Système tiers pour l’intégration

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.

Accès aux systèmes tiers activé

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

Concept de test tiers

Définit :

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

Définition du seuil

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.

Chronologie et jalons

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.

Total des efforts du projet

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 de formation

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.

Comprend la portée du projet et les attentes

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.

Concept de gestion des URL

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.

Cas d’utilisation

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.

Cas d’utilisation convertis en scénarios de test

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.

Guides de l’utilisateur

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.

Plan budgétaire validé

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.

Résultats des tests boîte blanche

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.

Spécifications de workflow

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.

Concept des workflows

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.